Today, Microsoft is excited to announce that we are shifting to a new threat actor naming taxonomy aligned to the theme of weather. The complexity, scale, and volume of threats is increasing, driving the need to reimagine not only how Microsoft talks about threats but also how we enable customers to understand those threats quickly and with clarity. With the new taxonomy, we intend to bring better context to customers and security researchers that are already confronted with an overwhelming amount of threat intelligence data. It will offer a more organized, memorable, and easy way to reference adversary groups so that organizations can better prioritize threats and protect themselves. Simply put, security professionals will instantly have an idea of the type of threat actor they are up against, just by reading the name.
Figure 1: Eight threat actor groups that Microsoft tracks represented in the new naming taxonomy
The Microsoft Threat Intelligence community has spent over a decade discovering, tracking, and identifying targeted malicious activity and sharing that critical intelligence with customers. Our threat research has grown to track more than 300 unique threat actors, including 160 nation states, 50 ransomware groups, and hundreds of others. A global multi-disciplinary assembly of threat intelligence analysts, pen testers, and data scientists work together alongside experts in geopolitics and disinformation to take a whole-of-adversary approach. This helps Microsoft Threat Intelligence teams fully understand the what of an attack, make assessments on the why, then forecast and implement protections for where an attacker might go next. Our vision is that this new naming model helps our customers and the industry move to a more proactive approach to defense.
We realize that other vendors in the industry also have unique naming taxonomies representing their distinct view of threats based on their intelligence. However, there are often overlaps or close alignments with tracked actors, and keeping track of these names can be challenging for defenders. Microsoft Threat Intelligence is committed to helping customers understand threats, no matter which naming taxonomy they are familiar with. Therefore, we will strive to also include other threat actor names within our security products to reflect these analytic overlaps and help customers make well-informed decisions.
The Microsoft threat actor taxonomy explained
In our new taxonomy, threat actor groups will be named after weather events. A weather event or “family name” represents either a nation-state actor attribution (e.g., Typhoon indicates origin or attribution to China) or a motivation (e.g., Tempest indicates financially motivated actors). The table below shows the threat actor groups Microsoft tracks and their assigned weather events in the new naming convention.
Actor category
Type
Family Name
Nation state
China
Typhoon
Iran
Sandstorm
Lebanon
Rain
North Korea
Sleet
Russia
Blizzard
South Korea
Hail
Turkey
Dust
Vietnam
Cyclone
Financially motivated
Financially motivated
Tempest
Private sector offensive actors
PSOAs
Tsunami
Influence operations
Influence operations
Flood
Groups in development
Groups in development
Storm
Threat actors within the same weather family are given an adjective to distinguish actor groups that have distinct TTPs, infrastructure, objectives, or other identified patterns. The examples below show how the naming system works for Russia and Iran.
Figure 2: Russian and Iranian nation state actor groups that Microsoft tracks
Where there is a newly discovered, unknown, or emerging cluster of threat activity, we use a temporary designation of Storm (previously DEV) and a four-digit number, allowing us to track it as a unique set of information until we can reach high confidence about the origin or identity of the actor behind the operation. Once our analysis has developed to meet high confidence criteria, a Storm is converted to a named actor.
Figure 3: Threat actor groups in development that Microsoft track
We believe this new approach, along with the new icon system shown in some of the examples above, makes it even easier to identify and remember Microsoft’s threat actors. Each icon uniquely represents a family name, and where it makes sense will accompany the threat actor names as a visual aid. This new naming approach does not in any way change who the threat actors are that we are tracking, or our current analysis behind the names.
The naming approach we have used previously (Elements, Trees, Volcanoes, and DEVs) has been retired. We have reassigned all existing threat actors to the new taxonomy, and going forward will be using the new threat actor names. Over the next few weeks, you will start seeing changes across public facing content and in-product experiences. We estimate to complete prioritized in-product updates by September 2023. There will be some surfaces that will not be updated. To ease the transition from old names to new names, we developed a reference guide at https://aka.ms/threatactors. Make sure to bookmark it for future reference.
Microsoft’s approach to threat actor tracking
The way Microsoft Threat Intelligence approaches identifying and naming threat actors is outlined below in Figure 4. As is sometimes the case, when a new threat surfaces, we don’t know all the details. We might know about a subset of victims and the malware they were infected with, and/or the command-and-control infrastructure, but we sometimes don’t immediately know the full scope of the actor’s capability or victimology. Microsoft maintains an internal process for tracking these ‘in-development’ activity clusters (now Storm-###) for reference across our hunting teams. In-development names (e.g., Storm-0257) apply to all actor types (nation-state, financially motivated, PSOA, etc.).
Figure 4: Threat actor naming lifecycle. *Full attribution means known capabilities, techniques, infrastructure, scope, and intent of the activity
Storm names may persist indefinitely, but we strive to progress our understanding of all clusters of threat activity to either merge them with existing fully named actors (thereby expanding the definition), or merge multiple in-development clusters together to define a new fully named actor.
To meet the requirements of a full name, we aim to gain knowledge of the actor’s infrastructure, tooling, victimology, and motivation. We expand and update the definitions supporting our actor names based on our own telemetry, industry reporting, and a combination thereof.
The new centralized home of Microsoft threat actor intelligence
As a security industry leader, Microsoft has unique capabilities to track threats and the expectation to provide timely, consistent analysis will only increase. In a growing industry of complexity, confusion, and an overwhelming amount of data, we see an opportunity to provide customers with hyper relevant threat intelligence enabling them to implement even more proactive defenses.
We know defenders benefit from context and actionable insight– they need to understand what threat actor is behind an attack and how they can take steps to mitigate the issue. This is where Intel Profiles in Microsoft Defender Threat Intelligence can bring crucial information and context about threats. Integrated into Microsoft 365 Defender, Intel Profiles are updated daily and put the wealth of information tracked by the Microsoft Threat Intelligence community about threat actors and their tools and techniques directly into the hands of security operations professionals so that they can investigate, analyze, and hunt for threats.
We’re excited to share this new threat actor update with you, our defenders, and help bring clarity and relevance to the threat intelligence you are getting from Microsoft.
Resources
To ease the transition to the new naming taxonomy, use this reference guide to look up the old and new names of Microsoft threat actors: https://aka.ms/threatactors.
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.
Microsoft Threat Intelligence analysts assess with high confidence that a threat group tracked by Microsoft as DEV-0196 is linked to an Israel-based private sector offensive actor (PSOA) known as QuaDream. QuaDream reportedly sells a platform they call REIGN to governments for law enforcement purposes. REIGN is a suite of exploits, malware, and infrastructure designed to exfiltrate data from mobile devices.
In this blog, Microsoft analyzes DEV-0196, discusses technical details of the actor’s iOS malware, which we call KingsPawn, and shares both host and network indicators of compromise that can be used to aid in detection.
Over the course of our investigation into DEV-0196, Microsoft collaborated with multiple partners. One of those partners, Citizen Lab of the University of Toronto’s Munk School, identified at least five civil society victims of the DEV-0196 malware that included journalists, political opposition figures, and a non-government organisation (NGO) worker, in North America, Central Asia, Southeast Asia, Europe, and the Middle East. Furthermore, Citizen Lab was able to identify operator locations for QuaDream systems in the following countries: Bulgaria, Czechia, Hungary, Ghana, Israel, Mexico, Romania, Singapore, United Arab Emirates, and Uzbekistan. Read the Citizen Lab report here.
Microsoft is sharing information about DEV-0196 with our customers, industry partners, and the public to improve collective knowledge of how PSOAs operate and raise awareness about how PSOAs facilitate the targeting and exploitation of civil society. For more info, read Standing up for democratic values and protecting stability of cyberspace.
DEV-0196: A private-sector offensive actor based in Israel
PSOAs, which Microsoft also refers to as cyber mercenaries, sell hacking tools or services through a variety of business models, including access as a service. In access as a service, the actor sells full end-to-end hacking tools that can be used by the purchaser in cyber operations. The PSOA itself is not involved in any targeting or running of the operations.
Microsoft Threat Intelligence analysts assess with high confidence that DEV-0196 uses this model, selling exploitation services and malware to governments. It’s not directly involved in targeting. Microsoft also assesses with high confidence that DEV-0196 is linked to an Israel-based private company called QuaDream. According to the Israeli Corporations Authority, QuaDream, under the Israeli name קוודרים בע”מ, was incorporated in August 2016. The company has no website, and there is little public reporting about the company, with a few notable exceptions.
QuaDream came to international attention in a 2022 Reuters report, which cited a company brochure that described the REIGN platform and a list of capabilities, the report also notably suggested that QuaDream used a zero-click iOS exploit that leveraged the same vulnerability seen in NSO Group’s ForcedEntry exploit. An earlier report by Israeli news outlet Haaretz, also citing a QuaDream brochure, revealed that QuaDream did not sell REIGN directly to customers but instead did so through a Cypriot company. Haaretz also reported that Saudi Arabia’s government was among QuaDream’s clients, as was the government of Ghana. However, Haaretz could not confirm allegations made in the Ghanian press and repeated in the Israeli press that QuaDream employees were among 14 Israeli tech workers from different companies who travelled to Accra, Ghana in 2020 to meet with the incumbent administration three months prior to the presidential election for the purposes of a special project relating to it.
QuaDream was mentioned in a December 2022 report from Meta, which reportedly took down 250 accounts associated with the company. According to the report, Meta observed QuaDream testing its ability to exploit iOS and Android mobile devices with the intent “to exfiltrate various types of data including messages, images, video and audio files, and geolocation.”
Technical investigation: DEV-0196 malware
Microsoft Threat Intelligence analysts assess with high confidence that the malware, which we call KingsPawn, is developed by DEV-0196 and therefore strongly linked to QuaDream. We assess with medium confidence that the mobile malware we associate with DEV-0196 is part of the system publicly discussed as REIGN.
The captured samples targeted iOS devices, specifically iOS 14, but there were indications that some of the code could also be used on Android devices. Since the malware sample targets iOS 14, some of the techniques used in this sample may no longer work or be relevant on newer iOS versions. However, we assess it’s highly likely that DEV-0196 will have updated their malware, targeting newer versions to account for this. Analysis of the malware revealed that it is split into multiple components. The sections below focus on two of those components: a monitor agent and the main malware agent.
Monitor agent
The monitor agent is a native Mach-O file written in Objective-C. It is responsible for reducing the forensic footprint of the malware to prevent detection and hinder investigations. It has multiple techniques to do this, one of which is monitoring various directories, such as /private/var/db/analyticsd/ and /private/var/mobile/Library/Logs/CrashReporter, for any malware execution artifacts or crash-related files. Once these artifacts or files are identified, the monitor agent deletes them.
The monitor agent is also in charge of managing the various processes and threads spawned on behalf of the malware to avoid artifacts created from unexpected process crashes. The agent uses the waitpid function to monitor all child processes that are spawned, and the child process IDs are added to a tracking list. The monitor agent attempts to safely shut down tracked child processes by calling sigactionwith the SIGSTOPparameter, if sigaction returns successfully this means the child process is reachable and a SIGKILL command is sent to kill it. This avoids sending a kill command to a non-existent PID, which can leave error messages and artifacts behind.
Main agent
The main agent is also a native Mach-O file. However, it is written in Go, a highly portable language, which was likely chosen because it allows compilation across multiple platforms, reducing development effort.
This agent includes capabilities to:
Get device information (such as iOS version and battery status)
Wi-Fi information (such as SSID and airplane mode status)
Cellular information (such as carrier, SIM card data, and phone number)
Search for and retrieve files
Use the device camera in the background
Get device location
Monitor phone calls
Access the iOS keychain
Generate an iCloud time-based one-time password (TOTP)
It achieves some of these functionalities, for example the surreptitious camera use, by leveraging two key binaries, tccd and mediaserverd, a technique described by ZecOps. The name tccd stands for Transparency, Consent, and Control (TCC) Daemon, and the process manages the access permissions for various peripherals such as the camera and microphone. Normally, users are met with a pop-up prompt from the tccd process, alerting them that something has requested access to the camera, microphone, or other peripheral, and the user is required to either allow or deny it. In this compromise scenario, the agent injects itself into the tccd binary, which allows the agent to spawn both new processes and threads as part of the exploitation process, and also allows it to bypass any tccd prompts on the device meaning the user would be unaware of camera compromise. In concert with tccd, the agent also provisions itself permission to run in the background via mediaserverd. This binary handles the interface that other apps interact with when utilizing the camera. For more details on iOS process injection, tccd and other system components, see Jonathan Levin’s macOS and iOS internals books and blog.
The techniques used in the main agent include a PMAP bypass, an Apple Mobile File Integrity (AMFI) bypass, and a sandbox escape. PMAP is one of the mechanisms that works with the Page Protection Layer (PPL) to prevent unsigned code from running on iOS devices. AMFI is a protection mechanism comprised of multiple components including a kernel extension, AppleFileMobileIntegrity.kext, as well as userland daemon, amfid. The sandbox limits access to system resources and user data via an entitlements system. Although PMAP, PPL, AMFI, and the sandbox have been hardened over the years, advanced attackers attempt to circumvent these protection mechanisms in order to run unsigned code.
The agent also creates a secure channel for XPC messaging by creating a nested app extension called fud.appex. XPC messaging allows the agent to query various system binaries for sensitive device information, such as location details. Although there is a legitimate binary called fud on iOS devices that is part of the Mobile Accessory updater service, fud.appex is not part of a legitimate Apple service. The agent creates the malicious app extension inside the folder /private/var/db/com.apple.xpc.roleaccountd.staging/PlugIns/. The primary reason for performing XPC messaging from within this application extension is to establish a covert channel that enables the agent to avoid being monitored. This nested directory technique means that the XPC service is registered such a way that it is only visible to the app extension itself, so any external monitoring by other applications and system processes is far more difficult. Upon unhooking and restoring tccd to its original state, the entire PlugIns folder is removed to further hide any artifacts of its existence.
In their blog, Citizen Lab discusses the presence of likely malicious calendar events on devices compromised by DEV-0196’s malware, so another notable function of the main agent is that it contains specific code to remove events from the device’s calendar. The agent searches all calendar events from two years prior to the current time and up to the furthest possible allowed future time, removing any events that are tied to a given email address as the “organizer”. The agent also removes the email address from the idstatuscache.plist, which is a database containing records of the first contact of the device with other iCloud accounts. This list would contain the email address that sent the malicious calendar invitation, as well as a time stamp of the original interaction, such as when the invite was received.
There is additional functionality within the agent to cover its tracks by removing artifacts of location monitoring from the locationd process’ records. To first query locations from locationd, the agent must register a client that communicates with locationd via XPC messaging. The locationd process then stores a record of these connections in /private/var/root/Library/Caches/locationd/clients.plist. The malicious agent searches for items in the client plist that have a suffix of subridged, and then removes them, which indicates that the name of their location monitoring client likely ends in that word. This is another example of malicious activity attempting to masquerade as benign system processes, since subridged is the name of a legitimate Apple binary, a part of the SoftwareUpdateBridge Framework.
Technical investigation: DEV-0196 infrastructure
Microsoft developed unique network detections that could be used to fingerprint DEV-0196’s infrastructure on the internet. The group heavily utilized domain registrars and inexpensive cloud hosting providers that accepted cryptocurrency as payment. They tended to only use a single domain per IP address and domains were very rarely reused across multiple IP addresses. Many of the observed domains were deployed using free Let’s Encrypt SSL certificates, while others used self-signed certificates designed to blend in with normal Kubernetes deployments.
We have included network-based indicators at the end of this post for detection purposes. Often, threat actors employ domains that carry country-specific TLDs or themes that align with the location of intended targets. Notably, our list of DEV-0196 domains includes domains strongly associated with some countries that Citizen Lab has identified as locations of victims, countries where QuaDream platforms were operating, or both. To be clear, the identification of victims of the malware in a country doesn’t necessarily mean that an entity in that country is a DEV-0196 customer, as international targeting is common.
Prevention and detection
Preventing exploitation of mobile devices by advanced actors who potentially have zero-click exploits is difficult. There are also significant challenges in detecting an attack on mobile devices, both during and after the compromise. This section discusses some methods for minimizing the risk of malicious actors compromising mobile devices, and then provides some indicators of compromise we associate with DEV-0196 activity.
Basic cyber hygiene is important in helping prevent mobile device compromise. Specific best practices include keeping the device’s software updated to the latest version, enabling automatic software updates if available, using anti-malware software, and being vigilant about not clicking links in any unexpected or suspicious messages.
If you believe you may be targeted by advanced attackers and use an iOS device, we recommend enabling Lockdown Mode. Lockdown Mode offers enhanced security for iOS devices by reducing the attack surface available to threat actors.
Sentinel detections
Microsoft Sentinel customers can use the TI Mapping analytic to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here: https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy.
These host-based indicators are indicative of DEV-0196 activity; however, they shouldn’t be used solely as attribution since other actors may also use the same or similar TTPs.
The file existing, or process activity from, /private/var/db/com.apple.xpc.roleaccountd.staging/subridged
The file existing, or process activity from, com.apple.avcapture
The folder /private/var/db/com.apple.xpc.roleaccountd.staging/PlugIns/fud.appex/ existing, or having activity detected from the folder.
Network indicators
Based on the results of our C2 investigation, Microsoft Threat Intelligence associate the following domains with DEV-0196 activity. The dates the domains were first detected as likely in use is given, along with the last seen active date.
The Microsoft Threat Intelligence Center (MSTIC) and the Microsoft Security Response Center (MSRC) found a private-sector offensive actor (PSOA) using multiple Windows and Adobe 0-day exploits, including one for the recently patched CVE-2022-22047, in limited and targeted attacks against European and Central American customers. The PSOA, which MSTIC tracks as KNOTWEED, developed malware called Subzero which was used in these attacks.
This blog details Microsoft’s analysis of the observed KNOTWEED activity and related malware used in targeted attacks against our customers. This information is shared with our customers and industry partners to improve detection of these attacks. Customers are encouraged to expedite deployment of the July 2022 Microsoft security updates to protect their systems against exploits using CVE-2022-22047. Microsoft Defender Antivirus and Microsoft Defender for Endpoint have also implemented detections against KNOTWEED’s malware and tools.
PSOAs, which Microsoft also refers to as cyber mercenaries, sell hacking tools or services through a variety of business models. Two common models for this type of actor are access-as-a-service and hack-for-hire. In access-as-a-service, the actor sells full end-to-end hacking tools that can be used by the purchaser in operations, with the PSOA not involved in any targeting or running of the operation. In hack-for-hire, detailed information is provided by the purchaser to the actor, who then runs the targeted operations. Based on observed attacks and news reports, MSTIC believes that KNOTWEED may blend these models: they sell the Subzero malware to third parties but have also been observed using KNOTWEED-associated infrastructure in some attacks, suggesting more direct involvement.
Who is KNOTWEED?
KNOTWEED is an Austria-based PSOA named DSIRF. The DSIRF website [web archive link] says they provide services “to multinational corporations in the technology, retail, energy and financial sectors” and that they have “a set of highly sophisticated techniques in gathering and analyzing information.” They publicly offer several services including “an enhanced due diligence and risk analysis process through providing a deep understanding of individuals and entities” and “highly sophisticated Red Teams to challenge your company’s most critical assets.”
However, multiplenewsreports have linked DSIRF to the development and attempted sale of a malware toolset called Subzero. MSTIC found the Subzero malware being deployed through a variety of methods, including 0-day exploits in Windows and Adobe Reader, in 2021 and 2022. As part of our investigation into the utility of this malware, Microsoft’s communications with a Subzero victim revealed that they had not commissioned any red teaming or penetration testing, and confirmed that it was unauthorized, malicious activity. Observed victims to date include law firms, banks, and strategic consultancies in countries such as Austria, the United Kingdom, and Panama. It’s important to note that the identification of targets in a country doesn’t necessarily mean that a DSIRF customer resides in the same country, as international targeting is common.
MSTIC has found multiple links between DSIRF and the exploits and malware used in these attacks. These include command-and-control infrastructure used by the malware directly linking to DSIRF, a DSIRF-associated GitHub account being used in one attack, a code signing certificate issued to DSIRF being used to sign an exploit, and other open-source news reports attributing Subzero to DSIRF.
Observed actor activity
KNOTWEED initial access
MSTIC found KNOTWEED’s Subzero malware deployed in a variety of ways. In the succeeding sections, the different stages of Subzero are referred to by their Microsoft Defender detection names: Jumplump for the persistent loader and Corelump for the main malware.
KNOTWEED exploits in 2022
In May 2022, MSTIC found an Adobe Reader remote code execution (RCE) and a 0-day Windows privilege escalation exploit chain being used in an attack that led to the deployment of Subzero. The exploits were packaged into a PDF document that was sent to the victim via email. Microsoft was not able to acquire the PDF or Adobe Reader RCE portion of the exploit chain, but the victim’s Adobe Reader version was released in January 2022, meaning that the exploit used was either a 1-day exploit developed between January and May, or a 0-day exploit. Based on KNOTWEED’s extensive use of other 0-days, we assess with medium confidence that the Adobe Reader RCE is a 0-day exploit. The Windows exploit was analyzed by MSRC, found to be a 0-day exploit, and then patched in July 2022 as CVE-2022-22047. Interestingly, there were indications in the Windows exploit code that it was also designed to be used from Chromium-based browsers, although we’ve seen no evidence of browser-based attacks.
The CVE-2022-22047 vulnerability is related to an issue with activation context caching in the Client Server Run-Time Subsystem (CSRSS) on Windows. At a high level, the vulnerability could enable an attacker to provide a crafted assembly manifest, which would create a malicious activation context in the activation context cache, for an arbitrary process. This cached context is used the next time the process spawned.
CVE-2022-22047 was used in KNOTWEED related attacks for privilege escalation. The vulnerability also provided the ability to escape sandboxes (with some caveats, as discussed below) and achieve system-level code execution. The exploit chain starts with writing a malicious DLL to disk from the sandboxed Adobe Reader renderer process. The CVE-2022-22047 exploit was then used to target a system process by providing an application manifest with an undocumented attribute that specified the path of the malicious DLL. Then, when the system process next spawned, the attribute in the malicious activation context was used, the malicious DLL was loaded from the given path, and system-level code execution was achieved.
It’s important to note that exploiting CVE-2022-22047 requires attackers to be able to write a DLL to disk. However, in the threat model of sandboxes, such as that of Adobe Reader and Chromium, the ability to write out files where the attacker cannot control the path isn’t considered dangerous. Hence, these sandboxes aren’t a barrier to the exploitation of CVE-2022-22047.
KNOTWEED exploits in 2021
In 2021, MSRC received a report of two Windows privilege escalation exploits (CVE-2021-31199 and CVE-2021-31201) being used in conjunction with an Adobe Reader exploit (CVE-2021-28550), all of which were patched in June 2021. MSTIC was able to confirm the use of these in an exploit chain used to deploy Subzero.
We were later able to link the deployment of Subzero to a fourth exploit, one related to a Windows privilege escalation vulnerability in the Windows Update Medic Service (CVE-2021-36948), which allowed an attacker to force the service to load an arbitrary signed DLL. The malicious DLL used in the attacks was signed by ‘DSIRF GmbH’.
Figure 1. Valid digital signature from DSIRF on Medic Service exploit DLL
Malicious Excel documents
In addition to the exploit chains, another method of access that led to the deployment of Subzero was an Excel file masquerading as a real estate document. The file contained a malicious macro that was obfuscated with large chunks of benign comments from the Kama Sutra, string obfuscation, and use of Excel 4.0 macros.
Figure 2: Two examples of KNOTWEED Excel macro obfuscation
After de-obfuscating strings at runtime, the VBA macro uses the ExecuteExcel4Macro function to call native Win32 functions to load shellcode into memory allocated using VirtualAlloc. Each opcode is individually copied into a newly allocated buffer using memset before CreateThread is called to execute the shellcode.
Figure 3: Copying opcodesFigure 4: Calling CreateThread on shellcode
The following section describes the shellcode executed by the macro.
KNOTWEED malware and tactics, techniques, and procedures (TTPs)
Corelump downloader and loader shellcode
The downloader shellcode is the initial shellcode executed from either the exploit chains or malicious Excel documents. The shellcode’s purpose is to retrieve the Corelump second-stage malware from the actor’s command-and-control (C2) server. The downloader shellcode downloads a JPEG image that contains extra encrypted data appended to the end of the file (past the 0xFF 0xD9 marker that signifies the end of a JPEG file). The JPEG is then written to the user’s %TEMP% directory.
Figure 5: One of the images embedded with the loader shellcode and Corelump
The downloader shellcode searches for a 16-byte marker immediately following the end of JPEG. After finding the marker, the downloader shellcode RC4 decrypts the loader shellcode using the next 16 bytes as the RC4 key. Finally, the loader shellcode RC4 decrypts the Corelump malware using a second RC4 key and manually loads it into memory.
Corelump malware
Corelump is the main payload and resides exclusively in memory to evade detection. It contains a variety of capabilities including keylogging, capturing screenshots, exfiltrating files, running a remote shell, and running arbitrary plugins downloaded from KNOTWEED’s C2 server.
As part of installation, Corelump makes copies of legitimate Windows DLLs and overwrites sections of them with malicious code. As part of this process, Corelump also modifies the fields in the PE header to accommodate the nefarious changes, such as adding new exported functions, disabling Control Flow Guard, and modifying the image file checksum with a computed value from CheckSumMappedFile. These trojanized binaries (Jumplump) are dropped to disk in C:\Windows\System32\spool\drivers\color\, and COM registry keys are modified for persistence (see the Behaviors section for more information on COM hijacking).
Jumplump loader
Jumplump is responsible for loading Corelump into memory from the JPEG file in the %TEMP% directory. If Corelump is not present, Jumplump attempts to download it again from the C2 server. Both Jumplump and the downloader shellcode are heavily obfuscated to make analysis difficult, with most instructions being followed by a jmp to another instruction/jmp combination, giving a convoluted control flow throughout the program.
Figure 6: Disassembly showing the jmp/instruction obfuscation used in Jumplump
Mex and PassLib
KNOTWEED was also observed using the bespoke utility tools Mex and PassLib. These tools are developed by KNOTWEED and bear capabilities that are derived from publicly available sources. Mex, for example, is a command-line tool containing several red teaming or security plugins copied from GitHub (listed below):
PassLib is a custom password stealer tool capable of dumping credentials from a variety of sources including web browsers, email clients, LSASS, LSA secrets, and the Windows credential manager.
Post-compromise actions
In victims where KNOTWEED malware had been used, a variety of post-compromise actions were observed:
Setting of UseLogonCredential to “1” to enable plaintext credentials:
Attempt to access emails with dumped credentials from a KNOTWEED IP address
Using Curl to download KNOTWEED tooling from public file shares such as vultrobjects[.]com
Running PowerShell scripts directly from a GitHub gist created by an account associated with DSIRF
KNOTWEED infrastructure connections to DSIRF
Pivoting off a known command-and-control domain identified by MSTIC, acrobatrelay[.]com, RiskIQ expanded the view of KNOTWEED’s attack infrastructure. Leveraging unique patterns in the use of SSL certificates and other network fingerprints specific to the group and associated with that domain, RiskIQ identified a host of additional IP addresses under the control of KNOTWEED. This infrastructure, largely hosted by Digital Ocean and Choopa, has been actively serving malware since at least February of 2020 and continues through the time of this writing.
RiskIQ next utilized passive DNS data to determine which domains those IPs resolved to at the time they were malicious. This process yielded several domains with direct links to DSIRF, including demo3[.]dsirf[.]eu (the company’s own website), and several subdomains that appear to have been used for malware development, including debugmex[.]dsirflabs[.]eu (likely a server used for debugging malware with the bespoke utility tool Mex) and szstaging[.]dsirflabs[.]eu (likely a server used to stage Subzero malware).
Detection and prevention
Microsoft will continue to monitor KNOTWEED activity and implement protections for our customers. The current detections and IOCs detailed below are in place and protecting Microsoft customers across our security products. Additional advanced hunting queries are also provided below to help organizations extend their protections and investigations of these attacks.
Behaviors
Corelump drops the Jumplump loader DLLs to C:\Windows\System32\spool\drivers\color\. This is a common directory used by malware as well as some legitimate programs, so writes of PE files to the folder should be monitored.
Jumplump uses COM hijacking for persistence, modifying COM registry keys to point to the Jumplump DLL in C:\Windows\System32\spool\drivers\color\. Modifications of default system CLSID values should be monitored to detect this technique (e.g., HKLM\SOFTWARE\Classes\CLSID\{GUID}\InProcServer32 Default value). The five CLSIDs used by Jumplump are listed below with their original clean values on Windows 11:
Many of the post-compromise actions can be detected based on their command lines. Customers should monitor for possible malicious activity such as PowerShell executing scripts from internet locations, modification of commonly abused registry keys such as HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest, and LSASS credential dumping via minidumps.
Recommended customer actions
The techniques used by the actor and described in the Observed actor activity section can be mitigated by adopting the security considerations provided below:
All customers should prioritize patching of CVE-2022-22047.
Confirm that Microsoft Defender Antivirus is updated to security intelligence update 1.371.503.0 or later to detect the related indicators.
Use the included indicators of compromise to investigate whether they exist in your environment and assess for potential intrusion.
Change Excel macro security settings to control which macros run and under what circumstances when you open a workbook. Customers can also stop malicious XLM or VBA macros by ensuring runtime macro scanning by Antimalware Scan Interface (AMSI) is on. This feature—enabled by default—is on if the Group Policy setting for Macro Run Time Scan Scope is set to “Enable for All Files” or “Enable for Low Trust Files”.
Enable multifactor authentication (MFA) to mitigate potentially compromised credentials and ensure that MFA is enforced for all remote connectivity. Note: Microsoft strongly encourages all customers download and use password-less solutions like Microsoft Authenticator to secure accounts.
Review all authentication activity for remote access infrastructure, with a particular focus on accounts configured with single factor authentication, to confirm authenticity and investigate any anomalous activity.
Indicators of compromise (IOCs)
The following list provides IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems. All sample hashes are available in VirusTotal.
NOTE: These indicators should not be considered exhaustive for this observed activity.
Detections
Microsoft Defender Antivirus
Microsoft Defender Antivirus detects the malware tools and implants used by KNOTWEED starting with signature build 1.371.503.0 as the following family names:
Backdoor:O97M/JumplumpDropper
Trojan:Win32/Jumplump
Trojan:Win32/Corelump
HackTool:Win32/Mexlib
Trojan:Win32/Medcerc
Behavior:Win32/SuspModuleLoad
Microsoft Defender for Endpoint
Microsoft Defender for Endpoint customers may see the following alerts as an indication of a possible attack. These alerts are not necessarily an indication of KNOTWEED compromise:
COM Hijacking – Detects multiple behaviors, including JumpLump malware persistence techniques.
Possible privilege escalation using CTF module – Detects a possible privilege escalation behavior associated with CVE-2022-2204; also detects an attempt to perform local privilege escalation by launching an elevated process and loading an untrusted module to perform malicious activities
KNOTWEED actor activity detected – Detects KNOTWEED actor activities
WDigest configuration change – Detects potential retrieval of clear text password from changes to UseLogonCredential registry key
The Microsoft Threat Intelligence Center (MSTIC) alongside the Microsoft Security Response Center (MSRC) has uncovered a private-sector offensive actor, or PSOA, that we are calling SOURGUM in possession of now-patched, Windows 0-day exploits (CVE-2021-31979 and CVE-2021-33771).
Private-sector offensive actors are private companies that manufacture and sell cyberweapons in hacking-as-a-service packages, often to government agencies around the world, to hack into their targets’ computers, phones, network infrastructure, and other devices. With these hacking packages, usually the government agencies choose the targets and run the actual operations themselves. The tools, tactics, and procedures used by these companies only adds to the complexity, scale, and sophistication of attacks. We take these threats seriously and have moved swiftly alongside our partners to build in the latest protections for our customers.
MSTIC believes SOURGUM is an Israel-based private-sector offensive actor. We would like to thank the Citizen Lab, at the University of Toronto’s Munk School, for sharing the sample of malware that initiated this work and their collaboration during the investigation. In their blog, Citizen Lab asserts with high confidence that SOURGUM is an Israeli company commonly known as Candiru. Third-party reports indicate Candiru produces “hacking tools [that] are used to break into computers and servers”.
As we shared in the Microsoft on the Issues blog, Microsoft and Citizen Lab have worked together to disable the malware being used by SOURGUM that targeted more than 100 victims around the world including politicians, human rights activists, journalists, academics, embassy workers, and political dissidents. To limit these attacks, Microsoft has created and built protections into our products against this unique malware, which we are calling DevilsTongue. We have shared these protections with the security community so that we can collectively address and mitigate this threat. We have also issued a software update that will protect Windows customers from the associated exploits that the actor used to help deliver its highly sophisticated malware.
SOURGUM victimology
Media reports (1, 2, 3) indicate that PSOAs often sell Windows exploits and malware in hacking-as-a-service packages to government agencies. Agencies in Uzbekistan, United Arab Emirates, and Saudi Arabia are among the list of Candiru’s alleged previous customers. These agencies, then, likely choose whom to target and run the cyberoperations themselves.
Microsoft has identified over 100 victims of SOURGUM’s malware, and these victims are as geographically diverse as would be expected when varied government agencies are believed to be selecting the targets. Approximately half of the victims were found in Palestinian Authority, with most of the remaining victims located in Israel, Iran, Lebanon, Yemen, Spain (Catalonia), United Kingdom, Turkey, Armenia, and Singapore. To be clear, the identification of victims of the malware in a country doesn’t necessarily mean that an agency in that country is a SOURGUM customer, as international targeting is common.
Any Microsoft 365 Defender and Microsoft Defender for Endpoint alerts containing detection names for the DevilsTongue malware name are signs of compromise by SOURGUM’s malware. We have included a comprehensive list of detection names below for customers to perform additional hunting in their environments.
Exploits
SOURGUM appears to use a chain of browser and Windows exploits, including 0-days, to install malware on victim boxes. Browser exploits appear to be served via single-use URLs sent to targets on messaging applications such as WhatsApp.
During the investigation, Microsoft discovered two Windows 0-day exploits for vulnerabilities tracked as CVE-2021-31979 and CVE-2021-33771, both of which have been fixed in the July 2021 security updates. These vulnerabilities allow privilege escalation, giving an attacker the ability to escape browser sandboxes and gain kernel code execution. If customers have taken the July 2021 security update, they are protected from these exploits.
CVE-2021-31979 fixes an integer overflow within Windows NT-based operating system (NTOS). This overflow results in an incorrect buffer size being calculated, which is then used to allocate a buffer in the kernel pool. A buffer overflow subsequently occurs while copying memory to the smaller-than-expected destination buffer. This vulnerability can be leveraged to corrupt an object in an adjacent memory allocation. Using APIs from user mode, the kernel pool memory layout can be groomed with controlled allocations, resulting in an object being placed in the adjacent memory location. Once corrupted by the buffer overflow, this object can be turned into a user mode to kernel mode read/write primitive. With these primitives in place, an attacker can then elevate their privileges.
CVE-2021-33771 addresses a race condition within NTOS resulting in the use-after-free of a kernel object. By using multiple racing threads, the kernel object can be freed, and the freed memory reclaimed by a controllable object. Like the previous vulnerability, the kernel pool memory can be sprayed with allocations using user mode APIs with the hopes of landing an object allocation within the recently freed memory. If successful, the controllable object can be used to form a user mode to kernel mode read/write primitive and elevate privileges.
DevilsTongue malware overview
DevilsTongue is a complex modular multi-threaded piece of malware written in C and C++ with several novel capabilities. Analysis is still on-going for some components and capabilities, but we’re sharing our present understanding of the malware so defenders can use this intelligence to protect networks and so other researchers can build on our analysis.
For files on disk, PDB paths and PE timestamps are scrubbed, strings and configs are encrypted, and each file has a unique hash. The main functionality resides in DLLs that are encrypted on disk and only decrypted in memory, making detection more difficult. Configuration and tasking data is separate from the malware, which makes analysis harder. DevilsTongue has both user mode and kernel mode capabilities. There are several novel detection evasion mechanisms built in. All these features are evidence that SOURGUM developers are very professional, have extensive experience writing Windows malware, and have a good understanding of operational security.
When the malware is installed, a first-stage ‘hijack’ malware DLL is dropped in a subfolder of C:\Windows\system32\IME\; the folders and names of the hijack DLLs blend with legitimate names in the \IME\ directories. Encrypted second-stage malware and config files are dropped into subfolders of C:\Windows\system32\config\ with a .dat file extension. A third-party legitimate, signed driver physmem.sys is dropped to the system32 folder. A file called WimBootConfigurations.ini is also dropped; this file has the command for following the COM hijack. Finally, the malware adds the hijack DLL to a COM class registry key, overwriting the legitimate COM DLL path that was there, achieving persistence via COM hijacking.
From the COM hijacking, the DevilsTongue first-stage hijack DLL gets loaded into a svchost.exe process to run with SYSTEM permissions. The COM hijacking technique means that the original DLL that was in the COM registry key isn’t loaded. This can break system functionality and trigger an investigation that could lead to the discovery of the malware, but DevilsTongue uses an interesting technique to avoid this. In its DllMain function it calls LoadLibrary on the original COM DLL so it is correctly loaded into the process. DevilsTongue then searches the call stack to find the return address of LoadLibraryExW (i.e., the function currently loading the DevilsTongue DLL), which would usually return the base address of the DevilsTongue DLL.
Once the LoadLibraryExW return address has been found, DevilsTongue allocates a small buffer with shellcode that puts the COM DLL’s base address (imecfmup.7FFE49060000 in Figure 1) into the rax register and then jumps to the original return address of LoadLibraryExW (svchost.7FF78E903BFB in Figures 1 and 2). In Figure 1 the COM DLL is named imecfmup rather than a legitimate COM DLL name because some DevilsTongue samples copied the COM DLL to another location and renamed it.
DevilsTongue then swaps the original LoadLibraryExW return address on the stack with the address of the shellcode so that when LoadLibraryExW returns it does so into the shellcode (Figures 2 and 3). The shellcode replaces the DevilsTongue base address in rax with the COM DLL’s base address, making it look like LoadLibraryExW has returned the COM DLL’s address. The svchost.exe host process now uses the returned COM DLL base address as it usually would.
Figure 2. Call stack before stack swap, LoadLibraryExW in kernelbase returning to svchost.exe (0x7FF78E903BFB)
Figure 3. Call stack after stack swap, LoadLibraryExW in kernelbase returning to the shellcode address (0x156C51E0000 from Figure 1)
This technique ensures that the DevilsTongue DLL is loaded by the svchost.exe process, giving the malware persistence, but that the legitimate COM DLL is also loaded correctly so there’s no noticeable change in functionality on the victim’s systems.
After this, the hijack DLL then decrypts and loads a second-stage malware DLL from one of the encrypted .dat files. The second-stage malware decrypts another .dat file that contains multiple helper DLLs that it relies on for functionality.
DevilsTongue has standard malware capabilities, including file collection, registry querying, running WMI commands, and querying SQLite databases. It’s capable of stealing victim credentials from both LSASS and from browsers, such as Chrome and Firefox. It also has dedicated functionality to decrypt and exfiltrate conversations from the Signal messaging app.
It can retrieve cookies from a variety of web browsers. These stolen cookies can later be used by the attacker to sign in as the victim to websites to enable further information gathering. Cookies can be collected from these paths (* is a wildcard to match any folders):
Interestingly, DevilsTongue seems able to use cookies directly from the victim’s computer on websites such as Facebook, Twitter, Gmail, Yahoo, Mail.ru, Odnoklassniki, and Vkontakte to collect information, read the victim’s messages, and retrieve photos. DevilsTongue can also send messages as the victim on some of these websites, appearing to any recipient that the victim had sent these messages. The capability to send messages could be weaponized to send malicious links to more victims.
Alongside DevilsTongue a third-party signed driver is dropped to C:\Windows\system32\physmem.sys. The driver’s description is “Physical Memory Access Driver,” and it appears to offer a “by-design” kernel read/write capability. This appears to be abused by DevilsTongue to proxy certain API calls via the kernel to hinder detection, including the capability to have some of the calls appear from other processes. Functions capable of being proxied include CreateProcessW, VirtualAllocEx, VirtualProtectEx, WriteProcessMemory, ReadProcessMemory, CreateFileW and RegSetKeyValueW.
Prevention and detection
To prevent compromise from browser exploits, it’s recommended to use an isolated environment, such as a virtual machine, when opening links from untrusted parties. Using a modern version of Windows 10 with virtualization-based protections, such as Credential Guard, prevents DevilsTongue’s LSASS credential-stealing capabilities. Enabling the attack surface reduction rule “Block abuse of exploited vulnerable signed drivers” in Microsoft Defender for Endpoint blocks the driver that DevilsTongue uses. Network protection blocks known SOURGUM domains.
Detection opportunities
This section is intended to serve as a non-exhaustive guide to help customers and peers in the cybersecurity industry to detect the DevilsTongue malware. We’re providing this guidance with the expectation that SOURGUM will likely change the characteristics we identify for detection in their next iteration of the malware. Given the actor’s level of sophistication, however, we believe that outcome would likely occur irrespective of our public guidance.
File locations
The hijack DLLs are in subfolders of \system32\ime\ with names starting with ‘im’. However, they are blended with legitimate DLLs in those folders. To distinguish between the malicious and benign, the legitimate DLLs are signed (on Windows 10) whereas the DevilsTongue files aren’t. Example paths:
C:\Windows\System32\IME\IMEJP\imjpueact.dll
C:\Windows\system32\ime\IMETC\IMTCPROT.DLL
C:\Windows\system32\ime\SHARED\imecpmeid.dll
The DevilsTongue configuration files, which are AES-encrypted, are in subfolders of C:\Windows\system32\config\ and have a .dat extension. The exact paths are victim-specific, although some folder names are common across victims. As the files are AES-encrypted, any files whose size mod 16 is 0 can be considered as a possible malware config file. The config files are always in new folders, not the legitimate existing folders (e.g., on Windows 10, never in \Journal, \systemprofile, \TxR etc.). Example paths:
The two COM keys that have been observed being hijacked for persistence are listed below with their default clean values. If their default value DLL is in the \system32\ime\ folder, the DLL is likely DevilsTongue.
This Yara rule can be used to find the DevilsTongue hijack DLL:
import "pe"
rule DevilsTongue_HijackDll
{
meta:
description = "Detects SOURGUM's DevilsTongue hijack DLL"
author = "Microsoft Threat Intelligence Center (MSTIC)"
date = "2021-07-15"
strings:
$str1 = "windows.old\\windows" wide
$str2 = "NtQueryInformationThread"
$str3 = "dbgHelp.dll" wide
$str4 = "StackWalk64"
$str5 = "ConvertSidToStringSidW"
$str6 = "S-1-5-18" wide
$str7 = "SMNew.dll" // DLL original name
// Call check in stack manipulation
// B8 FF 15 00 00 mov eax, 15FFh
// 66 39 41 FA cmp [rcx-6], ax
// 74 06 jz short loc_1800042B9
// 80 79 FB E8 cmp byte ptr [rcx-5], 0E8h ; 'è'
$code1 = {B8 FF 15 00 00 66 39 41 FA 74 06 80 79 FB E8}
// PRNG to generate number of times to sleep 1s before exiting
// 44 8B C0 mov r8d, eax
// B8 B5 81 4E 1B mov eax, 1B4E81B5h
// 41 F7 E8 imul r8d
// C1 FA 05 sar edx, 5
// 8B CA mov ecx, edx
// C1 E9 1F shr ecx, 1Fh
// 03 D1 add edx, ecx
// 69 CA 2C 01 00 00 imul ecx, edx, 12Ch
// 44 2B C1 sub r8d, ecx
// 45 85 C0 test r8d, r8d
// 7E 19 jle short loc_1800014D0
$code2 = {44 8B C0 B8 B5 81 4E 1B 41 F7 E8 C1 FA 05 8B CA C1 E9 1F 03 D1 69 CA 2C 01 00 00 44 2B C1 45 85 C0 7E 19}
condition:
filesize < 800KB and
uint16(0) == 0x5A4D and
(pe.characteristics & pe.DLL) and
(
4 of them or
($code1 and $code2) or
(pe.imphash() == "9a964e810949704ff7b4a393d9adda60")
)
}
Microsoft Defender Antivirus detections
Microsoft Defender Antivirus detects DevilsTongue malware with the following detections:
Trojan:Win32/DevilsTongue.A!dha
Trojan:Win32/DevilsTongue.B!dha
Trojan:Script/DevilsTongueIni.A!dha
VirTool:Win32/DevilsTongueConfig.A!dha
HackTool:Win32/DevilsTongueDriver.A!dha
Microsoft Defender for Endpoint alerts
Alerts with the following titles in the security center can indicate DevilsTongue malware activity on your network:
COM Hijacking
Possible theft of sensitive web browser information
Stolen SSO cookies
Azure Sentinel query
To locate possible SOURGUM activity using Azure Sentinel, customers can find a Sentinel query containing these indicators in this GitHub repository.
Indicators of compromise (IOCs)
No malware hashes are being shared because DevilsTongue files, except for the third part driver below, all have unique hashes, and therefore, are not a useful indicator of compromise.
Physmem driver
Note that this driver may be used legitimately, but if it’s seen on path C:\Windows\system32\physmem.sys then it is a high-confidence indicator of DevilsTongue activity. The hashes below are provided for the one driver observed in use.
