In-memory attacks are on the rise and attracting increasing attention, as reported, for example, in these posts, SentinelOne: In memory attacks loom large, leave little trace, Hunting in memory, and Hunting for in-memory .NET attacks.
These attacks involve the attacker carrying out malicious activities entirely in-memory, rather than writing a file to disk – as is common with more traditional Trojans or implants found in many malware infections. The CSO article titled "How hackers invade systems without installing software" provides a good overview.
Detection can be challenging because in-memory attacks often leave little to no footprint in many of the standard operating system event logs. Although many anti-virus solutions support some level of in-memory protection, they are often most-effective at detecting threats in malicious files on disk – and there are none in the in-memory scenario.
In this post, we will describe two in-memory attack techniques and show how these can be detected using Sysmon and Azure Security Center.
The attack
The attacker strategy in this example is as follows:
The first two stages of this attack chain involve in-memory techniques:
Initial compromise – process injection
The victim is tricked into enabling macros in a Microsoft Office Word document delivered via email.
#Hancitor is such an example threat – it uses a macro to inject into verclsid.exe. The malicious code is copied directly into the verclsid.exe process space so never touches the disk. Because verclsid.exe is a trusted Windows process, its activity is unlikely to be blocked by intrusion detection products.
Evade future detection – process interference
After gaining a foothold on the victim machine, the attacker quickly takes steps to limit the likelihood of future detection.
Invoke-Phant0m uses inter-process Windows API calls to find and terminate the threads associated with the Windows Event Log service. The service will still appear to be running – but it will no longer be writing events to the event log.
The attacker is now free to carry out other actions, safe in the knowledge that most of that activity won’t get logged.
Detect in-memory attacks using Sysmon and Azure Security Center
By collecting and analyzing Sysmon events in Security Center, you can detect attacks like the ones above. To enable these detections, you must:
- Install Sysmon on cloud and on-premises machines
- Collect Sysmon event data in your Log Analytics workspace
-
Define custom alerts in Security Center to detect suspicious Sysmon events
Sysmon installation and configuration
Both the attack techniques discussed involve one process accessing another process’ memory. This basic operation happens all the time as part of normal OS operations, but the kinds of access involved here are unusual (write privilege, rather than the more typical read privilege) as are the target processes whose memory is being modified (verclsid.exe and svchost.exe).
Sysmon can log such process accesses in a highly configurable way. It can be downloaded and installed from documentation. The Sysmon configuration is key as it determines the level and volume of logging.
The precise configuration desired will be highly customer dependent – indeed part of the rationale for Sysmon is to provide customers the flexibility to choose a very granular level of logging that goes beyond the OS defaults. There are online resources with suggested default Sysmon configurations – @SwiftOnSecurity has published a good example on GitHub.
The following configuration logs only privileged levels of memory access to specific processes. This will typically be very low volume, with Sysmon events only being logged in the event of attacker activity:
exampleSysmonConfig.xml:
<Sysmon schemaversion="3.30">
<EventFiltering>
<!-- Restrict logging to access targeting svchost.exe and verclsid.exe -->
<ProcessAccess onmatch="exclude">
<TargetImage condition="excludes">verclsid.exe</TargetImage>
<TargetImage condition="excludes">svchost.exe</TargetImage>
</ProcessAccess>
<!-- Process access requests with suspect privileged access,
or call trace indicative of unknown modules -->
<ProcessAccess onmatch="include">
<GrantedAccess condition="is">0x1F0FFF</GrantedAccess>
<GrantedAccess condition="is">0x1F1FFF</GrantedAccess>
<GrantedAccess condition="is">0x1F2FFF</GrantedAccess>
<GrantedAccess condition="is">0x1F3FFF</GrantedAccess>
...
<GrantedAccess condition="is">0x1FFFFF</GrantedAccess>
<CallTrace condition="contains">unknown</CallTrace>
</ProcessAccess>
</EventFiltering>
</Sysmon>
Installation is then performed via:
sysmon.exe -i exampleSysmonConfig.xml
Or: sysmon64.exe -i exampleSysmonConfig.xml (for the 64-bit version)
When the attacks above are executed, Sysmon logs a type 10 ‘ProcessAccess’ event like:
Enable collection of Sysmon event data
Azure Security Center collects a specific set of events to monitor for threats. Collection of additional data sources – such as Sysmon events – can be configured from the Azure portal: open the Log Analytics workspace, and select Advanced Settings.
Data sources in log analytics provide details on how to import many types of data for analytics. In the case of Windows event data, simply specify the path to the event log as shown below. For Sysmon event collection, you simply add:
Microsoft-Windows-Sysmon/Operational:
The Microsoft Monitoring Agent will now collect Sysmon events for all machines connected to this workspace. It just remains to put in place some alerting based on this data.
Define a custom alert in Azure Security Center
In the example Sysmon configuration above, the only events logged are very likely malicious. Therefore, we can alert on any ProcessAccess events that are collected.
Open Security Center in the Azure portal, select Customer Alerts and New Custom Alert Rule, specify the alert details, and use the following query for any type 10 Sysmon events:
search "Microsoft-Windows-Sysmon/Operational" | where EventID==10
View alerts in Security Center
The attacks from the first section are now detected, with the resulting alerts raised in Azure Security Center along with other built-in alerts:
Refinement – more granular alert queries
You may want to create alerts based on specific criteria in the Sysmon event rather alerting on all events that are collected. This can be achieved by creating custom fields and then defining alert rules based on a query of these fields.
Summary
In this post, we described how Sysmon can be used to detect several in-memory attacks and shown how alerting based on this data can be put in place and surfaced in Azure Security Center – whether for an Azure virtual machine or an on-premises machine.
Happy hunting!
Further reading
- Phant0m: Killing Windows Event Log – May 6th 2017
- Data collection in Azure Security Center - Microsoft Azure documentation, September 11th 2017
- Data sources in log analytics – Microsoft Azure documentation, May 23rd 2017
- Custom alert rules in Azure Security Center (Preview) – Microsoft Azure documentation, Sept 18th 2017
- Simplify hybrid cloud protection with Microsoft Azure Security Center – Sarah Fender, Meital Taran-Gutman – Ignite 2017
- System Monitor (Sysmon) – Mark Russinovich and Thomas Garnier
- Advanced Incident Detection and Threat Hunting using Sysmon (and Splunk) – Tom Ueltschi, Swiss Post CERT, Presented at FIRST2017
- Splunkmon – taking Sysmon to the Next Level – Alec Randazzo, Thomas Aneiro and James Espinosa, Crypsis
- Tales of a threat Hunter 1 – Eideon, 9th September 2017