Microsoft’s IoT security commitments 

While customers are familiar with our approach to Windows PC and server security, many are unaware that Microsoft has taken similar steps to strengthen the security of business-critical systems and the networks that enclose them, including vulnerable and unmanaged IoT and OT endpoints. Microsoft often detects a wide range of threats targeting IoT devices, including sophisticated malware that enables attackers to target compromised devices using botnets³ or compromised routers,⁴ and a malicious form of cryptomining called cryptojacking.⁵ This blog post details Microsoft’s efforts to help partners create IoT solutions with strong security, thereby supporting initiatives outlined in the new National Cybersecurity Strategy and other US Cybersecurity and Infrastructure Security Agency (CISA) initiatives.

Developing and deploying software products that are secure by design and default is both a challenging and costly endeavor. According to recent guidance from the CISA, Secure-by-Design requires significant resources to incorporate security functions at each layer of the product development process.⁶ To maximize effectiveness, this approach needs to be integrated into a product’s design from the onset and cannot always be “bolted on” later.

Security by design and default is an enduring priority at Microsoft. In 2021, we committed to investing USD100 billion to advance our security solutions over five years (approximately USD20 billion per year) and today we employ more than 8,000 security professionals.⁷ One result of these investments is Windows 11, our most secure version of Windows yet. At Microsoft, we have a great deal of experience around security by design and default and have strived to implement best practices into our products and programs to assist partners who combine hardware, innovative functionality, online services, and operating systems (OS) to produce and maintain IoT solutions with robust security.

Applying Zero Trust to IoT

Instead of believing everything behind the corporate firewall is safe, the Zero Trust model assumes breach and verifies each request as though it originated from an uncontrolled network. Regardless of where the request originates or what resource it accesses, the Zero Trust model teaches us to “never trust, always verify.” A Zero Trust approach should extend throughout the entire digital estate and serve as an integrated security philosophy and end-to-end strategy.

Microsoft advocates for a Zero Trust approach to IoT security, based on the principle of verifying everything and trusting nothing (see Seven Properties of Highly Secure Devices). Zero Trust is also aligned with the new directives in the US National Cybersecurity Strategy and the requirements of the new US cybersecurity labeling program.

A traditional network security model often doesn’t meet the security or user experience needs of modern organizations, including those that have embraced IoT in their digital transformation strategy. User and device interactions with corporate resources and services now often bypass on-premises, perimeter-based defenses. Organizations need a comprehensive security model that more effectively adapts to the complexity of the modern environment, embraces the mobile workforce, and protects their people, devices, applications, and data wherever they are.

To optimize security and minimize risk for IoT devices, a Zero Trust approach requires:

1. Secure identity with Zero Trust: Identities—whether they represent people, services, or IoT devices—define the Zero Trust control plane. When an identity attempts to access a resource, verify that identity with strong authentication, and ensure access is compliant and typical for that identity. Follow least privilege access principles.
2. Secure endpoints with Zero Trust: Once an identity has been granted access to a resource, data can flow to a variety of different endpoints—from IoT devices to smartphones, bring-your-own-device (BYOD) to partner-managed devices, and on-premises workloads to cloud-hosted servers. This diversity creates a massive attack surface area. Monitor and enforce device health and compliance for secure access.
3. Secure applications with Zero Trust: Applications and APIs provide the interface by which data is consumed. They may be legacy on-premises, lifted and shifted to cloud workloads, or modern software as a service (SaaS) applications. Apply controls and technologies to discover shadow IT, ensure appropriate in-app permissions, gate access based on real-time analytics, monitor for abnormal behavior, control user actions, and validate secure configuration options.
4. Secure data with Zero Trust: Ultimately, security teams are protecting data. Where possible, data should remain safe even if it leaves the devices, apps, infrastructure, and networks the organization controls. Classify, label, and encrypt data, and restrict access based on those attributes.
5. Secure infrastructure with Zero Trust: Infrastructure—whether on-premises servers, cloud-based virtual machines, containers, or micro-services—represents a critical threat vector. Assess for version, configuration, and just-in-time access to harden defense. Use telemetry to detect attacks and anomalies, automatically block and flag risky behavior, and take protective actions.
6. Secure networks with Zero Trust: All data is ultimately accessed over network infrastructure. Networking controls can provide critical controls to enhance visibility and help prevent attackers from moving laterally across the network. Segment networks (and do deeper in-network micro-segmentation) and deploy real-time threat protection, end-to-end encryption, monitoring, and analytics.
7. Visibility, automation, and orchestration with Zero Trust: In our Zero Trust guides, we define the approach to implement an end-to-end Zero Trust methodology across identities, endpoints and devices, data, apps, infrastructure, and networks. These activities increase your visibility, which gives you better data for making trust decisions. With each of these individual areas generating their own relevant alerts, we need an integrated capability to manage the resulting influx of data to better defend against threats and validate trust in a transaction.

Microsoft’s Edge Secured-Core program

At Microsoft, we understand Secure-by-Design and Secure-by-Default are difficult to build and even more challenging to get right. To simplify this process, we created Edge Secured-Core, a Microsoft device certification program that codifies and operationalizes the security tenets such as secure by default and Zero Trust into a clear set of requirements. Edge Secured-Core also provides tooling and assistance to our device ecosystem partners to help them build devices that meet these security requirements. We have further customized those requirements for various platforms that manufacturers use to build devices, including Microsoft-provided operating systems Windows IoT and Microsoft Azure Sphere, and ecosystem-provided operating systems based on Linux. Edge Secured-Core devices from partners including Intel, AAEON, Lenovo, and Asus can be found in the Azure Certified Device Catalog today. 

Windows IoT

Windows IoT is a platform that leverages our long history and investment in Windows security to enable more secure and reliable IoT solutions. Whether you are building devices for industrial usage, healthcare or retail sectors, or other scenarios, Windows IoT provides key capabilities to protect your devices and data from the many prevalent threats in today’s digital landscape. 

Windows IoT capabilities include:

• BitLocker, which encrypts the data stored on the device to prevent unauthorized access.
• Secure Boot, which verifies the integrity of the boot process and prevents malicious code from running.
• Code integrity, which verifies the integrity of operating system files when loaded and enforces device manufacturer policies that dictate the drivers and applications that can be loaded on the device.
• Exploit mitigations, which automatically applies several exploit mitigation techniques to operating system processes and apps (examples include kernel pool protection, data execution protection, and address space layout randomization).
• Device attestation, which proves the identity and health of the device to cloud services.

Windows IoT also offers end-to-end management and updates using the trusted Windows infrastructure, ensuring consistent and timely delivery of security patches and feature enhancements. Some versions of Windows IoT support a 10-year servicing term, allowing partners to receive updates and maintain application compatibility, reducing the risk of obsolescence and vulnerability. 

Another benefit of Windows IoT is the flexibility to run containerized workflows, including Linux, on the same device. This allows partners to use existing skills and tools, thereby optimizing performance and resource utilization. Containers provide isolation and portability, enhancing the security and reliability of applications.

Defending against threats with Microsoft Azure Sphere

Microsoft Azure Sphere is a fully managed, integrated hardware, operating system, and cloud platform solution for medium- and low-power IoT devices. It offers a comprehensive approach to secure IoT devices from chip to cloud. 

Azure Sphere devices combine a low-power Arm Cortex-A processor running a custom Linux-based operating system serviced by Microsoft with Arm Cortex-M processors for real-time processing and control. Device manufacturers can develop, deploy, and update their applications, while Microsoft independently provides operating system security updates and device monitoring. Additionally, Azure Sphere devices embed the Microsoft Pluton security architecture, providing a hardware-based root of trust and cryptographic engine. Pluton protects the device identity, keys, and firmware from physical and software attacks and enables secure boot and remote attestation. 

Azure Sphere provides deep defense by employing multiple layers of protection to mitigate the impact of potential vulnerabilities, such as secure boot, kernel hardening, and a per-application network firewall. Azure Sphere devices communicate with a dedicated cloud service, the Azure Sphere Security Service, which attests the device is running expected and up-to-date software, performs both operating system and application updates, provides error reporting, and retrieves a Microsoft signed certificate that is renewed daily.

Similar to Windows IoT, Azure Sphere also offers a 10-year term for security fixes and operating system updates for all devices, as well as an application compatibility promise that ensures existing applications will continue to run on future operating system versions. Also, supporting CISA’s secure-by-design recommendations, Azure Sphere has started enabling embedded development using Rust, a coding language designed to improve memory safety and reduce mistakes during development.⁸

Enhancing security on Linux devices

While Microsoft directly provides operating system updates for Windows IoT and Azure Sphere, Edge Secured-core provides a way of ensuring the same security tenets of secure-by-design and default principles are applicable for devices that use ecosystem-provided distributions of the Linux OS. We collaborate with Linux partner companies to ensure their distributions meet security requirements such as committing to security updates for at least five years, building in support for Secure boot, etc. Microsoft incorporates security checks to onboard operating system partners and ongoing monitoring using Microsoft security agents on these devices, thus providing confidence to customers.

Secure your IoT devices with Microsoft Defender for IoT

Next to consumers, organizations are investing in automation and smart technology to streamline operations, cyber-physical systems, once completely isolated from the network, are now converging with mainstream IT infrastructure. Microsoft Defender for IoT is a security solution that enables organizations to implement Zero Trust principles across enterprise IoT and OT devices to minimize risk and protect these mission-critical systems from threats, as their attack surface expands.⁹

Defender for IoT empowers analysts to discover, manage, and secure enterprise IoT and OT devices in their environment. With network layer monitoring, analysts get a full view of their IoT and OT device estate as well as valuable insights into device-specific details and behaviors. These insights in tandem with generated alerts help analysts protect their environment by easily identifying and prioritizing risks like unpatched systems, vulnerabilities, and anomalous behavior all from a centralized user experience.

Support for the broader IoT ecosystem

Beyond these core platforms, Microsoft provides additional programs and services to enable partners to create more secure IoT devices. For example, due to the wide range of possible configurations and hardware platforms, operating systems such as Azure RTOS place the responsibility of security more heavily on the device manufacturer. SDKs and services like Device Update for Microsoft Azure IoT Hub allow partners to add support for over-the-air software updates to their products.

Microsoft Security supports the US National Cybersecurity Strategy

Microsoft remains committed to supporting the US National Cybersecurity Strategy and helping partners effectively deliver and maintain more secure IoT solutions using powerful technology, tools, and programs designed to improve security outcomes. It is vitally important that partners focus on IoT security by prioritizing security through smart design and development practices and carefully selecting platforms and security defaults that are secure as possible to lower the cost of maintaining the security of products.

Learn more

Learn more about Microsoft Defender for IoT.

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 on LinkedIn (Microsoft Security) and Twitter (@MSFTSecurity) for the latest news and updates on cybersecurity.

¹United States National Cybersecurity Strategy, The White House. March 2023.

²Biden-⁠Harris Administration Announces Cybersecurity Labeling Program for Smart Devices to Protect American Consumers, The White House. July 13, 2023.

³Microsoft research uncovers new Zerobot capabilities, Microsoft Threat Intelligence. December 21, 2022.

⁴Uncovering Trickbot’s use of IoT devices in command-and-control infrastructure, Microsoft Threat Intelligence. March 16, 2022.

⁵IoT devices and Linux-based systems targeted by OpenSSH trojan campaign, Microsoft Threat Intelligence. June 23, 2023.

⁶Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default, CISA. April 13, 2023.

⁷Satya Nadella on Twitter. August 25, 2021.

⁸Modernizing embedded development on Azure Sphere with Rust, Akshatha Udayashankar. January 11, 2023.

⁹Learn how Microsoft strengthens IoT and OT security with Zero Trust, Michal Braverman-Blumenstyk. November 8, 2021.

The post Adopting guidance from the US National Cybersecurity Strategy to secure the Internet of Things appeared first on Microsoft Security Blog.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. To learn more about this evolution, how the new taxonomy represents the origin, unique traits, and impact of threat actors, and a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

September 2022 update – New information about recent Qakbot campaigns leading to ransomware deployment.

July 2022 update – New information about DEV-0206-associated activity wherein existing Raspberry Robin infections are used to deploy FakeUpdates, which then leads to follow-on actions resembling DEV-0243.

June 2022 update – More details in the Threat actors and campaigns section, including recently observed activities from DEV-0193 (Trickbot LLC), DEV-0504, DEV-0237, DEV-0401, and a new section on Qakbot campaigns that lead to ransomware deployments.

Microsoft processes 24 trillion signals every 24 hours, and we have blocked billions of attacks in the last year alone. Microsoft Security tracks more than 35 unique ransomware families and 250 unique threat actors across observed nation-state, ransomware, and criminal activities.

That depth of signal intelligence gathered from various domains—identity, email, data, and cloud—provides us with insight into the gig economy that attackers have created with tools designed to lower the barrier for entry for other attackers, who in turn continue to pay dividends and fund operations through the sale and associated “cut” from their tool’s success.

The cybercriminal economy is a continuously evolving connected ecosystem of many players with different techniques, goals, and skillsets. In the same way our traditional economy has shifted toward gig workers for efficiency, criminals are learning that there’s less work and less risk involved by renting or selling their tools for a portion of the profits than performing the attacks themselves. This industrialization of the cybercrime economy has made it easier for attackers to use ready-made penetration testing and other tools to perform their attacks.

Within this category of threats, Microsoft has been tracking the trend in the ransomware as a service (RaaS) gig economy, called human-operated ransomware, which remains one of the most impactful threats to organizations. We coined the industry term “human-operated ransomware” to clarify that these threats are driven by humans who make decisions at every stage of their attacks based on what they find in their target’s network.

Unlike the broad targeting and opportunistic approach of earlier ransomware infections, attackers behind these human-operated campaigns vary their attack patterns depending on their discoveries—for example, a security product that isn‘t configured to prevent tampering or a service that’s running as a highly privileged account like a domain admin. Attackers can use those weaknesses to elevate their privileges to steal even more valuable data, leading to a bigger payout for them—with no guarantee they’ll leave their target environment once they’ve been paid. Attackers are also often more determined to stay on a network once they gain access and sometimes repeatedly monetize that access with additional attacks using different malware or ransomware payloads if they aren’t successfully evicted.

Ransomware attacks have become even more impactful in recent years as more ransomware as a service ecosystems have adopted the double extortion monetization strategy. All ransomware is a form of extortion, but now, attackers are not only encrypting data on compromised devices but also exfiltrating it and then posting or threatening to post it publicly to pressure the targets into paying the ransom. Most ransomware attackers opportunistically deploy ransomware to whatever network they get access to, and some even purchase access to networks from other cybercriminals. Some attackers prioritize organizations with higher revenues, while others prefer specific industries for the shock value or type of data they can exfiltrate.

All human-operated ransomware campaigns—all human-operated attacks in general, for that matter—share common dependencies on security weaknesses that allow them to succeed. Attackers most commonly take advantage of an organization’s poor credential hygiene and legacy configurations or misconfigurations to find easy entry and privilege escalation points in an environment. 

In this blog, we detail several of the ransomware ecosystems  using the RaaS model, the importance of cross-domain visibility in finding and evicting these actors, and best practices organizations can use to protect themselves from this increasingly popular style of attack. We also offer security best practices on credential hygiene and cloud hardening, how to address security blind spots, harden internet-facing assets to understand your perimeter, and more. Here’s a quick table of contents:

1. How RaaS redefines our understanding of ransomware incidents
   • The RaaS affiliate model explained
   • Access for sale and mercurial targeting
2. “Human-operated” means human decisions
   • Exfiltration and double extortion
   • Persistent and sneaky access methods
3. Threat actors and campaigns deep dive: Threat intelligence-driven response to human-operated ransomware attacks
4. Defending against ransomware: Moving beyond protection by detection
   • Building credential hygiene
   • Auditing credential exposure
   • Prioritizing deployment of Active Directory updates
   • Cloud hardening
   • Addressing security blind spots
   • Reducing the attack surface
   • Hardening internet-facing assets and understanding your perimeter

How RaaS redefines our understanding of ransomware incidents

With ransomware being the preferred method for many cybercriminals to monetize attacks, human-operated ransomware remains one of the most impactful threats to organizations today, and it only continues to evolve. This evolution is driven by the “human-operated” aspect of these attacks—attackers make informed and calculated decisions, resulting in varied attack patterns tailored specifically to their targets and iterated upon until the attackers are successful or evicted.

In the past, we’ve observed a tight relationship between the initial entry vector, tools, and ransomware payload choices in each campaign of one strain of ransomware. The RaaS affiliate model, which has allowed more criminals, regardless of technical expertise, to deploy ransomware built or managed by someone else, is weakening this link. As ransomware deployment becomes a gig economy, it has become more difficult to link the tradecraft used in a specific attack to the ransomware payload developers.

Reporting a ransomware incident by assigning it with the payload name gives the impression that a monolithic entity is behind all attacks using the same ransomware payload and that all incidents that use the ransomware share common techniques and infrastructure. However, focusing solely on the ransomware stage obscures many stages of the attack that come before, including actions like data exfiltration and additional persistence mechanisms, as well as the numerous detection and protection opportunities for network defenders.

We know, for example, that the underlying techniques used in human-operated ransomware campaigns haven’t changed very much over the years—attacks still prey on the same security misconfigurations to succeed. Securing a large corporate network takes disciplined and sustained focus, but there’s a high ROI in implementing critical controls that prevent these attacks from having a wider impact, even if it’s only possible on the most critical assets and segments of the network. 

Without the ability to steal access to highly privileged accounts, attackers can’t move laterally, spread ransomware widely, access data to exfiltrate, or use tools like Group Policy to impact security settings. Disrupting common attack patterns by applying security controls also reduces alert fatigue in security SOCs by stopping the attackers before they get in. This can also prevent unexpected consequences of short-lived breaches, such as exfiltration of network topologies and configuration data that happens in the first few minutes of execution of some trojans.

In the following sections, we explain the RaaS affiliate model and disambiguate between the attacker tools and the various threat actors at play during a security incident. Gaining this clarity helps surface trends and common attack patterns that inform defensive strategies focused on preventing attacks rather than detecting ransomware payloads. Threat intelligence and insights from this research also enrich our solutions like Microsoft 365 Defender, whose comprehensive security capabilities help protect customers by detecting RaaS-related attack attempts.

The RaaS affiliate model explained

The cybercriminal economy—a connected ecosystem of many players with different techniques, goals, and skillsets—is evolving. The industrialization of attacks has progressed from attackers using off-the-shelf tools, such as Cobalt Strike, to attackers being able to purchase access to networks and the payloads they deploy to them. This means that the impact of a successful ransomware and extortion attack remains the same regardless of the attacker’s skills.

RaaS is an arrangement between an operator and an affiliate. The RaaS operator develops and maintains the tools to power the ransomware operations, including the builders that produce the ransomware payloads and payment portals for communicating with victims. The RaaS program may also include a leak site to share snippets of data exfiltrated from victims, allowing attackers to show that the exfiltration is real and try to extort payment. Many RaaS programs further incorporate a suite of extortion support offerings, including leak site hosting and integration into ransom notes, as well as decryption negotiation, payment pressure, and cryptocurrency transaction services

RaaS thus gives a unified appearance of the payload or campaign being a single ransomware family or set of attackers. However, what happens is that the RaaS operator sells access to the ransom payload and decryptor to an affiliate, who performs the intrusion and privilege escalation and who is responsible for the deployment of the actual ransomware payload. The parties then split the profit. In addition, RaaS developers and operators might also use the payload for profit, sell it, and run their campaigns with other ransomware payloads—further muddying the waters when it comes to tracking the criminals behind these actions.

Access for sale and mercurial targeting

A component of the cybercriminal economy is selling access to systems to other attackers for various purposes, including ransomware. Access brokers can, for instance, infect systems with malware or a botnet and then sell them as a “load”. A load is designed to install other malware or backdoors onto the infected systems for other criminals. Other access brokers scan the internet for vulnerable systems, like exposed Remote Desktop Protocol (RDP) systems with weak passwords or unpatched systems, and then compromise them en masse to “bank” for later profit. Some advertisements for the sale of initial access specifically cite that a system isn’t managed by an antivirus or endpoint detection and response (EDR) product and has a highly privileged credential such as Domain Administrator associated with it to fetch higher prices.

Most ransomware attackers opportunistically deploy ransomware to whatever network they get access to. Some attackers prioritize organizations with higher revenues, while some target specific industries for the shock value or type of data they can exfiltrate (for example, attackers targeting hospitals or exfiltrating data from technology companies). In many cases, the targeting doesn’t manifest itself as specifically attacking the target’s network, instead, the purchase of access from an access broker or the use of existing malware infection to pivot to ransomware activities.

In some ransomware attacks, the affiliates who bought a load or access may not even know or care how the system was compromised in the first place and are just using it as a “jump server” to perform other actions in a network. Access brokers often list the network details for the access they are selling, but affiliates aren’t usually interested in the network itself but rather the monetization potential. As a result, some attacks that seem targeted to a specific industry might simply be a case of affiliates purchasing access based on the number of systems they could deploy ransomware to and the perceived potential for profit.

“Human-operated” means human decisions

Microsoft coined the term “human-operated ransomware” to clearly define a class of attacks driven by expert human intelligence at every step of the attack chain and culminate in intentional business disruption and extortion. Human-operated ransomware attacks share commonalities in the security misconfigurations of which they take advantage and the manual techniques used for lateral movement and persistence. However, the human-operated nature of these actions means that variations in attacks—including objectives and pre-ransom activity—evolve depending on the environment and the unique opportunities identified by the attackers.

These attacks involve many reconnaissance activities that enable human operators to profile the organization and know what next steps to take based on specific knowledge of the target. Many of the initial access campaigns that provide access to RaaS affiliates perform automated reconnaissance and exfiltration of information collected in the first few minutes of an attack.

After the attack shifts to a hands-on-keyboard phase, the reconnaissance and activities based on this knowledge can vary, depending on the tools that come with the RaaS and the operator’s skill. Frequently attackers query for the currently running security tools, privileged users, and security settings such as those defined in Group Policy before continuing their attack. The data discovered via this reconnaissance phase informs the attacker’s next steps.

If there’s minimal security hardening to complicate the attack and a highly privileged account can be gained immediately, attackers move directly to deploying ransomware by editing a Group Policy. The attackers take note of security products in the environment and attempt to tamper with and disable these, sometimes using scripts or tools provided with RaaS purchase that try to disable multiple security products at once, other times using specific commands or techniques performed by the attacker.  

This human decision-making early in the reconnaissance and intrusion stages means that even if a target’s security solutions detect specific techniques of an attack, the attackers may not get fully evicted from the network and can use other collected knowledge to attempt to continue the attack in ways that bypass security controls. In many instances, attackers test their attacks “in production” from an undetected location in their target’s environment, deploying tools or payloads like commodity malware. If these tools or payloads are detected and blocked by an antivirus product, the attackers simply grab a different tool, modify their payload, or tamper with the security products they encounter. Such detections could give SOCs a false sense of security that their existing solutions are working. However, these could merely serve as a smokescreen to allow the attackers to further tailor an attack chain that has a higher probability of success. Thus, when the attack reaches the active attack stage of deleting backups or shadow copies, the attack would be minutes away from ransomware deployment. The adversary would likely have already performed harmful actions like the exfiltration of data. This knowledge is key for SOCs responding to ransomware: prioritizing investigation of alerts or detections of tools like Cobalt Strike and performing swift remediation actions and incident response (IR) procedures are critical for containing a human adversary before the ransomware deployment stage.

Exfiltration and double extortion

Ransomware attackers often profit simply by disabling access to critical systems and causing system downtime. Although that simple technique often motivates victims to pay, it is not the only way attackers can monetize their access to compromised networks. Exfiltration of data and “double extortion,” which refers to attackers threatening to leak data if a ransom hasn’t been paid, has also become a common tactic among many RaaS affiliate programs—many of them offering a unified leak site for their affiliates. Attackers take advantage of common weaknesses to exfiltrate data and demand ransom without deploying a payload.

This trend means that focusing on protecting against ransomware payloads via security products or encryption, or considering backups as the main defense against ransomware, instead of comprehensive hardening, leaves a network vulnerable to all the stages of a human-operated ransomware attack that occur before ransomware deployment. This exfiltration can take the form of using tools like Rclone to sync to an external site, setting up email transport rules, or uploading files to cloud services. With double extortion, attackers don’t need to deploy ransomware and cause downtime to extort money. Some attackers have moved beyond the need to deploy ransomware payloads and are shifting straight to extortion models or performing the destructive objectives of their attacks by directly deleting cloud resources. One such extortion attackers is DEV-0537 (also known as LAPSUS$), which is profiled below.  

Persistent and sneaky access methods

Paying the ransom may not reduce the risk to an affected network and potentially only serves to fund cybercriminals. Giving in to the attackers’ demands doesn’t guarantee that attackers ever “pack their bags” and leave a network. Attackers are more determined to stay on a network once they gain access and sometimes repeatedly monetize attacks using different malware or ransomware payloads if they aren’t successfully evicted.

The handoff between different attackers as transitions in the cybercriminal economy occur means that multiple attackers may retain persistence in a compromised environment using an entirely different set of tools from those used in a ransomware attack. For example, initial access gained by a banking trojan leads to a Cobalt Strike deployment, but the RaaS affiliate that purchased the access may choose to use a less detectable remote access tool such as TeamViewer to maintain persistence on the network to operate their broader series of campaigns. Using legitimate tools and settings to persist versus malware implants such as Cobalt Strike is a popular technique among ransomware attackers to avoid detection and remain resident in a network for longer.

Some of the common enterprise tools and techniques for persistence that Microsoft has observed being used include:

• AnyDesk
• Atera Remote Management
• ngrok.io
• Remote Manipulator System
• Splashtop
• TeamViewer

Another popular technique attackers perform once they attain privilege access is the creation of new backdoor user accounts, whether local or in Active Directory. These newly created accounts can then be added to remote access tools such as a virtual private network (VPN) or Remote Desktop, granting remote access through accounts that appear legitimate on the network. Ransomware attackers have also been observed editing the settings on systems to enable Remote Desktop, reduce the protocol’s security, and add new users to the Remote Desktop Users group.

The time between initial access to a hands-on keyboard deployment can vary wildly depending on the groups and their workloads or motivations. Some activity groups can access thousands of potential targets and work through these as their staffing allows, prioritizing based on potential ransom payment over several months. While some activity groups may have access to large and highly resourced companies, they prefer to attack smaller companies for less overall ransom because they can execute the attack within hours or days. In addition, the return on investment is higher from companies that can’t respond to a major incident. Ransoms of tens of millions of dollars receive much attention but take much longer to develop. Many groups prefer to ransom five to 10 smaller targets in a month because the success rate at receiving payment is higher in these targets. Smaller organizations that can’t afford an IR team are often more likely to pay tens of thousands of dollars in ransom than an organization worth millions of dollars because the latter has a developed IR capability and is likely to follow legal advice against paying. In some instances, a ransomware associate threat actor may have an implant on a network and never convert it to ransom activity. In other cases, initial access to full ransom (including handoff from an access broker to a RaaS affiliate) takes less than an hour.

The human-driven nature of these attacks and the scale of possible victims under control of ransomware-associated threat actors underscores the need to take targeted proactive security measures to harden networks and prevent these attacks in their early stages.

Threat actors and campaigns deep dive: Threat intelligence-driven response to human-operated ransomware attacks

For organizations to successfully respond to evict an active attacker, it’s important to understand the active stage of an ongoing attack. In the early attack stages, such as deploying a banking trojan, common remediation efforts like isolating a system and resetting exposed credentials may be sufficient. As the attack progresses and the attacker performs reconnaissance activities and exfiltration, it’s important to implement an incident response process that scopes the incident to address the impact specifically. Using a threat intelligence-driven methodology for understanding attacks can assist in determining incidents that need additional scoping.

In the next sections, we provide a deep dive into the following prominent ransomware threat actors and their campaigns to increase community understanding of these attacks and enable organizations to better protect themselves:

• DEV-0193 cluster (Trickbot LLC): The most prolific ransomware group today  
• ELBRUS: (Un)arrested development
• DEV-0504: Shifting payloads reflecting the rise and fall of RaaS programs
• DEV-0237: Prolific collaborator
• DEV-0450 and DEV-0464: Distributing Qakbot for ransomware deployment
• DEV-0206 and DEV-0243: An “evil” partnership
• DEV-0401: China-based lone wolf turned LockBit 2.0 affiliate
• DEV-0537: From extortion to destruction

Microsoft threat intelligence directly informs our products as part of our commitment to track adversaries and protect customers. Microsoft 365 Defender customers should prioritize alerts titled “Ransomware-linked emerging threat activity group detected”. We also add the note “Ongoing hands-on-keyboard attack” to alerts that indicate a human attacker is in the network. When these alerts are raised, it’s highly recommended to initiate an incident response process to scope the attack, isolate systems, and regain control of credentials attackers may be in control of.

A note on threat actor naming: as part of Microsoft’s ongoing commitment to track both nation-state and cybercriminal threat actors, we refer to the unidentified threat actors as a “development group”. We use a naming structure with a prefix of “DEV” to indicate an emerging threat group or unique activity during investigation. When a nation-state group moves out of the DEV stage, we use chemical elements (for example, PHOSPHORUS and NOBELIUM) to name them. On the other hand, we use volcano names (such as ELBRUS) for ransomware or cybercriminal activity groups that have moved out of the DEV state. In the cybercriminal economy, relationships between groups change very rapidly. Attackers are known to hire talent from other cybercriminal groups or use “contractors,” who provide gig economy-style work on a limited time basis and may not rejoin the group. This shifting nature means that many of the groups Microsoft tracks are labeled as DEV, even if we have a concrete understanding of the nature of the activity group.

DEV-0193 cluster (Trickbot LLC): The most prolific ransomware group today

A vast amount of the current cybercriminal economy connects to a nexus of activity that Microsoft tracks as DEV-0193, also referred to as Trickbot LLC. DEV-0193 is responsible for developing, distributing, and managing many different payloads, including Trickbot, Bazaloader, and AnchorDNS. In addition, DEV-0193 managed the Ryuk RaaS program before the latter’s shutdown in June 2021, and Ryuk’s successor, Conti as well as Diavol. Microsoft has been tracking the activities of DEV-0193 since October 2020 and has observed their expansion from developing and distributing the Trickbot malware to becoming the most prolific ransomware-associated cybercriminal activity group active today. 

DEV-0193’s actions and use of the cybercriminal gig economy means they often add new members and projects and utilize contractors to perform various parts of their intrusions. As other malware operations have shut down for various reasons, including legal actions, DEV-0193 has hired developers from these groups. Most notable are the acquisitions of developers from Emotet, Qakbot, and IcedID, bringing them to the DEV-0193 umbrella.

A subgroup of DEV-0193, which Microsoft tracks as DEV-0365, provides infrastructure as a service for cybercriminals. Most notably, DEV-0365 provides Cobalt Strike Beacon as a service. These DEV-0365 Beacons have replaced unique C2 infrastructure in many active malware campaigns. DEV-0193 infrastructure has also been implicated in attacks deploying novel techniques, including exploitation of CVE-2021-40444. 

The leaked chat files from a group publicly labeled as the “Conti Group” in February 2022 confirm the wide scale of DEV-0193 activity tracked by Microsoft. Based on our telemetry from 2021 and 2022, Conti has become one of the most deployed RaaS ecosystems, with multiple affiliates concurrently deploying their payload—even as other RaaS ecosystems (DarkSide/BlackMatter and REvil) ceased operations. However, payload-based attribution meant that much of the activity that led to Conti ransomware deployment was attributed to the “Conti Group,” even though many affiliates had wildly different tradecraft, skills, and reporting structures. Some Conti affiliates performed small-scale intrusions using the tools offered by the RaaS, while others performed weeks-long operations involving data exfiltration and extortion using their own techniques and tools. One of the most prolific and successful Conti affiliates—and the one responsible for developing the “Conti Manual” leaked in August 2021—is tracked as DEV-0230. This activity group also developed and deployed the FiveHands and HelloKitty ransomware payloads and often gained access to an organization via DEV-0193’s BazaLoader infrastructure.

Microsoft hasn’t observed a Conti deployment in our data since April 19, 2022, suggesting that the Conti program has shut down or gone on hiatus, potentially in response to the visibility of DEV-0230’s deployment of Conti in high-profile incidents or FBI’s announcement of a reward for information related to Conti. As can be expected when a RaaS program shuts down, the gig economy nature of the ransomware ecosystem means that affiliates can easily shift between payloads. Conti affiliates who had previously deployed Conti have moved on to other RaaS payloads. For example, DEV-0506 was deploying BlackBasta part-time before the Conti shutdown and is now deploying it regularly. Similarly, DEV-0230 shifted to deploying QuantumLocker around April 23, 2022.

ELBRUS: (Un)arrested development

ELBRUS, also known as FIN7, has been known to be in operation since 2012 and has run multiple campaigns targeting a broad set of industries for financial gain. ELBRUS has deployed point-of-sale (PoS) and ATM malware to collect payment card information from in-store checkout terminals. They have also targeted corporate personnel who have access to sensitive financial data, including individuals involved in SEC filings.

In 2018, this activity group made headlines when three of its members were arrested. In May 2020, another arrest was made for an individual with alleged involvement with ELBRUS. However, despite law enforcement actions against suspected individual members, Microsoft has observed sustained campaigns from the ELBRUS group itself during these periods.

ELBRUS is responsible for developing and distributing multiple custom malware families used for persistence, including JSSLoader and Griffon. ELBRUS has also created fake security companies called “Combi Security” and “Bastion Security” to facilitate the recruitment of employees to their operations under the pretense of working as penetration testers.

In 2020 ELBRUS transitioned from using PoS malware to deploying ransomware as part of a financially motivated extortion scheme, specifically deploying the MAZE and Revil RaaS families. ELBRUS developed their own RaaS ecosystem named DarkSide. They deployed DarkSide payloads as part of their operations and recruited and managed affiliates that deployed the DarkSide ransomware. The tendency to report on ransomware incidents based on payload and attribute it to a monolithic gang often obfuscates the true relationship between the attackers, which is very accurate of the DarkSide RaaS. Case in point, one of the most infamous DarkSide deployments wasn’t performed by ELBRUS but by a ransomware as a service affiliate Microsoft tracks as DEV-0289.

ELBRUS retired the DarkSide ransomware ecosystem in May 2021 and released its successor, BlackMatter, in July 2021. Replicating their patterns from DarkSide, ELBRUS deployed BlackMatter themselves and ran a RaaS program for affiliates. The activity group then retired the BlackMatter ransomware ecosystem in November 2021.

While they aren’t currently publicly observed to be running a RaaS program, ELBRUS is very active in compromising organizations via phishing campaigns that lead to their JSSLoader and Griffon malware. Since 2019, ELBRUS has partnered with DEV-0324 to distribute their malware implants. DEV-0324 acts as a distributor in the cybercriminal economy, providing a service to distribute the payloads of other attackers through phishing and exploit kit vectors. ELBRUS has also been abusing CVE-2021-31207 in Exchange to compromise organizations in April of 2022, an interesting pivot to using a less popular authenticated vulnerability in the ProxyShell cluster of vulnerabilities. This abuse has allowed them to target organizations that patched only the unauthenticated vulnerability in their Exchange Server and turn compromised low privileged user credentials into highly privileged access as SYSTEM on an Exchange Server.  

DEV-0504: Shifting payloads reflecting the rise and fall of RaaS programs

An excellent example of how clustering activity based on ransomware payload alone can lead to obfuscating the threat actors behind the attack is DEV-0504. DEV-0504 has deployed at least six RaaS payloads since 2020, with many of their attacks becoming high-profile incidents attributed to the “REvil gang” or “BlackCat ransomware group”. This attribution masks the actions of the set of the attackers in the DEV-0504 umbrella, including other REvil and BlackCat affiliates. This has resulted in a confusing story of the scale of the ransomware problem and overinflated the impact that a single RaaS program shutdown can have on the threat environment.  

DEV-0504 shifts payloads when a RaaS program shuts down, for example the deprecation of REvil and BlackMatter, or possibly when a program with a better profit margin appears. These market dynamics aren’t unique to DEV-0504 and are reflected in most RaaS affiliates. They can also manifest in even more extreme behavior where RaaS affiliates switch to older “fully owned” ransomware payloads like Phobos, which they can buy when a RaaS isn’t available, or they don’t want to pay the fees associated with RaaS programs.

DEV-0504 appears to rely on access brokers to enter a network, using Cobalt Strike Beacons they have possibly purchased access to. Once inside a network, they rely heavily on PsExec to move laterally and stage their payloads. Their techniques require them to have compromised elevated credentials, and they frequently disable antivirus products that aren’t protected with tamper protection.

DEV-0504 was responsible for deploying BlackCat ransomware in companies in the energy sector in January 2022. Around the same time, DEV-0504 also deployed BlackCat in attacks against companies in the fashion, tobacco, IT, and manufacturing industries, among others. BlackCat remains DEV-0504’s primary payload as of June 2022.

DEV-0237: Prolific collaborator

Like DEV-0504, DEV-0237 is a prolific RaaS affiliate that alternates between different payloads in their operations based on what is available. DEV-0237 heavily used Ryuk and Conti payloads from Trickbot LLC/DEV-0193, then Hive payloads more recently. Many publicly documented Ryuk and Conti incidents and tradecraft can be traced back to DEV-0237.

After the activity group switched to Hive as a payload, a large uptick in Hive incidents was observed. Their switch to the BlackCat RaaS in March 2022 is suspected to be due to public discourse around Hive decryption methodologies; that is, DEV-0237 may have switched to BlackCat because they didn’t want Hive’s decryptors to interrupt their business. Overlap in payloads has occurred as DEV-0237 experiments with new RaaS programs on lower-value targets. They have been observed to experiment with some payloads only to abandon them later.

Beyond RaaS payloads, DEV-0237 uses the cybercriminal gig economy to also gain initial access to networks. DEV-0237’s proliferation and success rate come in part from their willingness to leverage the network intrusion work and malware implants of other groups versus performing their own initial compromise and malware development.

Like all RaaS operators, DEV-0237 relies on compromised, highly privileged account credentials and security weaknesses once inside a network. DEV-0237 often leverages Cobalt Strike Beacon dropped by the malware they have purchased, as well as tools like SharpHound to conduct reconnaissance. The group often utilizes BITSadmin /transfer to stage their payloads. An often-documented trademark of Ryuk and Conti deployments is naming the ransomware payload xxx.exe, a tradition that DEV-0237 continues to use no matter what RaaS they are deploying, as most recently observed with BlackCat. In late March of 2022, DEV-0237 was observed to be using a new version of Hive again.

In May 2022, DEV-0237 started to routinely deploy Nokoyawa, a payload that we observed the group previously experimenting with when they weren’t using Hive. While the group used other payloads such as BlackCat in the same timeframe, Nokoyawa became a more regular part of their toolkits. By June 2022, DEV-0237 was still primarily deploying Hive and sometimes Nokoyawa but was seen experimenting with other ransomware payloads, including Agenda and Mindware.

DEV-0237 is also one of several actors observed introducing other tools into their attacks to replace Cobalt Strike. Cobalt Strike’s ubiquity and visible impact has led to improved detections and heightened awareness in security organizations, leading to observed decreased use by actors. DEV-0237 now uses the SystemBC RAT and the penetration testing framework Sliver in their attacks, replacing Cobalt Strike.

DEV-0450 and DEV-0464: Distributing Qakbot for ransomware deployment

The evolution of prevalent trojans from being commodity malware to serving as footholds for ransomware is well documented via the impact of Emotet, Trickbot, and BazaLoader. Another widely distributed malware, Qakbot, also leads to handoffs to RaaS affiliates. Qakbot is delivered via email, often downloaded by malicious macros in an Office document. Qakbot’s initial actions include profiling the system and the network, and exfiltrating emails (.eml files) for later use as templates in its malware distribution campaigns.

Qakbot is prevalent across a wide range of networks, building upon successful infections to continue spreading and expanding. Microsoft tracks DEV-0450 and DEV-0464 as  Qakbot distributors that result in observed ransomware attacks. DEV-0450 distributes the “presidents”-themed Qakbot, using American presidents’ names in their malware campaigns. Meanwhile, DEV-0464 distributes the “TR” Qakbot and other malware such as SquirrelWaffle. DEV-0464 also rapidly adopted the Microsoft Support Diagnostic Tool (MSDT) vulnerability (CVE-2022-30190) in their campaigns. The abuse of malicious macros and MSDT can be blocked by preventing Office from creating child processes, which we detail in the hardening guidance below.

Historically, Qakbot infections typically lead to hands-on-keyboard activity and ransomware deployments by DEV-0216, DEV-0506, and DEV-0826. DEV-0506 previously deployed Conti but switched to deploying Black Basta around April 8, 2022. This group uses DEV-0365’s Cobalt Strike Beacon infrastructure instead of maintaining their own. In late September 2022, Microsoft observed DEV-0506 adding Brute Ratel as a tool to facilitate their hands-on-keyboard access as well as Cobalt Strike Beacons.

Another RaaS affiliate that acquired access from Qakbot infections was DEV-0216, which maintains their own Cobalt Strike Beacon infrastructure and has operated as an affiliate for Egregor, Maze, Lockbit, REvil, and Conti in numerous high-impact incidents. Microsoft no longer sees DEV-0216 ransomware incidents initiating from DEV-0464 and DEV-0450 infections, indicating they may no longer be acquiring access via Qakbot.

DEV-0206 and DEV-0243: An “evil” partnership

Malvertising, which refers to taking out a search engine ad to lead to a malware payload, has been used in many campaigns, but the access broker that Microsoft tracks as DEV-0206 uses this as their primary technique to gain access to and profile networks. Targets are lured by an ad purporting to be a browser update, or a software package, to download a ZIP file and double-click it. The ZIP package contains a JavaScript file (.js), which in most environments runs when double-clicked. Organizations that have changed the settings such that script files open with a text editor by default instead of a script handler are largely immune from this threat, even if a user double clicks the script.

Once successfully executed, the JavaScript framework, also referred to SocGholish, acts as a loader for other malware campaigns that use access purchased from DEV-0206, most commonly Cobalt Strike payloads. These payloads have, in numerous instances, led to custom Cobalt Strike loaders attributed to DEV-0243. DEV-0243 falls under activities tracked by the cyber intelligence industry as “EvilCorp,”  The custom Cobalt Strike loaders are similar to those seen in publicly documented Blister malware’s inner payloads. In DEV-0243’s initial partnerships with DEV-0206, the group deployed a custom ransomware payload known as WastedLocker, and then expanded to additional DEV-0243 ransomware payloads developed in-house, such as PhoenixLocker and Macaw.

Around November 2021, DEV-0243 started to deploy the LockBit 2.0 RaaS payload in their intrusions. The use of a RaaS payload by the “EvilCorp” activity group is likely an attempt by DEV-0243 to avoid attribution to their group, which could discourage payment due to their sanctioned status.

On July 26, 2022, Microsoft researchers discovered the FakeUpdates malware being delivered via existing Raspberry Robin infections. Raspberry Robin is a USB-based worm first publicly discussed by Red Canary. The DEV-0206-associated FakeUpdates activity on affected systems has since led to follow-on actions resembling DEV-0243 pre-ransomware behavior.

DEV-0401: China-based lone wolf turned LockBit 2.0 affiliate

Differing from the other RaaS developers, affiliates, and access brokers profiled here, DEV-0401 appears to be an activity group involved in all stages of their attack lifecycle, from initial access to ransomware development. Despite this, they seem to take some inspiration from successful RaaS operations with the frequent rebranding of their ransomware payloads. Unique among human-operated ransomware threat actors tracked by Microsoft, DEV-0401 is confirmed to be a China-based activity group.

DEV-0401 differs from many of the attackers who rely on purchasing access to existing malware implants or exposed RDP to enter a network. Instead, the group heavily utilizes unpatched vulnerabilities to access networks, including vulnerabilities in Exchange, Manage Engine AdSelfService Plus, Confluence, and Log4j 2. Due to the nature of the vulnerabilities they preferred, DEV-0401 gains elevated credentials at the initial access stage of their attack.

Once inside a network, DEV-0401 relies on standard techniques such as using Cobalt Strike and WMI for lateral movement, but they have some unique preferences for implementing these behaviors. Their Cobalt Strike Beacons are frequently launched via DLL search order hijacking. While they use the common Impacket tool for WMI lateral movement, they use a customized version of the wmiexec.py module of the tool that creates renamed output files, most likely to evade static detections. Ransomware deployment is ultimately performed from a batch file in a share and Group Policy, usually written to the NETLOGON share on a Domain Controller, which requires the attackers to have obtained highly privileged credentials like Domain Administrator to perform this action.

Because DEV-0401 maintains and frequently rebrands their own ransomware payloads, they can appear as different groups in payload-driven reporting and evade detections and actions against them. Their payloads are sometimes rebuilt from existing for-purchase ransomware tools like Rook, which shares code similarity with the Babuk ransomware family. In February of 2022, DEV-0401 was observed deploying the Pandora ransomware family, primarily via unpatched VMware Horizon systems vulnerable to the Log4j 2 CVE-2021-44228 vulnerability.

Like many RaaS operators, DEV-0401 maintained a leak site to post exfiltrated data and motivate victims to pay, however their frequent rebranding caused these systems to sometimes be unready for their victims, with their leak site sometimes leading to default web server landing pages when victims attempt to pay.  In a notable shift—possibly related to victim payment issues—DEV-0401 started deploying LockBit 2.0 ransomware payloads in April 2022. Around June 6, 2022, it began replacing Cobalt Strike with the Sliver framework in their attacks.

DEV-0537: From extortion to destruction

An example of a threat actor who has moved to a pure extortion and destruction model without deploying ransomware payloads is an activity group that Microsoft tracks as DEV-0537, also known as LAPSUS$. Microsoft has detailed DEV-0537 actions taken in early 2022 in this blog. DEV-0537 started targeting organizations mainly in Latin America but expanded to global targeting, including government entities, technology, telecom, retailers, and healthcare. Unlike more opportunistic attackers, DEV-0537 targets specific companies with an intent. Their initial access techniques include exploiting unpatched vulnerabilities in internet-facing systems, searching public code repositories for credentials, and taking advantage of weak passwords. In addition, there is evidence that DEV-0537 leverages credentials stolen by the Redline password stealer, a piece of malware available for purchase in the cybercriminal economy. The group also buys credentials from underground forums which were gathered by other password-stealing malware.

Once initial access to a network is gained, DEV-0537 takes advantage of security misconfigurations to elevate privileges and move laterally to meet their objectives of data exfiltration and extortion. While DEV-0537 doesn’t possess any unique technical capabilities, the group is especially cloud-aware. They target cloud administrator accounts to set up forwarding rules for email exfiltration and tamper with administrative settings on cloud environments. As part of their goals to force payment of ransom, DEV-0537 attempts to delete all server infrastructure and data to cause business disruption. To further facilitate the achievement of their goals, they remove legitimate admins and delete cloud resources and server infrastructure, resulting in destructive attacks. 

DEV-0537 also takes advantage of cloud admin privileges to monitor email, chats, and VOIP communications to track incident response efforts to their intrusions. DEV-0537 has been observed on multiple occasions to join incident response calls, not just observing the response to inform their attack but unmuting to demand ransom and sharing their screens while they delete their victim’s data and resources.

Defending against ransomware: Moving beyond protection by detection

A durable security strategy against determined human adversaries must include the goal of mitigating classes of attacks and detecting them. Ransomware attacks generate multiple, disparate security product alerts, but they could easily get lost or not responded to in time. Alert fatigue is real, and SOCs can make their lives easier by looking at trends in their alerts or grouping alerts into incidents so they can see the bigger picture. SOCs can then mitigate alerts using hardening capabilities like attack surface reduction rules. Hardening against common threats can reduce alert volume and stop many attackers before they get access to networks. 

Attackers tweak their techniques and have tools to evade and disable security products. They are also well-versed in system administration and try to blend in as much as possible. However, while attacks have continued steadily and with increased impact, the attack techniques attackers use haven’t changed much over the years. Therefore, a renewed focus on prevention is needed to curb the tide.

Ransomware attackers are motivated by easy profits, so adding to their cost via security hardening is key in disrupting the cybercriminal economy.

Building credential hygiene

More than malware, attackers need credentials to succeed in their attacks. In almost all attacks where ransomware deployment was successful, the attackers had access to a domain admin-level account or local administrator passwords that were consistent throughout the environment. Deployment then can be done through Group Policy or tools like PsExec (or clones like PAExec, CSExec, and WinExeSvc). Without the credentials to provide administrative access in a network, spreading ransomware to multiple systems is a bigger challenge for attackers. Compromised credentials are so important to these attacks that when cybercriminals sell ill-gotten access to a network, in many instances, the price includes a guaranteed administrator account to start with.

Credential theft is a common attack pattern. Many administrators know tools like Mimikatz and LaZagne, and their capabilities to steal passwords from interactive logons in the LSASS process. Detections exist for these tools accessing the LSASS process in most security products. However, the risk of credential exposure isn’t just limited to a domain administrator logging in interactively to a workstation. Because attackers have accessed and explored many networks during their attacks, they have a deep knowledge of common network configurations and use it to their advantage. One common misconfiguration they exploit is running services and scheduled tasks as highly privileged service accounts.

Too often, a legacy configuration ensures that a mission-critical application works by giving the utmost permissions possible. Many organizations struggle to fix this issue even if they know about it, because they fear they might break applications. This configuration is especially dangerous as it leaves highly privileged credentials exposed in the LSA Secrets portion of the registry, which users with administrative access can access. In organizations where the local administrator rights haven’t been removed from end users, attackers can be one hop away from domain admin just from an initial attack like a banking trojan. Building credential hygiene is developing a logical segmentation of the network, based on privileges, that can be implemented alongside network segmentation to limit lateral movement.

Here are some steps organizations can take to build credential hygiene:

• Aim to run services as Local System when administrative privileges are needed, as this allows applications to have high privileges locally but can’t be used to move laterally. Run services as Network Service when accessing other resources.
• Use tools like LUA Buglight to determine the privileges that applications really need.
• Look for events with EventID 4624 where the logon type is 2, 4, 5, or 10 and the account is highly privileged like a domain admin. This helps admins understand which credentials are vulnerable to theft via LSASS or LSA Secrets. Ideally, any highly privileged account like a Domain Admin shouldn’t be exposed on member servers or workstations.
• Monitor for EventID 4625 (Logon Failed events) in Windows Event Forwarding when removing accounts from privileged groups. Adding them to the local administrator group on a limited set of machines to keep an application running still reduces the scope of an attack as against running them as Domain Admin.
• Randomize Local Administrator passwords with a tool like Local Administrator Password Solution (LAPS) to prevent lateral movement using local accounts with shared passwords.
• Use a cloud-based identity security solution that leverages on-premises Active Directory signals get visibility into identity configurations and to identify and detect threats or compromised identities

Auditing credential exposure

Auditing credential exposure is critical in preventing ransomware attacks and cybercrime in general. BloodHound is a tool that was originally designed to provide network defenders with insight into the number of administrators in their environment. It can also be a powerful tool in reducing privileges tied to administrative account and understanding your credential exposure. IT security teams and SOCs can work together with the authorized use of this tool to enable the reduction of exposed credentials. Any teams deploying BloodHound should monitor it carefully for malicious use. They can also use this detection guidance to watch for malicious use.

Microsoft has observed ransomware attackers also using BloodHound in attacks. When used maliciously, BloodHound allows attackers to see the path of least resistance from the systems they have access, to highly privileged accounts like domain admin accounts and global administrator accounts in Azure.

Prioritizing deployment of Active Directory updates

Security patches for Active Directory should be applied as soon as possible after they are released. Microsoft has witnessed ransomware attackers adopting authentication vulnerabilities within one hour of being made public and as soon as those vulnerabilities are included in tools like Mimikatz. Ransomware activity groups also rapidly adopt vulnerabilities related to authentication, such as ZeroLogon and PetitPotam, especially when they are included in toolkits like Mimikatz. When unpatched, these vulnerabilities could allow attackers to rapidly escalate from an entrance vector like email to Domain Admin level privileges.

Cloud hardening

As attackers move towards cloud resources, it’s important to secure cloud resources and identities as well as on-premises accounts. Here are ways organizations can harden cloud environments:

Cloud identity hardening

• Implement the Azure Security Benchmark and general best practices for securing identity infrastructure, including:
  • Prevent on-premises service accounts from having direct rights to the cloud resources to prevent lateral movement to the cloud.
  • Ensure that “break glass” account passwords are stored offline and configure honey-token activity for account usage.
  • Implement Conditional Access policies enforcing Microsoft’s Zero Trust principles.
• Enable risk-based user sign-in protection and automate threat response to block high-risk sign-ins from all locations and enable MFA for medium-risk ones.
• Ensure that VPN access is protected via modern authentication methods.

Multifactor authentication (MFA)

• Enforce MFA on all accounts, remove users excluded from MFA, and strictly require MFA from all devices, in all locations, at all times.
• Enable passwordless authentication methods (for example, Windows Hello, FIDO keys, or Microsoft Authenticator) for accounts that support passwordless. For accounts that still require passwords, use authenticator apps like Microsoft Authenticator for MFA. Refer to this article for the different authentication methods and features.
• Identify and secure workload identities to secure accounts where traditional MFA enforcement does not apply.
• Ensure that users are properly educated on not accepting unexpected two-factor authentication (2FA).
• For MFA that uses authenticator apps, ensure that the app requires a code to be typed in where possible, as many intrusions where MFA was enabled (including those by DEV-0537) still succeeded due to users clicking “Yes” on the prompt on their phones even when they were not at their computers. Refer to this article for an example.
• Disable legacy authentication.

Cloud admins

• Ensure cloud admins/tenant admins are treated with the same level of security and credential hygiene as Domain Admins.
• Address gaps in authentication coverage.

Addressing security blind spots

In almost every observed ransomware incident, at least one system involved in the attack had a misconfigured security product that allowed the attacker to disable protections or evade detection. In many instances, the initial access for access brokers is a legacy system that isn’t protected by  antivirus or EDR solutions. It’s important to understand that the lack security controls on these systems that have access to highly privileged credentials act as blind spots that allow attackers to perform the entire ransomware and exfiltration attack chain from a single system without being detected. In some instances, this is specifically advertised as a feature that access brokers sell.

Organizations should review and verify that security tools are running in their most secure configuration and perform regular network scans to ensure appropriate security products are monitoring and protecting all systems, including servers. If this isn’t possible, make sure that your legacy systems are either physically isolated through a firewall or logically isolated by ensuring they have no credential overlap with other systems.

For Microsoft 365 Defender customers, the following checklist eliminates security blind spots:

• Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker tools and techniques, block new and unknown malware variants, and enhance attack surface reduction rules and tamper protection.
• Turn on tamper protection features to prevent attackers from stopping security services.
• Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when a non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode also blocks indicators identified proactively by Microsoft Threat Intelligence teams.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches.
• Use device discovery to increase visibility into the network by finding unmanaged devices and onboarding them to Microsoft Defender for Endpoint.
• Protect user identities and credentials using Microsoft Defender for Identity, a cloud-based security solution that leverages on-premises Active Directory signals to monitor and analyze user behavior to identify suspicious user activities, configuration issues, and active attacks.

Reducing the attack surface

Microsoft 365 Defender customers can turn on attack surface reduction rules to prevent common attack techniques used in ransomware attacks. These rules, which can be configured by all Microsoft Defender Antivirus customers and not just those using the EDR solution, offer significant hardening against attacks. In observed attacks from several ransomware-associated activity groups, Microsoft customers who had the following rules enabled were able to mitigate the attack in the initial stages and prevented hands-on-keyboard activity:

• Common entry vectors:
  • Block all Office applications from creating child processes
  • Block Office communication application from creating child processes
  • Block Office applications from creating executable content
  • Block Office applications from injecting code into other processes
  • Block execution of potentially obfuscated scripts
  • Block JavaScript or VBScript from launching downloaded executable content
• Ransomware deployment and lateral movement stage (in order of impact based on the stage in attack they prevent):
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)
  • Block process creations originating from PsExec and WMI commands
  • Use advanced protection against ransomware

In addition, Microsoft has changed the default behavior of Office applications to block macros in files from the internet, further reduce the attack surface for many human-operated ransomware attacks and other threats.

Hardening internet-facing assets and understanding your perimeter

Organizations must identify and secure perimeter systems that attackers might use to access the network. Public scanning interfaces, such as RiskIQ, can be used to augment data. Some systems that should be considered of interest to attackers and therefore need to be hardened include:

• Secure Remote Desktop Protocol (RDP) or Windows Virtual Desktop endpoints with MFA to harden against password spray or brute force attacks.
• Block Remote IT management tools such as Teamviewer, Splashtop, Remote Manipulator System, Anydesk, Atera Remote Management, and ngrok.io via network blocking such as perimeter firewall rules if not in use in your environment. If these systems are used in your environment, enforce security settings where possible to implement MFA.

Ransomware attackers and access brokers also use unpatched vulnerabilities, whether already disclosed or zero-day, especially in the initial access stage. Even older vulnerabilities were implicated in ransomware incidents in 2022 because some systems remained unpatched, partially patched, or because access brokers had established persistence on a previously compromised systems despite it later being patched.

Some observed vulnerabilities used in campaigns between 2020 and 2022 that defenders can check for and mitigate include:

• Citrix ADC systems affected by CVE-2019-19781
• Pulse Secure VPN systems affected by CVE-2019-11510, CVE-2020-8260, CVE-2020-8243, CVE-2021-22893, CVE-2021-22894, CVE-2021-22899, and CVE-2021-22900
• SonicWall SSLVPN affected by CVE-2021-20016
• Microsoft SharePoint servers affected by CVE-2019-0604
• Unpatched Microsoft Exchange servers
• Zoho ManageEngine systems affected by CVE-2020-10189
• FortiGate VPN servers affected by CVE-2018-13379
• Apache log4j CVE-2021-44228

Ransomware attackers also rapidly adopt new vulnerabilities. To further reduce organizational exposure, Microsoft Defender for Endpoint customers can use the threat and vulnerability management capability to discover, prioritize, and remediate vulnerabilities and misconfigurations.

Microsoft 365 Defender: Deep cross-domain visibility and unified investigation capabilities to defend against ransomware attacks

The multi-faceted threat of ransomware requires a comprehensive approach to security. The steps we outlined above defend against common attack patterns and will go a long way in preventing ransomware attacks. Microsoft 365 Defender is designed to make it easy for organizations to apply many of these security controls.

Microsoft 365 Defender’s industry-leading visibility and detection capabilities, demonstrated in the recent MITRE Engenuity ATT&CK® Evaluations, automatically stop most common threats and attacker techniques. To equip organizations with the tools to combat human-operated ransomware, which by nature takes a unique path for every organization, Microsoft 365 Defender provides rich investigation features that enable defenders to seamlessly inspect and remediate malicious behavior across domains.

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

In line with the recently announced expansion into a new service category called Microsoft Security Experts, we’re introducing the availability of Microsoft Defender Experts for Hunting for public preview. Defender Experts for Hunting is for customers who have a robust security operations center but want Microsoft to help them proactively hunt for threats across Microsoft Defender data, including endpoints, Office 365, cloud applications, and identity.

Join our research team at the Microsoft Security Summit digital event on May 12 to learn what developments Microsoft is seeing in the threat landscape, as well as how we can help your business mitigate these types of attacks. Ask your most pressing questions during the live chat Q&A. Register today.

The post Ransomware as a service: Understanding the cybercrime gig economy and how to protect yourself appeared first on Microsoft Security Blog.

This continuous evolution has seen Trickbot expand its reach from computers to Internet of Things (IoT) devices such as routers, with the malware updating its C2 infrastructure to utilize MikroTik devices and modules. MikroTik routers are widely used around the world across different industries. By using MikroTik routers as proxy servers for its C2 servers and redirecting the traffic through non-standard ports, Trickbot adds another persistence layer that helps malicious IPs evade detection by standard security systems.

The Microsoft Defender for IoT research team has recently discovered the exact method through which MikroTik devices are used in Trickbot’s C2 infrastructure. In this blog, we will share our analysis of the said method and provide insights on how attackers gain access to MikroTik devices and use compromised IoT devices in Trickbot attacks.

This analysis has enabled us to develop a forensic tool to identify Trickbot-related compromise and other suspicious indicators on MikroTik devices. We published this tool to help customers ensure these IoT devices are not susceptible to these attacks. We’re also sharing recommended steps for detection and remediating compromise if found, as well as general prevention steps to protect against future attacks.

How attackers compromise MikroTik devices for Trickbot C2

The purpose of Trickbot for using MikroTik devices is to create a line of communication between the Trickbot-affected device and the C2 server that standard defense systems in the network are not able to detect. The attackers begin by hacking into a MikroTik router. They do this by acquiring credentials using several methods, which we will discuss in detail in the following section.

The attackers then issue a unique command that redirects traffic between two ports in the router, establishing the line of communication between Trickbot-affected devices and the C2. MikroTik devices have unique hardware and software, RouterBOARD and RouterOS. This means that to run such a command, the attackers need expertise in RouterOS SSH shell commands. We uncovered this attacker method by tracking traffic containing these SSH shell commands.

Accessing the MikroTik device and maintaining access

Attackers first need to access the MikroTik shell to run the routing commands. To do so, they need to acquire credentials. As mentioned earlier, based on our analysis, there are several methods that attackers use to access a target router:

• Using default MikroTik passwords.
• Launching brute force attacks. We have seen attackers use some unique passwords that probably were harvested from other MikroTik devices.
• Exploiting CVE-2018-14847 on devices with RouterOS versions older than 6.42. This vulnerability gives the attacker the ability to read arbitrary files like user.dat, which contains passwords.

To maintain access, the attackers then change the affected router’s password.

Redirecting traffic

MikroTik devices have a unique Linux-based OS called RouterOS with a unique SSH shell that can be accessed through SSH protocol using a restricted set of commands. These commands can be easily identified by the prefix “/”. For example:

/ip
/system
/tool

These commands usually won’t have any meaning on regular Linux-based shells and are solely intended for MikroTik devices. We observed through Microsoft threat data the use of these types of commands. Understanding that these are MikroTik-specific commands, we were able to track their source and intent. For example, we observed attackers issuing the following commands:

/ip firewall nat add chain=dstnat proto=tcp dst-port=449   to-port=80 action=dst-nat to-addresses=<infected device> dst-address=<real C2 address>

From the command, we can understand the following:

• A new rule, similar to iptables, is created
• The rule redirects traffic from the device to a server
• The redirected traffic is received from port 449 and redirected to port 80

The said command is a legitimate network address translation (NAT) command that allows the NAT router to perform IP address rewriting. In this case, it is being used for malicious activity. Trickbot is known for using ports 443 and 449, and we were able to verify that some target servers were identified as TrickBot C2 servers in the past.

This analysis highlights the importance of keeping IoT devices secure in today’s ever evolving threat environment. Using Microsoft threat data, Microsoft’s IoT and operational technology (OT) security experts established the exact methods that attackers use to leverage compromised IoT devices and gained knowledge that can help us better protect customers from threats.

Defending IoT devices against Trickbot attacks

As security solutions for conventional computing devices continue to evolve and improve, attackers will explore alternative ways to compromise target networks. Attack attempts against routers and other IoT devices are not new, and being unmanaged, they can easily be the weakest links in the network. Therefore, organizations should also consider these devices when implementing security policies and best practices.

An open-source tool for MikroTik forensics

While investigating MikroTik and attacks in the wild, we observed several methods of attacking these devices in addition to the method we described in this blog. We aggregated our knowledge of these methods and known CVEs into an open-source tool that can extract the forensic artifacts related to these attacks.

Some of this tool’s functionalities include the following:

• Get the version of the device and map it to CVEs
• Check for scheduled tasks
• Look for traffic redirection rules (NAT and other rules)
• Look for DNS cache poisoning
• Look for default ports change
• Look for non-default users

We have published the tool in GitHub and are sharing this tool with the broader community to encourage better intelligence-sharing in the field of IoT security and to help build better protections against threat actors abusing IoT devices.

How to detect, remediate, and prevent infections

Organizations with potentially at-risk MikroTik devices can perform the following detection and remediation steps:

• Run the following command to detect if the NAT rule was applied to the device (completed by the tool as well):

/ip firewall nat print

If the following data exists, it might indicate infection:

chain=dstnat action=dst-nat to-addresses=<public IP address> 
to-ports=80 protocol=tcp dst-address=<your MikroTik IP> dst-port=449 
chain=srcnat action=masquerade src-address=<your MikroTik IP>

• Run the following command to remove the potentially malicious NAT rule:

/ip firewall nat remove numbers=<rule number to remove>

To prevent future infections, perform the following steps:

• Change the default password to a strong one
• Block port 8291 from external access
• Change SSH port to something other than default (22)
• Make sure routers are up to date with the latest firmware and patches
• Use a secure virtual private network (VPN) service for remote access and restrict remote access to the router

Protect IoT devices and IT networks with Microsoft Defender

To harden IoT devices and IT networks against threats like Trickbot, organizations must implement solutions that detect malicious attempts to access devices and raises alerts on anomalous network behavior. Microsoft Defender for IoT provides agentless, network-layer security that lets organizations deploy continuous asset discovery, vulnerability management, and threat detection for IoT, OT devices, and Industrial Control Systems (ICS) on-premises or in Azure-connected environments. It is updated regularly with indicators of compromise (IoCs) from threat research like the one described on this blog, and rules to detect malicious activity.

Meanwhile, Microsoft 365 Defender protects against attacks related to highly modular, multi-stage malware like Trickbot by coordinating threat data across identities, endpoints, cloud apps, email, and documents. Such cross-domain visibility allows Microsoft 365 Defender to comprehensively detect and remediate Trickbot’s end-to-end attack chain—from malicious attachments and links it sends via emails to its follow-on activities in endpoints. Its rich set of tools like advanced hunting also lets defenders surface threats and gain insights for hardening networks from compromise.

In addition, working with the Microsoft Defender for IoT Research Team, RiskIQ identified compromised MikroTik routers acting as communication channels for Trickbot C2 and created detection logic to flag devices under threat actor control. See RiskIQ’s article.

To learn more about securing your IoT and OT devices, explore Microsoft Defender for IoT.

David Atch, Section 52 at Microsoft Defender for IoT
Noa Frumovich, Section 52 at Microsoft Defender for IoT
Ross Bevington, Microsoft Threat Intelligence Center (MSTIC)

The post Uncovering Trickbot’s use of IoT devices in command-and-control infrastructure appeared first on Microsoft Security Blog.

The data-driven decisions the system makes are based on extensive research and experimentation to maximize blocking effectiveness without impacting customer experience. Since the adaptive protection is AI-driven, the risk score given to a device is not only dependent on individual indicators but on a broad swath of patterns and features that the system uses to determine whether an attack is imminent or underway. This capability is suited in fighting against human-operated ransomware because even if attackers use an unknown or benign file or even a legitimate file or process, the system can help prevent the file or process from launching.

In a customer environment, the AI-driven adaptive protection feature was especially successful in helping prevent humans from entering the network by stopping the binary that would grant them access. By considering indicators that would otherwise be considered low priority for remediation, adaptive protection stopped the attack chain at an early stage such that the overall impact of the attack was significantly reduced. The threat turned out to be Cridex, a banking trojan commonly used for credential theft and data exfiltration, which are also key components in many cyberattacks including human-operated ransomware.

Microsoft Defender for Endpoint customers who have enabled cloud protection are already getting the benefits of this improvement on their devices (servers excluded)—no additional step required. While cloud-delivered protection is turned on by default, we encourage customers to check and ensure that it remains on. This backend enhancement can help prevent human-operated attacks and other sophisticated threats from progressing inside a network and give incident responders more time to analyze and remediate attacks when they do happen. Microsoft will continue to use data science techniques to enrich and develop machine learning algorithms used in Microsoft 365 Defender.

Seeing adaptive protection in action

At Microsoft, our data scientists are constantly researching and prototyping advanced AI techniques to battle ransomware attackers. One feature that has proven to be effective against these attacks is the new AI-driven adaptive protection, recently released to our enterprise customers.

Figure 1. How the AI-driven adaptive protection works. Note that the device risk scoring is done in real time by design and thus does not cause any latency.

The adaptive protection feature works on top of the existing robust cloud protection, which defends against threats through different next-generation technologies. Compared to the existing cloud protection level feature, which relies on admins to manually adjust the cloud protection level, the adaptive protection is smarter and faster. It can, when queried by a device, automatically ramp the aggressiveness of cloud-delivered blocking verdicts up or down based on real-time machine learning predictions, thus proactively protecting the device.

We can see the AI-driven adaptive protection in action in a case where the system blocked a certain file. Before the occurrence of this file on the device, there were suspicious behaviors observed on the device such as system code injection and task scheduling. These signals, among others, were all taken into consideration by the AI-driven adaptive protection’s intelligent cloud classifiers, and when the device was predicted as “at risk,” the cloud blocking aggressiveness was instantly ramped up. Owing to the increased aggressiveness, Microsoft Defender Antivirus detected and blocked this file. It’s more difficult by nature to detect and block new malware at first sight, so without the adaptive cloud protection capability, this file might not have been blocked on this customer’s device.

Later the file was determined as a variant of Cridex, which is commonly used for credential theft and data exfiltration, leading to these credentials and data being used by cybercriminals in later attacks. These behaviors are also key components in human-operated ransomware attacks, where early detection is critical to prevent further impact. We elaborate more on how the adaptive cloud protection can protect customers from human-operated ransomware attacks in the next sections.

Using machine learning to power adaptive cloud protection

For this feature to perform as we intended, we needed it to do two things quite well. One, we needed the system to accurately determine whether a device is at risk. Two, the system then needed to respond and adjust depending on the previous judgment or score.

Predicting whether a device is at risk

As devices come under attack, activities on a device often start as a small number of suspicious indicators that would not, in isolation, typically be surfaced as a malicious attack. However, when these signals are seen in sequence over time or in a cluster pattern, AI-driven protection can assess the state of a device at the arrival time of each new signal and can immediately adjust the risk score of the device accordingly. Example signals include previous malware encounters, threats, behavior events, and other relevant information.

If a device is incorrectly scored as not at risk when it is in fact at risk, the attacker could perform additional activities that might be more difficult for detection technologies to catch, for instance if the attacker steals credentials and uses them to move laterally. Conversely, if a device is incorrectly determined as at risk when it is not, then the customer experience suffers. To strike a balance, we needed to find an intelligent machine learning model that can give an accurate score and test that model vigorously.

The model we chose is a binary classifier with pattern recognition (specifically, frequent itemset mining) integrated. A study has shown that the co-occurrence or pattern is a stronger discriminator for these purposes rather than individual tokens, and that using co-occurrence increases the overall robustness of the model. To this end, we’ve included frequent patterns that commonly show up in the malicious samples as input features. To further increase the accuracy of the model (or the number of correct classifications over total predictions), only discriminative patterns were selected by excluding the patterns that have a small Jaccard similarity distance to the frequent patterns present in the benign samples.

The risk score for the device as calculated by the model at that point in time then determines the system’s next steps.

Adjusting cloud blocking aggressiveness automatically

If the risk score of the given device exceeds a certain threshold, cloud protection automatically switches to aggressive blocking. This level of blocking means that some processes or files that would not immediately be considered malicious might also be blocked given that the device is at risk, and they are likely to have been used maliciously. Both the risk score threshold and the switch to aggressive mode are data-driven decisions based on intensive research and experiments to maximize blocking effectiveness without impacting customer experience.

Furthermore, since the risk of a device is scored and refreshed in real time, the cloud immediately ramps down the aggressiveness right after the device is deemed to be no longer at risk. Therefore, we can make sure that this AI-driven adaptive protection feature won’t cause unnecessary false positives or disrupt customer experience.

Delivering contextual and personalized protection

The responsiveness of the blocking mechanism to the real-time risk score computation in the cloud assures that the system makes better-informed decisions, resulting in contextual or stateful blocking in devices. This level of protection customization is such that the protection experience on each device is different—even for the same file or behavior.

For instance, process A can be allowed on a device that has a low risk score, but process A can be blocked and alerted on a potentially risky device. This “personalization” is beneficial for customers because they are less likely to contract false positives or false negatives, unlike machine learning models trained on a dataset that is a mix of every device. Essentially, each device receives a level of protection that is tailored to it.

Adaptive cloud machine learning against human-operated ransomware

AI-driven adaptive protection has a wide range of use cases and tremendous potential value. Its application in human-operated ransomware prevention has been particularly successful. Human-operated ransomware attack chains usually follow specific patterns, starting with campaigns to distribute malicious files, then using techniques such as lateral movement for credential theft and data exfiltration, and finally deploying and activating ransomware payloads to encrypt files on the device and display a ransom note.

However, since threat actors react and adjust to specific findings in the environment, they are able to move fast and use a variety of alternatives to get to their next steps. This makes it challenging for incident responders to quickly determine whether an attack is underway and how to stop the attackers. Our adaptive protection, however, can pick up traces of attacker activity that occur before the actual encryption of files. These data are all collected by our machine learning algorithm and used as evidence to evaluate risk. When the system determines that the current device is compromised or at risk, aggressive cloud blocking kicks in instantly.

Detecting and blocking abuse of legitimate processes or files

In the hands-on-keyboard phase of human-operated ransomware attacks, attackers often use legitimate processes or files for their succeeding steps. For example, network enumeration is a benign behavior by nature, but when it is observed on a device that is determined to be compromised, the likelihood that attackers are performing reconnaissance activities and identifying targets is greater. Adaptive protection can intelligently block network enumeration behavior on risky devices to stop the attack chain and prevent further attacks.

Detecting and blocking ransomware loaders

Ransomware loaders refer to a set of tools or commodity malware that are usually used in the initial and intermediate stages of a ransomware attack. For example, Ryuk is delivered through banking trojan infections like Trickbot. If Trickbot infections go undetected, attackers may be able to move laterally and gain privilege on critical accounts, leading to destructive outcomes.

Known ransomware loaders are fairly easy to detect, so attackers usually make slight changes to the file to evade file signature matching. They then distribute many versions of the file so they can increase the chances that at least one will not be blocked. Due to their polymorphic nature, these files can sometimes be missed by traditional approaches to malware detection. However, with real-time knowledge of the device state, adaptive cloud machine learning significantly reduces the chance of missing them.

Stopping ransomware payloads

Hypothetically, in attacks where early to mid-stage attack activities are not detected and blocked, AI-driven adaptive protection can still demonstrate huge value when it comes to the final ransomware payload. Given the device is already compromised, our AI-driven adaptive protection system can easily and automatically switch to the most aggressive mode and block the actual ransomware payloads, preventing important files and data from being encrypted so attackers won’t be able to demand ransom for them.

Smarter, faster protection from the cloud

With the AI-driven adaptive protection, Microsoft Defender for Endpoint can adjust the aggressiveness in real time according to the device state, buy security operations centers more time when incidents happen, and potentially stop an attack chain from the beginning. With the wide coverage and high blocking quality of this feature, we believe it will benefit all enterprise customers and further enhance next-generation of AI-powered protection.

The AI-driven adaptive protection feature in Microsoft Defender for Endpoint is just one of the many different AI layers that support our threat intelligence, which strengthen our ability to detect and protect against security threats. More threat data increases the quality of signals analyzed by Microsoft 365 Defender as it provides cross-domain defense against costly attacks like human-operated ransomware.

Ruofan Wang and Kelly Kang
Microsoft 365 Defender Research Team

The post AI-driven adaptive protection against human-operated ransomware appeared first on Microsoft Security Blog.

As the name suggests, HTML smuggling lets an attacker “smuggle” an encoded malicious script within a specially crafted HTML attachment or web page. When a target user opens the HTML in their web browser, the browser decodes the malicious script, which, in turn, assembles the payload on the host device. Thus, instead of having a malicious executable pass directly through a network, the attacker builds the malware locally behind a firewall.

Figure 1. HTML smuggling overview

This technique is highly evasive because it could bypass standard perimeter security controls, such as web proxies and email gateways, that often only check for suspicious attachments (for example, EXE, ZIP, or DOCX) or traffic based on signatures and patterns. Because the malicious files are created only after the HTML file is loaded on the endpoint through the browser, what some protection solutions only see at the onset are benign HTML and JavaScript traffic, which can also be obfuscated to further hide their true purpose.

Threats that use HTML smuggling bank on the legitimate uses of HTML and JavaScript in daily business operations in their attempt to stay hidden and relevant, as well as challenge organizations’ conventional mitigation procedures. For example, disabling JavaScript could mitigate HTML smuggling created using JavaScript Blobs. However, JavaScript is used to render business-related and other legitimate web pages. In addition, there are multiple ways to implement HTML smuggling through obfuscation and numerous ways of coding JavaScript, making the said technique highly evasive against content inspection. Therefore, organizations need a true “defense in depth” strategy and a multi-layered security solution that inspects email delivery, network activity, endpoint behavior, and follow-on attacker activities.

The surge in the use of HTML smuggling in email campaigns is another example of how attackers keep refining specific components of their attacks by integrating highly evasive techniques. Microsoft Defender for Office 365 stops such attacks at the onset using dynamic protection technologies, including machine learning and sandboxing, to detect and block HTML-smuggling links and attachments. Email threat signals from Defender for Office 365 also feed into Microsoft 365 Defender, which provides advanced protection on each domain—email and data, endpoints, identities, and cloud apps—and correlates threat data from these domains to surface evasive, sophisticated threats. This provides organizations with comprehensive and coordinated defense against the end-to-end attack chain.

This blog entry details how HTML smuggling works, provides recent examples of threats and targeted attack campaigns that use it, and enumerates mitigation steps and protection guidance.

How HTML smuggling works

HTML smuggling uses legitimate features of HTML5 and JavaScript, which are both supported by all modern browsers, to generate malicious files behind the firewall. Specifically, HTML smuggling leverages the HTML5 “download” attribute for anchor tags, as well as the creation and use of a JavaScript Blob to put together the payload downloaded into an affected device.

In HTML5, when a user clicks a link, the “download” attribute lets an HTML file automatically download a file referenced in the “href” tag. For example, the code below instructs the browser to download “malicious.docx” from its location and save it into the device as “safe.docx”:

The anchor tag and a file’s “download” attribute also have their equivalents in JavaScript code, as seen below:

The use of JavaScript Blobs adds to the “smuggling” aspect of the technique. A JavaScript Blob stores the encoded data of a file, which is then decoded when passed to a JavaScript API that expects a URL. This means that instead of providing a link to an actual file that a user must manually click to download, the said file can be automatically downloaded and constructed locally on the device using JavaScript codes like the ones below:

Today’s attacks use HTML smuggling in two ways: the link to an HTML smuggling page is included within the email message, or the page itself is included as an attachment. The following section provides examples of actual threats we have recently seen using either of these methods.

Real-world examples of threats using HTML smuggling

HTML smuggling has been used in banking malware campaigns, notably attacks attributed to DEV-0238 (also known as Mekotio) and DEV-0253 (also known as Ousaban), targeting Brazil, Mexico, Spain, Peru, and Portugal. In one of the Mekotio campaigns we’ve observed, attackers sent emails with a malicious link, as shown in the image below.

Figure 2. Sample email used in a Mekotio campaign. Clicking the link starts the HTML smuggling technique.

Figure 3. Threat behavior observed in the Mekotio campaign

In this campaign, a malicious website, hxxp://poocardy[.]net/diretorio/, is used to implement the HTML smuggling technique and drop the malicious downloader file. The image below shows an HTML smuggling page when rendered on the browser.

Figure 4. HTML smuggling page of the Mekotio campaign. Note how the “href” tag references a JavaScript Blob with an octet/stream type to download the malicious ZIP file.

It should be noted that this attack attempt relies on social engineering and user interaction to succeed. When a user clicks the emailed hyperlink, the HTML page drops a ZIP file embedded with an obfuscated JavaScript file.

Figure 5. ZIP file with an obfuscated JavaScript file

When the user opens the ZIP file and executes the JavaScript, the said script connects to hxxps://malparque[.]org/rest/restfuch[.]png and downloads another ZIP file that masquerades as a PNG file. This second ZIP file contains the following files related to DAEMON Tools:

• sptdintf.dll – This is a legitimate file. Various virtual disc applications, including DAEMON Tools and Alcohol 120%, use this dynamic-link library (DLL) file.
• imgengine.dll – This is a malicious file that is either Themida-packed or VMProtected for obfuscation. It accesses geolocation information of the target and attempts credential theft and keylogging.
• An executable file with a random name, which is a renamed legitimate file “Disc Soft Bus Service Pro.” This legitimate file is part of DAEMON Tools Pro and loads both DLLs.

Finally, once the user runs the primary executable (the renamed legitimate file), it launches and loads the malicious DLL via DLL sideloading. As previously mentioned, this DLL file is attributed to Mekotio, a malware family of banking Trojans typically deployed on Windows systems that have targeted Latin American industries since the latter half of 2016.

HTML smuggling in targeted attacks

Beyond banking malware campaigns, various cyberattacks—including more sophisticated, targeted ones—incorporate HTML smuggling in their arsenal. Such adoption shows how tactics, techniques, and procedures (TTPs) trickle down from cybercrime gangs to malicious threat actors and vice versa. It also reinforces the current state of the underground economy, where such TTPs get commoditized when deemed effective.

For example, in May, Microsoft Threat Intelligence Center (MSTIC) published a detailed analysis of a new sophisticated email attack from NOBELIUM. MSTIC noted that the spear-phishing email used in that campaign contained an HTML file attachment, which, when opened by the targeted user, uses HTML smuggling to download the main payload on the device.

Since then, other malicious actors appeared to have followed NOBELIUM’s suit and adopted the technique for their own campaigns. Between July and August, open-source intelligence (OSINT) community signals showed an uptick in HTML smuggling in campaigns that deliver remote access Trojans (RATs) such as AsyncRAT/NJRAT.

In September, we saw an email campaign that leverages HTML smuggling to deliver Trickbot. Microsoft attributes this Trickbot campaign to an emerging, financially motivated cybercriminal group we’re tracking as DEV-0193.

In the said campaign, the attacker sends a specially crafted HTML page as an attachment to an email message purporting to be a business report.

Figure 6. HTML smuggling page attached in a Trickbot spear-phishing campaign

When the target recipient opens the HTML attachment in a web browser, it constructs a JavaScript file and saves the said file in the device’s default Downloads folder. As an added detection-evasion technique against endpoint security controls, the created JavaScript file is password-protected. Therefore, the user must type the password indicated in the original HTML attachment to open it.

Figure 7. HTML attachment constructs a password-protected downloader JavaScript in the browser

Once the user executes the JavaScript, it initiates a Base64-encoded PowerShell command, which then calls back to the attacker’s servers to download Trickbot.

Figure 8. HTML smuggling attack chain in the Trickbot spear-phishing campaign

Based on our investigations, DEV-0193 targets organizations primarily in the health and education industries, and works closely with ransomware operators, such as those behind the infamous Ryuk ransomware. After compromising an organization, this group acts as a fundamental pivot point and enabler for follow-on ransomware attacks. They also often sell unauthorized access to the said operators. Thus, once this group compromises an environment, it is highly likely that a ransomware attack will follow.

Defending against the wide range of threats that use HTML smuggling

HTML smuggling presents challenges to traditional security solutions. Effectively defending against this stealthy technique requires true defense in depth. It is always better to thwart an attack early in the attack chain—at the email gateway and web filtering level. If the threat manages to fall through the cracks of perimeter security and is delivered to a host machine, then endpoint protection controls should be able to prevent execution.

Microsoft 365 Defender uses multiple layers of dynamic protection technologies, including machine learning-based protection, to defend against malware threats and other attacks that use HTML smuggling at various levels. It correlates threat data from email, endpoints, identities, and cloud apps, providing in-depth and coordinated threat defense. All of these are backed by threat experts who continuously monitor the threat landscape for new attacker tools and techniques.

Microsoft Defender for Office 365 inspects attachments and links in emails to detect and alert on HTML smuggling attempts. Over the past six months, Microsoft blocked thousands of HTML smuggling links and attachments. The timeline graphs below show a spike in HTML smuggling attempts in June and July.

Figure 9. HTML smuggling links detected and blocked

Figure 10. HTML smuggling attachments detected and blocked

Safe Links and Safe Attachments provide real-time protection against HTML smuggling and other email threats by utilizing a virtual environment to check links and attachments in email messages before they are delivered to recipients. Thousands of suspicious behavioral attributes are detected and analyzed in emails to determine a phishing attempt. For example, behavioral rules that check for the following have proven successful in detecting malware-smuggling HTML attachments:

• An attached ZIP file contains JavaScript
• An attachment is password-protected
• An HTML file contains a suspicious script code
• An HTML file decodes a Base64 code or obfuscates a JavaScript

Through automated and threat expert analyses, existing rules are modified, and new ones are added daily.

On endpoints, attack surface reduction rules block or audit activity associated with HTML smuggling. The following rules can help:

• Block JavaScript or VBScript from launching downloaded executable content
• Block execution of potentially obfuscated scripts
• Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Endpoint protection platform (EPP) and endpoint detection and response (EDR) capabilities detect malicious files, malicious behavior, and other related events before and after execution. Advanced hunting, meanwhile, lets defenders create custom detections to proactively find related threats.

Defenders can also apply the following mitigations to reduce the impact of threats that utilize HTML smuggling:

• Prevent JavaScript codes from executing automatically by changing file associations for .js and .jse files.
  • Create new Open With parameters in the Group Policy Management Console under User Configuration > Preferences > Control Panel Settings > Folder Options.
  • Create parameters for .jse and .js file extensions, associating them with notepad.exe or another text editor.
• Check Office 365 email filtering settings to ensure they block spoofed emails, spam, and emails with malware. Use Microsoft Defender for Office 365 for enhanced phishing protection and coverage against new threats and polymorphic variants. Configure Office 365 to recheck links on click and neutralize malicious messages that have already been delivered in response to newly acquired threat intelligence.
• Check the perimeter firewall and proxy to restrict servers from making arbitrary connections to the internet to browse or download files. Such restrictions help inhibit malware downloads and command and control (C2) activity.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites. Turn on network protection to block connections to malicious domains and IP addresses.
• Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Educate users about preventing malware infections. Encourage users to practice good credential hygiene—limit the use of accounts with local or domain admin privileges and turn on Microsoft Defender Firewall to prevent malware infection and stifle propagation.

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

Microsoft 365 Defender Threat Intelligence Team

The post HTML smuggling surges: Highly evasive loader technique increasingly used in banking malware, targeted attacks appeared first on Microsoft Security Blog.

The observed attack vector relies on a malicious ActiveX control that could be loaded by the browser rendering engine using a malicious Office document. Customers who enabled attack surface reduction rules to block Office from creating child processes are not impacted by the exploitation technique used in these attacks. While these attacks used a vulnerability to access entry point devices and run highly-privileged code, the secondary actions taken by the attackers still rely on stealing credentials and moving laterally to cause organization-wide impact. This illustrates the importance of investing in attack surface reduction, credential hygiene, and lateral movement mitigations. Customers are advised to apply the security patch for CVE-2021-40444 to fully mitigate this vulnerability.

This blog details our in-depth analysis of the attacks that used the CVE-2021-40444, provides detection details and investigation guidance for Microsoft 365 Defender customers, and lists mitigation steps for hardening networks against this and similar attacks. Our colleagues at RiskIQ conducted their own analysis and coordinated with Microsoft in publishing this research.

Exploit delivery mechanism

The initial campaigns in August 2021 likely originated from emails impersonating contracts and legal agreements, where the documents themselves were hosted on file-sharing sites. The exploit document used an external oleObject relationship to embed exploitative JavaScript within MIME HTML remotely hosted content that results in (1) the download of a CAB file containing a DLL bearing an INF file extension, (2) decompression of that CAB file, and (3) execution of a function within that DLL. The DLL retrieves remotely hosted shellcode (in this instance, a custom Cobalt Strike Beacon loader) and loads it into wabmig.exe (Microsoft address import tool.)

Figure 1. The original exploit vector: an externally targeted oleObject relationship definition bearing an MHTML handler prefix pointed at an HTML file hosted on infrastructure that has similar qualities to the Cobalt Strike Beacon infrastructure that the loader’s payload communicates with.

Content that is downloaded from an external source is tagged by the Windows operating system with a mark of the web, indicating it was downloaded from a potentially untrusted source. This invokes Protected Mode in Microsoft Office, requiring user interaction to disable it to run content such as macros. However, in this instance, when opened without a mark of the web present, the document’s payload executed immediately without user interaction – indicating the abuse of a vulnerability.

Figure 2. Attack chain of DEV-0413 campaign that used CVE-2021-40444

DEV-0413 observed exploiting CVE-2021-40444

As part of Microsoft’s ongoing commitment to tracking both nation state and cybercriminal threat actors, we refer to the unidentified threat actor as a “development group” and utilize a threat actor naming structure with a prefix of “DEV” to indicate an emerging threat group or unique activity during the tracking and investigation phases before MSTIC reaches high confidence about the origin or identity of the actor behind an operation. MSTIC tracks a large cluster of cybercriminal activity involving Cobalt Strike infrastructure under the name DEV-0365.

The infrastructure we associate with DEV-0365 has several overlaps in behavior and unique identifying characteristics of Cobalt Strike infrastructure that suggest it was created or managed by a distinct set of operators. However, the follow-on activity from this infrastructure indicates multiple threat actors or clusters associated with human-operated ransomware attacks (including the deployment of Conti ransomware). One explanation is that DEV-0365 is involved in a form of command- and-control infrastructure as a service for cybercriminals.

Additionally, some of the infrastructure that hosted the oleObjects utilized in the August 2021 attacks abusing CVE-2021-40444 were also involved in the delivery of BazaLoader and Trickbot payloads — activity that overlaps with a group Microsoft tracks as DEV-0193. DEV-0193 activities overlap with actions tracked by Mandiant as UNC1878.

Due to the uncertainty surrounding the nature of the shared qualities of DEV-0365 infrastructure and the significant variation in malicious activity, MSTIC clustered the initial email campaign exploitation identified as CVE-2021-40444 activity separately, under DEV-0413.

The DEV-0413 campaign that used CVE-2021-40444 has been smaller and more targeted than other malware campaigns we have identified leveraging DEV-0365 infrastructure. We observed the earliest exploitation attempt of this campaign on August 18. The social engineering lure used in the campaign, initially highlighted by Mandiant, aligned with the business operations of targeted organizations, suggesting a degree of purposeful targeting. The campaign purported to seek a developer for a mobile application, with multiple application development organizations being targeted. In most instances, file-sharing services were abused to deliver the CVE-2021-40444-laden lure.

It is worth highlighting that while monitoring the DEV-0413 campaign, Microsoft identified active DEV-0413 infrastructure hosting CVE-2021-40444 content wherein basic security principles had not been applied. DEV-0413 did not limit the browser agents able to access the server to their malware implant or known targets, thereby permitting directory listing for their web server. In doing so, the attackers exposed their exploit to anyone who might have gained interest based on public social media discussion.

Figure 3. Content of the original DEV-0413 email lure seeking application developers

At least one organization that was successfully compromised by DEV-0413 in their August campaign was previously compromised by a wave of similarly-themed malware that interacted with DEV-0365 infrastructure almost two months before the CVE-2021-40444 attack. It is currently not known whether the retargeting of this organization was intentional, but it reinforces the connection between DEV-0413 and DEV-0365 beyond sharing of infrastructure.

In a later wave of DEV-0413 activity on September 1, Microsoft identified a lure change from targeting application developers to a “small claims court” legal threat.

Figure 4. Example of the “Small claims court” lure utilized by DEV-0413 

Vulnerability usage timeline

On August 21, 2021, MSTIC observed a social media post by a Mandiant employee with experience tracking Cobalt Strike Beacon infrastructure. This post highlighted a Microsoft Word document (SHA-256: 3bddb2e1a85a9e06b9f9021ad301fdcde33e197225ae1676b8c6d0b416193ecf) that had been uploaded to VirusTotal on August 19, 2021. The post’s focus on this document was highlighting the custom Cobalt Strike Beacon loader and did not focus on the delivery mechanism.

MSTIC analyzed the sample and determined that an anomalous oleObject relationship in the document was targeted at an external malicious HTML resource with an MHTML handler and likely leading to abuse of an undisclosed vulnerability. MSTIC immediately engaged the Microsoft Security Response Center and work began on a mitigation and patch. During this process, MSTIC collaborated with the original finder at Mandiant to reduce the discussion of the issue publicly and avoid drawing threat actor attention to the issues until a patch was available. Mandiant partnered with MSTIC and did their own reverse engineering assessment and submitted their findings to MSRC.

On September 7, 2021, Microsoft released a security advisory for CVE-2021-40444 containing a partial workaround. As a routine in these instances, Microsoft was working to ensure that the detections described in the advisory would be in place and a patch would be available before public disclosure. During the same time, a third-party researcher reported a sample to Microsoft from the same campaign originally shared by Mandiant. This sample was publicly disclosed on September 8. We observed a rise in exploitation attempts within 24 hours.

Figure 5. Graphic showing original exploitation on August 18 and attempted exploitation increasing after public disclosure

Microsoft continues to monitor the situation and work to deconflict testing from actual exploitation. Since the public disclosure, Microsoft has observed multiple threat actors, including ransomware-as-a-service affiliates, adopting publicly disclosed proof-of-concept code into their toolkits. We will continue to provide updates as we learn more.

Mitigating the attacks

Microsoft has confirmed that the following attack surface reduction rule blocks activity associated with exploitation of CVE-2021-40444 at the time of publishing:

• ​Block all Office applications from creating child processes

Apply the following mitigations to reduce the impact of this threat and follow-on actions taken by attackers.

• Apply the security updates for CVE-2021-40444. Comprehensive updates addressing the vulnerabilities used in this campaign are available through the September 2021 security updates.
• Run the latest version of your operating systems and applications. Turn on automatic updates or deploy the latest security updates as soon as they become available.
• Use a supported platform, such as Windows 10, to take advantage of regular security updates.
• Turn on cloud-delivered protectionin Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block the majority of new and unknown variants.
• Turn on tamper protectionin Microsoft Defender for Endpoint, to prevent malicious changes to security settings.
• Run EDR in block modeso that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Enable investigation and remediationin full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Use device discoveryto increase your visibility into your network by finding unmanaged devices on your network and onboarding them to Microsoft Defender for Endpoint.

Microsoft 365 Defender detection details

Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• TrojanDownloader:O97M/Donoff.SA – Detects the Word Doc files in the observed attacks
• TrojanDownloader:HTML/Donoff.SA – Detects the remotely-loaded HTML
• Trojan:Win32/Agent.SA — Detects the .inf(Dll)/CAB components in the observed attacks
• Trojan:Win32/CplLoader.A – Blocks Rundll32/Control abuse used in this CVE exploitation
• Behavior:Win32/OfficeMhtInj.A – Detects the injection into wabmig.exe
• TrojanDownloader:O97M/Donoff.SA!CAB – Detects CAB files in observed attacks
• TrojanDownloader:O97M/Donoff.SA!Gen – Detects Office documents in observed attacks

Endpoint detection and response (EDR)

Alerts with the following titles in the security center can indicate threat activity on your network:

• Possible exploitation of CVE-2021-40444 (requires Defender Antivirus as the Active AV)

The following alerts might also indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Suspicious Behavior By Office Application (detects the anomalous process launches that happen in exploitation of this CVE, and other malicious behavior)
• Suspicious use of Control Panel item

Microsoft Defender for Office365

Microsoft Defender for Office 365 detects exploit documents delivered via email when detonation is enabled using the following detection names:

• Trojan_DOCX_OLEAnomaly_A
  • Description = “The sample is an Office document which contains a suspicious oleobject definition.”
• Trojan_DOCX_OLEAnomaly_AB
  • Description = “The sample is an Office document which exhibits malicious template injection qualities.”
• Exploit_Office_OleObject_A
  • Description = “This sample is an Office document which exhibits malicious qualities.”
• Exploit_Office_OleObject_B
  • Description = “This sample is an Office document which exhibits malicious qualities.”

The following alerts in your portal indicate that a malicious attachment has been blocked, although these alerts are also used for many different threats:

• Malware campaign detected and blocked
• Malware campaign detected after delivery
• Email messages containing malicious file removed after delivery

Advanced hunting

To locate possible exploitation activity, run the following queries.

Relative path traversal (requires Microsoft 365 Defender)

Use the following query to surface abuse of Control Panel objects (.cpl) via URL protocol handler path traversal as used in the original attack and public proof of concepts at time of publishing:

DeviceProcessEvents
| where (FileName in~('control.exe','rundll32.exe') and ProcessCommandLine has '.cpl:')
or ProcessCommandLine matches regex @'\"\.[a-zA-Z]{2,4}:\.\.\/\.\.'

Azure Sentinel 

To locate possible attacks that exploit the CVE-2021-40444 , Azure Sentinel customers can leverage the following detection query: Azure Sentinel MSHTML exploit detection.

The post Analyzing attacks that exploit the CVE-2021-40444 MSHTML vulnerability appeared first on Microsoft Security Blog.

Microsoft Defender Antivirus is using this integration to detect and block XLM-based malware, and we encourage other antivirus products to use this open interface to gain better visibility and improve protections against these threats.

XLM macros is a legacy macro language that was made available to Microsoft Excel in 1992, prior to the introduction of Visual Basic for Applications (VBA) in 1993. While more rudimentary than VBA, XLM is powerful enough to provide interoperability with the operating system, and many organizations and users continue to use its functionality for legitimate purposes. Cybercriminals know this, and they have been abusing XLM macros, increasingly more frequently, to call Win32 APIs and run shell commands.

The AMSI instrumentation for VBA has been providing deep visibility into the runtime behavior of VBA macros. Its release in 2018 effectively removed the armor that macro-obfuscation equipped malware with, exposing malicious code to improved levels of scrutiny. Naturally, threat actors like those behind Trickbot, Zloader, and Ursnif have looked elsewhere for features to abuse and operate under the radar of security solutions, and they found a suitable alternative in XLM.

Like VBA and many other scripting languages abused by malware, XLM code can be obfuscated relatively easily to conceal the real intent of the macro. For example, attackers can hide URLs or file names of executable files from static inspection through simple strings manipulations. Attackers also take advantage of the way macro code persists within the Excel document—while VBA macros are stored in a dedicated OLE stream (and hence can be easily located and extracted), XLM macros do not exist as a separate, well-defined entity. Rather, each XLM macro statement is a formula within a cell. Extracting a whole XLM macro can become a cumbersome task, requiring a cell-by-cell inspection of the whole document.

Figure 1. Sample malicious XLM macro

In addition, while formulas are typically executed downwards starting from the top, with XLM the macro content can be quite spread out, thanks to control flow statements like RUN, CALL, or GOTO, which allow the switching of execution flow from one column to another. This feature, together with obfuscation, has been abused by attackers to craft documents that could evade static analysis.

AMSI instrumentation for Excel 4.0 (XLM) macros

AMSI is an open interface that allows any application to request the scanning of any data at any time. In a nutshell, this technology provides applications the capability to interface with the installed antivirus solution in order to inspect and scan potentially dangerous data (e.g., a file downloaded from a remote location, or data generated dynamically by an application). Microsoft already utilizes this technology in various applications to detect malicious macros, script-based malware, and other threats:

• Office VBA macros
• JScript
• VBScript
• PowerShell
• WMI
• Dynamically loaded .NET assemblies
• MSHTA/Jscript9

The data provided by AMSI is leveraged extensively by Microsoft Defender for Endpoint. It provides important data for machine learning models that process billions of signals every day to identify and block malicious behaviors. The XLM instrumentation is similar to the implementation in VBA and other scripting engines that integrate with AMSI:

Figure 2. AMSI instrumentation for XLM

The XLM language allows a user to write programs that call native runtime functions, as well as external Win32 APIs. In both cases, the interfaces that dispatch the calls to these functions are intercepted and directed to an internal logger. The logger component stores the intercepted functions in text format within a circular buffer. When certain dangerous functions are called, for example the runtime function EXEC or the Win32 API ShellExecute, XLM halts the macro execution and invokes AMSI to request a synchronous scan of the circular buffer containing the functions logged up to that point. Such dangerous functions are called “trigger functions”. If the antivirus identifies the macro as malware, the execution of the macro is aborted and Excel is safely terminated, blocking the attack and preventing the malicious macro from doing any damage. Otherwise, the user experience continues seamlessly.

It’s important to observe that the interception of XLM function calls happens at runtime. This means that the logger component always registers the true behavior of all functions and associated parameters, which may contain URLs, file names, and other important IOCs, regardless of the obfuscation used by the malware.

The following is an example of an XLM macro found in a malicious document:

Figure 3. Sample XLM macro

This malicious macro consists of a series of commands (e.g., RUN, REGISTER, IF, etc.) with related parameters specified by references to other cells. For example, the token $CA$1889 passed to the first function RUN indicates that the string provided as parameter for this function is in the cell at column CA and row 1889.

This is only one of the many ways that XLM-based malware can obfuscate code. Detecting this macro is challenging because it doesn’t expose any suspicious strings or behavior. This is where the power of AMSI comes into play: the instrumentation allows XLM to inspect functions when they are invoked, so that all their parameters have already been de-obfuscated. As a result, the above macro produces a log that looks like the following:

Figure 4. Sample log

The XLM engine determines that the dangerous function ShellExecuteA is being invoked, and subsequently places the macro execution on hold and passes the macro behavioral log to AMSI for scanning. The antivirus now has visibility into a behavioral log that completely exposes all of the data including, API names, URLs, and file names. The log makes it easy to conclude that this macro is trying to download and execute a DLL payload via the tool Rundll32.

Case study: ZLoader campaign

ZLoader is a malware family that has been actively perpetrating financial theft for several years. Like many of its peers, ZLoader operates via aggressive campaigns that rely on social engineering and the abuse of Office documents spread via email.

We have been monitoring the activity of this threat and observed that in the last year the attackers shifted to XLM as their infection vector of choice. The Excel documents have a typical lure message to trick the user into clicking “Enable Content” to allow the macro code to run.

Figure 5. Malicious Excel file used in Zloader campaign

A closer look at the document reveals an Excel sheet with an obscure-looking name. That sheet embeds XLM macro formulas, which are stored several rows down to make the sheet look empty. Furthermore, the macro formulas are spread out and obfuscated, hindering static analysis and raising more challenges for identifying intent.

Figure 6. Malicious XLM macro used in ZLoader campaign

Executing and debugging the macro with Excel is not very straightforward either. The macro has long loops that are used to decode and run further obfuscated macro formulas, and the Excel’s debugger doesn’t have the ability to control the execution in a granular way in order to skip loops and break on specific formulas.

However, when this macro runs with the AMSI instrumentation enabled, it produces up to three different logs that are passed to AMSI. The first two look like the following:

Figure 7. Log produced when ZLoader’s XLM macro is run

The image only shows the final part of the log where the interesting activity shows up. We can see that the macro is issuing a new EXEC statement to run a .vbs file via explorer.exe. This EXEC statement causes the execution of the VBScript named EW2H.vbs, which has been decoded and saved to disk by the macro prior to the EXEC line. The VBScript then tries to download and run a binary payload. The macro attempts to do this twice, hence this log (with minor variations) is passed to AMSI twice.

If the above steps fail, the macro resorts to downloading the payload directly, producing the following log for AMSI:

Figure 8. Log produced when ZLoader’s XLM macro is run

The macro defines two URLs, then downloads their content with the API URLDownloadToFileA, and finally invokes the API ShellExecuteA to launch the downloaded payload (the file jxi09.txt) via rundll32.exe. We can infer from this line that the payload is a DLL.

All three logs offer plenty of opportunities to detect malicious behavior and also allow the easy extraction of relevant IOCs like URLs, file names, etc. The initial XLM code in the Excel document is completely obfuscated and contains no usable information, making it tricky to issue static detections that are both effective and durable. With the dynamic nature of AMSI, the runtime behavior can be observed in cleartext, even with obfuscation. Detections based on the logs passed to AMSI also have the advantage of being more robust and generic in nature.

Availability

Runtime inspection of XLM macros is now available in Microsoft Excel and can be used by antivirus solutions like Microsoft Defender Antivirus that are registered as an AMSI provider on the device. This feature is included as an addition to the existing AMSI integration with Office. It’s enabled by default on the February Current Channel and Monthly Enterprise Channel for Microsoft 365 subscription users.

In its default configuration, XLM macros are scanned at runtime via AMSI, except in the following scenarios:

• Files opened while macro security settings are set to “Enable all macros”
• Files opened from a trusted location
• Files that are trusted documents

Administrators can now use the existing Microsoft 365 applications policy control to configure when both XLM and VBA macros are scanned at runtime via AMSI. Get the latest group policy template files.

AMSI improves security for all

AMSI provides deep and dynamic visibility into the runtime behaviors of macros and other scripts to expose threats that hide malicious intent behind obfuscation, junk control flow statements, and many other tricks. Microsoft Defender Antivirus, the built-in antivirus solution on Windows 10, has been leveraging AMSI to uncover a wide range of threats, from common malware to sophisticated attacks. The recent AMSI instrumentation in XLM directly tackles the rise of malware campaigns that abuse this feature. Because AMSI is an open interface, other antivirus solutions can leverage the same visibility to improve protections against threats. Security vendors can learn how to leverage AMSI in their antivirus products here.

At Microsoft, we take full advantage of signals from AMSI. The data generated by AMSI is not only useful for immediate client antimalware detections, but also provides rich signals for Microsoft Defender for Endpoint. In our blog post about AMSI for VBA, we described how these signals are ingested by multiple layers of cloud-based machine learning classifiers and are combined with all other signals. The result is an enhanced protection layer that learns to recognize and block new and unknown threats in real-time.

Figure 9. Example of detection from Microsoft Defender Antivirus based on data inspected by AMSI

Figure 10: Notification from Microsoft Excel after AMSI reported malware detection

Figure 11: Example of Microsoft Defender for Endpoint alert for detection of XLM malware

The visibility provided by AMSI leads to significant improvements in generic and resilient signatures that can stop waves of obfuscated and mutated variants of threats. AMSI-driven protection adds to an extensive multi-layer protection stack in Microsoft Defender for Endpoint, which also includes attack surface reduction, network protection, behavior monitoring and other technologies that protect against macro malware and other similar script-based threats.

The AMSI-enriched visibility provided by Microsoft Defender for Endpoint is further amplified across Microsoft 365 Defender, such that XLM macro threats are detected and blocked on various entry vectors. The orchestration of signal-sharing and coordinated defense in Microsoft 365 ensures that, for example, Microsoft Defender for Office 365 blocks macro malware distributed via email, which is the most common delivery methods for these threats.

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

Giulia Biagini, Office 365 Threat Research Team

Auston Wallace, Microsoft 365 Security Team

Andrea Lelli, Microsoft 365 Defender Research Team

The post XLM + AMSI: New runtime defense against Excel 4.0 macro malware appeared first on Microsoft Security Blog.

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.

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.

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

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.

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.php, yymclv.php, zpsxxla.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.

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:

• Block executable content from email client and webmail
• Block all Office applications from creating child processes
• Block Office applications from creating executable content
• Block Office applications from injecting code into other processes
• Block Win32 API calls from Office macros
• Block executable files from running unless they meet a prevalence, age, or trusted list criterion
• Block Javascript or VBScript from launching downloaded executable content
• Block execution of potentially obfuscated scripts

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 StrangeU email 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.

Additional resources

• Listen to Episode 19 of the Security Unlocked podcast, where threat analyst Elif Kaya speaks about this email infrastructure
• Watch this Microsoft 365 Defender webinar about this research:

Indicators of compromise

StrangeU domains

RandomU domains

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

VBS and HVCI-enabled devices help protect from advanced attacks

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

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

Surface enables added security features by default to combat common threats

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

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

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

The simple choice for device security

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

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

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

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

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

Natalia: Looking back at the threat landscape of 2020, what stands out?  

Jake: The biggest thing that stands out has to be the continued ransomware advances. With IANS, I actually coined the term ransomware 2.0 in early 2019. We were trying to differentiate between the drive-by ransomware attacks and what I call the more APT-style ransomware attacks, where they’re doing lateral movement and actively targeting backups before encryption. Disaster recovery (DR) plans work for the former but really not the latter because the latter cases are actively targeting disaster recovery infrastructure. What I saw this year was just a lot of advancement in attacks.

The second thing is that the number of different groups that are using that commodity malware has definitely gone up. They’re using that commodity malware to get back into orbit for initial access into a network. We’re seeing a lot more of that, like TrickBot. Cybersecurity professionals I’m talking to say, “the TrickBot takedown” but it was an interruption, not a takedown, unlike other malware and botnets in the past that have been wiped out. DNSChanger is a good example. DNSChanger was cut off at the knees but not TrickBot. This is a flesh wound.

We’re seeing a lot more of this commodity malware being used as an entryway. This is the stuff that a lot of folks, myself included, have been talking about for years. This is always a risk. You can’t just say, “Don’t worry, Microsoft Defender Antivirus caught and quarantined it so we’re good now.” From maybe mid-September on, it’s been even more viral than the rest of the year put together. It’s really accelerating, too.

Natalia: What critical threat groups should security teams be actively monitoring? 

Jake: The week before last, I was in a dark web forum and an account that I and a number of other folks in the intel community assess with moderate confidence to be associated with Ryuk was advertising for help with their ransomware operations. They’re looking for experienced ransomware operators, and they have a whole set of criteria, including that they want to see a history that you’re getting an average $400,000 payout. They haven’t asked for help in the past. They have more work than they can handle. That gives you an idea of scope, and I think it comes from the commodity malware. Before now, I haven’t seen large, established ransomware groups advertising for help with their operations. If they thought those accesses were going to last forever, they wouldn’t worry about recruiting others right now.

There’s definitely a place for dark web monitoring but most organizations don’t have the maturity level where they’re getting a good return on that investment. Because even if I tell you that cybercrime groups are recruiting, how do I take that and turn that into something actionable that will help with detection and prevention? I don’t know how much any guidance I provide will help if you’re not patching domain controllers.

From a cybercrime standpoint, we’re seeing a lot more lateral movement being critical to cybercriminals’ attacks. We’re not seeing as many point attacks where they land a phishing email and bam, they’ve extracted a bunch of data and gone. It sounds almost like a cop-out but focus on lateral movement because it kills two birds with one stone. Nation-state groups have to do a lateral movement. So do cybercrime groups to get maximum payouts. Once they’ve had a bite of that big apple, how do they ever go back? I think you’re seeing more groups spending in some cases up to six weeks in a network before they’re doing data extraction and playing a little bit of a longer game versus that immediate gratification.

Natalia: Cybersecurity mixes both defensive and offensive practices to combat cybercrime. How should organizations think about red and blue teaming in their organization? Do organizations need both, and why?  

Jake: A huge majority of people who get into cybersecurity these days want to be red team. I get it. It’s sexy. Bottom line, if you’re thinking of red team as those folks who are actually attempting to penetrate your internal network, I think the number is 1 to 20, 1 to 25, or something like that compared to blue team. You need a lot less red team focus. I’m not saying that organizations where red team is similarly sized to blue don’t provide value. They definitely do, but it’s a question of could you take those same resources and plug them elsewhere and get more value? I think generally, I need a lot more defense than I need offense.

In way too many organizations that have much more balanced red and blue teams, I see a lot of red teams identifying problems that the blue team simply can’t fix from a resourcing standpoint. I also am working with organizations that have very large red teams but haven’t yet moved into hunt teaming. In those situations, I don’t know whether you put hunt under red or blue. I’m ambivalent there but the bottom line is I do need the red team, but I need them for a lot less than a lot of people use them for. I say that as an ex-government hacker; and I still do red team occasionally, but it’s just not where most organizations are going to get the most significant return on investment. I’m not trying to say red team isn’t important but generally, we need to structure significantly more blue team people than red team, and that’s just an unpopular thing for a lot of people to hear.

If you don’t have a solid blue team and have holes today in your defenses, you shouldn’t have a red team. When people say, “We need our own internal red team,” my question is, “Have you had an external red team come in and do a red team evaluation? And if you have, have you actioned those findings?” Not one of them but all of them. If the answer is no, we need to step back and figure out what we need to do. Let’s make sure that you’ve got a blue team that is functioning today and ready to roll forward with the recommendations from the red team. Separate from pragmatism, there’s also a legality issue. Knowing about something and not doing anything about it puts you in a more legally compromising position than not knowing about it at all.

That’s what we find a lot of folks with internal red teams end up with. They’ve got this red team that is basically pushing identified risks into a funnel. How much are we stuffing that funnel? How much do we need defense versus offense?

Natalia: How does an organization know when to hire an internal red team? What’s the breaking point?

Jake: A lot of that depends on the reaction. How quickly are you actioning those findings? If you’re in a spot where you fix all the findings from the annual red team in two months, that’s when I would say, “Yes, without a shadow of a doubt, let’s go hire a red team.” Because that’s going to give me more of that constant churn of findings. On the other hand, if it takes you nine months to get through those findings, you’re going to have another external red team likely in a month anyway. Where’s our value there? If it takes you somewhere in the middle, a lot of it is going to depend on how much risk do we accept.

When we’re documenting where we have gaps and where we don’t, it comes down to where can I get the best return on my investment for our organization? If I still have a lot of blue team gaps, investing in red team would be throwing more gaps at blue team, which causes huge morale issues.

Read the second part of the interview as Jake Williams shares best practices on how to structure and evolve red and blue teaming within your organization.

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 or on LinkedIn for the latest news and updates on cybersecurity.

The post The dynamic duo: How to build a red and blue team to strengthen your cybersecurity, Part 1 appeared first on Microsoft Security Blog.