Threat Hunting and HTML Response Size
Imagine that you are sitting at your workstation at work and you notice that your environment is experiencing a higher than usual HTML response size coming from your database that contains credit card information of your clients. You think that this may be caused by data exfiltration by an attacker. What should you do? This article will explore the relationship between threat hunting and HTML response size and what you as an Information Security professional can do about it.
Indicators of Compromise
Indicators of Compromise, or IoCs, are pieces of forensic data “breadcrumbs” that Information Security professionals use to track down potential threats in their environments. This normally translates to odd or unusual activity on a network and systems that can help you spot an attacker quickly and easily so that appropriate action can be taken to mitigate and neutralize the threat.
HTML Response Size as an Indicator of Compromise
HTML Response Size is an important IoC to take into consideration when threat hunting. In fact, according to a McAfee Labs Threat Report, HTML Response Size was used by 44% of threat hunters as an IoC that they rely upon when conducting a threat investigation. Of all data to be concerned with, why is HTML Response Size So Important?
According to Kyle Adams, Chief Software Architect for Junos WebApp Secure at Juniper Networks, the answer is quite simple. If the attackers use SQL injection to extract data through a Web Application, requests issued by the Web Application will issue responses that are markedly larger than what is normally issued. For example, your HTML response size is normally around 260 KB and what you are looking at is 50MB. This is easy to spot and should be a red flag for threat hunters.
SQL Injection is one of the main methods by which attackers can siphon your data away. A SQL Injection attack is where attackers add SQL code to a form input box in a Web Application giving them access to data resources. While SQL injection attacks are simple in their form and structure, they take advantage of security exploits that a Web Application contains, and any well-designed Web Application will not have these vulnerabilities but unfortunately many still do.
OK so SQL Injection is still a high severity threat, and you think that your environment may be a victim. Where should you look?
Web Server Logs
Web Server Logs are a great source of data related to activity on the server. The data gets stored in the logs in raw log form, and when you are threat hunting within this data you should be looking for:
- Compare the HTML responses sent by your Web Application during the time of the suspected attack against the size of the HTML responses that are normally present. Has there been a large increase in the size of the HTML files? If so, that means that the attackers are searching for security vulnerabilities in the Web Application and they are reading what is coming back to them by way of the HTML responses that it issues. Essentially, attackers are searching for a form input box that will let them deposit its line of SQL code. If you see this, chances are it is a legitimate threat in action.
- Check for 500 Internal Server Errors and 501 Header Value errors in the Web Server Logs. These errors can indicate that the attackers are trying generated more and larger HTML responses, so they can find out more about potential security vulnerabilities of the Web Application.
The drawbacks of using Web Server Logs are that raw log files are difficult to use for most Information Security professionals and that the data is easily manipulated and changed by attackers who are looking to go the extra mile in hiding their tracks.
Log Analyzers and Security Information and Event Management software (SIEM) are another great way to threat hunt for Web Application HTML responses with larger than normal sizes. These tools collect and aggregate the data that comes through the network, including traffic generated by Web Application responses. Then, this data is made usable for the administrator or tech tasked with threat hunting. Graphical interfaces and dashboards allow even the most inexperienced Information Security professional to use and make sense of the data, patterns, and trends it collects.
A great example of a Log Analyzer/SIEM is SolarWinds Log and Event Manager, or LEM. LEM collects and correlates all the data that comes across the network via the use of installed agents on the domain controllers, servers, and network devices (such as Cisco ASA) so that the data can be analyzed from the big picture view all the way down to the nitty gritty granular.
LEM is specifically equipped to analyze for threats based on HTML response size. This is done by monitoring the responses that Web Applications generate for spikes in size and then it flags the traffic as being suspicious. The near real-time data is then presented in a graphical format allowing the threat hunter to either act or wait for more correlation before acting.
HTML Response Size is a common Indicator of Compromise that threat hunters can use in their investigation. If you suspect this is occurring on your network, check the logs in your Web Server to narrow down when the attack occurred and where it came from. If you prefer to not work with the raw log data, go to your log analyzer/SIEM and use its convenient graphical interface to track down the threat.