Extended detection and response (XDR) is a security solution that delivers end-to-end visibility, detection, investigation and response across multiple security layers. Core components of an XDR architecture include federation of security signals, higher-level behavioral and cross-correlated analytics, and closed-loop and highly automated responses. This creates a truly unified experience supported by a solutions architecture that equals more than the sum of its parts. Security teams are able to get more value from an XDR that meets the following criteria:
Supports open standards
Delivers advanced analytics
Provides a simpler, unified analyst experience
Streamlines operations
Enhances response through automation
An XDR solution can achieve improved visibility across an organization’s networks, endpoints, SIEM and more via open-system integration. Open source standards can help move the industry away from expensive and wasteful ‘rip and replace’ programs. Instead, an open approach helps organizations get more out of their existing investments.
An XDR solution can also offer more automation and AI enrichments at all levels of detection, analytics, investigation and response. Automation throughout the threat life cycle can dramatically reduce mean time to detect (MTTD) and mean time to recovery (MTTR). Not only does reducing these metrics have a direct relationship to mitigating the cost of a data breach, it also frees up time for analysts to do more human-led activities like investigation. An XDR solution also bolsters investigation with a unified view of threat activity, a single search and investigation experience and consistent enrichment with threat intelligence and domain expertise.
Is XDR Just Another Acronym or a Fundamental Market Shift?
For many decades now, emerging threats have put organizations at risk. As the IT landscape evolved and threat actors found new ways to attack, security teams needed to find new ways to detect and respond to threats.
Today, this evolving theme of complexity continues. And the list of point solutions being deployed to overcome these burgeoning threats goes on and on — from SIEM, to cloud workload protection, to endpoint detection and response (EDR), to network detection and response (NDR) and more. While these investments each do their part to solve immediate and dire issues, in combination they’ve created a bigger challenge: how to use and get value from them together.
This is why we call them point tools; they were made to address specific challenges. Now that security teams face a myriad of challenges, it’s never been more critical to have them work in concert. Without doing so, limited security operations resources will continue to be spread thin, total cost of ownership will continue to increase and the process of pinpointing and responding to threats will continue to be time-consuming and inefficient.
Extended detection and response (XDR) is the beginning of a shift towards uniting multiple siloed solutions and reducing the complexity that impedes fast detection and response. As stated in the blog Gartner Top 9 Security and Risk Trends for 2020: “The primary goals of an XDR solution are to increase detection accuracy and improve security operations efficiency and productivity.” Gartner identified XDR as the number one security and risk trend at the end of 2020, suggesting now is the moment when all this complexity — too many tools, too many alerts, too little time — is coming to a head, with XDR as a response.
What Are The Different Approaches to XDR?
Industry analysts have outlined two different approaches to extended detection and response: native and hybrid. Native XDR is a suite that integrates with a vendor’s other solutions to collect telemetry and execute response actions. Hybrid or open XDR is a platform that integrates with various vendors and third parties to collect telemetry and execute response actions.
Vendors have been taking different approaches to what is under the hood of XDR, so to speak. For instance, does XDR = EDR plus additional capabilities? Or is it EDR plus NDR, or some other combination? It might be too soon to tell where the market will land as the technology is nascent, but the delineation between native and hybrid XDR is one thing the industry seems to agree on.
How Does XDR ‘Extend’ SIEM?
For some readers, SIEM may have immediately come to mind as you perused the qualities of XDR. There are some key differences between the two. Correlation and alerting tend to be fully automated, employing use cases that are provided and tuned by the vendor. Lastly, incident response tends to focus on highly repeatable actions that can be automated, such as sending a suspicious file to a sandbox for detonation, enriching an alert with threat intelligence or blocking an email sender tied to phishing emails. This approach differs from SOAR, which can be broadly customized with custom playbooks and used to unite people in addition to technology.
XDR in many ways can extend the detection and response capabilities that are today enabled by SIEM. In fact, SIEM can play an integral role to support an XDR architecture in gathering, organizing and assessing massive amounts of data for SOC analysts. In this capacity, XDR builds on the data and events flowing through your SIEM solution. By bringing together the capabilities of multiple point solutions, XDR can take SIEM analytics one step further and amplify the outcome. As an example, when you receive analytics from a SIEM, endpoints and networks separately, it can be like having three different witnesses to an attack. XDR helps you immediately bring all three witnesses together and create one complete story — helping an analyst see more clearly across multiple sources.
XDR is not just a place where you consolidate security signals but a place where you can run more advanced, correlated analytics. As The Forrester Wave for Security Analytics Platforms, Q4 2020 asserts, security analytics and endpoint detection and response have been on a “collision course” for some time. Bringing together these capabilities with XDR can provide “highly enriched telemetry, speedy investigations, and automated response actions.” Behavioral analytics or machine learning analytics can also enrich content, increase accuracy and lead to automated response actions.
How Does XDR Compare to MDR?
Even though XDR vendors are striving to untangle the complexity problem, it will take time to make inroads. Compounding this challenge is the skills shortage. The dire need for talent to run security analysis and investigations leads many organizations to utilize a partner for managed detection and response (MDR) services.
MDR is an approach to managing sophisticated detection and response tools — whether via endpoint, network or SIEM technology. Some MDR providers include proactive threat hunting to reveal undetected threats faster. Research from EMA conducted in 2020 found that 94% of respondents not already using an MDR service were currently evaluating or had plans to evaluate MDR services over the next 18 months.
MDR services can provide critical skills and advanced threat intelligence, plus rapid response with 24/7 SOC coverage. As Jon Oltsik, senior principal analyst at ESG, stated, “XDR success still seems to be based on human expertise,” making MDR an invaluable companion to XDR for customers who could use a helping hand.
How Does XDR Support Customers With Zero Trust Aspirations?
If you set up a game of security buzzword bingo, there’s no doubt you’d come across both zero trust and XDR. There’s industry chatter around these powerful security frameworks with good reason — one concept can help enforce the other.
Zero trust is a framework that starts with an assumption of compromise, then continuously validates the conditions for connection between users’ data and resources to determine authorization and need. XDR provides an essential function to zero trust by continuously monitoring for incidents and responding in the most targeted way possible to avoid disruption to the business.
How so? XDR enables analysts to determine if their organization is under attack and figure out as quickly as possible what’s happening, what will happen next and how to prevent that from unfolding. Instead of placing blind trust in a system and saying the controls are enough, with XDR you constantly monitor the places where things could go wrong.
In this way, XDR is ensuring that zero trust security controls are working. The ‘never trust, always verify’ zero trust methodology is supported by verification. When it comes to detecting and responding to threats, as well as improving protection policies based on insights, a zero trust framework and an XDR solution can work hand in hand. And it’s exactly why identity tools, such as identity and access management (IAM), will play a critical role tying into XDR solution architectures to ensure the appropriate user-centric context is being employed for threat detection and response.
What Should Customers Look for in an XDR Solution?
Your XDR should be an open, extensible solution that enables your organization to get more from its existing investments. Look for integrations with third parties that will save your organization from a costly and unrealistic rip-and-replace approach. Cloud-native solutions are also critical for extending cloud visibility.
XDR goes far beyond being an improved EDR solution; it should instead be your end game for threat detection and response activities — as part of a unified platform. Reaching that level of maturity is a goal that takes time, with the basics in place and a clear strategy as prerequisites for how to get started with XDR. With powerful automation, artificial intelligence and expert-built detection and prescribed response actions available through a unified user experience, security teams can counter attacks across silos — mitigating risk and resolving threats fast.
Ultimately, XDR makes it easier for the people managing and responding to threats on a daily basis to do the work. Open standards mean we can better serve customers and the community, preventing time and dollars lost to ripping and replacing technology. Advanced analytics, constantly updated threat intelligence and a streamlined user workforce empower analysts to be more efficient and spend their valuable time on investigations — not gathering the data.
People and culture are the keys to the SOC. By uniting threat detection data and tools and strengthening ability and context for fast incident response, XDR enables the collaboration and openness that helps teams thrive.
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.
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:
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.
Figure 1. How the RaaS affiliate model enables ransomware attacks
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.
Figure 2. Human-operated ransomware targeting and rate of success, based on a sampling of Microsoft data over six months between 2021 and 2022
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:
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.
Figure 3. Ransomware payloads distributed by DEV-0504 between 2020 and June 2022
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.
Figure 4. Ransomware payloads distributed by DEV-0237 between 2020 and June 2022
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.
Figure 5. Examples of DEV-0237’s relationships with other cybercriminal activity groups
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.
Figure 6. The handover from DEV-0206 to DEV-0243
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.
Figure 7. Ransomware payloads distributed by DEV-0401 between 2021 and April 2022
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:
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.
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.
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.
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:
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:
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.
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 recent Kaseya ransomware attack is yet another reminder of the voracity of the war cybercriminals are waging on the business world. In 2020, scan-and-exploit became the top initial attack vector for surveyed organizations, surpassing phishing, according to the 2021 IBM X-Force Threat Intelligence Index. The report noted manufacturing as the second-most attacked industry in 2020 for respondents. This is an increase from eighth place the year prior, and second only to financial services.
What’s behind these attacks?
Companies have invested a great deal in building castle-and-moat protections against external threats, focusing on protecting the DMZ or perimeter zone. In a world of known threats and less sophisticated techniques, this protection model worked reasonably well. But times have changed.
Cybercriminals can be well resourced and tenacious and even backed by nation-states. They can leverage evermore sophisticated tools, such as Ransomware-as-a-Service. These tools can be incentivized by cryptocurrencies with their strong liquidity and poor traceability. As a result, they are well positioned in the arms race against traditional perimeter defenses. Clearly, it is time to consider a zero trust approach to help protect your most valuable resource—your data.
The problem with the castle-and-moat model is the primary focus on external defenses. Once inside, cybercriminals can generally move freely around without much impediment and wreak havoc. This has led to a broadening of the security perspective to encompass internal security, with what is termed the zero trust model.
The Biden administration in the United States, recently issued an Executive Order calling for advancement towards a zero trust model within the federal government and among federal contractors. Subsequently, in response to multiple high-profile ransomware attacks, the White House also issued a memo to business executives urging them to protect against the threat of the ransomware. Such a model is an “evolving set” of concepts that move beyond “defenses from static, network-based perimeters” according to the National Institute of Standard and Technology (NIST).
What happens when a cybercriminal or organization has breached a perimeter and has access to your secure environment? Typically, they will start a stealth scan to build a map of your network. They enumerate the server they are on for all its credentials and then try those credentials on your other servers to travel laterally. Most breaches move from computer to computer over standard protocols such as SSH, FTP, SFTP, HTTP, and HTTPS. This means you need to have a strategy for restricting the spread or movement within your organization.
Zero Trust Protects File Transfers
At IBM, our Sterling Secure File Transfer (SFT) solution is designed to align with a zero trust approach and harden servers to help reduce the possibility for ransomware or malware to travel laterally. The aim is to protect the inside of the castle – or inside the DMZ. Ultimately safeguarding internal intellectual property and assets. A zero trust approach requires securing and regulating movement between internal computers and servers and we begin by removing untrusted protocols.
Our SFT solution is designed to include IBM Sterling Connect:Direct which uses a security-hardened protocol. When malware reaches out internally, it will not know how to ‘talk’ to the protocol. It can also check the IP address from the server that has requested access. If that IP address is not on the internal list of trusted servers, which can be consistently updated, the receiving server automatically drops the session.
Connect:Direct can have additional checkpoints to further help prevent the spread of malware to another server. The malware also needs the correct credentials, which can be increased for additional protection of high-value servers. Also, only files with a specified name may be transferred.
Each server that uses Connect:Direct becomes a checkpoint – and choke point – for malware. This zero trust approach in Connect:Direct hardens infrastructure. It includes capabilities for zero trust practices for communications that can help mitigate risks of traditional protocols using FTP, SFTP and SSH. SFT can also encrypt data at rest. In transit, it provides multifactor authentication helping implement a zero trust strategy for your file transfers.
Do you have a traditional castle-and-moat security model? I urge you to consider implementing or expanding your zero trust strategy. It will help protect what is most valuable inside of your organization. You can start small and add more protections over time. The key is to begin now because the war will continue to escalate.
It’s Cybersecurity Awareness Month. So, let’s discuss a topic that has been around for a decade, but is recently gaining significant traction in business circles: zero trust. The concept of zero trust has been around since John Kindervag coined the term in 2010. Google’s internal implementation through it’s BeyondCorp team in 2011 was one of the first examples. The objective of the group was simply to allow “employees to work more securely from virtually any location.” It’s a very progressive idea given the first Android phone was launched only three years earlier. Businesses exploring zero trust have begun to implement it to help manage the flow of corporate data to mobile devices.
Today, mobile working is commonplace. Recent research by Deloitte found that 40 percent of workers use a mobile device as part of their job. The zero trust model is important for businesses that are undergoing digital transformation to enable productive mobile workflows.
Simply put, zero trust means no implied accreditation, always ensure security and only provide visibility into what you need to. Access should only be granted on a case-by-case basis per app; everything else should remain hidden. A successful, scalable and secure mobile-enabled business strategy should incorporate zero trust.
The Advent of Modern Productivity
It is no secret that businesses have embraced mobile workflows for productivity gains. These companies have embarked on continuous digital transformation to capture this latent potential within their organization. The three pillars of this productivity shift are the concepts of enablement, identity and zero trust.
Unified endpoint management (UEM) enables employees to easily use mobile devices to work wherever they are. This creates new, more productive workflows. Businesses use UEM today to push apps, password policies and email settings seamlessly to thousands of devices. It gives administrators an invisible pair of hands to remotely configure and manage the devices and apps that employees use. The ability to manage Windows 10 devices as well as mobiles has allowed companies to consolidate the configuration tools they use, leading to a rise in UEM deployments.
Identity and access management (IAM) helps by simplifying access. Users only need to remember one password. If the identity of the end user accessing data is known, single sign-on (SSO) can be provided. With the number of business apps ballooning, employees must remember an ever-increasing number of credentials and businesses need better ways to manage access. IAM removes the requirement to remember multiple login details and continuously authenticate. The technology can also act as a security tool. It provides a layer for multifactor authentication (MFA) and a single link that IT teams can limit if a breach is detected.
UEM and IAM provide some of the tools IT teams need to control how company data is managed, but both suffer from the critical flaw of implied trust. It is implied that the connection is secure and private, that the device is uncompromised by malware, and that other apps on the device are not leaking information. Mobile threat defense (MTD) acts as a third pillar to create a zero trust posture that truly enables mobile productivity.
Managing a Blurred Boundary
Although many of the opportunities for mobile digital transformation were driven by UEM and IAM, they left a gap in security posture. Businesses knew who was accessing data and through what device, but not whether the device, applications or network were secure. Organizations also struggled to discover whether a compromise had even occurred; Verizon found that 63 percent of business-related breaches were reported by third parties.
MTD can provide the insights businesses need to make informed decisions about when their data is accessed. Continuous conditional access (CCA), a method of consistently evaluating security to determine risky activity immediately, allows businesses to control how and where their data is being accessed in real time. Best-in-class MTD products are capable of providing conditional access by monitoring device, app and network threats to ensure that data being sent to a device remains secure.
Building Zero Trust With UEM, IAM and MTD
Bringing UEM, IAM and MTD services together can enable employees to use their mobile devices to securely access corporate resources. Integrating these three technologies and aligning the policies between them can also create a seamless, unified security stance. An MTD partner that can integrate with your existing services is crucial to building a strong security posture.
The CCA scanning, provided in real time by a strong MTD solution, is the glue that binds the zero trust model for secure productivity. CCA allows for dynamic risk assessment: If a device’s risk profile becomes too high at any point, preventative action can be taken. Leading MTD solutions use threat intelligence engines to monitor a number of vectors, including known and zero-day threats.
Integration with other technologies is extremely powerful once risk levels have been exceeded. After the MTD tool categorizes the risk, it can then communicate with the UEM solution to trigger a seamless, automatic response. Integration with other services such as security information and event management (SIEM) can help improve the IT team’s level of response and visibility when a risk occurs.
In the real world, the scenario may be as simple as an employee downloading an entertainment app for their commute to work. If the entertainment app contains a vulnerability, MTD is designed to detect that corporate information accessed on the device is at risk. Combining the insights gained from UEM, IAM and MTD in a single policy engine helps security and business leaders make richer, more contextual access decisions.
For example, when an MTD solution recognizes a risk, it can work with UEM to prevent access to company services from the device. Informing the employee why action has taken place gives them options to choose how to work. If the IAM system believes the user’s credentials are not compromised, the employee could continue to work from a secondary device. Or, if the main device’s risk profile can be lowered, it could become a work tool again. A single policy engine powered by the three tools can dynamically enable productivity and protection.
How Can Businesses Move to the Zero Trust Model?
The reality is that zero trust isn’t just a single product or service, and there is no industry-standard architecture. As new ways of working develop, IT teams will need to hold BeyondCorp’s mantra close to heart and allow “employees to work more securely from virtually any location.”
Using and linking UEM, IAM and MTD together can create a unified, comprehensive security policy businesses undergoing digital transformation can use today. This will help ensure that enterprise data is securely accessed by only the right users, applications and devices.
As a security architect within IBM Security Services, I often get asked the question, “What exactly is a Zero Trust architecture?” Well, there is no single or unique answer to that question for two reasons.
First, Zero Trust is not an architectural model but rather a set of guiding principles that should be applied to existing and new designs. With that said, these principles present a number of architectural patterns or use cases that can serve as a starting point for implementation.
Second, the implementation of Zero Trust principles results in very different technical solutions and approaches for different uses cases. For example, applying the same Zero Trust principles for an employee remote access use case would be addressed in a very different way than handling micro-services connectivity in a service mesh running on containers.
So, where does one even start and how would Zero Trust change the way security solutions are designed? To answer these questions, I propose starting at the right architectural entry point: enterprise security architecture (ESA). In this article, I’ll briefly describe how the principles of Zero Trust could be introduced at your organization through the different architectural governance levels and against ESA.
Looking at Zero Trust Architecture Through an ESA Lens
To establish an IT security governance model, most organizations define an ESA as part of a wider enterprise architecture program. In an ESA, all aspects of IT security are defined through the different stages of design. You’ll typically find the following stages: the contextual or business layer, the conceptual layer, the logical layer and the physical layer. Below I provide a summarized overview of the concepts.
Source: IBM Security
In addition, an ESA should address the governance of how the solutions and artifacts are maintained at the different layers like what is shown above. Security operations will need to manage the day-to-day operational risks while architecture review cycles ensure that the solution’s building blocks are identified and up to date. I’ll come back to this last topic later.
Also, the security controls of an ESA should be designed, implemented and managed at the enterprise level. A security control is typically a solution that combines your people, processes and technology. From a high-level perspective, both the actions required to mitigate identified IT risks and the actions required to ensure regulatory compliance are translated into a set of security policies that are then enforced and implemented through an extended collection of security controls. An ESA helps to define the approach of how to achieve that goal in line with business requirements.
Combining Security Architecture With a Zero Trust Governance Model
If we start applying the Zero Trust principles to security architecture, it is clear that the contextual level does not change. The regulations, risks and business drivers are not changing, but the way an organization would address these requirements might change. Therefore, implementing Zero Trust principles will start at the conceptual layer of your architecture. IBM Security’s four-tenet Zero Trust governance model could be leveraged to structure the approach (see figure below).
Source: IBM Security
1. Define Context
Defining context is key for Zero Trust across all security domains. Here, the foundation for your Zero Trust implementation road map has to be defined. New security policies will have to be defined and existing policies might require adaptation. The use cases within the organization should be identified as soon as possible, including what kind of integrations should be established between the controls at the different layers. Integrations will be one of the major changes coming with Zero Trust implementations in the next couple of years.
The vanishing perimeter paradigm will have to result in more integration between the security controls installed at the different layers of defense. The result is consolidated insights that can be used to make the access decisions for your data dynamically (under the principle of “Always Verify”) and access is no longer solely based on static access-control lists (ACLs).
From the ESA point of view, this “Define Context” tenet is where the security policies are set. Moreover, security services are needed to support the organization’s requirements. The capabilities needed to provide the services should be compiled and the high-level solution patterns built on these capabilities will need to address the Zero Trust use cases. The new and adapted capabilities have to be defined at the technical level and then deployed. The ESA should also define how to move from architectural version N to version N+1 through a transformation road map. In the picture below, I map the IBM Zero Trust governance model to the ESA example.
Source: IBM Security
2. Verify and Enforce
The “Verify and Enforce” tenet in the IBM governance model is where most security vendors position their Zero Trust solutions. In an ESA context, this is where the logical architectures define the required security building blocks (SBB).
Next, the logical architecture is worked out into technical designs based on the selected technologies. For example, the implementation of micro-segmentation for infrastructure in the data center will require a detailed technical design at the network layer. The role of ESA is to ensure the overall principles are followed during design and that the design goals like integration are achieved.
3. Resolve Incidents
Next comes everything related to security operations. This third tenet is called “Resolve Incidents” in IBM Security’s Zero Trust governance model. It is here where security operations are defined. This is also where security teams learn how to cope with security incidents impacting trusted connections and speed up both the detection and response for these incidents.
From my perspective, the operational architecture within ESA is the most important concept here. You could have the best security technologies available, but if they’re not properly managed by the security operations team, it won’t meet expectations and can result in failed outcomes. We all know that security maturity can’t be achieved in every layer at the same moment. To overcome this challenge, adequate security monitoring solutions and automated response measures are the best tools to overcome possible gaps in maturity.
4. Analyze and Improve
The tenet of “Analyze & Improve” is a key element of the Zero Trust governance model and it should also be a standard component of every ESA. In a rapidly evolving technology landscape, where there are accelerated product releases thanks to Agile approaches combined with automated CI/CD delivery models, an ESA should focus on the continuous improvement loop.
Implementing Zero Trust principles won’t be achieved overnight. The changes should be tested on a single use case that’s relevant to your business and the effectiveness of that implementation should be consistently measured with improvements applied in an Agile way. Once your initial use case is deemed ready, the same approach can be scaled out to other enterprisewide use cases, meaning that all activities related to “Analyze & Improve” will have to occur at an accelerated pace.
Interested in learning how you can begin your Zero Trust adoption? Learn about the steps you can take with an integrated, multi-disciplinary governance model that advances progress toward maturity.
Data security is on everyone’s mind these days, and for good reason. The number of successful data breaches is growing thanks to the increased attack surfaces created by more complex IT environments, widespread adoption of cloud services and the increasingly sophisticated nature of cybercriminals.
One part of this story that has remained consistent over the years is that most security breaches are preventable. Although every organization’s security challenges and goals are different, there are certain mistakes that many companies make as they begin to tackle data security. What’s worse, these mistakes are often accepted as the norm, hiding in plain sight under the guise of common practice.
Below are five common data security failures that, if left unchecked, could lead to unforced errors and contribute to the next major data breach.
1. Failure to Move Beyond Compliance
It is often said that compliance does not equal security, and most security professionals would agree with that statement. However, organizations often focus their limited security resources on achieving compliance and, once they receive their certifications, become complacent. As a result, many of the largest data breaches in recent years have happened in organizations that may have been fully compliant on paper.
2. Failure to Recognize the Need for Centralized Data Security
Compliance can help raise awareness of the need for data security, but without broader mandates that cover data privacy and security, organizations often forget to move past compliance and a focus on consistent, enterprise-wide data security. A typical organization today has a hybrid multicloud environment, which is constantly changing and growing. New types of data stores can appear weekly, if not daily, and greatly disperse sensitive data.
3. Failure to Assign Responsibility for the Data
Even when aware of the need for data security, many companies have no one specifically responsible for protecting sensitive data. This situation often becomes apparent during a data security or audit incident when the organization is under pressure to find out who is actually responsible.
4. Failure to Address Known Vulnerabilities
High-profile breaches in enterprises have often resulted from known vulnerabilities that went unpatched even after the release of patches. Failure to quickly patch known vulnerabilities puts your organization’s data at risk because cybercriminals actively seek these easy points of entry.
According to a recent IDC research report, organizations are struggling to manage data security across multi-cloud and hybrid environments. In fact, in a recent survey more than 37% of respondents indicated that the growing complexity of security solutions as a significant challenge, which often impedes data governance and policy enforcement.
5. Failure to Prioritize and Leverage Data Activity Monitoring
Monitoring data access and use is an essential part of any data security strategy. Organizations need to know who, how and when people are accessing data. This monitoring should encompass whether these people should have access, if that access level is correct and if it represents an elevated risk for the enterprise.
Taking Steps to Close Data Security Pitfalls
There is nothing easy about securing sensitive data to combat today’s threat landscape, but companies can take steps to ensure that they are devoting the right resources to their data protection strategy.
When starting on a data security journey, you need to size and scope your monitoring efforts to properly address the requirements and risks. This activity often involves adopting a phased approach that enables development and scaling best practices across your enterprise. Moreover, it’s critical to have conversations with key business and IT stakeholders early in the process to understand short-term and long-term business objectives.
