{"id":90212,"date":"2019-11-26T09:00:56","date_gmt":"2019-11-26T17:00:56","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/\/?p=90212"},"modified":"2023-09-11T15:49:59","modified_gmt":"2023-09-11T22:49:59","slug":"insights-from-one-year-of-tracking-a-polymorphic-threat","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2019\/11\/26\/insights-from-one-year-of-tracking-a-polymorphic-threat\/","title":{"rendered":"Insights from one year of tracking a polymorphic threat"},"content":{"rendered":"
A little over a year ago, in October 2018, our polymorphic outbreak monitoring system detected a large surge in reports, indicating that a large-scale campaign was unfolding. We observed as the new threat attempted to deploy files that changed every 20-30 minutes on thousands of devices. We gave the threat the name \u201cDexphot,\u201d based on certain characteristics of the malware code.<\/p>\n
The Dexphot attack used a variety of sophisticated methods to evade security solutions. Layers of obfuscation, encryption, and the use of randomized file names hid the installation process. Dexphot then used fileless techniques<\/a> to run malicious code directly in memory, leaving only a few traces that can be used for forensics. It hijacked legitimate system processes to disguise malicious activity. If not stopped, Dexphot ultimately ran a cryptocurrency miner on the device, with monitoring services and scheduled tasks triggering re-infection when defenders attempt to remove the malware.<\/p>\n In the months that followed, we closely tracked the threat and witnessed the attackers upgrade the malware, target new processes, and work around defensive measures:<\/p>\n <\/p>\n While Microsoft Defender Advanced Threat Protection<\/a>\u2019s pre-execution detection engines blocked Dexphot in most cases, behavior-based machine learning models<\/a> provided protection for cases where the threat slipped through. Given the threat\u2019s persistence mechanisms, polymorphism, and use of fileless techniques, behavior-based detection was a critical component of the comprehensive protection against this malware and other threats that exhibit similar malicious behaviors.<\/p>\n Microsoft Defender ATP data shows the effectiveness of behavioral blocking and containment capabilities in stopping the Dexphot campaign. Over time, Dexphot-related malicious behavior reports dropped to a low hum, as the threat lost steam.<\/p>\n <\/p>\n Our close monitoring of Dexphot helped us ensure that our customers were protected from the evolving threat. More importantly, one year\u2019s worth of intelligence helped us gain insight not only into the goals and motivations of Dexphot\u2019s authors, but of cybercriminals in general.<\/p>\n The early stages of a Dexphot infection involves numerous files and processes. During the execution stage, Dexphot writes five key files to disk:<\/p>\n Except for the installer, the other processes that run during execution are legitimate system processes. This can make detection and remediation more difficult. These legitimate system processes include msiexec.exe<\/em> (for installing MSI packages), unzip.exe<\/em> (for extracting files from the password-protected ZIP archive), rundll32.exe<\/em> (for loading the loader DLL), schtasks.exe<\/em> (for scheduled tasks), powershell.exe<\/em> (for forced updates). In later stages, Dexphot targets a few other system processes for process hollowing: svchost.exe<\/em>, tracert.exe<\/em>, and setup.exe<\/em>.<\/p>\n <\/p>\n Based on Microsoft Defender ATP signals, SoftwareBundler:Win32\/ICLoader<\/a> and its variants are primarily used to drop and run the Dexphot installer. The installer uses two URLs to download malicious payloads. These are the same two URLs that Dexphot use later to establish persistence, update the malware, and re-infect the device.<\/p>\n The installer downloads an MSI package from one of the two URLs, and then launches msiexec.exe<\/em> to perform a silent install. This is the first of several instances of Dexphot employing living-off-the-land techniques<\/a>, the use of legitimate system processes for nefarious purposes.<\/p>\n Dexphot\u2019s package often contains an obfuscated batch script. If the package contains this file, the script is the first thing that msiexec.exe<\/em> runs when it begins the installation process. The said obfuscated script is designed to check for antivirus products. Dexphot halts the infection process immediately if an antivirus product is found running.<\/p>\n When we first began our research, the batch script only checked for antivirus products from Avast and AVG. Later, Windows Defender Antivirus was added to the checklist.<\/p>\n <\/p>\n If the process is not halted, Dexphot decompresses the password-protected ZIP archive from the MSI package. The password to this archive is within the MSI package. Along with the password, the malware\u2019s authors also include a clean version of unzip.exe<\/em> so that they don\u2019t have to rely on the target system having a ZIP utility. The unzip.exe<\/em> file in the package is usually named various things, such as z.exe<\/em> or ex.exe<\/em>, to avoid scrutiny.<\/p>\n The ZIP archive usually contains three files: the loader DLL, an encrypted data file (usually named bin.dat<\/em>), and, often, one clean unrelated DLL, which is likely included to mislead detection.<\/p>\n Dexphot usually extracts the decompressed files to the target system\u2019s Favorites folder. The files are given new, random names, which are generated by concatenating words and numbers based on the time of execution (for example, C:\\Users\\<user>\\Favorites\\\\Res.Center.ponse\\<numbers><\/em>). The commands to generate the new names are also obfuscated, for example:<\/p>\n <\/p>\n Msiexec.exe<\/em> next calls rundll32.exe<\/em>, specifying loader DLL (urlmon.7z<\/em> in the example above) in order to decrypt the data file. The decryption process involves ADD and XOR operations, using a key hardcoded in the binary.<\/p>\n The decrypted data contains three executables. Unlike the files described earlier, these executables are never written to the filesystem. Instead, they exist only in memory, and Dexphot runs them by loading them into other system processes via process hollowing.<\/p>\n Process hollowing<\/a> is a technique that can hide malware within a legitimate system process. It replaces the contents of the legitimate process with malicious code. Detecting malicious code hidden using this method is not trivial, so process hollowing has become a prevalent technique used by malware today.<\/p>\n This method has the additional benefit of being fileless: the code can be run without actually being saved on the file system. Not only is it harder to detect the malicious code while it\u2019s running, it\u2019s harder to find useful forensics after the process has stopped.<\/p>\n To initiate process hollowing, the loader DLL targets two legitimate system processes, for example svchost.exe or nslookup.exe, and spawns them in a suspended state. The loader DLL replaces the contents of these processes with the first and second decrypted executables. These executables are monitoring services for maintaining Dexphot\u2019s components. The now-malicious processes are released from suspension and run.<\/p>\n Next, the loader DLL targets the setup.exe<\/em> file in SysWoW64. It removes setup.exe<\/em>\u2019s contents and replaces them with the third decrypted executable, a cryptocurrency miner. Although Dexphot always uses a cryptocurrency miner of some kind, it\u2019s not always the same miner. It used different programs like XMRig and JCE Miner over the course of our research.<\/p>\n <\/p>\n The two monitoring services simultaneously check the status of all three malicious processes. Having dual monitoring services provides redundancy in case one of the monitoring processes is halted. If any of the processes are terminated, the monitors immediately identify the situation, terminate all remaining malicious processes, and re-infect the device. This forced update\/re-infection process is started by a PowerShell command similar to the one below:<\/p>\n <\/p>\n The monitoring components also detect freshly launched cmd.exe<\/em> processes and terminate them promptly. As a final fail-safe, Dexphot uses schtasks.exe<\/em> to create scheduled tasks, with the command below.<\/p>\n <\/p>\n This persistence technique is interesting, because it employs two distinct MITRE ATT&CK techniques: Scheduled Task<\/a> and Signed Binary Proxy Execution<\/a>.<\/p>\n The scheduled tasks call msiexec.exe<\/em> as a proxy to run the malicious code, much like how msiexec.exe<\/em> was used during installation. Using msiexec.exe<\/em>, a legitimate system process, can make it harder to trace the source of malicious activity.<\/p>\n Furthermore, the tasks allow Dexphot to conveniently update the payload from the web every time the tasks run. They automatically update all of Dexphot’s components, both upon system reboot as well as every 90 or 110 minutes while the system is running.<\/p>\n Dexphot also generates the names for the tasks at runtime, which means a simple block list of hardcoded task names will not be effective in preventing them from running. The names are usually in a GUID format, although after we released our first round of Dexphot-blocking protections, the threat authors began to use random strings.<\/p>\n The threat authors have one more evasion technique for these scheduled tasks: some Dexphot variants copy msiexec.exe<\/em> to an arbitrary location and give it a random name, such as %AppData%\\<random>.exe<\/em>. This makes the system process running malicious code a literal moving target.<\/p>\n Dexphot exhibits multiple layers of polymorphism across the binaries it distributes. For example, the MSI package used in the campaign contains different files, as shown in the table below. The MSI packages generally include a clean version of unzip.exe<\/em>, a password-protected ZIP file, and a batch file that checks for currently installed antivirus products. However, the batch file is not always present, and the names of the ZIP files and Loader DLLs, as well as the password for extracting the ZIP file, all change from one package to the next.<\/p>\n In addition, the contents of each Loader DLL differs from package to package, as does the encrypted data included in the ZIP file. This leads to the generation of a different ZIP archive and, in turn, a unique MSI package, each time the attacker bundles the files together. Because of these carefully designed layers of polymorphism, a traditional file-based detection approach wouldn\u2019t be effective against Dexphot.<\/p>\n <\/p>\nComplex attack chain<\/h3>\n
\n
Multiple layers of security evasion<\/h3>\n
Stealthy execution through fileless techniques<\/h3>\n
Persistence through regularly scheduled malware updates<\/h3>\n
Polymorphism<\/h3>\n