This blog was reviewed by Ben Nick (Senior Program Manager), Tino Morenz (Senior Software Engineer), Abhishek Singh (Senior Software Engineer) and the Fileless Attack Detection Dev Team.
In October 2018 we announced a new detection capability for Azure Security Center that targets fileless attacks on Windows machines. When Security Center detects this type of attack, it triggers an alert. This alert contains important details to help responders better understand the attack pattern and behavior.
This capability uses memory forensic techniques to cover a wide range of fileless attack behaviors, including: shell code, injected modules, and obfuscation techniques that you can read about here.
While the information that is exposed in the alert is useful for understanding what activity is present in a compromised process, it may not give you the entire answer of how that process came to be compromised. This is especially true if multiple processes are involved. For this reason, it is important to enable audit policies Process Creation (Event 4688) and the CommandLine field inside event 4688. For more information about Process Creation Event 4688 and general Audit Policy recommendations, read this article.
In this scenario, Contoso’s Incident Response Team identifies an alert in Security Center that has the following information:
Cobalt Strike is a feature-rich penetration testing tool that provides remote attackers with a wide range of capabilities, including escalating privileges, capturing user input, executing arbitrary commands through PowerShell or WMI, performing reconnaissance, communicating with C&C servers over various protocols, and downloading and installing additional malware. Microsoft Security Intelligence already reported the use of this tool in different campaigns.
To better understand what happened here we need to navigate throughout the other fields in this alert, and there we will find:
Based on the information available in the alert, we can interpret that the attacker compromised the system, and started rundll32.exe in suspended mode, injected their payload into the process, changed the entry point for the process to point to their payload, and started running the process. This interpretation is possible because of the following facts:
As far as who injected the thread into the process, given the proximity of Process Creation time and Thread Creation time, and the fact that rundll32 would have had to be started in suspended mode, it’s likely that the parent process did indeed do the injection. Unfortunately, we don’t have more than the parent PID in this case, possibly because the attacker had already killed that parent process to avoid detection.
What to do next?
After reading the alert details, and understand what it was done, you can start by following the remediation steps provided by this alert, which are:
Some of these steps may not be possible in some circumstances, such as the step number 2, since in this particular case, when the Contoso IR Team arrived the compromised Server was restarted already. If the machine was still running, you could use the instructions from this article to obtain a user-mode dump.
If Security Center is monitoring your Windows Servers (supported versions here), you will also have Windows Server Defender ATP, since it will be automatically deployed by ASC. Windows Server Defender ATP has more analytics which can give more information about this type of attack. Read the article Out of sight but not invisible: Defeating fileless malware with behavior monitoring, AMSI, and next-..., for more information on how Microsoft Defender ATP can be used to not only detect, but to stop fileless attacks. For more information about how ASC uses memory forensic techniques to perform fileless attack detection see this article.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.