{"id":3333,"date":"2017-11-02T00:00:00","date_gmt":"2017-11-02T00:00:00","guid":{"rendered":"https:\/\/azure.microsoft.com\/blog\/detecting-in-memory-attacks-with-sysmon-and-azure-security-center"},"modified":"2025-06-26T07:43:06","modified_gmt":"2025-06-26T14:43:06","slug":"detecting-in-memory-attacks-with-sysmon-and-azure-security-center","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/detecting-in-memory-attacks-with-sysmon-and-azure-security-center\/","title":{"rendered":"Detecting in-memory attacks with Sysmon and Azure Security Center"},"content":{"rendered":"\n

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<\/a>, Hunting in memory<\/a>, and Hunting for in-memory .NET attacks<\/a>.<\/p>\n\n\n\n

These attacks involve the attacker carrying out malicious activities entirely in-memory, rather than writing a file to disk \u2013 as is common with more traditional Trojans or implants found in many malware infections. The CSO article titled \u201cHow hackers invade systems without installing software<\/a>\u201d provides a good overview.<\/p>\n\n\n\n

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 \u2013 and there are none in the in-memory scenario.<\/p>\n\n\n\n

In this post, we will describe two in-memory attack techniques and show how these can be detected using Sysmon and Azure Security Center.<\/p>\n\n\n\n

The attack<\/h2>\n\n\n\n

The attacker strategy in this example is as follows:<\/p>\n\n\n

\"graphical<\/figure>\n\n\n\n

The first two stages of this attack chain involve in-memory techniques:<\/p>\n\n\n\n

Initial compromise \u2013 process injection<\/h3>\n\n\n
\"graphical<\/figure>\n\n\n\n

The victim is tricked into enabling macros in a Microsoft Office Word document delivered via email.<\/p>\n\n\n\n

#Hancitor is such an example threat \u2013 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.<\/p>\n\n\n\n

Evade future detection \u2013 process interference<\/h3>\n\n\n
\"text\"<\/figure>\n\n\n\n

After gaining a foothold on the victim machine, the attacker quickly takes steps to limit the likelihood of future detection.<\/p>\n\n\n\n

Invoke-Phant0m<\/a><\/code> 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 \u2013 but it will no longer be writing events to the event log.<\/p>\n\n\n\n

The attacker is now free to carry out other actions, safe in the knowledge that most of that activity won\u2019t get logged.<\/p>\n\n\n\n

Detect in-memory attacks using Sysmon and Azure Security Center<\/h2>\n\n\n\n

By collecting and analyzing Sysmon events in Security Center, you can detect attacks like the ones above. To enable these detections, you must:<\/p>\n\n\n\n

    \n
  1. Install Sysmon on cloud and on-premises machines<\/li>\n\n\n\n
  2. Collect Sysmon event data in your Log Analytics workspace<\/li>\n\n\n\n
  3. Define custom alerts in Security Center to detect suspicious Sysmon events<\/li>\n<\/ol>\n\n\n\n

    Sysmon installation and configuration<\/h3>\n\n\n\n

    Both the attack techniques discussed involve one process accessing another process\u2019 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).<\/p>\n\n\n\n

    Sysmon can log such process accesses in a highly configurable way. It can be downloaded and installed from documentation<\/a>. The Sysmon configuration is key as it determines the level and volume of logging.<\/p>\n\n\n\n

    The precise configuration desired will be highly customer dependent \u2013 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 \u2013 @SwiftOnSecurity<\/a> has published a good example on GitHub<\/a>.<\/p>\n\n\n\n

    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:<\/p>\n\n\n

    \nexampleSysmonConfig.xml:\n\n\n  \n  \n    verclsid.exe\n    svchost.exe\n  \n  \n     \n         0x1F0FFF\n         0x1F1FFF\n         0x1F2FFF\n         0x1F3FFF\n             ...\n         0x1FFFFF\n         unknown\n<\/pre><\/div>\n\n\n
    Installation is then performed via:<\/p>\n\n\n
    \nsysmon.exe -i exampleSysmonConfig.xml\n<\/pre><\/div>\n\n\n
    or <\/p>\n\n\n
    \nsysmon64.exe -i exampleSysmonConfig.xml ((for the 64-bit version))\n<\/pre><\/div>\n\n\n
    When the attacks above are executed, Sysmon logs a type 10 \u2018ProcessAccess\u2019 event like:
    <\/p>\n\n\n
    \"graphical<\/figure>\n\n\n\n
    Enable collection of Sysmon event data<\/h2>\n\n\n
    \"graphical<\/figure>\n\n\n\n
    Azure Security Center collects a specific set of events to monitor for threats<\/a>. Collection of additional data sources \u2013 such as Sysmon events \u2013 can be configured from the Azure portal: open the Log Analytics workspace, and select Advanced Settings.<\/p>\n\n\n\n
    Data sources in log analytics<\/a> 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:<\/p>\n\n\n
    \nMicrosoft-Windows-Sysmon\/Operational:\n<\/pre><\/div>\n\n
    \"graphical<\/figure>\n\n\n\n
    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.<\/p>\n\n\n\n
    Define a custom alert in Azure Security Center<\/h2>\n\n\n
    \"graphical<\/figure>\n\n\n\n
    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.<\/p>\n\n\n\n
    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:<\/p>\n\n\n
    \nsearch \"Microsoft-Windows-Sysmon\/Operational\" | where EventID==10\n<\/pre><\/div>\n\n\n
    View alerts in Security Center<\/h2>\n\n\n\n
    The attacks from the first section are now detected, with the resulting alerts raised in Azure Security Center along with other built-in alerts:<\/p>\n\n\n
    \"graphical<\/figure>\n\n\n
    \"graphical<\/figure>\n\n\n\n
    Refinement \u2013 more granular alert queries<\/h3>\n\n\n\n
    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\u00a0custom fields<\/a>\u00a0and then defining alert rules based on a query of these fields.<\/p>\n\n\n\n
    Summary<\/h2>\n\n\n\n
    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 \u2013 whether for an Azure virtual machine or an on-premises machine.<\/p>\n\n\n\n
    Happy hunting!<\/p>\n\n\n\n
    Further reading<\/h2>\n\n\n\n