Archive for the ‘fileless malware’ Category

Now you see me: Exposing fileless malware

January 24th, 2018 No comments

Attackers are determined to circumvent security defenses using increasingly sophisticated techniques. Fileless malware boosts the stealth and effectiveness of an attack, and two of last years major ransomware outbreaks (Petya and WannaCry) used fileless techniques as part of their kill chains.

The idea behind fileless malware is simple: If tools already exist on a device (for example PowerShell.exe or wmic.exe) to fulfill an attackers objectives, then why drop custom tools that could be flagged as malware? If an attacker can take over a process, run code in its memory space, and then use that code to call tools that are already on a device, the attack becomes more difficult to detect.

Successfully using this approach, sometimes called living off the land, is not a walk in the park. Theres another thing that attackers need to deal with: Establishing persistence. Memory is volatile, and with no files on disk, how can attackers get their code to auto-start after a system reboot and retain control of a compromised system?

Misfox: A fileless gateway to victim networks

In April 2016, a customer contacted the Microsoft Incident Response team about a case of cyber-extortion. The attackers had requested a substantial sum of money from the customer in exchange for not releasing their confidential corporate information that the attackers had stolen from the customers compromised computers. In addition, the attackers had threatened to “flatten” the network if the customer contacted law enforcement. It was a difficult situation.

Quick fact
Windows Defender AV detections of Misfox more than doubled in Q2 2017 compared to Q1 2017.

The Microsoft Incident Response team investigated machines in the network, identified targeted implants, and mapped out the extent of the compromise. The customer was using a well-known third-party antivirus product that was installed on the vast majority of machines. While it was up-to-date with the latest signatures, the AV product had not detected any targeted implants.

The Microsoft team then discovered that the attackers attempted to encrypt files with ransomware twice. Luckily, those attempts failed. As it turned out, the threat to flatten the network was a plan B to monetize the attack after their plan A had failed.

Whats more, the team also discovered that the attackers had covertly persisted in the network for at least seven months through two separate channels:

  • The first channel involved a backdoor named Swrort.A that was deployed on several machines; this backdoor was easily detected by antivirus.
  • The second channel was much more subtle and interesting, because:

    • It did not infect any files on the device
    • It left no artifacts on disk
    • Common file scanning techniques could not detect it

Should you disable PowerShell?
No. PowerShell is a powerful and secure management tool and is important for many system and IT functions. Attackers use malicious PowerShell scripts as post-exploitation technique that can only take place after an initial compromise has already occurred. Its misuse is a symptom of an attack that begins with other malicious actions like software exploitation, social engineering, or credential theft. The key is to prevent an attacker from getting into the position where they can misuse PowerShell. For tips on mitigating PowerShell abuse, continue reading.

The second tool was a strain of fileless malware called Misfox. Once Misfox was running in memory, it:

  • Created a registry run key that launches a “one-liner” PowerShell cmdlet
  • Launched an obfuscated PowerShell script stored in the registry BLOB; the obfuscated PowerShell script contained a reflective portable executable (PE) loader that loaded a Base64-encoded PE from the registry

Misfox did not drop any executable files, but the script stored in the registry ensured the malware persisted.

Fileless techniques

Misfox exemplifies how cyberattacks can incorporate fileless components in the kill chain. Attackers use several fileless techniques that can make malware implants stealthy and evasive. These techniques include:

  1. Reflective DLL injection
    Reflective DLL injection involves the manual loading of malicious DLLs into a process’ memory without the need for said DLLs to be on disk. The malicious DLL can be hosted on a remote attacker-controlled machine and delivered through a staged network channel (for example, Transport Layer Security (TLS) protocol), or embedded in obfuscated form inside infection vectors like macros and scripts. This results in the evasion of the OS mechanism that monitors and keeps track of loading executable modules. An example of malware that uses Reflective DLL injection is HackTool:Win32/Mikatz!dha.
  2. Memory exploits
    Adversaries use fileless memory exploits to run arbitrary code remotely on victim machines. For example, the UIWIX threat uses the EternalBlue exploit, which was used by both Petya and WannaCry, and has been observed to install the DoublePulsar backdoor, which lives entirely in the kernel’s memory (SMB Dispatch Table). Unlike Petya and Wannacry, UIWIX does not drop any files on disk.
  3. Script-based techniques
    Scripting languages provide powerful means for delivering memory-only executable payloads. Script files can embed encoded shellcodes or binaries that they can decrypt on the fly at run time and execute via .NET objects or directly with APIs without requiring them to be written to disk. The scripts themselves can be hidden in the registry (as in the case of Misfox), read from network streams, or simply run manually in the command-line by an attacker, without ever touching the disk.
  4. WMI persistence
    Weve seen certain attackers use the Windows Management Instrumentation (WMI) repository to store malicious scripts that are then invoked periodically using WMI bindings. This article [PDF] presents very good examples.

Fileless malware-specific mitigations on Microsoft 365

Microsoft 365 brings together a set of next-gen security technologies to protect devices, SaaS apps, email, and infrastructure from a wide spectrum of attacks. The following Windows-related components from Microsoft 365 have capabilities to detect and mitigate malware that rely on fileless techniques:

In addition to fileless malware-specific mitigations, Windows 10 comes with other next-gen security technologies that mitigate attacks in general. For example, Windows Defender Application Guard can stop the delivery of malware, fileless or otherwise, through Microsoft Edge and Internet Explorer. Read about the Microsoft 365 security and management features available in Windows 10 Fall Creators Update.

Windows Defender Antivirus

Windows Defender AV blocks the vast majority of malware using generic, heuristic, and behavior-based detections, as well as local and cloud-based machine learning models. Windows Defender AV protects against fileless malware through these capabilities:

  • Detecting script-based techniques by leveraging AMSI, which provides the capability to inspect PowerShell and other script types, even with multiple layers of obfuscation
  • Detecting and remediating WMI persistence techniques by scanning the WMI repository, both periodically and whenever anomalous behavior is observed
  • Detecting reflective DLL injection through enhanced memory scanning techniques and behavioral monitoring

Windows Defender Exploit Guard

Windows Defender Exploit Guard (Windows Defender EG), a new set of host intrusion prevention capabilities, helps reduce the attack surface area by locking down the device against a wide variety of attack vectors. It can help stop attacks that use fileless malware by:

  • Mitigating kernel-memory exploits like EternalBlue through Hypervisor Code Integrity (HVCI), which makes it extremely difficult to inject malicious code using kernel-mode software vulnerabilities
  • Mitigating user-mode memory exploits through the Exploit protection module, which consists of a number of exploit mitigations that can be applied either at the operating system level or at the individual app level
  • Mitigating many script-based fileless techniques, among other techniques, through Attack Surface Reduction (ASR) rules that lock down application behavior

On top of technical controls, it is important that administrative controls related to people and processes are also in place. The use of fileless techniques that rely on PowerShell and WMI on a remote victim machine requires that the adversary has privileged access to those machines. This may be due to poor administrative practices (for example, configuring a Windows service to run in the context of a domain admin account) that can enable credential theft. Read more about Securing Privileged Access.

Windows Defender Application Control

Windows Defender Application Control (WDAC) offers a mechanism to enforce strong code Integrity policies and to allow only trusted applications to run. In the context of fileless malware, WDAC locks down PowerShell to Constrained Language Mode, which limits the extended language features that can lead to unverifiable code execution, such as direct .NET scripting, invocation of Win32 APIs via the Add-Type cmdlet, and interaction with COM objects. This essentially mitigates PowerShell-based reflective DLL injection attacks.

Windows Defender Advanced Threat Protection

Windows Defender Advanced Threat Protection (Windows Defender ATP) is the integrated platform for our Windows Endpoint Protection (EPP) and Endpoint Detection and Response (EDR) capabilities. When it comes to post breach scenarios ATP alerts enterprise customers about highly sophisticated and advanced attacks on devices and corporate networks that other preventive protection features have been unable to defend against. It uses rich security data, advanced behavioral analytics, and machine learning to detect such attacks. It can help detect fileless malware in a number of ways, including:

  • Exposing covert attacks that use fileless techniques like reflective DLL loading using specific instrumentations that detect abnormal memory allocations
  • Detecting script-based fileless attacks by leveraging AMSI, which provides runtime inspection capability into PowerShell and other script-based malware, and applying machine learning models

Microsoft Edge

According to independent security tester NSS Labs, Microsoft Edge blocks more phishing sites and socially engineered malware than other browsers. Microsoft Edge mitigates fileless malware using arbitrary code protection capabilities, which can prevent arbitrary code, including malicious DLLs, from running. This helps mitigate reflective DLL loading attacks. In addition, Microsoft Edge offers a wide array of protections that mitigate threats, fileless or otherwise, using Windows Defender Application Guard integration and Windows Defender SmartScreen.

Windows 10 S

Windows 10 S is a special configuration of Windows 10 that combines many of the security features of Microsoft 365 automatically configured out of the box. It reduces attack surface by only allowing apps from the Microsoft Store. In the context of fileless malware, Windows 10 S has PowerShell Constrained Language Mode enabled by default. In addition, industry-best Microsoft Edge is the default browser, and Hypervisor Code Integrity (HVCI) is enabled by default.


Zaid Arafeh

Senior Program Manager, Windows Defender Research team


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

Windows Defender ATP machine learning and AMSI: Unearthing script-based attacks that ‘live off the land’

December 4th, 2017 No comments

Data center

Scripts are becoming the weapon of choice of sophisticated activity groups responsible for targeted attacks as well as malware authors who indiscriminately deploy commodity threats.

Scripting engines such as JavaScript, VBScript, and PowerShell offer tremendous benefits to attackers. They run through legitimate processes and are perfect tools for living off the landstaying away from the disk and using common tools to run code directly in memory. Often part of the operating system, scripting engines can evaluate and execute content from the internet on-the-fly. Furthermore, integration with popular apps make them effective vehicles for delivering malicious implants through social engineering as evidenced by the increasing use of scripts in spam campaigns.

Malicious scripts are not only used as delivery mechanisms. We see them in various stages of the kill chain, including during lateral movement and while establishing persistence. During these latter stages, the scripting engine of choice is clearly PowerShellthe de facto scripting standard for administrative tasks on Windowswith the ability to invoke system APIs and access a variety of system classes and objects.

While the availability of powerful scripting engines makes scripts convenient tools, the dynamic nature of scripts allows attackers to easily evade analysis and detection by antimalware and similar endpoint protection products. Scripts are easily obfuscated and can be loaded on-demand from a remote site or a key in the registry, posing detection challenges that are far from trivial.

Windows 10 provides optics into script behavior through Antimalware Scan Interface (AMSI), a generic, open interface that enables Windows Defender Antivirus to look at script contents the same way script interpreters doin a form that is both unencrypted and unobfuscated. In Windows 10 Fall Creators Update, with knowledge from years analyzing script-based malware, weve added deep behavioral instrumentation to the Windows script interpreter itself, enabling it to capture system interactions originating from scripts. AMSI makes this detailed interaction information available to registered AMSI providers, such as Windows Defender Antivirus, enabling these providers to perform further inspection and vetting of runtime script execution content.

This unparalleled visibility into script behavior is capitalized further through other Windows 10 Fall Creators Update enhancements in both Windows Defender Antivirus and Windows Defender Advanced Threat Protection (Windows Defender ATP). Both solutions make use of powerful machine learning algorithms that process the improved optics, with Windows Defender Antivirus delivering enhanced blocking of malicious scripts pre-breach and Windows Defender ATP providing effective behavior-based alerting for malicious post-breach script activity.

In this blog, we explore how Windows Defender ATP, in particular, makes use of AMSI inspection data to surface complex and evasive script-based attacks. We look at advanced attacks perpetrated by the highly skilled KRYPTON activity group and explore how commodity malware like Kovter abuses PowerShell to leave little to no trace of malicious activity on disk. From there, we look at how Windows Defender ATP machine learning systems make use of enhanced insight about script characteristics and behaviors to deliver vastly improved detection capabilities.

KRYPTON: Highlighting the resilience of script-based attacks

Traditional approaches for detecting potential breaches are quite file-centric. Incident responders often triage autostart entries, sorting out suspicious files by prevalence or unusual name-folder combinations. With modern attacks moving closer towards being completely fileless, it is crucial to have additional sensors at relevant choke points.

Apart from not having files on disk, modern script-based attacks often store encrypted malicious content separately from the decryption key. In addition, the final key often undergoes multiple processes before it is used to decode the actual payload, making it is impossible to make a determination based on a single file without tracking the actual invocation of the script. Even a perfect script emulator would fail this task.

For example, the activity group KRYPTON has been observed hijacking or creating scheduled tasksthey often target system tasks found in exclusion lists of popular forensic tools like Autoruns for Windows. KRYPTON stores the unique decryption key within the parameters of the scheduled task, leaving the actual payload content encrypted.

To illustrate KRYPTON attacks, we look at a tainted Microsoft Word document identified by John Lambert and the Office 365 Advanced Threat Protection team.

KRYPTON lure document

Figure 1. KRYPTON lure document

To live off the land, KRYPTON doesnt drop or carry over any traditional malicious binaries that typically trigger antimalware alerts. Instead, the lure document contains macros and uses the Windows Scripting Host (wscript.exe) to execute a JavaScript payload. This script payload executes only with the right RC4 decryption key, which is, as expected, stored as an argument in a scheduled task. Because it can only be triggered with the correct key introduced in the right order, the script payload is resilient against automated sandbox detonations and even manual inspection.

KRYPTON script execution chain through wscript.exe

Figure 2. KRYPTON script execution chain through wscript.exe

Exposing actual script behavior with AMSI

AMSI overcomes KRYPTONs evasion mechanisms by capturing JavaScript API calls after they have been decrypted and ready to be executed by the script interpreter. The screenshot below shows part of the exposed content from the KRYPTON attack as captured by AMSI.

Part of the KRYPTON script payload captured by AMSI and sent to the cloud for analysis

Figure 3. Part of the KRYPTON script payload captured by AMSI and sent to the cloud for analysis

By checking the captured script behavior against indicators of attack (IoAs) built up by human experts as well as machine learning algorithms, Windows Defender ATP effortlessly flags the KRYPTON scripts as malicious. At the same time, Windows Defender ATP provides meaningful contextual information, including how the script is triggered by a malicious Word document.

Windows Defender ATP machine learning detection of KRYPTON script captured by AMSI

Figure 4. Windows Defender ATP machine learning detection of KRYPTON script captured by AMSI

PowerShell use by Kovter and other commodity malware

Not only advanced activity groups like KRYPTON are shifting from binary executables to evasive scripts. In the commodity space, Kovter malware uses several processes to eventually execute its malicious payload. This payload resides in a PowerShell script decoded by a JavaScript (executed by wscript.exe) and passed to powershell.exe as an environment variable.

Windows Defender ATP machine learning alert for the execution of the Kovter script-based payload

Figure 5. Windows Defender ATP machine learning alert for the execution of the Kovter script-based payload

By looking at the PowerShell payload content captured by AMSI, experienced analysts can easily spot similarities to PowerSploit, a publicly available set of penetration testing modules. While such attack techniques involve file-based components, they remain extremely hard to detect using traditional methods because malicious activities occur only in memory. Such behavior, however, is effortlessly detected by Windows Defender ATP using machine learning that combines detailed AMSI signals with signals generated by PowerShell activity in general.

Part of the Kovter script payload captured by AMSI and sent to the cloud for analysis

Figure 6. Part of the Kovter script payload captured by AMSI and sent to the cloud for analysis

Fresh machine learning insight with AMSI

While AMSI provides rich information from captured script content, the highly variant nature of malicious scripts continues to make them challenging targets for detection. To efficiently extract and identify new traits differentiating malicious scripts from benign ones, Windows Defender ATP employs advanced machine learning methods.

As outlined in our previous blog, we employ a supervised machine learning classifier to identify breach activity. We build training sets based on malicious behaviors observed in the wild and normal activities on typical machines, augmenting that with data from controlled detonations of malicious artifacts. The diagram below conceptually shows how we capture malicious behaviors in the form of process trees.

Process tree augmented by instrumentation for AMSI data

Figure 7. Process tree augmented by instrumentation for AMSI data

As shown in the process tree, the kill chain begins with a malicious document that causes Microsoft Word (winword.exe) to launch PowerShell (powershell.exe). In turn, PowerShell executes a heavily obfuscated script that drops and executes the malware fhjUQ72.tmp, which then obtains persistence by adding a run key to the registry. From the process tree, our machine learning systems can extract a variety of features to build expert classifiers for areas like registry modification and file creation, which are then converted into numeric scores that are used to decide whether to raise alerts.

With the instrumentation of AMSI signals added as part of the Windows 10 Fall Creators Update (version 1709), Windows Defender ATP machine learning algorithms can now make use of insight into the unobfuscated script content while continually referencing machine state changes associated with process activity. Weve also built a variety of script-based models that inspect the nature of executed scripts, such as the count of obfuscation layers, entropy, obfuscation features, ngrams, and specific API invocations, to name a few.

As AMSI peels off the obfuscation layers, Windows Defender ATP benefits from growing visibility and insight into API calls, variable names, and patterns in the general structure of malicious scripts. And while AMSI data helps improve human expert knowledge and their ability to train learning systems, our deep neural networks automatically learn features that are often hidden from human analysts.

Machine-learning detections of JavaScript and PowerShell scripts

Figure 8. Machine learning detections of JavaScript and PowerShell scripts

While these new script-based machine learning models augment our expert classifiers, we also correlate new results with other behavioral information. For example, Windows Defender ATP correlates the detection of suspicious script contents from AMSI with other proximate behaviors, such as network connections. This contextual information is provided to SecOps personnel, helping them respond to incidents efficiently.

Machine learning combines VBScript content from AMSI and tracked network activity

Figure 9. Machine learning combines VBScript content from AMSI and tracked network activity

Detection of AMSI bypass attempts

With AMSI providing powerful insight into malicious script activity, attacks are more likely to incorporate AMSI bypass mechanisms that we group into three categories:

  • Bypasses that are part of the script content and can be inspected and alerted on
  • Tampering with the AMSI sensor infrastructure, which might involve the replacement of system files or manipulation of the load order of relevant DLLs
  • Patching of AMSI instrumentation in memory

The Windows Defender ATP research team proactively develops anti-tampering mechanisms for all our sensors. We have devised heuristic alerts for possible manipulation of our optics, designing these alerts so that they are triggered in the cloud before the bypass can suppress them.

During actual attacks involving CVE-2017-8759, Windows Defender ATP not only detected malicious post-exploitation scripting activity but also detected attempts to bypass AMSI using code similar to one identified by Matt Graeber.

Windows Defender ATP alert based on AMSI bypass pattern

Figure 10. Windows Defender ATP alert based on AMSI bypass pattern

AMSI itself captured the following bypass code for analysis in the Windows Defender ATP cloud.

AMSI bypass code sent to the cloud for analysis

Figure 11. AMSI bypass code sent to the cloud for analysis

Conclusion: Windows Defender ATP machine learning and AMSI provide revolutionary defense against highly evasive script-based attacks

Provided as an open interface on Windows 10, Antimalware Scan Interface delivers powerful optics into malicious activity hidden in encrypted and obfuscated scripts that are oftentimes never written to disk. Such evasive use of scripts is becoming commonplace and is being employed by both highly skilled activity groups and authors of commodity malware.

AMSI captures malicious script behavior by looking at script content as it is interpreted, without having to check physical files or being hindered by obfuscation, encryption, or polymorphism. At the endpoint, AMSI benefits local scanners, providing the necessary optics so that even obfuscated and encrypted scripts can be inspected for malicious content. Windows Defender Antivirus, specifically, utilizes AMSI to dynamically inspect and block scripts responsible for dropping all kinds of malicious payloads, including ransomware and banking trojans.

With Windows 10 Fall Creators Update (1709), newly added script runtime instrumentation provides unparalleled visibility into script behaviors despite obfuscation. Windows Defender Antivirus uses this treasure trove of behavioral information about malicious scripts to deliver pre-breach protection at runtime. To deliver post-breach defense, Windows Defender ATP uses advanced machine learning systems to draw deeper insight from this data.

Apart from looking at specific activities and patterns of activities, new machine learning algorithms in Windows Defender ATP look at script obfuscation layers, API invocation patterns, and other features that can be used to efficiently identify malicious scripts heuristically. Windows Defender ATP also correlates script-based indicators with other proximate activities, so it can deliver even richer contextual information about suspected breaches.

To benefit from the new script runtime instrumentation and other powerful security enhancements like Windows Defender Exploit Guard, customers are encourage to install Windows 10 Fall Creators Update.

Read the The Total Economic Impact of Microsoft Windows Defender Advanced Threat Protection from Forrester to understand the significant cost savings and business benefits enabled by Windows Defender ATP. To directly experience how Windows Defender ATP can help your enterprise detect, investigate, and respond to advance attacks, sign up for a free trial.


Stefan Sellmer, Windows Defender ATP Research


Shay Kels, Windows Defender ATP Research

Karthik Selvaraj, Windows Defender Research


Additional readings


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.


Detecting reflective DLL loading with Windows Defender ATP

November 13th, 2017 No comments

Today’s attacks put emphasis on leaving little, if any, forensic evidence to maintain stealth and achieve persistence. Attackers use methods that allow exploits to stay resident within an exploited process or migrate to a long-lived process without ever creating or relying on a file on disk. In recent blogs we described how attackers use basic cross-process migration or advanced techniques like atom bombing and process hollowing to avoid detection.

Reflective Dynamic-Link Library (DLL) loading, which can load a DLL into a process memory without using the Windows loader, is another method used by attackers.

In-memory DLL loading was first described in 2004 by Skape and JT, who illustrated how one can patch the Windows loader to load DLLs from memory instead of from disk. In 2008, Stephen Fewer of Harmony Security introduced the reflective DLL loading process that loads a DLL into a process without being registered with the process. Modern attacks now use this technique to avoid detection.

Reflective DLL loading isnt trivialit requires writing the DLL into memory and then resolving its imports and/or relocating it. To reflectively load DLLs, one needs to author ones own custom loader.

However, attackers are still motivated to not use the Windows loader, as most legitimate applications would, for two reasons:

  1. Unlike when using the Windows loader (which is invoked by calling the LoadLibrary function), reflectively loading a DLL doesnt require the DLL to reside on disk. As such, an attacker can exploit a process, map the DLL into memory, and then reflectively load DLL without first saving on the disk.
  2. Because its not saved on the disk, a library that is loaded this way may not be readily visible without forensic analysis (e.g., inspecting whether executable memory has content resembling executable code).

Instrumentation and detection

A crucial aspect of reflectively loading a DLL is to have executable memory available for the DLL code. This can be accomplished by taking existing memory and changing its protection flags or by allocating new executable memory. Memory procured for DLL code is the primary signal we use to identify reflective DLL loading.

In Windows 10 Creators Update, we instrumented function calls related to procuring executable memory, namely VirtualAlloc and VirtualProtect, which generate signals for Windows Defender Advanced Threat Protection (Windows Defender ATP). Based on this instrumentation, weve built a model that detects reflective DLL loading in a broad range of high-risk processes, for example, browsers and productivity software.

The model takes a two-pronged approach, as illustrated in Figure 1:

  1. First, the model learns about the normal allocations of a process. As a simplified example, we observe that a process like Winword.exe allocates page-aligned executable memory of size 4,000 and particular execution characteristics. Only a select few threads within the Winword process allocate memory in this way.
  2. Second, we find that a process associated with malicious activity (e.g., executing a malicious macro or exploit) allocates executable memory that deviates from the normal behavior.

Figure 1. Memory allocations observed by a process running normally vs. allocations observed during malicious activity

This model shows that we can use memory events as the primary signal for detecting reflective DLL loading. In our real model, we incorporate a broad set of other features, such as allocation size, allocation history, thread information, allocation flags, etc. We also consider the fact that application behavior varies greatly because of other factors like plugins, so we add other behavioral signals like network connection behavior to increase the effectiveness of our detection.

Detecting reflective DLL Loading

Lets show how Windows Defender ATP can detect reflective DLL loading used with a common technique in modern threats: social engineering. In this attack, the target victim opens a Microsoft Word document from a file share. The victim is tricked into running a macro like the code shown in Figure 2. (Note: A variety of mechanisms allow customers to mitigate this kind attack at the onset; in addition, several upcoming Office security features further protect from this attack.)

Figure 2. Malicious macro

When the macro code runs, the Microsoft Word process reaches out to the command-and-control (C&C) server specified by the attacker, and receives the content of the DLL to be reflectively loaded. Once the DLL is reflectively loaded, it connects to the C&C and provides command line access to the victim machine.

Note that the DLL is not part of the original document and does not ever touch the disk. Other than the initial document with the small macro snippet, the rest of the attack happens in memory. Memory forensics reveals that there are several larger RWX sections mapped into the Microsoft Word process without a corresponding DLL, as shown in Figure 3. These are the memory sections where the reflectively loaded DLL resides.

Figure 3. Large RWX memory sections in Microsoft Word process upon opening malicious document and executing malicious macro

Windows Defender ATP identifies the memory allocations as abnormal and raises an alert, as shown in Figure 4. As you can see (Figure 4), Windows Defender ATP provides context on the document, along with information on command-and-control communication, which can allow security operations personnel to assess the scope of the attack and start containing the breach.

Figure 4. Example alert on WDATP

Microsoft Office 365 Advanced Threat Protection protects customers against similar attacks dynamic behavior matching. In attacks like this, SecOps personnel would see an Office 365 ATP behavioral detection like that shown in Figure 5 in Office 365s Threat Explorer page.

Figure 5. Example Office 365 ATP detection

Conclusion: Windows Defender ATP uncovers in-memory attacks

Windows 10 continues to strengthen defense capabilities against the full range of modern attacks. In this blog post, we illustrated how Windows Defender ATP detects the reflective DLL loading technique. Security operations personnel can use the alerts in Windows Defender ATP to quickly identify and respond to attacks in corporate networks.

Windows Defender Advanced ATP is a post-breach solution that alerts SecOps personnel about hostile activity. Windows Defender ATP uses rich security data, advanced behavioral analytics, and machine learning to detect the invariant techniques used in attacks. Enhanced instrumentation and detection capabilities in Windows Defender ATP can better expose covert attacks.

Windows Defender ATP also provides detailed event timelines and other contextual information that SecOps teams can use to understand attacks and quickly respond. The improved functionality in Windows Defender ATP enables them to isolate the victim machine and protect the rest of the network.

For more information about Windows Defender ATP, check out its features and capabilities and read about why a post-breach detection approach is a key component of any enterprise security strategy. Windows Defender ATP is built into the core of Windows 10 Enterprise and can be evaluated free of charge.


Christian Seifert

Windows Defender ATP Research


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.