Archive

Author Archive

Teaming up in the war on tech support scams

(Editors note: Erik Wahlstrom spoke about the far-reaching impact of tech support scams and the need for industry-wide cooperation in his RSA Conference 2018 talk Tech Scams: Its Time to Release the Hounds.)

 

Social engineering attacks like tech support scams are so common because theyre so effective. Cybercriminals want to bilk users money. They can spend a great deal of time and energy attacking the security of a devicebrute-force passwords, develop custom and sophisticated malware, and hunt down vulnerabilities to exploit. Or they can save themselves the trouble and convince users to freely give up access to their devices and sensitive information.

Microsoft has built the most secure version of its platform in Windows 10. Core OS technologies like virtualization-based security, kernel-based mitigations, and the Windows Defender ATP stack of security defenses make it much more difficult for exploits, malware, and other threats to infect devices. Every day, machine learning and artificial intelligence in Windows Defender ATP protect millions of devices from malware outbreaks and cyberattacks. In many cases, customers may not even know they were protected. Windows 10 S, a special configuration of Windows 10, takes this even further by only running apps from the Microsoft Store, effectively preventing the vast majority of attacks.

Protect yourself from tech support scams

  • Note that Microsoft does not send unsolicited email messages or make unsolicited phone calls to request for personal or financial information, or fix your computer.
  • Remember, Microsoft will never proactively reach out to you to provide unsolicited PC or technical support. Any communication we have with you must be initiated by you.
  • Dont call the number in pop-ups. Microsofts error and warning messages never include a phone number.

The Windows 10 security stack greatly increases the cost for attackers. Many cybercriminals instead choose to target the humans in front of the PCs. It can sometimes be easier to convince users to willingly share their passwords, account info, or to install hazardous apps onto their device than to develop malware and steal info unnoticed.

Scammers continue to capitalize on the proven effectiveness of social engineering to perpetrate tech support scams. These scams are designed to trick users into believing their devices are compromised or broken. They do this to scare or coerce victims into purchasing unnecessary support services.

To help protect customers from scammers, we continue to enhance antivirus, email, URL blocking, and browser security solutions. However, given the scale and complexity of tech support scams, how can the security industry at large work together to deal a major blow to this enduring threat?

Still a growing global problem

In 2017, Microsoft Customer Support Services received 153,000 reports from customers who encountered or fell victim to tech support scams, a 24% growth from the previous year. These reports came from 183 countries, indicating a global problem.

Approximately 15% of these customers lost money in the scam, costing them on average between $200 and $400. In some cases, victims pay a lot more. In December 2017, Microsoft received a report of a scammer emptying a bank account of 89,000 during a tech support scam in the Netherlands.

Tech support scams reported to Microsoft

In a 2016 survey sponsored by Microsoft, two in three respondents reported experiencing some form of tech support scam in the previous 12 months, with nearly one in ten losing money.

However, as with many social engineering attacks, its tricky to put an absolute number to the problem. The figures above represent reports to Microsoft. The problem is so much bigger, given that tech support scams target customers of various other devices, platforms, or software.

An organized cybercriminal enterprise

Tech support scams come in several forms, but they share a common attack plan:

Scammers initiate these social engineering attacks in many ways, including:

  • Scam websites that use various tactics including browser dialog traps, fake antivirus detecting fake threats, and fake full-screen error messages. Scammers lead potential victims to these websites through ads, search results, typosquatting and other fraudulent mechanisms.
  • Email campaigns that use phishing-like techniques to trick recipients into clicking URLs or opening malicious attachments
  • Malware thats installed on computers to make system changes and display fake error messages
  • Unsolicited phone calls (also known as cold calls), which are telemarketing calls from scammers that pretend to be from a vendors support team

The complete attack chain shows that these attacks lead to the same goal of getting customers in contact with a call center. Once connected, a fake technician (an experienced scammer) convinces the victim of a problem with their device. They often scare victims with urgent problems requiring immediate action. They instruct victims to install remote administration tools (RATs), which provide the scammers access to and control over the device.

tech support scams attack chain

From this point on, scammers can make changes to the device or point out common non-critical errors, and present these as problems. For example, scammers are known to use Event Viewer to show errors or netstat to show connections to foreign IP addresses. The scammers then attempt to make the sale. With control of the device, scammers can make a compelling case about errors in the device and pressure the victim to pay.

An industry-wide problem requires industry-wide action

The tech support scam problem is far-reaching. Its impact spans various platforms, devices, software, services. Examples include:

  • Tech support scams targeting specific platforms like Windows, macOS, iOS, and Android
  • Tech support scam websites that imply a formal relationship or some sort of approval by well-known vendors
  • Fake malware detection from programs or websites that mimic various antivirus solutions
  • Customized tech support scams that tailor messages and techniques based on geography, OS, browser, or ISP

As in many forms of social engineering attacks, customer education is key. There are tell-tale signs: normal error and warning messages should not have phone numbers, most vendors dont make unsolicited phone calls to fix a device, etc. To help protect and educate Microsoft customers, we have published blogs, websites, videos, and social media campaigns on the latest tech support scam trends and tactics. We have also empowered customers to report tech support scams.

Beyond customer education, the scale and complexity of tech support scams require cooperation and broad partnerships across the industry. The Microsoft Digital Crimes Unit (DCU) works with law enforcement and other agencies to crack down on scammers.

We have further built partnerships across the ecosystem to make a significant dent on this issue:

  • Web hosting providers, which can take down verified tech support scam websites
  • Telecom networks, which can block tech support scam phone numbers
  • Browser developers, who can continuously thwart tech support scam tactics and block tech support scam websites
  • Antivirus solutions, which can detect tech support scam malware
  • Financial networks, who can help protects customers from fraudulent transactions
  • Law enforcement agencies, who can go after the crooks

We seek to continue expanding and enriching these partnerships. While we continue to help protect customers through a hardened platform and increasingly better security solutions, we believe its high time for the industry to come together and put an end to the tech support scam problem. Together, we can make our customers lives easier and safer.

 

 

Erik Wahlstrom
Windows Defender Research Project Manager

 

 


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.

Introducing Windows Defender System Guard runtime attestation

At Microsoft, we want users to be in control of their devices, including knowing the security health of these devices. If important security features should fail, users should be aware. Windows Defender System Guard runtime attestation, a new Windows platform security technology, fills this need.

In Windows 10 Fall Creators Update, we reorganized all system integrity features into Windows Defender System Guard. This move allowed us to continually make significant innovations in platform security. Windows Defender System Guard runtime attestation, which is built into the core Windows operating system, will soon be delivered in all editions of Windows. Windows Defender System Guard runtime attestation, like Credential Guard, takes advantage of the same hardware-rooted security technologies in virtualization-based security (VBS) to mitigate attacks in software.

Security technologies are targeted by exploits that attempt to run in the same domain of trust. For example, privileged processes are designed to provide a certain degree of isolation (at least in respect to code and data) from regular user-mode processes. The NT kernel determines whether a process is protected based on certain values held in the executive process object. Tampering with these values via a kernel exploit or with a driver (e.g., Mimikatz) can effectively disable process protection. Moving the security decision related to tampering to a separate domain of trust increases complexity for attackers.

Runtime attestation can help in many scenarios, including:

  • Providing supplementary signals for endpoint detection and response (EDR) and antivirus vendors (including full integration with the Windows Defender Advanced Threat Protection stack)
  • Detecting artifacts of kernel tampering, rootkits, and exploits
  • Protected game anti-cheat scenarios (for example, detection of process-protection bypasses that can lead to game-state modification)
  • Sensitive transactions (banking apps, trading platforms)
  • Conditional access (enabling and enhancing device security-based access policies)

With the next update to Windows 10, we are implementing the first phase of Windows Defender System Guard runtime attestation, laying the groundwork for future innovation in this area. This includes developing new OS features to support efforts to move towards a future where violations of security promises are observable and effectively communicated in the event of a full system compromise, such as through a kernel-level exploit.

Attestation and establishing trust

To introduce Windows Defender System Guard runtime attestation on a technical level, its best to begin at the most visible layer: a client API that will eventually be exposed to a relying party. (Note: We share details of the general design as its currently architected; final implementation may differ.)

We are working towards providing an API that relying parties can use to attest to the state of the device at a point in time. The API returns a runtime report that details the claims that Windows Defender System Guard runtime attestation makes about the security posture of the system. These claims include assertions, which are runtime measurements of sensitive system properties.

For the runtime report to have any significant meaning, it must be generated in a fashion that provides reasonable resistance against tampering. This gives rise to the following basic component requirements:

  1. Runtime report generation must be isolated from an attacker
  2. This isolation must be attestable
  3. The runtime report must be cryptographically signed in a manner that is irreproducible outside the isolated environment

Enter VBS enclaves. Were not going to describe these enclaves in-depth here, but its prudent to give some context. On a device with virtual secure mode (VSM) enabled, virtualization extensions of the underlying Instruction Set Architecture (ISA) are employed to logically divide the system into two (theoretically, more) separate worlds: the normal world running the NT kernel that were all familiar with and a separate secure world running a Secure Kernel (SK). We call these two logical levels of separation Virtual Trust Levels (VTLs), in this case NT being VTL-0 and SK being VTL-1.

VBS enclaves enable what can be thought of as a siloed part of a normal world VTL-0 user-mode process. All code and data in this silo live in VTL-1. Transactions in and out of an enclave are done via a well-defined API backed by VSL calls (the mechanism that NT and SK use to communicate). The result of this intricacy is that, as of Windows Fall Creators Update (1709), it is possible to execute code and hold data within an enclave such that the entire VTL-0 normal world both user-mode and kernel-mode cannot directly act upon the siloed code and data while executing and held within the enclave (in VTL-1).

From the VBS enclave, the runtime attestation component can observe and attest to a set of security properties contained in a report. For example, an app could ask Windows Defender System Guard to measure the security of the system from the hardware-backed enclave and return a report. The details in this report can be used by the app to decide whether it performs a sensitive financial transaction or display personal information.

VBS enclaves can also expose an enclave attestation report signed by a VBS-specific signing key. If Windows Defender System Guard can obtain proof that the host system is running with VSM active, it can use this proof together with a signed session report to ensure that the particular enclave is running.

As for the signature of the runtime report itself, an asymmetrical public-private key pair is generated within the enclave. The public key is signed by the Windows Defender System Guard attestation service backend to create a session certificate. In addition, the Windows Defender System Guard attestation service backend produces a signed session report containing details about the machine. These details include boot security properties, including whether the machine booted with Secure boot enabled, to ensure that the core operating system has not been jailbroken or tampered with. Finally, runtime reports are signed locally by the paired private key, which never leaves the enclave. The runtime and session reports can be verified by relying parties with little effort by verifying the report signatures against the session certificate and then ensuring that the certificate is validly signed, rooted in the relevant Microsoft CA.

Establishing the trust necessary to guarantee that the runtime report is authentic, therefore, requires the following:

  • Attesting to the boot state of the machine: the OS, hypervisor, and Secure Kernel (SK) binaries must be signed by Microsoft and configured according to a secure policy
  • Binding trust between the TPM and the health of the hypervisor to allow trust in the Measured Boot Log
  • Extracting the VSM IDKs from the Measured Boot Log and using these to verify the VBS enclave signature
  • Backend verification of the above and signing of the public component of an ephemeral key-pair generated within the enclave with a trusted CA to issue a session certificate
  • Signing of the runtime report with the ephemeral private key

Networking calls between the enclave and the Windows Defender System Guard attestation service are made from VTL-0. However, the design of the attestation protocol ensures that it is resilient against tampering even over untrusted transport mechanisms.

Numerous underlying technologies are required before the chain of trust described above can be sufficiently established. To inform a relying party to the level of trust in the runtime report that they can expect on any particular configuration, a security level is assigned to each Windows Defender System Guard attestation service-signed session report. The security level reflects the underlying technologies enabled on the platform and attributes a level of trust based on the capabilities of the platform. We are mapping the enablement of various security technologies to security levels, and we will share this when the API is published for third-party use. The highest level of trust is likely to require the following features, at the very least:

  • VBS-capable hardware + OEM configuration
  • Dynamic root-of-trust measurements at boot
  • Secure boot to verify hypervisor, NT, SK images
  • Secure policy ensuring:

    • Hypervisor-protected code integrity (HVCI)-enforced kernel mode code integrity (KMCI)
    • Test-signing is disabled
    • Kernel debugging is disabled

Measurement

Now that we have explained the trusted report component, let us discuss the contents of the runtime report.

The security level exposed in the session report is an important and interesting metric in and of itself. However, Windows Defender System Guard can provide so much more specifically in respect to runtime measurement of system security posture.

We call this runtime measurement component the assertion engine. The idea is to continually measure assert system integrity at runtime, with the security level attesting to security posture at boot.

Some caveats:

  • The assertion engine was designed with the ideal system configuration in mind (i.e., a system configuration with the highest security level)

    • Business needs require Windows Defender System Guard runtime attestation to function on systems even with the lowest security level; Windows Defender System Guard runtime attestation makes no guarantees in this scenario and can act as a signal for other security products on non-locked down editions of Windows

  • When running the ideal configuration, non-ROP kernel-mode code execution is difficult due to hypervisor-protected code integrity (HVCI)-enforced kernel mode code integrity (KMCI); in this scenario:

    • Data corruption attacks are more likely
    • It can be assumed that it’s difficult to tamper with any required kernel-mode agents in non-racing scenarios
    • The runtime assertions are therefore targeted at attacks that can reasonably be performed under the most restrictive attack conditions

  • We are working to limitations of (current) operating system design

    • We have a deep partnership with other teams in Microsoft and we are work in tandem to improve System Guard runtime attestation and core kernel security features. In the current version of the OS, we rely on NT kernel thread management and the Secure Kernel primitives provided to us.

Windows Defender System Guard runtime attestation architecture

High-level overview of Windows Defender System Guard runtime attestation architecture

Architecturally, the solution is collectively referred to as the Windows Defender System Guard runtime monitor and consists of the following client-side components:

  • The VTL-1 assertion engine itself
  • A VTL-0 kernel-mode agent
  • A VTL-0 process we call the broker to host the assertion engine

To rapidly respond to threats, we opted for a dynamic scripting approach that will allow us to frequently release updates going forward. We chose an open-source library that met our requirements for maturity, footprint, and performance. This scripting component forms the core of the assertion engine that executes in VTL-1 (if available).

Running arbitrary logic in this engine wouldnt be very useful if it couldnt interact with the system in any way. For the engine to perform useful work, we provide native helpers in the form of assists. These assists are executed in VTL-0 either by the broker service or by a Kernel-mode agent.

In the next update to Windows, assertion logic is delivered in-band (within the signed engine DLL itself). At some point in the future, these scripts will be delivered out-of-band. This is a core part of the design. It enables us to immediately respond to security events (for example, the discovery of new attack invariants) without the need for delivering a component update via servicing. Apps and services can take advantage of this attestation technology to ensure that the system is free from tampering and that critical processes are running as expected. This hardware-rooted proof-of-health can then be used to identify compromised machines or gate access to critical cloud services. Runtime attestation serves as a platform for a wide variety of advanced security applications.

We believe that we can significantly raise the bar for security on locked-down platforms with modern hardware and appropriate security policies. In a world where direct privileged code-execution is difficult, we think that attacks will increasingly leverage data corruption. Transient changes are also a challenge in the current model. However, future innovations will make achieving persistence harder, making transient malicious changes more difficult. The idea is to continually elevate defense across the entire Windows 10 security stack, thereby pushing attackers into a corner where system changes affecting security posture are detectable. One can think of runtime attestation as being more about detecting minute symptoms that can indicate an attack rather than looking for flashing signals.

We are very excited about this technology because of its potential for making significant leaps in platform security. Theres a lot more about Windows Defender System Guard runtime attestation that we did not cover in this blog, for example, the detailed design itself and where we see this technology going. Stay tuned.

 

 

David Kaplan (@depletionmode), Windows Defender ATP Research Team
Adam Zabrocki (@Adam_pi3), Windows Offensive Security Research Team
Rafael Goncalves, Enterprise & Security

 

 


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.

Hunting down Dofoil with Windows Defender ATP

Dofoil is a sophisticated threat that attempted to install coin miner malware on hundreds of thousands of computers in March, 2018. In previous blog posts we detailed how behavior monitoring and machine learning in Windows Defender AV protected customers from a massive Dofoil outbreak that we traced back to a software update poisoning campaign several weeks prior. Notably, customers of Windows 10 S, a special Windows 10 configuration that provides streamlined Microsoft-verified security, were not affected by the Dofoil outbreak.

In this blog post, we will expound on Dofoils anti-debugging and anti-analysis tactics, and demonstrate how the rich detection libraries of Windows Defender Advanced Threat Protection and Windows Defender Exploit Guard can help during investigation.

We found that Dofoil was designed to be elusive to analysis. It checks its environment and stops running in virtual machine environments. It also checks for various analysis tools and kills them right away. This can make malware analysis and assessment challenging.

The following diagram shows the multi-stage malware execution process, which includes checks for traits of analysis environments during some stages.

Figure 1. Dofoil multi-stage shellcode and payload execution flow

The table below describes the purpose of each stage. The first five stages have at least one or two different techniques that can deter dynamic or static malware analysis.

STAGES DESCRIPTION
1. Obfuscated wrapper code Anti-heuristics

Anti-emulation

2. Bootstrap module Performs self-process hollowing to load the next module
3. Anti-debugging module Performs anti-debugging operation
4. Trojan downloader module Performs system environment checks

Performs anti-VM operation

Injects itself to explorer.exe through process hollowing

5. Trojan downloader module in explorer.exe Contacts C&C server to download trojan and run it using process hollowing technique
6. Payload downloader module in explorer.exe Contacts C&C server to download the main payload
7. Trojan module Steals credentials from various application settings and sends stolen into to the C&C server over HTTP channel
8. CoinMiner.D Mines digital currencies

Table 1. Dofoil’s multi-stage modules

Initial stages

The first three stages (i.e., obfuscated wrapper code, bootstrap module, anti-debugging module) use the following techniques to avoid analysis and identification.

ANTI-ANALYSIS TECHNIQUES DESCRIPTION
Benign code insertion Inserts a huge benign code block to confuse heuristics and manual inspection
Anti-emulation Enumerates an arbitrary registry key (HKEY_CLASSES_ROOT\Interface\{3050F557-98B5-11CF-BB82-00AA00BDCE0B}) and compares the data with an expected value (DispHTMLCurrentStyle) to check if the malware runs inside an emulator
Self-process hollowing Uses the process hollowing technique on the current process, making analysis extra difficult due to the altered code mapping
Debugger checks Checks for debuggers, and modifies code to crash. This can add additional layer of confusion to researchers, who are bound to investigate the cause of the crashes. It checks for the PEB.BeingDebugged and PEB.NtGlobalFlag fields in the PEB structure. For example, PEB.BeingDebugged is set to 1 and PEB.NtGlobalFlag is set to FLG_HEAP_ENABLE_TAIL_CHECK|FLG_HEAP_ENABLE_FREE_CHECK| FLG_HEAP_VALIDATE_PARAMETERS when a debugger is attached to the process.

Table 2. Anti-analysis techniques

The first stage contains some benign-looking code before the actual malicious code. This can give the executable a harmless appearance. It can also make the emulation of the code difficult because emulating various API calls that are not present in many malware codes can be challenging.

The first-stage code also performs a registry key enumeration to make sure it has the expected value. When all checks are passed, it decodes the second-stage shellcode and runs it on the allocated memory. This shellcode un-maps the original main modules memory, and then decodes the third-stage shellcode into that memory this is known as a self-process hollowing technique.

Figure 2. Self-modification based on PEB.BeingDebugged value

Windows Defender ATPs process tree can help with investigation by exposing these anti-debugging techniques.

Figure 3. Windows Defender ATP process tree showing anti-debugging techniques

Trojan downloader module

The trojan downloader module performs various environment checks, including virtual environment and analysis tool checks, before downloading the payload.

ANTI-ANALYSIS TECHNIQUES DESCRIPTION
Check module name Checks if the main executable name contains the string “sample”
Check volume serial Checks if current volume serial number is 0xCD1A40 or 0x70144646
Check modules Checks the presence of DLLs related to debuggers
Check disk-related registry keys Checks the value of the registry key HKLM\System\CurrentControlSet\Services\Disk\Enum against well-known disk name patterns for virtual machines (qemu, virtual, vmware, xen, ffffcce24)
Process check Checks running processes and kills those with processes names associated with analysis tools (procexp.exe, procexp64.exe, procmon.exe, procmon64.exe, tcpview.exe, wireshark.exe, processhacker.exe, ollydbg.exe, idaq.exe, x32dbg.exe)
Windows class name check Checks the current Windows class names and exits when some well-known names are found (Autoruns, PROCEXPL, PROCMON_WINDOW_CLASS, TCPViewClass, ProcessHacker, OllyDbg, WinDbgFrameClass)

Table 3. Anti-analysis techniqueof Dofoil’s trojan downloader module

The list of target process names and Windows class names exist in custom checksum form. The checksum algorithm looks like the following:

Figure 4. Shift and XOR custom checksum algorithm

The purpose of this checksum is to prevent malware researchers from quickly figuring out what analysis tools it detects, making analysis more time-consuming.

STRING CHECKSUM
Autoruns 0x0E5C1C5D
PROCEXPL 0x1D421B41
PROCMON_WINDOW_CLASS 0x4B0C105A
TCPViewClass 0x1D4F5C43
ProcessHacker 0x571A415E
OllyDbg 0x4108161D
WinDbgFrameClass 0x054E1905
procexp.exe 0x19195C02
procexp64.exe 0x1C0E041D
procmon.exe 0x06185D0B
procmon64.exe 0x1D07120A
tcpview.exe 0x060B5118
wireshark.exe 0x550E1E0D
processhacker.exe 0x51565C47
ollydbg.exe 0x04114C14
x32dbg.exe 0x5F4E5C04
idaq.exe 0x14585A12

Table 4. String checksum table used for process names and Windows class names

Process hollowing

Dofoil heavily uses the process hollowing technique. Its main target for process hollowing is explorer.exe. The Dofoil shellcode launches a new instance of explorer.exe, allocates shellcode in heap region, and then modifies the entry point code to jump into the shellcode. This way, the malware avoids using CreateRemoteThread API, but can still achieve code injection.

Figure 5. Modification of explorer.exe entry point code

Windows Defender ATP can detect the process hollowing behavior with advanced memory signals. The following process tree shows that the malware injects itself into explorer.exe using the process hollowing technique.

Figure 6. Windows Defender ATP alert process tree showing the first process hollowing

When the shellcode downloads another layer of payload, it spawns another explorer.exe to inject the payload into using process hollowing. Windows Defender ATP can save analysis time on these cases by pinpointing the malicious actions, eliminating the need for guessing what these newly spawned Windows system processes are doing.

Figure 7. Windows Defender ATP alert process tree showing the second process hollowing

The process hollowing behavior can be detected through Exploit protection in Windows Defender Exploit Guard. This can be done by enabling the Export Address Filter (EAF) mitigation against explorer.exe. The detection happens when the shellcode goes through the export addresses of the modules to find the export address of the LoadLibraryA and GetProcAddress functions.

Figure 8. Export Address Filter (EAF) event exposed in Event viewer

Windows Defender Exploit Guard events are also exposed in the Windows Defender ATP portal:

Figure 9. Windows Defender ATP view of the Windows Defender Exploit Guard event

Adding Windows Defender Exploit Guard EAF audit/block policy to common system processes like explorer.exe, cmd.exe, or verclsid.exe can be useful in finding and blocking process hollowing or process injection techniques commonly used by malware. This policy can impact third-party apps that may behave like shellcode, so we recommend testing Windows Defender Exploit Guard with audit mode enabled before enforcement.

Command-and-control (C&C) and NameCoin domains

Dofoils C&C connection is very cautious. The trojan code first tries to connect to well-known web pages and verifies that the malware has proper and real Internet connection, not simulated as in test environments. After it makes sure it has a real Internet connection, the malware makes HTTP connections to the actual C&C servers.

Figure 10. Access to known servers to confirm Internet connectivity

The malware uses NameCoin domain name servers. NameCoin is a decentralized name server system that provides extra privacy backed by blockchain technology. Except for the fact that the DNS client needs to use specific sets of NameCoin DNS servers, the overall operation is very similar to a normal DNS query. Because NameCoin uses blockchain technology, you can query the history of the domain name changes through blocks.

Figure 11. Malicious hostname DNS entry changes over time (https://namecha.in/name/d/vrubl)

Windows Defender ATP can provide visibility into the malwares network activities. The following alert process tree shows the malwares .bit domain resolution activity and, after that, the connections to the resolved C&C servers. You can also view other activities from the executable, for example, its connections to other servers using SMTP ports.

Figure 12. Windows Defender ATP alert process tree showing C&C server connection through NameCoin server name resolution

The Windows Defender ATP advanced hunting feature, which is currently in preview, can be used to hunt down more malware samples that possibly abuse NameCoin servers. For example, the following query will let you view recent connections observed in the network. This can lead to extra insights on other threats that use the same NameCoin servers.

Figure 13. Advanced hunting for other threats using the same NameCoin servers

The purpose of using NameCoin is to prevent easy sinkholing of the domains. Because there are no central authorities on the NameCoin domain name records, it is not possible for the authorities to change the domain record. Also, malware abusing NameCoin servers use massive numbers of NameCoin DNS servers to make full shutdown of those servers very difficult.

Conclusion

Dofoil is a very evasive malware. It has various system environment checks and tests Internet connectivity to make sure it runs on real machines, not in analysis environments or virtual machines. This can make the analysis time-consuming and can mislead malware analysis systems.

In attacks like the Dofoil outbreak, Windows Defender Advanced Threat Protection (Windows Defender ATP) can help network defenders analyze the timeline from the victim machine and get rich information on process execution flow, C&C connections, and process hollowing activities. Windows Defender ATP can be used as an analysis platform with fine-tuned visibility into system activities when set up in a lab environment. This can save time and resource during malware investigation.

In addition, Windows Defender Exploit Guard can be useful in finding malicious shellcodes that traverse export address tables. Windows Defender Exploit Guard can be an excellent tool for finding and blocking malware and exploit activities.

Windows Defender Exploit Guard events are surfaced in the Windows Defender ATP portal, which integrates protections from other Microsoft solutions, including Windows Defender AV and Windows Defender Application Guard. This integrated security management experience makes Windows Defender ATP a comprehensive solution for detecting and responding to a wide range of malicious activities across the network.

Windows 10 S, a special configuration of Windows 10, locks down devices against Dofoil and other attacks by working exclusively with apps from the Microsoft Store and using Microsoft Edge as the default browser. This streamlined, Microsoft-verified platform seals common malware entry points.

To test how Windows Defender ATP can help your organization detect, investigate, and respond to advanced attacks, sign up for a free trial.

 

 

Matt Oh, Stefan Sellmer, Jonathan Bar Or, Mark Wodrich
Windows Defender ATP Research

 

 

Indicators of compromise (IoCs)

TrojanDownloader:Win32/Dofoil.AB:

d191ee5b20ec95fe65d6708cbb01a6ce72374b309c9bfb7462206a0c7e039f4d

eaa63f6b500afedcaeb8d5b18a08fd6c7d95695ea7961834b974e2a653a42212

cded7aedca6b54a6d4273153864a25ccad35cba5cafeaec828a6ad5670a5973a

Trojan:Win32/Dofoil.AB:

070243ad7fb4b3c241741e564039c80ca65bfdf15daa4add70d5c5a3ed79cd5c

5f3efdc65551edb0122ab2c40738c48b677b1058f7dfcdb86b05af42a2d8299C

28ce9763a808c4a7509e9bf92d9ca80212a241dfa1aecd82caedf1f101eac692

5d7875abbbf104f665a0ee909c372e1319c5157dfc171e64ac2bc8b71766537f

Trojan:Win32/CoinMiner.D

2b83c69cf32c5f8f43ec2895ec9ac730bf73e1b2f37e44a3cf8ce814fb51f12

C&C URLs:

hxxp://levashov.bit/15022018/

hxxp://vrubl.bit/15022018/

C&C server:

vinik.bit

Related .bit domains (updated in same block as C&C server):

henkel.bit

makron.bit

makronwin.bit

NameCoin servers used by Dofoil:

139.59.208.246

130.255.73.90

31.3.135.232

52.174.55.168

185.121.177.177

185.121.177.53

62.113.203.55

144.76.133.38

169.239.202.202

5.135.183.146

142.0.68.13

103.253.12.18

62.112.8.85

69.164.196.21

107.150.40.234

162.211.64.20

217.12.210.54

89.18.27.34

193.183.98.154

51.255.167.0

91.121.155.13

87.98.175.85

185.97.7.7

 

 


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.

 

 

Why Windows Defender Antivirus is the most deployed in the enterprise

Statistics about the success and sophistication of malware can be daunting. The following figure is no different: Approximately 96% of all malware is polymorphic meaning that it is only experienced by a single user and device before it is replaced with yet another malware variant. This is because in most cases malware is caught nearly as fast as its created, so malware creators continually evolve to try and stay ahead. Data like this hammer home how important it is to have security solutions in place that are as agile and innovative as the attacks.

The type of security solution needed has a complex job: It must protect users from hundreds of thousands of new threats every day and then it must learn and grow to stay ahead of the next wave of attacks. The solution cannot just react to the latest threats; it must be able to predict and prevent malware infections.

Over the last year, weve talked about how were investing in new innovations to address this challenging threat landscape, what weve delivered, and how it will change the dynamics. Today, I want to share the results of our new antivirus capabilities in Windows Defender Advanced Threat Protection (ATP) which are genuinely incredible because they will directly benefit the work you are doing.

Currently, our antivirus capabilities on Windows 10 are repeatedly earning top scores on independent tests, often outperforming the competition. This performance is the result of a complete redesign of our security solution.

Whats more, this same technology is available for our Windows 7 customers as well, so that they can remain secure during their transition to Windows 10.

It started back in 2015

Weve been working to make our antivirus capabilities increasingly more effective, and in 2015 our results in two major independent tests (AV-Comparatives and AV-TEST) began to improve dramatically. As you can see in the chart below, beginning in March 2015 our scores on AV-TEST began to rise rapidly, and, over the course of the next five months, we moved from scores averaging 85% on their Prevalence Test to (or near) 100%. Since then, weve maintained those types of scores consistently. Our scores on AV-Comparatives experienced a very similar spike, trajectory, and results.

In December 2017, we reached another milestone on AV-TEST, where we achieved a perfect score across both the Prevalence and Real-World based tests. Previously we had only scored a perfect 100% on one of the two tests for a given month. The following chart from the AV-TEST site shows our scores from November and December 2017 on Windows 7. These same scores are also applicable to Windows 10, which shares the same technology (and more).

For AV-Comparatives, we recently achieved another important quality milestone: For five consecutive months we detected all malware samples. Our previous best was four consecutive months. The AV-Comparatives chart below shows our February 2018 results where we scored a perfect 100% block rate.

While independent antivirus tests are one indicator of a security solutions capabilities and protections, its important to understand that this is only one part of a complete quality assessment.

For example, in the case of Windows Defender ATP (which integrates our antivirus capabilities and the whole Windows security stack), our customers have a much larger set of protection features none of which are factored into the tests. These features provide additional layers of protection that help prevent malware from getting onto devices in the first place. These features include the following:

If organizations like AV-Comparatives and AV-TEST performed complete security stack tests (i.e., testing against the complete endpoint protection solution) the results would often tell a very different story. For example, in November, we scored a 98.9% based on a single file miss on the Real-World test. The good news, however, is that we would have scored 100% if either Windows Defender Application Guard or Application Control was enabled.

How did we achieve these results?

The short answer is that we completely redesigned our antivirus solutions for both Windows 7 and Windows 10 from the ground up.

To do this, we moved away from using a static signature-based engine that couldnt scale due to its dependence on constant input from researchers. Weve now moved to a model that uses predictive technologies, machine learning, applied science, and artificial intelligence to detect and stop malware at first sight. We described the use of these technologies in our recent posts on Emotet and BadRabbit, as well as the recent Dofoil outbreak. These are the types of approaches that can be very successful against the ongoing avalanche of malware threats.

Because of these changes, our antivirus solution can now block malware using local and cloud-based machine learning models, combined with behavior, heuristic, and generic-based detections on the client. We can block nearly all of it at first sight and in milliseconds!

This is incredible.

Weve also designed our antivirus solution to work in both online and offline scenarios. When connected to the cloud, its fed real-time intelligence from the Intelligent Security Graph. For offline scenarios, the latest dynamic intelligence from the Graph is provisioned to the endpoint regularly throughout the day.

Weve also built our solution to defend against the new wave of fileless attacks, like Petya and WannaCry. To read more about how we protect against these attacks, check out the blog post Now you see me: Exposing fileless malware.

What this means to you

Each of these milestones is great, but the thing that makes us the most excited here at Microsoft is very simple: Customer adoption.

Right now, we are seeing big growth in enterprise environments our across all of our platforms:

  • 18% of Windows 7 and Windows 8 devices are using our antivirus solution
  • Over 50% of Windows 10 devices are using our antivirus solution

These are awesome numbers and proof that customers trust Windows security. What we are seeing is that as organizations are moving to Windows 10 they are also moving to our antivirus as their preferred solution. With our antivirus solution being used on more than 50% percent of the Windows 10 PCs deployed in commercial organizations, it is now the most commonly used antivirus solution in commercial organizations on that platform. This usage is in commercial customers of all sizes from small and medium-sized businesses to the largest enterprise organizations.

Over the past couple of months Ive shared this data with multiple customers, and often Im asked why weve seen such a positive increase. The answer is simple:

  1. Our antivirus capabilities are a fantastic solution! The test results above really speak for themselves. With five months of top scores that beat some of our biggest competitors, you can be confident that our solution can protect you from the most advanced threats.
  2. Our solution is both easier and operationally cheaper to maintain than others. Most enterprise customers use Config Manager for PC management of Windows 7 and Windows 10 security features, including antivirus. With Windows 10, the antivirus capabilities are built directly into the operating system and theres nothing to deploy. Windows 7 didnt include antivirus capabilities by default, but it can be deployed and configured in Config Manager. Now organizations do not have to maintain two infrastructures one for PC management and another for antivirus. Several years ago, our Microsoft IT department retired the separate global infrastructure that was used to manage Microsofts antivirus solution and now you can too! With our solution theres less to maintain and secure.
  3. Our solution enables IT to be more agile. On Windows 10 theres no agent security is built into the platform. When a new update of Windows 10 is released, you dont need to wait for a 3rd party to certify and support it; instead, you have full support and compatibility on day one. This means that new releases of Windows and all the latest security technologies can be deployed faster. This allows you to get current, stay current, and be more secure.
  4. Our solution offers a better user experience. Its designed to work behind the scenes in a way that is unobtrusive to end users and minimizes power consumption. This means longer battery life and everyone wants more battery life!

While weve made excellent progress with our antivirus solution, Im even more excited about the protection and management capabilities we will deliver to our customers in the near future. In the meantime, one of the best ways to evaluate our antivirus capabilities is when you run it with Windows Defender ATP. With Windows Defender ATP, the power of the Windows security stack provides preventative protection, detects attacks and zero-day exploits, and gives you centralized management for your end-to-end security lifecycle.

Sign up to try Windows Defender ATP for yourself!

 

Invisible resource thieves: The increasing threat of cryptocurrency miners

The surge in Bitcoin prices has driven widescale interest in cryptocurrencies. While the future of digital currencies is uncertain, they are shaking up the cybersecurity landscape as they continue to influence the intent and nature of attacks.

Cybercriminals gave cryptocurrencies a bad name when ransomware started instructing victims to pay ransom in the form of digital currencies, most notably Bitcoin, the first and most popular of these currencies. It was not an unexpected move digital currencies provide the anonymity that cybercriminals desire. The sharp increase in the value of digital currencies is a windfall for cybercriminals who have successfully extorted Bitcoins from ransomware victims.

These dynamics are driving cybercriminal activity related to cryptocurrencies and have led to an explosion of cryptocurrency miners (also called cryptominers or coin miners) in various forms. Mining is the process of running complex mathematical calculations necessary to maintain the blockchain ledger. This process rewards coins but requires significant computing resources.

Coin miners are not inherently malicious. Some individuals and organizations invest in hardware and electric power for legitimate coin mining operations. However, others are looking for alternative sources of computing power; as a result, some coin miners find their way into corporate networks. While not malicious, these coin miners are not wanted in enterprise environments because they eat up precious computing resources.

As expected, cybercriminals see an opportunity to make money and they customize coin miners for malicious intents. Crooks then run malware campaigns that distribute, install, and run the trojanized miners at the expense of other peoples computing resources. On March 6, Windows Defender Advanced Threat Protection (Windows Defender ATP) blocked a massive coin mining campaign from the operators of Dofoil (also known as Smoke Loader).

In enterprise environments, Windows Defender ATP provides the next-gen security features, behavioral analysis, and cloud-powered machine learning to help protect against the increasing threats of coin miners: Trojanized miners, mining scripts hosted in websites, and even legitimate but unauthorized coin mining applications.

Coin mining malware

Cybercriminals repackage or modify existing miners and then use social engineering, dropper malware, or exploits to distribute and install the trojanized cryptocurrency miners on target computers. Every month from September 2017 to January 2018, an average of 644,000 unique computers encountered coin mining malware.

Figure 1. Volume of unique computers that encountered trojanized coin miners

Interestingly, the proliferation of malicious cryptocurrency miners coincide with a decrease in the volume of ransomware. Are these two trends related? Are cybercriminals shifting their focus to cryptocurrency miners as primary source of income? Its not likely that cybercriminals will completely abandon ransomware operations any time soon, but the increase in trojanized cryptocurrency miners indicates that attackers are definitely exploring the possibilities of this newer method of illicitly earning money.

We have seen a wide range of malicious cryptocurrency miners, some of them incorporating more sophisticated mechanisms to infect targets, including the use of exploits or self-distributing malware. We have also observed that established malware families long associated with certain modus operandi, such as banking trojans, have started to include coin mining routines in recent variants. These developments indicate widespread cybercriminal interest in coin mining, with various attackers and cybercriminal groups launching attacks.

Infection vectors

The downward trend in ransomware encounters may be due to an observed shift in the payload of one of its primary infection vectors: exploit kits. Even though there has been a continuous decrease in the volume of exploit kit activity since 2016, these kits, which are available as a service in cybercriminal underground markets, are now also being used to distribute coin miners. Before ransomware, exploit kits were known to deploy banking trojans.

DDE exploits, which have also been known to distribute ransomware, are now delivering miners. For example, a sample of the malware detected as Trojan:Win32/Coinminer (SHA-256: 7213cbbb1a634d780f9bb861418eb262f58954e6e5dca09ca50c1e1324451293) is installed by Exploit:O97M/DDEDownloader.PA, a Word document that contains the DDE exploit. The exploit launches a cmdlet that executes a malicious PowerShell script (Trojan:PowerShell/Maponeir.A), which then downloads the trojanized miner: a modified version of the miner XMRig, which mines Monero cryptocurrency.

Other miners use reliable social engineering tactics to infect machines. Cybercriminals have been distributing a file called flashupdate, masquerading the file as the Flash Player. The download link itselfseen in spam campaigns and malicious websitesalso uses the string flashplayer. Detected as Trojan:Win32/Coinminer, this trojanized coin miner (SHA-256 abbf959ac30d23cf2882ec223966b0b8c30ae85415ccfc41a5924b29cd6bd4db) likewise uses a modified version of the XMRig miner.

Persistence mechanisms

For cryptocurrency miners, persistence is a key element. The longer they stay memory-resident and undetected, the longer they can mine using stolen computer resources. While more traditional persistence mechanisms like scheduled tasks and autostart registry entries are common, cybercriminals can also use more advanced methods like code injection and other fileless techniques, which can allow them to evade detection.

One example of coin mining malware that uses code injection is a miner detected as Trojan:Win32/CoinMiner.BW!bit (SHA-256: f9c67313230bfc45ba8ffe5e6abeb8b7dc2eddc99c9cebc111fcd7c50d11dc80), which spawns an instance of notepad.exe and then injects its code. Once in memory, it uses some binaries related to legitimate cryptocurrency miners but runs them using specific parameters so that coins are sent to the attackers wallet.

We also came across a malicious PowerShell script, detected as TrojanDownloader:PowerShell/CoinMiner (SHA-256: 5d7e0fcf45004a7a4e27dd42c131bcebfea04f14540bd0f17635505b42a96d6e), that downloads mining code that it executes using its own parameters. It adds a scheduled task so that it runs every time the computer starts.

Spreading capabilities and other behaviors

Some coin miners have other capabilities. For example, a miner detected as Worm:Win32/NeksMiner.A (SHA-256: 80f098ac43f17dbd0f7bb6bad719cc204ef76015cbcdae7b28227c4471d99238) drops a copy in the root folder of all available drives, including mapped network drives and removable drives, allowing it to spread as these drives are accessed using other computers. It then runs legitimate cryptocurrency miners but using its own parameters.

As trojanized cryptocurrency miners continue evolving to become the monetization tool of choice for cybercriminals, we can expect the miners to incorporate more behaviors from established threat types.

Browser-based coin miners (cryptojacking)

Coin mining scripts hosted on websites introduced a new class of browser-based threats a few years ago. The increased interest in cryptocurrencies has intensified this trend. When the said websites are accessed, the malicious scripts mine coins using the visiting devices computing power. While some websites claim legitimacy by prompting the visitor to allow the coin mining script to run, others are more dubious.

Some of these websites, usually video streaming sites, appear to have been set up by cybercriminals specifically for coin mining purposes. Others have been compromised and injected with the offending scripts. One such coin miner is hidden in multiple layers of iframes.

Figure 2. A sample coin mining script hidden in multiple layers of iframes in compromised websites

We have also seen have seen tech support scam websites that double as coin miners. Tech support scam websites employ techniques that can make it difficult to close the browser. Meanwhile, a coin mining script runs in the background and uses computer resources.

Figure 3. A sample tech support scam website with a coin mining script

Unauthorized use of legitimate coin miners

On top of malware and malicious websites, enterprises face the threat of another form of cryptocurrency miners: legitimate but unauthorized miners that employees and other parties sneak in to take advantage of sizable processing power in enterprise environments.

While the presence of these miners in corporate networks dont necessarily indicate a bigger attack, they are becoming a corporate issue because they consume precious computing resources that are meant for critical business processes. Miners in corporate networks also result in additional energy consumption, leading to unnecessary costs. Unlike their trojanized counterparts, which arrive through known infection methods, non-malicious but unauthorized cryptocurrency miners might be trickier to detect and block.

In January 2018, Windows enterprise customers who have enabled the potentially unwanted application (PUA) protection feature encountered coin miners in more than 1,800 enterprise machines, a huge jump from the months prior. We expect this number to grow exponentially as we heighten our crackdown on these unwanted applications.

Figure 4. Volume of unique computers in enterprise environments with PUA protection enabled that encountered unauthorized coin miners

While non-malicious, miners classified as potentially unwanted applications (PUA) are typically unauthorized for use in enterprise environments because they can adversely affect computer performance and responsiveness. In contrast, trojanized miners are classified as malware; as such, they are automatically detected and blocked by Microsoft security products. Potentially unwanted applications are further differentiated from unwanted software, which are also considered malicious because they alter your Windows experience without your consent or control.

Apart from coin mining programs, potentially unwanted applications include:

  • Programs that install other unrelated programs during installation, especially if those other programs are also potentially unwanted applications
  • Programs that hijack web browsing experience by injecting ads to pages
  • Driver and registry optimizers that detect issues, request payment to fix the errors, and remain on the computer
  • Programs that run in the background and are used for market research

PUA protection is enabled by default in System Center Configuration Manager. Security administrators can also enable and configure the PUA protection feature using PowerShell cmdlets or Microsoft Intune.

Windows Defender AV blocks potentially unwanted applications when a user attempts to download or install the application and if the program file meets one of several conditions. Potentially unwanted applications that are blocked appear in the quarantine list in the Windows Defender Security Center app.

In September 2017, around 2% of potentially unwanted applications blocked by Windows Defender AV are coin miners. This figure has increased to around 6% in January 2018, another indication of the increase of these unwanted applications in corporate networks.

Figure 5. Breakdown of potentially unwanted applications

Protecting corporate networks from cryptocurrency miners

Windows 10 Enterprise customers benefit from Windows Defender Advanced Threat Protection, a wide and robust set of security features and capabilities that help prevent coin minters and other malware.

Windows Defender AV uses multiple layers of protection to detect new and emerging threats. Non-malicious but unauthorized miners can be blocked using the PUA protection feature in Windows Defender AV. Enterprises can also use Windows Defender Application Control to set code integrity policies that prevent employees from installing malicious and unauthorized applications.

Trojanized cryptocurrency miners are blocked by the same machine learning technologies, behavior-based detection algorithms, generics, and heuristics that allow Window Defender AV to detect most malware at first sight and even stop malware outbreaks, such as the massive Dofoil coin miner campaign. By leveraging Antimalware Scan Interface (AMSI), which provides the capability to inspect script malware even with multiple layers of obfuscation, Windows Defender AV can also detect script-based coin miners.

Coin mining malware with more sophisticated behaviors or arrival methods like DDE exploit and malicious scripts launched from email or Office apps can be mitigated using Windows Defender Exploit Guard, particularly its Attack surface reduction and Exploit protection features.

Malicious websites that host coin miners, such as tech support scam pages with mining scripts, can be blocked by Microsoft Edge using Windows Defender SmartScreen and Windows Defender AV.

Corporate networks face the threat of both non-malicious and trojanized cryptocurrency miners. Windows 10 S, a special configuration of Windows 10, can help prevent threats like coin miners and other malware by working exclusively with apps from the Microsoft Store and by using Microsoft Edge as the default browser, providing Microsoft-verified security.

Security operations personnel can use the advanced behavioral and machine learning detection libraries in Windows Defender Endpoint Detection and Response (Windows Defender EDR) to detect coin mining activity and other anomalies in the network.

Figure 6. Windows Defender EDR detection for coin mining malware

Windows Defender EDR integrates detections from Windows Defender AV, Windows Defender Exploit Guard, and other Microsoft security products, providing seamless security management that can allow security operations personnel to centrally detect and respond to cryptocurrency miners and other threats in the network.

 

Alden Pornasdoro, Michael Johnson, and Eric Avena
Windows Defender 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.

FinFisher exposed: A researcher’s tale of defeating traps, tricks, and complex virtual machines

Office 365 Advanced Threat Protection (Office 365 ATP) blocked many notable zero-day exploits in 2017. In our analysis, one activity group stood out: NEODYMIUM. This threat actor is remarkable for two reasons:

  • Its access to sophisticated zero-day exploits for Microsoft and Adobe software
  • Its use of an advanced piece of government-grade surveillance spyware FinFisher, also known as FinSpy and detected by Microsoft security products as Wingbird

FinFisher is such a complex piece of malware that, like other researchers, we had to devise special methods to crack it. We needed to do this to understand the techniques FinFisher uses to compromise and persist on a machine, and to validate the effectiveness of Office 365 ATP detonation sandbox, Windows Defender Advanced Threat Protection (Windows Defender ATP) generic detections, and other Microsoft security solutions.

This task proved to be nontrivial. FinFisher is not afraid of using all kinds of tricks, ranging from junk instructions and spaghetti code to multiple layers of virtual machines and several known and lesser-known anti-debug and defensive measures. Security analysts are typically equipped with the tools to defeat a good number of similar tricks during malware investigations. However, FinFisher is in a different category of malware for the level of its anti-analysis protection. Its a complicated puzzle that can be solved by skilled reverse engineers only with good amount of time, code, automation, and creativity. The intricate anti-analysis methods reveal how much effort the FinFisher authors exerted to keep the malware hidden and difficult to analyze.

This exercise revealed tons of information about techniques used by FinFisher that we used to make Office 365 ATP more resistant to sandbox detection and Windows Defender ATP to catch similar techniques and generic behaviors. Using intelligence from our in-depth investigation, Windows Defender ATP can raise alerts for malicious behavior employed by FinFisher (such as memory injection in persistence) in different stages of the attack kill chain. Machine learning in Windows Defender ATP further flags suspicious behaviors observed related to the manipulation of legitimate Windows binaries.

Figure 1. Generic Windows Defender ATP detections trigger alerts on FinFisher behavior

While our analysis has allowed us to immediately protect our customers, wed like to share our insights and add to the growing number of published analyses by other talented researchers (listed below this blog post). We hope that this blog post helps other researchers to understand and analyze FinFisher samples and that this industry-wide information-sharing translate to the protection of as many customers as possible.

Spaghetti and junk codes make common analyst tools ineffective

In analyzing FinFisher, the first obfuscation problem that requires a solution is the removal of junk instructions and spaghetti code, which is a technique that aims to confuse disassembly programs. Spaghetti code makes the program flow hard to read by adding continuous code jumps, hence the name. An example of FinFishers spaghetti code is shown below.

Figure 2. The spaghetti code in FinFisher dropper

This problem is not novel, and in common situations there are known reversing plugins that may help for this task. In the case of FinFisher, however, we could not find a good existing interactive disassembler (IDA) plugin that can normalize the code flow. So we decided to write our own plugin code using IDA Python. Armed with this code, we removed this first layer of anti-analysis protection.

Removing the junk instructions revealed a readable block of code. This code starts by allocating two chunks of memory: a global 1 MB buffer and one 64 KB buffer per thread. The big first buffer is used as index for multiple concurrent threads. A big chunk of data is extracted from the portable executable (PE) file itself and decrypted two times using a custom XOR algorithm. We determined that this chunk of data contains an array of opcode instructions ready to be interpreted by a custom virtual machine program (from this point on referenced generically as VM) implemented by FinFisher authors.

Figure 3. The stages of the FinFisher multi-layered protection mechanisms

Stage 0: Dropper with custom virtual machine

The main dropper implements the VM dispatcher loop and can use 32 different opcodes handlers. Th 64KB buffer is used as a VM descriptor data structure to store data and the just-in-time (JIT) generated code to run. The VM dispatcher loop routine ends with a JMP to another routine. In total, there are 32 different routines, each of them implementing a different opcode and some basic functionality that the malware program may execute.

Figure 4. A snapshot of the code that processes each VM opcode and the associate interpreter

The presence of a VM and virtualized instruction blocks can be described in simpler terms: Essentially, the creators of FinFisher interposed a layer of dynamic code translation (the virtual machine) that makes analysis using regular tools practically impossible. Static analysis tools like IDA may not be useful in analyzing custom code that is interpreted and executed through a VM and a new set of instructions. On the other hand, dynamic analysis tools (like debuggers or sandbox) face the anti-debug and anti-analysis tricks hidden in the virtualized code itself that detects sandbox environments and alters the behavior of the malware.

At this stage, the analysis can only continue by manually investigating the individual code blocks and opcode handlers, which are highly obfuscated (also using spaghetti code). Reusing our deobfuscation tool and some other tricks, we have been able to reverse and analyze these opcodes and map them to a finite list that can be used later to automate the analysis process with some scripting.

The opcode instructions generated by this custom VM are divided into different categories:

  1. Logical opcodes, which implement bit-logic operators (OR, AND, NOT, XOR) and mathematical operators
  2. Conditional branching opcodes, which implement a code branch based on conditions (equals to JC, JE, JZ, other similar branching opcodes)
  3. Load/Store opcodes, which write to or read from particular addresses of the virtual address space of the process
  4. Specialized opcodes for various purposes, like execute specialized machine instruction that are not virtualized

We are publishing below the (hopefully) complete list of opcodes used by FinFisher VM that we found during our analysis and integrated into our de-virtualization script:

INDEX

MNEMONIC

DESCRIPTION

0x0

EXEC

Execute machine code

0x1

JG

Jump if greater/Jump if not less or equal

0x2

WRITE

Write a value into the dereferenced internal VM value (treated as a pointer)

0x3

JNO

Jump if not overflow

0x4

JLE

Jump if less or equal (signed)

0x5

MOV

Move the value of a register into the VM descriptor (same as opcode 0x1F)

0x6

JO

Jump if overflow

0x7

PUSH

Push the internal VM value to the stack

0x8

ZERO

Reset the internal VM value to 0 (zero)

0x9

JP

Jump if parity even

0xA

WRITE

Write into an address

0xB

ADD

Add the value of a register to the internal VM value

0xC

JNS

Jump if not signed

0xD

JL

Jump if less (signed)

0xE

EXEC

Execute machine code and branch

0xF

JBE

Jump if below or equal or Jump if not above

0x10

SHL

Shift left the internal value the number of times specified into the opcodes

0x11

JA

Jump if above/Jump if not below or equal

0x12

MOV

Move the internal VM value into a register

0x13

JZ

JMP if zero

0x14

ADD

Add an immediate value to the internal Vm descriptor

0x15

JB

Jump if below (unsigned)

0x16

JS

Jump if signed

0x17

EXEC

Execute machine code (same as opcode 0x0)

0x18

JGE

Jump if greater or equal/Jump if not less

0x19

DEREF

Write a register value into a dereferenced pointer

0x1A

JMP

Special obfuscated Jump if below opcode

0x1B

*

Resolve a pointer

0x1C

LOAD

Load a value into the internal VM descriptor

0x1D

JNE

Jump if not equal/Jump if not zero

0x1E

CALL

Call an external function or a function located in the dropper

0x1F

MOV

Move the value of a register into the VM descriptor

0x20

JNB

Jump if not below/Jump if above or equal/Jump if not carry

0x21

JNP

Jump if not parity/Jump if parity odd

 

Each virtual instruction is stored in a special data structure that contains all the information needed to be properly read and executed by the VM. This data structure is 24 bytes and is composed of some fixed fields and a variable portion that depends on the opcode. Before interpreting the opcode, the VM decrypts the opcodes content (through a simple XOR algorithm), which it then relocates (if needed), using the relocation fields.

Here is an approximate diagram of the opcode data structure:

Figure 5. A graphical representation of the data structure used to store each VM opcode

The VM handler is completely able to generate different code blocks and deal with relocated code due to address space layout randomization (ASLR). It is also able to move code execution into different locations if needed. For instance, in the case of the Execute opcode (0x17), the 32-bit code to run is stored entirely into the variable section with the value at offset 5 specifying the number of bytes to be copied and executed. Otherwise, in the case of conditional opcodes, the variable part can contain the next JIT packet ID or the next relative virtual address (RVA) where code execution should continue.

Of course, not all the opcodes are can be easily read and understood due to additional steps that the authors have taken to make analysis extremely complicated. For example, this is how opcode 0x1A is implemented: The opcode should represent a JB (Jump if below) function, but its implemented through set carry (STC) instruction followed by a JMP into the dispatcher code that will verify the carry flag condition set by STC.

Figure 6. One of the obfuscation tricks included by the malware authors in a VM opcode dispatcher

Even armed with the knowledge we have described so far, it still took us many hours to write a full-fledged opcode interpreter thats able to reconstruct the real code executed by FinFisher.

Stage 1: Loader malware keeps sandbox and debuggers away

The first stage of FinFisher running through this complicated virtual machine is a loader malware designed to probe the system and determine whether its running in a sandbox environment (typical for cloud-based detonation solution like Office 365 ATP).

The loader first dynamically rebuilds a simple import address table (IAT), resolving all the API needed from Kernel32 and NtDll libraries. It then continues executing in a spawned new thread that checks if there are additional undesired modules inside its own virtual address space (for example, modules injected by certain security solutions). It eventually kills all threads that belong to these undesired modules (using ZwQueryInformationThread native API with ThreadQuerySetWin32StartAddress information class).

The first anti-sandbox technique is the loader checking the code segment. If its not 0x1B (for 32-bit systems) or 0x23 (for 32-bit system under Wow64), the loader exits.

Next, the dropper checks its own parent process for indications that it is running in a sandbox setup. It calculates the MD5 hash of the lower-case process image name and terminates if one of the following conditions are met:

  1. The MD5 hash of the parent process image name is either D0C4DBFA1F3962AED583F6FCE666F8BC or 3CE30F5FED4C67053379518EACFCF879
  2. The parent processs full image path is equal to its own process path

If these initial checks are passed, the loader builds a complete IAT by reading four imported libraries from disk (ntdll.dll, kernel32.dll, advapi32.dll, and version.dll) and remapping them in memory. This technique makes use of debuggers and software breakpoints useless. During this stage, the loader may also call a certain API using native system calls, which is another way to bypass breakpoints on API and security solutions using hooks.

Figure 7. FinFisher loader calling native Windows API to perform anti-debugging tricks

At this point, the fun in analysis is not over. A lot of additional anti-sandbox checks are performed in this exact order:

  1. Check that the malware is not executed under the root folder of a drive
  2. Check that the malware file is readable from an external source
  3. Check that the hash of base path is not 3D6D62AF1A7C8053DBC8E110A530C679
  4. Check that the full malware path contains only human readable characters (a-z, A-Z, and 0-9)
  5. Check that no node in the full path contains the MD5 string of the malware file
  6. Fingerprint the system and check the following registry values:

    1. HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid should not be “6ba1d002-21ed-4dbe-afb5-08cf8b81ca32”
    2. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId should not be “55274-649-6478953-23109”, “A22-00001”, or “47220”
    3. HARDWARE\Description\System\SystemBiosDate should not contain 01/02/03

  7. Check that the mutex WininetStartupMutex0 does not already exist
  8. Check that no DLL whose base name has hash value of 0xC9CEF3E4 is mapped into the malware address space

The hashes in these checks are most likely correspond to sandbox or security products that the FinFisher authors want to avoid.

Next, the loader checks that its not running in a virtualized environment (VMWare or Hyper-V) or under a debugger. For the hardware virtualization check, the loader obtains the hardware device list and checks if the MD5 of the vendor ID is equal to a predefined list. In our tests, the malware sample was able to easily detect both VMWare and Hyper-V environments through the detection of the virtualized peripherals (for example, Vmware has VEN_15AD as vendor ID, HyperV has VMBus as bus name). Office 365 ATP sandbox employs special mechanisms to avoid being detected by similar checks.

The loaders anti-debugger code is based on the following three methods:

  1. The first call aims to destroy the debugger connection:
    ZwSetInformationThread(GetCurrentProcess(), ThreadHideFromDebugger, NULL, 0);
    NOTE: This call completely stops the execution of WinDbg and other debuggers
  2. The second call tries to detect the presence of a debugger:
    ZwQueryInformationProcess(CurProc, ProcessDebugPort, &debugPort, sizeof(ULONG_PTR))
    ZwQueryInformationProcess(CurProc, ProcessDebugObjectHandle, &debugObjHandle, sizeof(ULONG_PTR))
  3. The final call tries to destroy the possibility of adding software breakpoint:
    VirtualProtectEx(CurProc, &DbgBreakPoint, 1, PAGE_RWX, &oldProtect)
    DbgBreakPoint[0] = 0x90; // Place a NOP opcode instead the standard INT 3

Finally, if the loader is happy with all the checks done so far, based on the victim operating system (32 or 64-bit) it proceeds to decrypt a set of fake bitmap resources (stage 2) embedded in the executable and prepares the execution of a new layer of VM decoding.

Each bitmap resource is extracted, stripped of the first 0x428 bytes (BMP headers and garbage data), and combined into one file. The block is decrypted using a customized algorithm that uses a key derived from the original malware droppers TimeDateStamp field multiplied by 5.

Figure 8. The fake bitmap image embedded as resource

The 32-bit stage 2 malware uses a customized loading mechanism (i.e., the PE file has a scrambled IAT and relocation table) and exports only one function. For the 64-bit stage 2 malware, the code execution is transferred from the loader using a well-known technique called Heavens Gate. In the next sections, for simplicity, we will continue the analysis only on the 64-bit payload.

Figure 9. Heavens gate is still in use in 2017

Stage 2: A second multi-platform virtual machine

The 64-bit stage 2 malware implements another loader combined with another virtual machine. The architecture is quite similar to the one described previously, but the opcodes are slightly different. After reversing these opcodes, we were able to update our interpreter script to support both 32-bit and 64-bit virtual machines used by FinFisher.

INDEX

MNEMONIC

DESCRIPTION

0x0

JMP

Special obfuscated conditional Jump (always taken or always ignored)

0x1

JMP

Jump to a function (same as opcode 0x10)

0x2

CALL

Call to the function pointed by the internal VM value

0x3

CALL

Optimized CALL function (like the 0x1E opcode of the 32-bit VM)

0x4

EXEC

Execute code and move to the next packet

0x5

JMP

Jump to an internal function

0x6

NOP

No operation, move to the next packet

0x7

CALL

Call an imported API (whose address is stored in the internal VM value)

0x8

LOAD

Load a value into the VM descriptor structure *

0x9

STORE

Store the internal VM value inside a register

0xA

WRITE

Resolve a pointer and store the value of a register in its content

0xB

READ

Move the value pointed by the VM internal value into a register

0xC

LOAD

Load a value into the VM descriptor structure (not optimized)

0xD

CMP

Compare the value pointed by the internal VM descriptor with a register

0xE

CMP

Compare the value pointed by the internal VM descriptor with an immediate value

0xF

XCHG

Exchange the value pointed by the internal VM descriptor with a register

0x10

SHL

Jump to a function (same as opcode 0x1)

 

This additional virtual machine performs the same duties as the one already described but in a 64-bit environment. It extracts and decrypts the stage 3 malware, which is stored in encrypted resources such as fake dialog boxes. The extraction method is the same, but the encryption algorithm (also XOR) is much simpler. The new payload is decrypted, remapped, and executed in memory, and represents the installation and persistence stage of the malware.

Stage 3: Installer that takes DLL side-loading to a new level

Stage 3 represents the setup program for FinFisher. It is the first plain stage that does not employ a VM or obfuscation. The code supports two different installation methods: setup in a UAC-enforced environment (with limited privileges), or an installation with full-administrative privileges enabled (in cases where the malware gains the ability to run with elevated permissions). We were a bit disappointed that we did not see traces of a true privilege escalation exploit after all this deobfuscation work, but it seems these FinFisher samples were designed to work just using UAC bypasses.

The setup code receives an installation command from the previous stage. In our test, this command was the value 3. The malware creates a global event named 0x0A7F1FFAB12BB2 and drops some files under a folder located in C:\ProgramData or in the user application data folder. The name of the folder and the malware configuration are read from a customized configuration file stored in the resource section of the setup program.

Here the list of the files potentially dropped during the installation stage:

FILE NAME STAGE DESCRIPTION
d3d9.dll Stage 4 Malware loader used for UAC environments with limited privileges; also protected by VM obfuscation
aepic.dll
sspisrv.dlluserenv.dll
Stage 4 Malware loader used in presence of administrative privileges; executed from (and injected into) a fake service; also protected by VM obfuscation
msvcr90.dll Stage 5 Malware payload injected into the explorer.exe or winlogon.exe process; also protected by VM obfuscation
<randomName>.cab Config Main configuration file; encrypted

 

setup.cab Unknown Last section of the setup executable; content still unknown
<randomName>.7z Plugin Malware plugin used to spy the victim network communications
wsecedit.rar Stage 6 Main malware executable

 

After writing some of these files, the malware decides which kind of installation to perform based on the current privilege provided by the hosting process (for example, if a Microsoft Office process was used as exploit vector):

  1. Installation process under UAC

When running under a limited UAC account, the installer extracts d3d9.dll and creates a persistence key under HKCU\Software\Microsoft\Windows\Run. The malware sets a registry value (whose name is read from the configuration file) to C:\Windows\system32\rundll32.exe c:\ProgramData\AuditApp\d3d9.dll, Control_Run. Before doing this, the malware makes a screenshot of the screen and displays it on top of all other windows for few seconds. This indicates that the authors are trying to hide some messages showed by the system during the setup process.

When loaded with startup command 2, the installer can copy the original explorer.exe file inside its current running directory and rename d3d9.dll to uxtheme.dll. In this case the persistence is achieved by loading the original explorer.exe from its startup location and, using DLL side-loading, passing the execution control to the stage 4 malware (discussed in next section).

Finally, the malware spawns a thread that has the goal to load, remap, and relocate the stage 5 malware. In this context, there is indeed no need to execute the stage 4 malware. The msvcr90.dll file is opened, read, and decrypted, and the code execution control is transferred to the RunDll exported routine.

In the case of 32-bit systems, the malware may attempt a known UAC bypass by launching printui.exe system process and using token manipulation with NtFilterToken as described in this blog post.

  1. Installation process with administrative privilege

This installation method is more interesting because it reveals how the malware tries to achieve stealthier persistence on the machine. The method is a well-known trick used by penetration testers that was automated and generalized by FinFisher

The procedure starts by enumerating the KnownDlls object directory and then scanning for section objects of the cached system DLLs. Next, the malware enumerates all .exe programs in the %System% folder and looks for an original signed Windows binary that imports from at least one KnownDll and from a library that is not in the KnownDll directory. When a suitable .exe file candidate is found, it is copied into the malware installation folder (for example, C:\ProgramData). At this point the malware extracts and decrypts a stub DLL from its own resources (ID 101). It then calls a routine that adds a code section to a target module. This section will contain a fake export table mimicking the same export table of the original system DLL chosen. At the time of writing, the dropper supports aepic.dll, sspisrv.dll, ftllib.dll, and userenv.dll to host the malicious FinFisher payload. Finally, a new Windows service is created with the service path pointing to the candidate .exe located in this new directory together with the freshly created, benign-looking DLL.

In this way, when the service runs during boot, the original Windows executable is executed from a different location and it will automatically load and map the malicious DLL inside its address space, instead of using the genuine system library. This routine is a form of generic and variable generator of DLL side-loading combinations.

Figure 10. Windows Defender ATP timeline can pinpoint the service DLL side-loading trick (in this example, using fltlib.dll).

In the past, we have seen other activity groups like LEAD employ a similar attacker technique named proxy-library to achieve persistence, but not with this professionalism. The said technique brings the advantage of avoiding auto-start extensibility points (ASEP) scanners and programs that checks for binaries installed as service (for the latter, the service chosen by FinFisher will show up as a clean Windows signed binary).

The malware cleans the system event logs using OpenEventLog/ClearEventLog APIs, and then terminates the setup procedure with a call to StartService to run the stage 4 malware.

Figure 11. The DLL side-loaded stage 4 malware mimicking a real export table to avoid detection

Stage 4: The memory loader Fun injection with GDI function hijacking

Depending on how stage 4 was launched, two different things may happen:

  • In the low-integrity case (under UAC) the installer simply injects the stage 5 malware into the bogus explorer.exe process started earlier and terminates
  • In the high-integrity case (with administrative privileges or after UAC bypass), the code searches for the process hosting the Plug and Play service (usually svchost.exe) loaded in memory and injects itself into it

For the second scenario, the injection process works like this:

  1. The malware opens the target service process.
  2. It allocates and fills four chunks of memory inside the service process. One chunk contains the entire malware DLL code (without PE headers). Another chunk is used to copy a basic Ntdll and Kernel32 import address table. Two chunks are filled with an asynchronous procedure call (APC) routine code and a stub.
  3. It opens the service thread of the service process and uses the ZwQueueApcThread native API to inject an APC.

The APC routine creates a thread in the context of the svchost.exe process that will map and execute the stage 5 malware into the winlogon.exe process.

The injection method used for winlogon.exe is also interesting and quite unusual. We believe that this method is engineered to avoid trivial detection of process injection using the well-detected CreateRemoteThread or ZwQueueApcThread API.

The malware takes these steps:

  1. Check if the system master boot record (MBR) contains an infection marker (0xD289C989C089 8-bytes value at offset 0x2C), and, if so, terminate itself
  2. Check again if the process is attached to a debugger (using the techniques described previously)
  3. Read, decrypt, and map the stage 5 malware (written in the previous stage in msvcr90.dll)
  4. Open winlogon.exe process
  5. Load user32.dll system library and read the KernelCallbackTable pointer from its own process environment block (PEB) (Note: The KernelCallbackTable points to an array of graphic functions used by Win32 kernel subsystem module win32k.sys as call-back into user-mode.)
  6. Calculate the difference between this pointer and the User32 base address.
  7. Copy the stage 5 DLL into winlogon.exe
  8. Allocate a chunk of memory in winlogon.exe process and copy the same APC routine seen previously
  9. Read and save the original pointer of the __fnDWORD internal User32 routine (located at offset +0x10 of the KernelCallbackTable) and replace this pointer with the address of the APC stub routine

After this function pointer hijacking, when winlogon.exe makes any graphical call (GDI), the malicious code can execute without using CreateRemoteThread or similar triggers that are easily detectable. After execution it takes care of restoring the original KernelCallbackTable.

Stage 5: The final loader takes control

The stage 5 malware is needed only to provide one more layer of obfuscation, through the VM, of the final malware payload and to set up a special Structured Exception Hander routine, which is inserted as Wow64PrepareForException in Ntdll. This special exception handler is needed to manage some memory buffers protection and special exceptions that are used to provide more stealthy execution.

After the VM code has checked again the user environment, it proceeds to extract and execute the final un-obfuscated payload sample directly into winlogon.exe (alternatively, into explorer.exe) process. After the payload is extracted, decrypted, and mapped in the process memory, the malware calls the new DLL entry point, and then the RunDll exported function. The latter implements the entire spyware program.

Stage 6: The payload is a modular spyware framework for further analysis

Our journey to deobfuscating FinFisher has allowed us to uncover the complex anti-analysis techniques used by this malware, as well as to use this intel to protect our customers, which is our top priority. Analysis of the additional spyware modules is future work.

It is evident that the ultimate goal of this program is to steal information. The malware architecture is modular, which means that it can execute plugins. The plugins are stored in its resource section and can be protected by the same VM. The sample we analyzed in October, for example, contains a plugin that is able to spy on internet connections, and can even divert some SSL connections and steal data from encrypted traffic.

Some FinFisher variants incorporate an MBR rootkit, the exact purpose of which is not clear. Quite possibly, this routine targets older platforms like Windows 7 and machines not taking advantage of hardware protections like UEFI and SecureBoot, available on Windows 10. Describing this additional piece of code in detail is outside the scope of this analysis and may require a new dedicated blog post.

Defense against FinFisher

Exposing as much of FinFishers riddles as possible during this painstaking analysis has allowed us to ensure our customers are protected against this advanced piece of malware.

Windows 10 S devices are naturally protected against FinFisher and other threats thanks to the strong code integrity policies that dont allow unknown unsigned binaries to run (thus stopping FinFishers PE installer) or loaded (blocking FinFishers DLL persistence). On Windows 10, similar code integrity policies can be configured using Windows Defender Application Control.

Office 365 Advanced Threat Protection secures mailboxes from email campaigns that use zero-day exploits to deliver threats like FinFisher. Office 365 ATP blocks unsafe attachments, malicious links, and linked-to files using time-of-click protection. Using intel from this research, we have made Office 365 ATP more resistant to FinFishers anti-sandbox checks.

Generic detections, advanced behavioral analytics, and machine learning technologies in Windows Defender Advanced Threat Protection detect FinFishers malicious behavior throughout the attack kill chain and alert SecOps personnel. Windows Defender ATP also integrates with the Windows protection stack so that protections from Windows Defender AV and Windows Defender Exploit Guard are reported in Windows Defender ATP portal, enabling SecOps personnel to centrally manage security, and as well as promptly investigate and respond to hostile activity in the network.

We hope that this writeup of our journey through all the multiple layers of protection, obfuscation, and anti-analysis techniques of FinFisher will be useful to other researchers studying this malware. We believe that an industry-wide collaboration and information-sharing is important in defending customers against this complex piece of malware. For further reading, we recommend these other great references:

 

Andrea Allievi, Office 365 ATP Research team
with Elia Florio, Windows Defender ATP Research team

 

Sample analyzed:

MD5: a7b990d5f57b244dd17e9a937a41e7f5
SHA-1: c217d48c4ac1555491348721cc7cfd1143fe0b16
SHA-256: b035ca2d174e5e4fd2d66fd3c8ce4ae5c1e75cf3290af872d1adb2658852afb8

 

 


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.

Categories: cybersecurity Tags:

How artificial intelligence stopped an Emotet outbreak

February 14th, 2018 No comments

At 12:46 a.m. local time on February 3, a Windows 7 Pro customer in North Carolina became the first would-be victim of a new malware attack campaign for Trojan:Win32/Emotet. In the next 30 minutes, the campaign tried to attack over a thousand potential victims, all of whom were instantly and automatically protected by Windows Defender AV.

How did Windows Defender AV uncover the newly launched attack and block it at the outset? Through layered machine learning, including use of both client-side and cloud machine learning (ML) models. Every day, artificial intelligence enables Windows Defender AV to stop countless malware outbreaks in their tracks. In this blog post, well take a detailed look at how the combination of client and cloud ML models detects new outbreaks.

Figure 1. Layered detected model in Windows Defender AV

Client machine learning models

The first layer of machine learning protection is an array of lightweight ML models built right into the Windows Defender AV client that runs locally on your computer. Many of these models are specialized for file types commonly abused by malware authors, including, JavaScript, Visual Basic Script, and Office macro. Some models target behavior detection, while other models are aimed at detecting portable executable (PE) files (.exe and .dll).

In the case of the Emotet outbreak on February 3, Windows Defender AV caught the attack using one of the PE gradient boosted tree ensemble models. This model classifies files based on a featurization of the assembly opcode sequence as the file is emulated, allowing the model to look at the files behavior as it was simulated to run.

Figure 2. A client ML model classified the Emotet outbreak as malicious based on emulated execution opcode machine learning model.

The tree ensemble was trained using LightGBM, a Microsoft open-source framework used for high-performance gradient boosting.

Figure 3a. Visualization of the LightBGM-trained client ML model that successfully classified Emotet’s emulation behavior as malicious. A set of 20 decision trees are combined in this model to classify whether the files emulated behavior sequence is malicious or not.

Figure 3b. A more detailed look at the first decision tree in the model. Each decision is based on the value of a different feature. Green triangles indicate weighted-clean decision result; red triangles indicate weighted malware decision result for the tree.

When the client-based machine learning model predicts a high probability of maliciousness, a rich set of feature vectors is then prepared to describe the content. These feature vectors include:

  • Behavior during emulation, such as API calls and executed code
  • Similarity fuzzy hashes
  • Vectors of content descriptive flags optimized for use in ML models
  • Researcher-driven attributes, such as packer technology used for obfuscation
  • File name
  • File size
  • Entropy level
  • File attributes, such as number of sections
  • Partial file hashes of the static and emulated content

This set of features form a signal sent to the Windows Defender AV cloud protection service, which runs a wide array of more complex models in real-time to instantly classify the signal as malicious or benign.

Real-time cloud machine learning models

Windows Defender AVs cloud-based real-time classifiers are powerful and complex ML models that use a lot of memory, disk space, and computational resources. They also incorporate global file information and Microsoft reputation as part of the Microsoft Intelligent Security Graph (ISG) to classify a signal. Relying on the cloud for these complex models has several benefits. First, it doesnt use your own computers precious resources. Second, the cloud allows us to take into consideration the global information and reputation information from ISG to make a better decision. Third, cloud-based models are harder for cybercriminals to evade. Attackers can take a local client and test our models without our knowledge all day long. To test our cloud-based defenses, however, attackers have to talk to our cloud service, which will allow us to react to them.

The cloud protection service is queried by Windows Defender AV clients billions of times every day to classify signals, resulting in millions of malware blocks per day, and translating to protection for hundreds of millions of customers. Today, the Windows Defender AV cloud protection service has around 30 powerful models that run in parallel. Some of these models incorporate millions of features each; most are updated daily to adapt to the quickly changing threat landscape. All together, these classifiers provide an array of classifications that provide valuable information about the content being scanned on your computer.

Classifications from cloud ML models are combined with ensemble ML classifiers, reputation-based rules, allow-list rules, and data in ISG to come up with a final decision on the signal. The cloud protection service then replies to the Windows Defender client with a decision on whether the signal is malicious or not all in a fraction of a second.

Figure 4. Windows Defender AV cloud protection service workflow.

In the Emotet outbreak, one of our cloud ML servers in North America received the most queries from customers; corresponding to where the outbreak began. At least nine real-time cloud-based ML classifiers correctly identified the file as malware. The cloud protection service replied to signals instructing the Windows Defender AV client to block the attack using two of our ML-based threat names, Trojan:Win32/Fuerboos.C!cl and Trojan:Win32/Fuery.A!cl.

This automated process protected customers from the Emotet outbreak in real-time. But Windows Defender AVs artificial intelligence didnt stop there.

Deep learning on the full file content

Automatic sample submission, a Windows Defender AV feature, sent a copy of the malware file to our backend systems less than a minute after the very first encounter. Deep learning ML models immediately analyzed the file based on the full file content and behavior observed during detonation. Not surprisingly, deep neural network models identified the file as a variant of Trojan:Win32/Emotet, a family of banking Trojans.

While the ML classifiers ensured that the malware was blocked at first sight, deep learning models helped associate the threat with the correct malware family. Customers who were protected from the attack can use this information to understand the impact the malware might have had if it were not stopped.

Additionally, deep learning models provide another layer of protection: in relatively rare cases where real-time classifiers are not able to come to a conclusive decision about a file, deep learning models can do so within minutes. For example, during the Bad Rabbit ransomware outbreak, Windows Defender AV protected customers from the new ransomware just 14 minutes after the very first encounter.

Intelligent real-time protection against modern threats

Machine learning and AI are at the forefront of the next-gen real-time protection delivered by Windows Defender AV. These technologies, backed by unparalleled optics into the threat landscape provided by ISG as well as world-class Windows Defender experts and researchers, allow Microsoft security products to quickly evolve and scale to defend against the full range of attack scenarios.

Cloud-delivered protection is enabled in Windows Defender AV by default. To check that its running, go to Windows Settings > Update & Security > Windows Defender. Click Open Windows Defender Security Center, then navigate to Virus & threat protection > Virus &threat protection settings, and make sure that Cloud-delivered protection and Automatic sample submission are both turned On.

In enterprise environments, the Windows Defender AV cloud protection service can be managed using Group Policy, System Center Configuration Manager, PowerShell cmdlets, Windows Management Instruction (WMI), Microsoft Intune, or via the Windows Defender Security Center app.

The intelligent real-time defense in Windows Defender AV is part of the next-gen security technologies in Windows 10 that protect against a wide spectrum of threats. Of particular note, Windows 10 S is not affected by this type of malware attack. Threats like Emotet wont run on Windows 10 S because it exclusively runs apps from the Microsoft Store. Learn more about Windows 10 S. To know about all the security technologies available in Windows 10, read Microsoft 365 security and management features available in Windows 10 Fall Creators Update.

 

Geoff McDonald, Windows Defender Research
with Randy Treit and Allan Sepillo

 

 


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.

Protecting customers from being intimidated into making an unnecessary purchase

January 30th, 2018 No comments

There has been an increase in free versions of programs that purport to scan computers for various errors, and then use alarming, coercive messages to scare customers into buying a premium version of the same program. The paid version of these programs, usually called cleaner or optimizer applications, purportedly fixes the problems discovered by the free version. We find this practice problematic because it can pressure customers into making unnecessary purchase decisions.

To help protect customers from receiving such coercive messaging, we are updating our evaluation criteria to specify that programs must not use alarming or coercive messaging that can put pressure on customers into making a purchase or performing other actions. We use the evaluation criteria to determine what programs are identified as malware and unwanted software. In the future, programs that display coercive messaging will be classified as unwanted software, detected, and removed.

This update comes in addition to our other long-standing customer protection requirements designed to keep our customers from being deceived by programs that display misleading, exaggerated, or threatening messages about a systems health. In February 2016, we required cleaner and optimizer programs that purport to clean up systems and optimize performance to provide customers with detailed information about what purportedly needs to be fixed. This requirement aims to protect customers from programs that present aggregate “error results with no specific details, without providing customers with the ability to assess and validate the so-called errors.

We have recently updated our evaluation criteria to state:

Unwanted behaviors: coercive messaging

Programs must not display alarming or coercive messages or misleading content to pressure you into paying for additional services or performing superfluous actions.

Software that coerces users may display the following characteristics, among others:

  • Reports errors in an exaggerated or alarming manner about the users system and requires the user to pay for fixing the errors or issues monetarily or by performing other actions such as taking a survey, downloading a file, signing up for a newsletter, etc.
  • Suggests that no other actions will correct the reported errors or issues
  • Requires the user to act within a limited period of time to get the purported issue resolved

Starting March 1, 2018, Windows Defender Antivirus and other Microsoft security products will classify programs that display coercive messages as unwanted software, which will be detected and removed. If you are software developer and want to validate the detection of your programs, visit the Windows Defender Security Intelligence portal.

Customer protection is our top priority. We adjust, expand, and update our evaluation criteria based on customer feedback and in order to capture the latest developments in unwanted software and other threats. We encourage our customers to submit programs that exhibit unwanted behaviors related to coercive messaging, or other unwanted or malicious behaviors in general.

 

Barak Shein
Windows Defender Security 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.

Categories: cybersecurity Tags:

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:

Tip
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

Tip
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.

Detonating a bad rabbit: Windows Defender Antivirus and layered machine learning defenses

December 11th, 2017 No comments

Windows Defender Antivirus uses a layered approach to protection: tiers of advanced automation and machine learning models evaluate files in order to reach a verdict on suspected malware. While Windows Defender AV detects a vast majority of new malware files at first sight, we always strive to further close the gap between malware release and detection.

In a previous blog post, we looked at a real-world case study showing how Windows Defender Antivirus cloud protection service leverages next-gen security technologies to save “patient zero” from new malware threats in real-time. In that case study, a new Spora ransomware variant was analyzed and blocked within seconds using a deep neural network (DNN) machine learning classifier in the cloud. In this blog post well look at how additional automated analysis and machine learning models can further protect customers within minutes in rare cases where initial classification is inconclusive.

Layered machine learning models

In Windows Defender AVs layered approach to defense, if the first layer doesnt detect a threat, we move on to the next level of inspection. As we move down the layers, the amount of time required increases. However, we catch the vast majority of malware at the first (fastest) protection layers and only need to move on to a more sophisticated (but slower) level of inspection for rarer/more advanced threats.

For example, the vast majority of scanned objects are evaluated by the local Windows Defender client machine learning models, behavior-based detection algorithms, generic and heuristic classifications, and more. This helps ensure that users get the best possible performance. In rare cases where local intelligence cant reach a definitive verdict, Windows Defender AV will use the cloud for deeper analysis.

Figure 1. Layered detection model

For a more detailed look at our approach to protection, see The evolution of malware prevention.

Detonation-based machine learning classification

We use a variety of machine learning models that use different algorithms to predict whether a certain file is malware. Some of these algorithms are binary classifiers that give a strict clean-or-malware verdict (0 or 1), while others are multi-class classifiers that provide a probability for each classification (malware, clean, potentially unwanted application, etc). Each machine learning model is trained against a set of different features (often thousands, sometimes hundreds of thousands) to learn to distinguish between different kinds of programs.

For the fastest classifiers in our layered stack, the features may include static attributes of the file combined with events (for example, API calls or behaviors) seen while the scanning engine emulates the file using dynamic translation. If the results from these models are inconclusive, well take an even more in-depth look at what the malware does by actually executing it in a sandbox and observing its run-time behavior. This is known as dynamic analysis, or detonation, and happens automatically whenever we receive a new suspected malware sample.

The activities seen in the sandbox machine (for example, registry changes, file creation/deletion, process injection, network connections, and so forth) are recorded and provided as features to our ML models. These models can then combine both the static features obtained from scanning the file with the dynamic features observed during detonation to arrive at an even stronger prediction.

Figure 2. Detonation-based machine learning classification

Ransom:Win32/Tibbar.A Protection in 14 minutes

On October 24, 2017, in the wake of recent ransomware outbreaks such as Wannacry and NotPetya, news broke of a new threat spreading, primarily in Ukraine and Russia: Ransom:Win32/Tibbar.A (popularly known as Bad Rabbit).

This threat is a good example of how detonation-based machine learning came into play to protect Windows Defender AV customers. First though, lets look at what happened to patient zero.

At 11:17 a.m. local time on October 24, a user running Windows Defender AV in St. Petersburg, Russia was tricked into downloading a file named FlashUtil.exe from a malicious website. Instead of a Flash update, the program was really the just-released Tibbar ransomware.

Windows Defender AV scanned the file and determined that it was suspicious. A query was sent to the cloud protection service, where several metadata-based machine learning models found the file suspicious, but not with a high enough probability to block. The cloud protection service requested that Windows Defender AV client to lock the file, upload it for processing, and wait for a decision.

Within a few seconds the file was processed, and sample-analysis-based ML models returned their conclusions. In this case, a multi-class deep neural network (DNN) machine learning classifier correctly classified the Tibbar sample as malware, but with only an 81.6% probability score. In order to avoid false positives, cloud protection service is configured by default to require at least 90% probability to block the malware (these thresholds are continually evaluated and fine-tuned to find the right balance between blocking malware while avoiding the blocking of legitimate programs). In this case, the ransomware was allowed to run.

Figure 3. Ransom:Win32/Tibbar.A ransom note

Detonation chamber

In the meantime, while patient zero and eight other unfortunate victims (in Ukraine, Russia, Israel, and Bulgaria) contemplated whether to pay the ransom, the sample was detonated and details of the system changes made by the ransomware were recorded.

Figure 4. Sample detonation events used by the machine learning model

As soon as the detonation results were available, a multi-class deep neural network (DNN) classifier that used both static and dynamic features evaluated the results and classified the sample as malware with 90.7% confidence, high enough for the cloud to start blocking.

When a tenth Windows Defender AV customer in the Ukraine was tricked into downloading the ransomware at 11:31 a.m. local time, 14 minutes after the first encounter, cloud protection service used the detonation-based malware classification to immediately block the file and protect the customer.

At this point the cloud protection service had “learned” that this file was malware. It now only required metadata from the client with the hash of the file to issue blocking decisions and protect customers. As the attack gained momentum and began to spread, Windows Defender AV customers with cloud protection enabled were protected. Later, a more specific detection was released to identify the malware as Ransom:Win32/Tibbar.A.

Closing the gap

While we feel good about Windows Defender AV’s layered approach to protection, digging deeper and deeper with automation and machine learning in order to finally reach a verdict on suspected malware, we are continually seeking to close the gap even further between malware release and protection. The cases where we cannot block at first sight are increasingly rare, but there is so much to be done. As our machine learning models are continuously updated and retrained, we are able to make better predictions over time. Yet malware authors will not rest, and the ever-changing threat landscape requires continuous investment in new and better technologies to detect new threats, but also to effectively differentiate the good from the bad.

What about systems that do get infected while detonation and classification are underway? One area that we’re actively investing in is advanced remediation techniques that will let us reach back out to those systems in an organization that were vulnerable and, if possible, get them back to a healthy state.

If you are organization that is willing to accept a higher false positive risk in exchange for stronger protection, you can configure the cloud protection level to tell the Windows Defender AV cloud protection service to take a more aggressive stance towards suspicious files, such as blocking at lower machine learning probability thresholds. In the Tibbar example above, for example, a configuration like this could have protected patient zero using the initial 81% confidence score, and not wait for the higher confidence (detonation-based) result that came later. You can also configure the cloud extended timeout to give the cloud protection service more time to evaluate a first-seen threat.

As another layer of real-time protection against ransomware, enable Controlled folder access, which is one of the features of the new Windows Defender Exploit Guard. Controlled folder access protects files from tampering by locking folders so that ransomware and other unauthorized apps cant access them.

For enterprises, Windows Defender Exploit Guards other features (Attack Surface Reduction, Exploit protection, and Network protection) further protect networks from advanced attacks. Windows Defender Advanced Threat Protection can also alert security operations personnel about malware activities in the network so that personnel can promptly investigate and respond to attacks.

For users running Windows 10 S, malware like Tibbar simply wont run. Windows 10 S provides advanced levels of security by exclusively running apps from the Microsoft Store. Threats such as Tibbar are non-issues for Windows 10 S users. Learn more about Windows 10 S.

New machine learning and AI techniques, in combination with both static and dynamic analysis, gives Windows Defender AV the ability to block more and more malware threats at first sight and, if that fails, learn as quickly as possible that something is bad and start blocking it. Using a layered approach, with different ML models at each layer, gives us the ability to target a wide variety of threats quickly while maintaining low false positive rates. As we gather more data about a potential threat, we can provide predictions with higher and higher confidence and take action accordingly. It is an exciting time to be in the fray.

 

Randy Treit

Senior Security Researcher, Windows Defender 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.

 

Microsoft teams up with law enforcement and other partners to disrupt Gamarue (Andromeda)

December 4th, 2017 No comments

Today, with help from Microsoft security researchers, law enforcement agencies around the globe, in cooperation with Microsoft Digital Crimes Unit (DCU), announced the disruption of Gamarue, a widely distributed malware that has been used in networks of infected computers collectively called the Andromeda botnet.

The disruption is the culmination of a journey that started in December 2015, when the Microsoft Windows Defender research team and DCU activated a Coordinated Malware Eradication (CME) campaign for Gamarue. In partnership with internet security firm ESET, we performed in-depth research into the Gamarue malware and its infrastructure.

Our analysis of more than 44,000 malware samples uncovered Gamarues sprawling infrastructure. We provided detailed information about that infrastructure to law enforcement agencies around the world, including:

  • 1,214 domains and IP addresses of the botnets command and control servers
  • 464 distinct botnets
  • More than 80 associated malware families

The coordinated global operation resulted in the takedown of the botnets servers, disrupting one of the largest malware operations in the world. Since 2011, Gamarue has been distributing a plethora of other threats, including:

A global malware operation

For the past six years, Gamarue has been a very active malware operation that, until the takedown, showed no signs of slowing down. Windows Defender telemetry in the last six months shows Gamarues global prevalence.

Figure 1. Gamarues global prevalence from May to November 2017

While the threat is global, the list of top 10 countries with Gamarue encounters is dominated by Asian countries.

Figure 2. Top 10 countries with the most Gamarue encounters from May to November 2017

In the last six months, Gamarue was detected or blocked on approximately 1,095,457 machines every month on average.

Figure 3. Machines, IPs, and unique file encounters for Gamarue from May to November 2017; data does not include LNK detections

The Gamarue bot

Gamarue is known in the underground cybercrime market as Andromeda bot. A bot is a program that allows an attacker to take control of an infected machine. Like many other bots, Gamarue is advertised as a crime kit that hackers can purchase.

The Gamarue crime kit includes the following components:

  • Bot-builder, which builds the malware binary that infects computers
  • Command-and-control application, which is a PHP-based dashboard application that allows hackers to manage and control the bots
  • Documentation on how to create a Gamarue botnet

A botnet is a network of infected machines that communicate with command-and-control (C&C) servers, which are computer servers used by the hacker to control infected machines.

The evolution of the Gamarue bot has been the subject of many thorough analyses by security researchers. At the time of takedown, there were five known active Gamarue versions: 2.06, 2.07, 2.08, 2.09, and 2.10. The latest and the most active is version 2.10.

Gamarue is modular, which means that its functionality can be extended by plugins that are either included in the crime kit or available for separate purchase. The Gamarue plugins include:

  • Keylogger ($150) Used for logging keystrokes and mouse activity in order to steal user names and passwords, financial information, etc
  • Rootkit (included in crime kit) Injects rootkit codes into all processes running on a victim computer to give Gamarue persistence
  • Socks4/5 (included in crime kit) Turns victim computer into a proxy server for serving malware or malicious instructions to other computers on the internet
  • Formgrabber ($250) Captures any data submitted through web browsers (Chrome, Firefox, and Internet Explorer)
  • Teamviewer ($250) Enables attacker to remotely control the victim machine, spy on the desktop, perform file transfer, among other functions
  • Spreader Adds capability to spread Gamarue malware itself via removable drives (for example, portable hard drives or flash drives connected via a USB port); it also uses Domain Name Generation (DGA) for the servers where it downloads updates

Gamarue attack kill-chain

Over the years, various attack vectors have been used to distribute Gamarue. These include:

  • Removable drives
  • Social media (such as Facebook) messages with malicious links to websites that host Gamarue
  • Drive-by downloads/exploit kits
  • Spam emails with malicious links
  • Trojan downloaders

Once Gamarue has infected a machine, it contacts the C&C server, making the machine part of the botnet. Through the C&C server, the hacker can control Gamarue-infected machines, steal information, or issue commands to download additional malware modules.

Figure 4. Gamarues attack kill-chain

Gamarues main goal is to distribute other prevalent malware families. During the CME campaign, we saw at least 80 different malware families distributed by Gamarue. Some of these malware families include:

The installation of other malware broadens the scale of what hackers can do with the network of infected machines.

Command-and-control communication

When the Gamarue malware triggers the infected machine to contact the C&C server, it provides information like the hard disks volume serial number (used as the bot ID for the computer), the Gamarue build ID, the operating system of the infected machine, the local IP address, an indication whether the signed in user has administrative rights, and keyboard language setting for the infected machine. This information is sent to the C&C server via HTTP using the JSON format:

Figure 5. Information sent by Gamarue to C&C server

The information about keyboard language setting is very interesting, because the machine will not be further infected if the keyboard language corresponds to the following countries:

  • Belarus
  • Russia
  • Ukraine
  • Kazahkstan

Before sending to the C&C server, this information is encrypted with RC4 algorithm using a key hardcoded in the Gamarue malware body.

Figure 6. Encrypted C&C communication

Once the C&C server receives the message, it sends a command that is pre-assigned by the hacker in the control dashboard.

Figure 7. Sample control dashboard used by attackers to communicate to Gamarue bots

The command can be any of the following:

  • Download EXE (i.e., additional executable malware files)
  • Download DLL (i.e., additional malware; removed in version 2.09 and later)
  • Install plugin
  • Update bot (i.e., update the bot malware)
  • Delete DLLs (removed in version 2.09 and later)
  • Delete plugins
  • Kill bot

The last three commands can be used to remove evidence of Gamarue presence in machines.

The reply from the C&C server is also encrypted with RC4 algorithm using the same key used to encrypt the message from the infected machine.

Figure 8. Encrypted reply from C&C server

When decrypted, the reply contains the following information:

  • Time interval in minutes time to wait for when to ask the C2 server for the next command
  • Task ID – used by the hacker to track if there was an error performing the task
  • Command one of the command mentioned above
  • Download URL – from which a plugin/updated binary/other malware can be downloaded depending on the command.

Figure 9. Decrypted reply from C&C server

Anti-sandbox techniques

Gamarue employs anti-AV techniques to make analysis and detection difficult. Prior to infecting a machine, Gamarue checks a list hashes of the processes running on a potential victims machine. If it finds a process that may be associated with malware analysis tools, such as virtual machines or sandbox tools, Gamarue does not infect the machine. In older versions, a fake payload is manifested when running in a virtual machine.

Figure 10. Gamarue checks if any of the running processes are associated with malware analysis tools

Stealth mechanisms

Gamarue uses cross-process injection techniques to stay under the radar. It injects its code into the following legitimate processes:

  • msiexec.exe (Gamarue versions 2.07 to 2.10)
  • wuauclt.exe, wupgrade.exe, svchost.exe (version 2.06)

It can also use a rootkit plugin to hide the Gamarue file and its autostart registry entry.

Gamarue employs a stealthy technique to store and load its plugins as well. The plugins are stored fileless, either saved in the registry or in an alternate data stream of the Gamarue file.

OS tampering

Gamarue attempts to tamper with the operating systems of infected computers by disabling Firewall, Windows Update, and User Account Control functions. These functionalities cannot be re-enabled until the Gamarue infection has been removed from the infected machine. This OS tampering behavior does not work on Windows 10

Figure 11. Disabled Firewall and Windows Update

Monetization

There are several ways hackers earn using Gamarue. Since Gamarues main purpose is to distribute other malware, hackers earn using pay-per-install scheme. Using its plugins, Gamarue can also steal user information; stolen information can be sold to other hackers in cybercriminal underground markets. Access to Gamarue-infected machines can also be sold, rented, leased, or swapped by one criminal group to another.

Remediation

To help prevent a Gamarue infection, as well as other malware and unwanted software, take these precautions:

  • Be cautious when opening emails or social media messages from unknown users.
  • Be wary about downloading software from websites other than the program developers.

More importantly, ensure you have the right security solutions that can protect your machine from Gamarue and other threats. Windows Defender Antivirus detects and removes the Gamarue malware. With advanced machine learning models, as well as generic and heuristic techniques, Windows Defender AV detects new as well as never-before-seen malware in real-time via the cloud protection service. Alternatively, standalone tools, such as Microsoft Safety Scanner and the Malicious Software Removal Tool (MSRT), can also detect and remove Gamarue.

Microsoft Edge can block Gamarue infections from the web, such as those from malicious links in social media messages and drive-by downloads or exploit kits. Microsoft Edge is a secure browser that opens pages within low privilege app containers and uses reputation-based blocking of malicious downloads.

In enterprise environments, additional layers of protection are available. Windows Defender Advanced Threat Protection can help security operations personnel to detect Gamarue activities, including cross-process injection techniques, in the network so they can investigate and respond to attacks. Windows Defender ATPs enhanced behavioral and machine learning detection libraries flag malicious behavior across the malware infection process, from delivery and installation, to persistence mechanisms, and command-and-control communication.

Microsoft Exchange Online Protection (EOP) can block Gamarue infections from email uses built-in anti-spam filtering capabilities that help protect Office 365 customers. Office 365 Advanced Threat Protection helps secure mailboxes against email attacks by blocking emails with unsafe attachments, malicious links, and linked-to files leveraging time-of-click protection.

Windows Defender Exploit Guard can block malicious documents (such as those that distribute Gamarue) and scripts. The Attack Surface Reduction (ASR) feature in Windows Defender Exploit Guard uses a set of built-in intelligence that can block malicious behaviors observed in malicious documents. ASR rules can also be turned on to block malicious attachments from being run or launched from Microsoft Outlook or webmail (such as Gmail, Hotmail, or Yahoo).

Microsoft is also continuing the collaborative effort to help clean Gamarue-infected computers by providing a one-time package with samples (through the Virus Information Alliance) to help organizations protect their customers.

 

 

Microsoft Digital Crimes Unit and Windows Defender Research team

 

 

Get more info on the Gamarue (Andromeda) takedown from the following sources:

 

 


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

with

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.