Detecting in-memory attacks with Sysmon and Azure Security Center

In-memory attacks are on the rise and attracting increasing attention. In this post, we will describe two in-memory attack techniques and show how these can be detected using Sysmon and Azure Security Center.

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-attack The first two stages of this attack chain involve in-memory techniques:

Initial compromise – process injection

office

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

Phantom

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:


  
  
    verclsid.exe
    svchost.exe
  
  
     
         0x1F0FFF
         0x1F1FFF
         0x1F2FFF
         0x1F3FFF
             ...
         0x1FFFFF
         unknown

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:

sysmon

Enable collection of Sysmon event data

Log Analytics

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:

advanced-settings

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:

alerts-security-center

suspect-process

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!