Microsoft has released its monthly security update for May of 2025 which includes 78 vulnerabilities affecting a range of products, including 11 that Microsoft marked as “critical”.  

Microsoft noted five vulnerabilities that have been observed to be exploited in the wild. CVE-2025-30397 is a remote code execution vulnerability in the Microsoft Scripting Engine. There were also four elevation of privilege vulnerabilities being actively exploited, CVE-2025-32709, CVE-2025-30400, CVE-2025-32701 and CVE-2025-32706 affecting the Ancillary Function Driver for WinSock, the DWM Core Library and the Windows Common Log File System Driver.  

The eleven “critical” entries consist of five remote code execution (RCE) vulnerabilities, four elevation of privilege vulnerabilities, one information disclosure vulnerability and one spoofing vulnerability. Three of the critical vulnerabilities have been marked as “Exploitation more likely”: CVE-2025-30386 –a Microsoft Office RCE vulnerability, CVE-2025-30390 –an Azure ML Compute elevation of privilege vulnerability, and CVE-2025-30398 – a Nuance PowerScribe 360 information disclosure vulnerability.  

The most notable of the “critical” vulnerabilities listed affect Microsoft Office. CVE-2025-30386 is a RCE vulnerability with base CVSS 3.1 score of 8.3. To successfully exploit CVE-2025-30386, an attacker could send a victim an email, and without the victim clicking the link, viewing or interacting with the email, trigger a use-after-free scenario, allowing arbitrary code to be executed. Microsoft has assessed that the attack complexity is “Low”, and exploitation is “More likely”. Another RCE vulnerability affecting Microsoft Office, CVE-2025-30377, has a CVSS 3.1 base score of 8.4, and has been assessed an attack complexity of “Low”, but exploitation is considered “Less Likely”. 

Two RCE vulnerabilities affect the Remote Desktop Client. CVE-2025-29966 and CVE-2025-29967 are both Heap-cased Buffer Overflow vulnerabilities with CVSS 3.1 base scores of 8.8 with “Low” attack complexity and exploitation “Less Likely”. An attacker controlling a Remote Desktop Server could trigger the buffer overflow in a vulnerable when a vulnerable Remote Desktop Client connects to the server. 

CVE-2025-29833 is a RCE affecting the Virtual Machine Bus. This is a Time-of-check Time-of-use (TOCTOU) Race Condition which has been assessed an attack complexity of “High” and exploitation is “Less Likely”. 

Talos would also like to highlight the following “important” vulnerabilities as Microsoft has determined that exploitation is “More likely”: 

• CVE-2025-24063 – Kernel Streaming Service Driver Elevation of Privilege Vulnerability 
• CVE-2025-29841 – Universal Print Management Service Elevation of Privilege Vulnerability 
• CVE-2025-29971 – Web Threat Defense (WTD.sys) Denial of Service Vulnerability 
• CVE-2025-29976 – Microsoft SharePoint Server Elevation of Privilege Vulnerability 
• CVE-2025-30382 – Microsoft SharePoint Server Remote Code Execution Vulnerability 
• CVE-2025-30385 – Windows Common Log File System Driver Elevation of Privilege Vulnerability 
• CVE-2025-30388 – Windows Graphics Component Remote Code Execution Vulnerability

A complete list of all the other vulnerabilities Microsoft disclosed this month is available on its update page.  

In response to these vulnerability disclosures, Talos is releasing a new Snort rule set that detects attempts to exploit some of them. Please note that additional rules may be released at a future date and current rules are subject to change pending additional information. Cisco Security Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. 

The rules included in this release that protect against the exploitation of many of these vulnerabilities are 64848-64867. There are also these Snort 3 rules: 64852-64853, 301192-301200, and 301203 

Cisco Talos Blog – ​Read More

Attackers keep improving ways to avoid being caught, making it harder to detect and investigate their attacks. The Tycoon 2FA phishing kit is a clear example, as its creators regularly add new tricks to bypass detection systems. 

In this study, we’ll take a closer look at how Tycoon 2FA’s anti-detection methods have changed over the past several months and suggest ways to spot them effectively. 

This article will discuss: 

• A review of old and new anti-detection techniques. 

• How the new tricks compared to the old ones. 

• Tips for spotting these early. 

Knowing how attackers dodge detection and keeping user detection rules up to date are key to fighting these anti-detection methods. 

What is Tycoon 2FA 

Tycoon 2FA is a modern Phishing-as-a-Service (PhaaS) platform designed to bypass two-factor authentication (2FA) for Microsoft 365 and Gmail. It was first identified by Sekoia analysts in October 2023, though the Saad Tycoon group, which promotes this tool through private Telegram channels, has been active since August 2023. 

Tycoon 2FA uses an Adversary-in-the-Middle (AiTM) approach, where attackers set up a phishing page through a reverse proxy server. After a user enters their credentials and completes the 2FA process, the server captures session cookies, allowing attackers to reuse the session and bypass security measures. 

Currently, Tycoon 2FA is highly popular and widely used by cybercriminals, including the Saad Tycoon group. The platform offers ready-made phishing pages and an easy-to-use admin panel, making it accessible even to less technically skilled attackers. 

Discover the latest examples of Tycoon 2FA attacks using this search query in ANY.RUN’s Threat Intelligence Lookup:

threatName:”Tycoon” 

In 2024, an updated version of Tycoon 2FA was released, featuring enhanced evasion techniques, including dynamic code generation, obfuscation, and traffic filtering to block bots. Phishing emails are now frequently sent from legitimate, potentially compromised email addresses. 

The evolution of this phishing kit continues, with ANY.RUN researchers noting regular updates and new evasion mechanisms in its malicious software. This article aims to investigate and provide technical details on how Tycoon 2FA has evolved, is evolving, and may continue to evolve. 

Before We Begin

Tune in to ANY.RUN’s live webinar on Wednesday, May 14 | 3:00 PM GMT. We welcome heads of SOC teams, managers, and security specialists of different tiers who want to: 

• Solve common security issues
• Optimize their work processes 
• Find out how to save company’s resources 

Analysis of a Tycoon2FA Attack from 01.10.2024 

Let’s begin the analysis with a typical Tycoon2FA attack observed October of 2024. The attack begins with a malicious URL and employs multiple evasion techniques to avoid detection. Below, we well break down each stage of the attack, highlighting its protective mechanisms and their purposes. 

View sandbox session 

Stage 1: Initial Attack Mechanisms 

The attack starts with a request to the following URL: 

hxxps://stellarnetwork[.]sucileton[.]com/EQn1RAKa/ 

Evasion Mechanism #1: Basic Code Obfuscation 

The page’s source code is obfuscated, making it difficult for automated systems or analysts to interpret its functionality.  

This is a foundational defense to hinder initial analysis. 

Evasion Mechanism #2: “Nomatch” Check 

The code compares the URL (part of the attacker’s infrastructure) against a “nomatch” value. This check appears to be a decoy or placeholder, as the comparison always returns False. It may serve as a flag for services like Cloudflare. 

Evasion Mechanism #3: Domain Comparison 

The code verifies whether the current page’s domain matches the attacker’s designated infrastructure domain. If the domains match, the attack proceeds to load Stage 2 (the malicious payload) into the Document Object Model (DOM). If not, a fake error page is displayed. 

Evasion Mechanism #4: Redirect to Fake Litespeed 404 Page on Failed Checks 

If the domain check fails, the user is redirected to a fake “Litespeed 404” error page.  

The page is designed to appear legitimate and deter further investigation. 

Purpose of Stage 1 Evasion Mechanisms 

These mechanisms are designed to prevent the malicious code from executing or revealing its behavior in isolated scenarios, such as: 

• Malware analysis sandboxes. 

• Offline inspection of saved HTML files. 

By ensuring the code only runs in the attacker’s controlled environment, these checks reduce the likelihood of detection. 

If all Stage 1 checks are passed, the malicious payload (Stage 2) is injected into the page’s DOM, advancing the attack to its next phase. 

Stage 2: Main Evasion Mechanisms 

Evasion Mechanism #5: Cloudflare Turnstile CAPTCHA  

Before loading the main content, Tycoon 2FA requires users to pass a Cloudflare Turnstile CAPTCHA. This protects the malicious page from web crawlers, Safebrowsing services, or automated systems that could capture and analyze the page’s content. 

Evasion Mechanism #6: Debugger Timing Check 

During Stage 2, the code also measures the time taken to launch a debugger, a technique used to detect whether the page is running in a real browser or a sandboxed environment. In this sample, the check is rudimentary, and the timing result is not actively used, suggesting it may be a placeholder or incomplete feature. 

Evasion Mechanism #7: C2 Server Queries 

Tycoon 2FA sends a series of requests to the attacker’s Command-and-Control (C2) servers to determine whether to proceed to Stage 3. This process involves two steps: 

• GET Request to Secondary C2 Domain: 
  A GET request is sent to another C2 domain, expecting a single-byte response: ‘0’ or ‘1’.  
  • If ‘1’ is received, the attack halts, and the user is redirected to a legitimate page.  
  • If ‘0’ is received, the attack continues. 

If all Stage 2 checks are successfully passed, the page reloads, and the Stage 3 payload, the core malicious component, is retrieved and executed. 

Stage 3: Payload Unpacking 

Evasion Mechanism #8: Base64 + XOR Obfuscation 

The payload in Stage 3 is obfuscated using a combination of Base64 encoding and XOR encryption with a predefined key. This protects the malicious code from being easily analyzed or detected. 

After deobfuscation (use this CyberChef recipe), the next stage is revealed, advancing the attack. 

Stage 4: Dynamic Payload Retrieval 

During the payload retrieval, a POST request is sent to the attacker’s C2 server. The request body contains data derived from the initial phishing URL, with logic that varies based on whether the victim’s email is included in the URL. 

Evasion Mechanism #9: Encrypted Payload Delivery

The C2 server responds with a JSON file containing ciphertext and decryption parameters. The specific data received depends on the contents of the POST request. The payload is decrypted to reveal the URL for the next stage. 

To see the sample of the retrieved payload and its decryption, visit JSFiddle. The result of this action is the URL for Stage 5. 

Stage 5: Fake Login Page Delivery 

The content in Stage 5 is mostly unobfuscated, presenting a fake Microsoft Outlook login page designed to deceive the victim. It includes SVG assets and a stylesheet to mimic the legitimate interface. 

At the end of the page’s source code, an additional JavaScript script reuses the Base64 + XOR obfuscation technique (previously seen in Stage 3) to hide further malicious code. 

Deobfuscating this script reveals the next stage of the attack. 

Stage 6: Fake Authorization and Data Exfiltration 

The frontend mimics a Microsoft Outlook login page, designed to trick victims into entering their credentials. 

At the end of the source code, a JavaScript script implements several new protective and operational mechanisms: 

Evasion Mechanism #10: Browser Detection 

The script identifies the victim’s browser to tailor the attack or detect analysis environments (e.g., sandboxes).  

Evasion Mechanism #11: Clipboard Manipulation 

The script replaces the clipboard contents with junk data to interfere with analysis or debugging attempts.  

Evasion Mechanism #9 (Reused): Payload Encryption/Decryption 

The script encrypts and decrypts the payload using hardcoded keys and initialization vectors (IVs), protecting data sent to and received from the C2 server.  

Evasion Mechanism #12: C2 Routing with Dynamic URLs 

A randomly generated URL for data exfiltration is created using the RandExp library, following a pattern determined by the Tycoon 2FA operation mode (e.g., checkmail, checkpass, twofaselected). This ensures varied C2 communication paths, complicating detection.  

Evasion Mechanism #13: Redirect API Validation 

The script checks the validity of a redirect API, likely used by Tycoon 2FA operators to monitor client status or subscription activity. 

Finally, the stolen data (e.g., credentials) is exfiltrated to a third C2 domain in the attack chain. The response from the C2 server dictates the phishing page’s behavior, such as prompting for 2FA or updating the account status.  

A JSFiddle snippet demonstrates the encryption/decryption of sent/received data.  

At the end of Stage 6, there is a link to another script, which loads the next stage of the attack. 

Stage 7: Phishing Framework Enhancements 

After deobfuscation, Stage 7 reveals additional functionality for the Phishing-as-a-Service (PhaaS) framework, defining critical operations for the phishing interface. 

The code includes logic for:  

• Managing the user interface behavior.  

• Handling transitions between frames.  

• Rendering core page elements.  

• Implementing a state machine for the phishing page.  

• Validating user inputs (e.g., email, password, OTP). 

Execution Chain Summary 

The complete execution chain, combining all mechanisms from Stages 1–7, is visualized below: 

With a comprehensive understanding of Tycoon 2FA’s attack flow, we can now analyze newer samples and compare them to this baseline to identify changes or additions to its anti-detection mechanisms. 

New Tycoon2FA Evasion Mechanisms: Timeline 

As we’ve discussed, Tycoon 2FA is steadily evolving, with its developers rolling out more sophisticated anti-detection mechanisms.  

Let’s now examine the latest evasion methods that have emerged in attacks since October. 

Attack Detected on 6 December 2024  

This sample introduces new anti-detection mechanisms in Stage 2, enhancing the malicious payload’s ability to avoid analysis and debugging environments. The following mechanisms were observed: 

Evasion Mechanism #14: Debug Environment Detection 

The script checks if the page is loaded in a legitimate browser rather than a debugging environment, such as Selenium (WebDriver), PhantomJS, or Burp Suite. If a debugging runtime is detected, the attack stops, and the user is redirected to about:blank.   

Evasion Mechanism #15: Keystroke Interception 

The code intercepts keyboard shortcuts associated with opening browser developer tools or other debugging functions, preventing their default actions. This hinders manual analysis by users or researchers.  

The intercepted shortcuts include:   

• F12: Opens DevTools (Firefox).  

• Ctrl + U: Displays page source code.  

• Ctrl + Shift + I: Opens DevTools (Generic).  

• Ctrl + Shift + C: Opens DevTools (Chrome).  

• Ctrl + Shift + J: Opens browser console (Firefox).  

• Ctrl + Shift + K: Duplicates current tab (Edge).  

• Ctrl + H: Opens browser history (Generic).  

• Meta + Alt + I: Opens insert menu (varies by browser).  

• Meta + Alt + C: Copies selected text.  

• Meta + U: Shows page source or accessibility menu. 

Evasion Mechanism #16: Context Menu Blocking 

The script disables the right-click context menu, preventing access to browser tools or page source inspection. 

Improved Evasion Mechanism #6: Debugger Timing Check

Building on the rudimentary version in earlier samples, this implementation fully measures the time taken to launch a debugger. If the timing is abnormally long (suggesting a sandbox environment), the script redirects to a legitimate page, halting execution. 

Attack Detected on 17 December 2024  

In another attack from December, the threat introduced a new capability to enhance the phishing page’s authenticity, making it more convincing to victims. 

Evasion Mechanism #17: Dynamic Multimedia via Legitimate CDN 
Specifically, the phishing page dynamically loads a logo and custom background tailored to the domain of the victim’s email address, increasing its visual credibility.  

The multimedia content is delivered through Microsoft’s legitimate AADCDN network, leveraging trusted infrastructure to evade detection and reduce suspicion. 

Attack Detected on 3 April 2025 

This sample introduces multiple new evasion mechanisms across various stages, reflecting Tycoon 2FA’s continued evolution in obfuscation, redirection, and anti-analysis techniques. 

Stage 1: Enhanced Obfuscation 

Evasion Mechanism #18: Complex JavaScript Code 

The payload uses Base64 obfuscation for JavaScript keywords, and method calls (e.g., document.write()) are invoked via object property access, complicating static analysis.  

The next stage’s content involves URL-encoding/decoding, further obscuring the code.  

Stage 2: New Evasion Techniques 

When Stage 2 code is deobfuscated, we can observe new evasion methods. 

Evasion Mechanism #19: Invisible Obfuscation 

The code employs whitespace-based “invisible” obfuscation, using proxy object calls and getter methods to retrieve and execute code via eval(). This technique makes the code harder to read and analyze. 

The form sent during the transition from Stage 2 to Stage 3 is now created as a FormData object, replacing the previous HTML <form> element approach, reducing detectability. 

Evasion Mechanism #20: Custom Fake Page Redirect 

Unlike earlier samples that redirected to legitimate sites (e.g., eBay) upon failing checks, this revision redirects to a custom fake HTML page, enhancing deception and avoiding reliance on external domains. 

Evasion Mechanism #21: Custom CAPTCHA 

A custom CAPTCHA replaces the previously used Cloudflare Turnstile, likely to complicate signature-based and behavioral analysis and mitigate potential issues with Cloudflare’s security services.  

Stage 5: Clipboard Protection 

Evasion Mechanism #22: Disabling Clipboard Copying 

In addition to filling the clipboard with junk data (as seen in earlier samples), this revision prevents copying from the login form’s input fields, further hindering analysis.  

Stage 6: Enhanced Data Exfiltration 

Evasion Mechanism #23: Custom Binary Encoding 

Data exfiltration now uses binary encoding for payloads, adding an additional layer of obfuscation.  

To see the payload example, we can use CyberChef. The result is decrypted data.  

The decryption key is IV: 1234567890123456 

Attack Detected on 14 April 2025 

This sample introduces a more complex method for launching the Stage 1 payload, leveraging redirect chains to obscure the attack’s entry point. 

Evasion Mechanism #24: Extended Redirect Chain  

Clicking the initial phishing link triggers a redirect to Google Ads, followed by another redirect to a malicious URL that uses the following format:  

hxxps://<domain>/?<2nd_domain>=<base64_payload> 

A script then extracts the Base64 payload from location.search(), decodes it, and constructs the URL for the Stage 1 payload.  

This extended redirect chain makes it harder to trace the attack’s origin. 

Tycoon 2FA has become more sophisticated in initiating its malicious payload, employing a longer redirect chain to obscure the entry point of the attack.  

The process is as follows: 

Additionally, in POST requests, the cf-turnstile-response field (previously used for Cloudflare validation) is now filled with a placeholder value (qweqwe), confirming Tycoon 2FA’s shift away from Cloudflare. 

Evasion Mechanism #25: Rotating CAPTCHAs 

This revised version replaces the previously used custom CAPTCHA with Google reCAPTCHA.  

Historical data shows Tycoon 2FA has cycled through different CAPTCHAs, such as IconCaptcha (observed in a submission on April 7, 2025).  

The use of varying CAPTCHAs complicates signature-based detection. 

Attack Detected on 23 April 2025 

Around this period, Tycoon 2FA introduced a new anti-detection mechanism focused on browser fingerprinting to detect sandbox environments and bot activity. 

View sandbox session 

Evasion Mechanism #26: Browser Fingerprinting

After opening the phishing link, a page is loaded requesting image element and executing a Base64-encoded script in case of an error.  

After decoding with CyberChef, the script reveals functionality for:  

• Collecting browser environment details: screen parameters, browser/platform name, URL, host, protocol, console properties, and document body.  

• Gathering additional data: timezone, JavaScript runtime internals, iframe checks, and graphical interface properties.  

• Collecting miscellaneous technical information. 

The collected data is formatted as JSON, inserted into an invisible form, and sent to the attacker’s server via a POST request.  

The server analyzes the fingerprint data and returns a response with a Location header, leading to one of two outcomes:  

• Redirect to a Legitimate Page: If checks fail (e.g., sandbox detected), the user is redirected to a legitimate site like Emirates, Tesla, or SpaceX. 

• Redirect to Stage 1 Payload: If checks pass, the user is directed to the Tycoon 2FA Stage 1 phishing page. 

This mechanism also allows the attacker to geographically restrict the operation of the malware, enabling Tycoon2FA to launch in certain regions while terminating the attack process in others. 

Attack Detected on 6 May 2025 

Evasion Mechanism #27: Obfuscation through Encryption 

In this sample, we can observe that the Tycoon2FA operator began using AES encryption for payload obfuscation, not just for uploading/downloading stolen and service data in the final stages of execution.

In all other parts, the execution chain of the new samples remains similar to the original.  

All Tycoon2FA Evasion Mechanisms 

Conclusion 

The operators and developers of the Tycoon 2FA Phishing-as-a-Service (PhaaS) framework continue to actively enhance their product, focusing on complicating analysis of the malicious software. 

Tycoon 2FA is adopting increasingly sophisticated anti-bot techniques, such as rotating CAPTCHAs (e.g., Google reCAPTCHA, IconCaptcha, custom CAPTCHAs) and browser fingerprinting, to protect its infrastructure from crawlers and Safebrowsing solutions. 

The analysis indicates that there are several different versions or types of Tycoon 2FA active at the same time. This is evident because the methods used to avoid detection vary across different samples and time periods. Some techniques show up, disappear, and come back later.  

Alongside the primary focus on Microsoft Outlook authentication phishing, variants targeting Google account authentication have been observed:  

https://app.any.run/browses/b9c0b778-df32-4073-a580-18d7fc330518

https://app.any.run/tasks/a487cada-21b9-48e2-a7f3-470e3eddab0d

Despite the addition of new evasion techniques, some methods lack sophistication and remain relatively easy to bypass: 

• Obfuscation: Most obfuscation relies on public tools like obfuscate.io, which can be reversed using deobfuscate.io.  

• Limited JavaScript Exploitation: Tycoon 2FA does not fully leverage advanced JavaScript runtime capabilities, such as prototype manipulation, reflection mechanisms, or other dynamic code restructuring techniques. 

In certain aspects, Tycoon 2FA’s evasion mechanisms seem quite amateur. For example, across all observed samples, C2 payloads and exfiltrated data are encrypted/decrypted using hardcoded keys and initialization vectors (1234567890123456 for both key and IV). Ideally, unique keys should be generated per session to enhance security. 

The core architecture of Tycoon 2FA remains unchanged, relying on three domains: 

• Primary phishing domain: Hosts the phishing page.  

• Controller domain: Authorizes or denies further execution based on protective checks.  

• Exfiltration domain: Receives stolen data. 

Similarly, the execution chain of the framework has remained consistent, enabling detection through behavioral analysis despite the introduction of new evasion mechanisms. 

Recommendations for Detecting Tycoon 2FA 

Given the constant changes in the source code of Tycoon 2FA phishing pages, signature-based analysis is largely ineffective, and behavioral analysis is essential for reliable detection.  

Tycoon 2FA employs a “triangle” of Command-and-Control (C2) domains from a specific pool of top-level domains (TLDs), including .ru, .es, .su, .com, .net, and .org. It also consistently loads a predictable set of JavaScript libraries, CSS stylesheets, and other web content, which can be leveraged for detection: Libraries: 

• https://code.jquery.com/jquery-3.6.0.min.js 

• https://github.com/fent/randexp.js/releases/download/v0.4.3/randexp.min.js 

• https://cdnjs.cloudflare.com/ajax/libs/crypto-js/4.1.1/crypto-js.min.js 

Okta CSS: 

• https://ok4static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.18.0/css/okta-sign-in.min.css 

• https://ok4static.oktacdn.com/assets/loginpage/css/loginpage-theme.e0d37a504604ef874bad26435d62011f.css 

Misc hyperlinks/web-content: 

• https://ok4static.oktacdn.com/fs/bcg/4/gfsh9pi7jcWKJKMAs1t7 

• https://www.okta.com/privacy 

• https://www.godaddy.com/ 

• https://sso.godaddy.com/v1/account/reset?app=o365&amp;realm=pass 

• https://www.godaddy.com/legal/agreements/privacy-policy?target=_blank 

• https://www.godaddy.com/legal/agreements/cookie-policy 

To detect Tycoon 2FA, security teams can implement a heuristic based on the following behavioral patterns observed in a single session: 

• C2 Domain Triangle: Communication with a set of domains from the TLD pool (e.g., .ru, .es, .su, .com, .net, .org).    

• Resource Loading: Retrieval of the specific JavaScript libraries, CSS stylesheets, or web content listed above.    

• Session Redirect: A redirect to the official Microsoft authentication page at the end of the session. 

Then there is a high probability that the activity involves Tycoon 2FA phishing. 

The post Evolution of Tycoon 2FA Defense Evasion Mechanisms: Analysis and Timeline appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

• In the evolving cyberthreat landscape, Cisco Talos is witnessing a significant shift towards compartmentalized attack kill chains, where distinct stages — such as initial compromise and subsequent exploitation — are executed by multiple threat actors. This trend complicates traditional threat modeling and actor profiling, as it requires understanding the intricate relationships and interactions between various groups, explained in the previous blog.
• The traditional Diamond Model of Intrusion Analysis’ feature-centered approach (adversary, capability, infrastructure and victim) to pivoting can lead to inaccuracies when analyzing “compartmentalized” attack kill chains that involve multiple distinct threat actors. Without incorporating context of relationships, the model faces challenges in accurately profiling actors and constructing comprehensive threat models.
• We have identified several methods for analyzing compartmentalized attacks and propose an extended Diamond Model, which adds a “Relationship Layer” to enrich the context of the relationships between the four features.
• In a collaboration between Cisco Talos and Vertex Project, a Synapse model update has just been published which introduces the entity:relationship providing modelling support to this methodology.
• We illustrate our investigative approach and application of the extended Diamond Model for effective pivoting by examining the ToyMaker campaign, where ToyMaker functioned as a financially-motivated initial access (FIA) group, handing over access to the Cactus ransomware group.

---

Impacts on defenders

The convergence of multiple threat actors operating within the same overall intrusion creates additional layers of obfuscation, making it difficult to differentiate the activities of one threat actor from another, or to identify when access has been handed off from one to the next. At each point where outsourcing occurs or access is handed off, the Diamond Model of the adversary changes. Likewise, the ability to leverage the output of kill chain analysis for the purpose of pivoting, clustering, and attribution becomes significantly more difficult as analysts may be forced to operate under the assumption that multiple actors are involved unless they can prove otherwise, where historically the opposite assumption was likely made.

Additionally, misattributing attacks due to tactics, techniques and procedures (TTPs) present in earlier stages of the intrusion may impact the way in which incident response or investigative activities are conducted post-compromise. They may also create uncertainty around the motivation(s) behind an attack or why an organization is being targeted in some cases. 

Analysis processes and analytical models must be updated to reflect these new changes in the way that adversaries conduct intrusions, as existing methodologies often create more confusion than clarity.

Introduction to threat modeling

NIST SP 800-53 (Rev. 5) defines threat modeling as “a form of risk assessment that models aspects of the attack and defense sides of a logical entity, such as a piece of data, an application, a host, a system, or an environment.”

For many organizations, this involves evaluating their preventative, detective and corrective security controls from an adversarial perspective to identify deficiencies in their ability to prevent, detect or respond to threats based on specific tactics, techniques, and procedures (TTPs). For example, adversary emulation simulates an attack scenario and demonstrates how an organization could reasonably expect their security program to respond if a specific threat is encountered.

Intrusion analysis is the process of analyzing computer intrusion activity. This involves reconstructing intrusion attack timelines, analyzing forensic artifacts and identifying the scope and impact of activity. Intrusion analysis typically results in a better understanding of an attack or adversary, and may also result in the development of a model to reflect what is known about the threat. This model can then be used to support more effective detection content development and threat modeling activities in the future. The symbiotic relationship between intrusion analysis and threat modeling allows organizations to effectively incorporate new knowledge and information about threats and threat actors into their security programs to ensure continued effectiveness.

Over the past several years, different analytical models have been developed to assist with intrusion analysis and threat modeling that provide logical ways to organize contextual details about threats and threat actors so that they can be communicated and incorporated more effectively. Two of the most popular models are the Diamond Model and the Kill Chain Model.

The Kill Chain Model shown above is typically used to break an intrusion down into distinct stages/phases so that the attack can be reconstructed and analyzed. This allows analysts to build a realistic model that reflects the TTPs and other characteristics present during the intrusion. This information can then be shared so that other organizations can determine whether their own security controls would be effective at combatting the same or similar intrusion(s) or whether they have encountered the same threat in the past. 

The Diamond Model, shown above, is commonly used across the industry for building a profile of a specific threat or threat actor. This model is developed by populating each quadrant based on information about an adversary’s characteristics, capabilities, infrastructure tendencies and typical targeting/victimology.  A fully populated diamond model creates an extensive profile of a given threat or threat actor.

It is important to note that an analysis may incorporate both (or other) models, and they are not mutually exclusive. There are also several other modeling frameworks that exist for similar purposes that are also often used in concert, such as the MITRE ATT&CK and D3FEND frameworks. For example, in some cases the information used to populate the Diamond Model may be the result of kill chain analyses of multiple intrusions over time that are ultimately attributed to the same threat actor(s). By leveraging the output of multiple kill chain analyses, one can build a more comprehensive model that reflects changes to characteristics or TTPs associated with a threat actor being tracked over time as well as improve overall understanding of the nature of a given threat.

Challenges applying existing models to compartmentalized threats

One of the key strengths of the Diamond Model is its concept of “centered approaches” for analytic pivoting — including victim-, capability-, infrastructure- and adversary-centered methods of investigation. These approaches enable analysts to uncover new malicious activities and reveal how each facet of an intrusion across the Diamond’s four dimensions intersects with others. For instance, in the paper’s infrastructure-centered example, an analyst might begin with a single IP address seen during an intrusion, then pivot to the domain it resolves to, scrutinize WHOIS registration details, and discover additional domains or IPs registered by the same entity. Further examination may reveal malware connected to or distributed by those domains. In such scenarios, the Diamond Model’s systematic method of traversing from one node to another can rapidly expose an interconnected web of adversaries, capabilities, and victims.

However, the original centered approach can introduce errors when dealing with a “compartmentalized” attack kill chain involving multiple distinct threat actors. In many cases, adversaries are now leveraging various relationships simultaneously while working towards their longer term mission objectives. This could include the outsourcing of tooling development, rental of infrastructure services for distribution or command and control (C2), or access-sharing agreements leveraged post-compromise to facilitate hand-off once initial access (IA), persistence or privilege escalation has been achieved. This compartmentalization has complicated many analytical activities including attribution, threat modeling, and intrusion analysis. Likewise, the modeling methodologies that were initially developed to combat intrusion operations in previous years no longer accurately reflect today’s threat landscape.

To illustrate the complexity of compartmentalization, let’s consider a hypothetical scenario that closely mirrors real-world events. In this scenario, four distinct threat actor groups are involved:

1. Actor A: A financially motivated threat actor aiming to profit by collecting logs from infostealer malware.
2. Actor B: A malware developer who creates and sells infostealer malware.
3. Actor C: A Traffic Distribution Service (TDS) provider.
4. Actor D: A ransomware group.

In this scenario, a financially-motivated threat actor (Actor A) who is seeking to infect victims with information-stealing malware to steal victims’ sensitive information may outsource the development of their malware to Actor B. They may engage the developer directly or purchase it from a storefront. Likewise, the distribution of the malware itself is conducted by outsourcing it to Actor C, who operates a spam botnet or traffic distribution service (TDS) that is offered for rent for a usage-based fee. Once Actor C has successfully achieved code execution on a system, they may infect it with the malware they initially received from Actor A, who is charged “per-install.” 

Likewise, once Actor A has successfully performed enumeration of the environment, they identify that they were successful in gaining access to a high value target. Rather than simply focus on monetizing information-stealing malware logs, they choose to monetize their access to the exfiltrated data by selling it to Actor D, who then leverages that access to deploy ransomware and extort the victim. 

In this hypothetical scenario, Actor C, who would be classified as a financially-motivated initial access (FIA) broker, may also be distributing multiple malware families at any given time and leverage traffic filtering to manage final payload delivery. They may even host these payloads on the same infrastructure. The nature of the business relationships described in this scenario are shown below.

While this scenario covers a single attack, it highlights a situation where applying the traditional analytical models poses several challenges. For example, consider the infrastructure used by Actor C, the TDS provider. The infrastructure that facilitates malware distribution is not solely dedicated to Actor A’s operations. This means that other malware found by pivoting the distribution infrastructure should not be considered as capabilities associated with Actor A. In addition, the malware’s targets are highly associated with the Actor C’s targeted network and should not be strongly considered as the motivation for the victimology of Actor A. In this compartmentalized scenario, the interconnected web of adversaries, capabilities and victims exposed by pivoting with the Diamond Model should not be associated with each other, as they originate from different threat actors and should not be modeled as part of a single threat actor profile.

In even more complex cases, a threat actor may choose to engage multiple distributors simultaneously or work with different distributors on a weekly basis depending on real-time pricing and service availability. A threat actor conducting ransomware operations may choose to procure access from several initial access brokers (IABs), each with their own characteristics, capabilities and motivations. Likewise, several otherwise unrelated threat actors operating in different capacities throughout the kill chain present complications when attempting to take the result of the analysis and incorporate it into existing attribution data or when attempting to identify overlaps with other clusters of malicious activity. Modeling the IABs themselves also presents complications, as their characteristics and TTPs are often encountered in attacks where they may have only been operating within a subset of the overall phases of the intrusion. 

State-sponsored or -aligned threat actors’ campaigns have been documented using anonymization networks or residential proxies to hide their activities. This will create the same kind of activity overlap described by the usage of a TDS.

Extending the Diamond Model with the Relationship Layer

To extend the Diamond Model to include the complexities posed by compartmentalized attacks, we propose an extension to the original Diamond Model by integrating a “Relationship Layer.” This additional layer is designed to contextualize the interactions between the four features (adversary, infrastructure, capability and victim) of individual diamonds representing distinct threat actors. By incorporating this layer, threat analysts can construct a nuanced understanding of compartmentalized contexts.

The Relationship Layer allows for the articulation of common relational dynamics such as “purchased from” to indicate a transactional association, “handover from” to reflect a transfer of operational control or resources, and “leaked from” to convey the use of leaked tools. Additionally, it describes the connections between adversarial groups, encompassing a variety of interactions such as “commercial relationship,” “partnership agreements,” “subcontracting arrangements,” “shared operational goals,” and more. 

The integration of the Relationship Layer enables analysts to contextualize the interactions within the Diamond Model’s four features, thereby enhancing their ability to perform logical pivoting and accurate attribution. This refinement offers a more sophisticated framework for analyzing modern, compartmentalized cyberthreats, providing a clearer representation of the complex web of relationships that characterize these operations.

Let’s look at the scenario involving Actors A through D again. Figure 4 shows how we can use the extended Diamond Model to describe the relationships between entities involved in the intrusion activity:

Each of the actors, A through D, possesses their own Diamond Model, reflecting their distinct roles as adversaries with unique capabilities, victims and infrastructures. We have extended each Diamond Model by integrating an additional Relationship Layer to illustrate the contextual relationships between these features. For instance, the infrastructure used by Actor A for Traffic Distribution Services (TDS) is linked to Actor C’s infrastructure through a “purchased from” relationship. Consequently, when performing analytical pivoting, analysts should account for this relationship and not attribute all infostealers distributed via the TDS infrastructure solely to Actor A’s capabilities. Similarly, the victims of those infostealers should not be automatically classified as Actor A’s victims.

Another illustrative case involves the relationship between the victims of Actor A and Actor D. Actor D obtained initial access through a transaction with Actor A, denoted by the “purchased from” relationship within the Relationship Layer. This relationship offers analysts crucial context, allowing them to avoid attributing the tools used in the initial access phase to Actor D’s capabilities.

The Relationship Layer also elucidates the connections between adversaries. On the graph, we denote these inter-adversary connections as “commercial relationships,” providing additional context that aids in actor profiling. This extension understanding allows analysts to discern the nature of interactions between threat actors, facilitating more accurate and insightful profiling efforts.

Integrating the Relationship Layer with the Cyber Kill Chain

The Cyber Kill Chain framework serves as a structured approach to analyzing cyberattacks, enabling security professionals to break down intrusions into discrete, sequential stages — from initial reconnaissance to actions on objectives. By organizing attacks in this manner, analysts can pinpoint attacker behaviors, anticipate adversary actions and develop targeted mitigation strategies, significantly enhancing overall threat intelligence.

Integrating the extended Diamond Model into the Cyber Kill Chain framework offers a more comprehensive view of compartmentalized campaigns by illustrating how each adversary contributes to different stages of an attack. This combined perspective enhances understanding by mapping out the intricate web of relationships among multiple threat actors, thereby providing a clearer picture of how resources, capabilities and infrastructure are shared or transferred throughout an attack’s lifecycle. Figure 5 illustrates the integration of the extended Diamond Model with the Cyber Kill Chain using the Actor A–D example.

The example above demonstrates the distinct roles that each adversary assumes at various stages of the kill chain in a hypothetical campaign. In this scenario, the victim is initially compromised by an infostealer, which Actor A acquired from Actor B, and subsequently faces a ransomware attack orchestrated by Actor D. To further enrich the analysis, we highlight the “handover” relationship between Actor C and Actor A, emphasizing its significance as both actors’ activities manifest within the targeted environment. This approach provides a more comprehensive view of the attack flow, allowing for a deeper understanding of how adversarial interactions and transitions unfold throughout the campaign.

This enriched view not only clarifies attacker tradecraft but also bolsters actor profiling and attribution efforts. By aligning specific tactics and resources with the threat groups deploying them, analysts can more accurately trace operations back to their origins. This approach also provides insights into adversary motivations, allowing defenders to tailor their response strategies effectively. For instance, understanding that an IAB is financially motivated might suggest a lower immediate threat to certain targets, while recognizing that access has been sold to a state-sponsored actor would escalate the priority of the threat response.

Identifying compartmentalized attacks

Identifying compartmentalization within the scope of an intrusion typically involves trying to determine where positive control is transferred between adversaries either pre- or post-compromise. It is essential to identify compartmentalization as this will significantly impact the overall understanding of the adversar(ies) and the capabilities available to them. Indicators of collaboration among distinct threat actors can vary significantly depending on the context and the phase of activity, and these can be categorized based on whether the actions occur before or after the compromise of a system or environment. It is important to note that while there are several examples listed in the following sections, compartmentalization can and does look different across intrusions and these are by no means comprehensive. Likewise, while the below elements are useful indicators that an analyst should investigate possible transfer of access, they are not necessarily indicative that a handoff has occurred. As more of these elements are encountered and evidence collected, an analyst may be able to strengthen their assessment that compartmentalization has occurred.

Pre-compromise

In the early stages of an intrusion, compartmentalization can often be identified by observing how tooling has been sourced, how malicious content is being delivered to potential victims and the initial/early execution flow of malicious components in the case that code execution has been achieved.

This stage may also be completely independent. In situations where a state-sponsored group is tasked with espionage operation, it may pass on the access to a ransomware group, making the state-sponsored group an IAG. It is not guaranteed that the ransomware group is aware of the nature of its IAG, but just by doing its activity it will fulfill the state-sponsored group objective of making incident analysis and attribution complex.

Shared tooling

While many of the indicators associated with the use of tooling are often identified in later stages of an intrusion, we characterize this compartmentalization as occurring pre-compromise as development and procurement activities must generally occur before the campaign is launched. It is often useful to identify if the threat actor procured tooling from third parties. This may involve identifying key characteristics of the malicious components being analyzed and searching/monitoring hacking forums and darknet marketplaces (DNMs) to identify whether a seller is advertising a capability matching the one used in the intrusion. Likewise, malware that has historically been used by one threat actor may be transferred to another threat actor, either on purpose or inadvertently in the case of source code leaks. In either case, analysis of contextual information surrounding the use of the tooling can help analysts identify when the tooling doesn’t match the threat actors’ known TTPs.

Shared delivery infrastructure

In the case of email-based delivery, analysis of the infrastructure used to send malicious emails, the content of the message, and the infrastructure used for hosting and delivering payloads may indicate that delivery has been outsourced in some capacity. Likewise, in the case of malvertising campaigns, analysis of the ad campaigns, traffic distribution infrastructure and gating methodologies may suggest the same. In many cases the infrastructure used is often observed distributing multiple distinct, otherwise unrelated malware families over a short period of time as the threat actor operating the delivery infrastructure may conduct business with multiple entities at any point in time. Analyzing activity associated with this infrastructure before, during, and after the intrusion may inform the analysis of whether compartmentalization has occurred.

Shared droppers/downloaders

When analyzing an intrusion, there is often a point at which code execution is achieved. This may be the point in which a malicious script-based component is delivered and executed by a victim. In many cases, these function as downloaders and are solely responsible for retrieving or extracting and executing follow-on payloads that allow an adversary to expand their ability to operate in an environment. Analysis of the dropper/downloader mechanisms used may identify cases where the same mechanism is used to deliver unrelated threats over time, indicating that delivery may have been outsourced. We have categorized this activity as “pre-compromise” to further differentiate it from handoffs that may occur later in the intrusion, once persistence has been achieved, etc.

Post-compromise 

In addition to the aforementioned types of compartmentalization that often occur early in an intrusion, there is another set of handoffs that may occur once an adversary has achieved compromise. These are typically used to transfer control of access from one party to another and may be performed for a variety of purposes, as described in our previous blog. This activity can often be identified by analyzing handoff behaviors, the motivation of the threat actors involved, and monitoring for typical indicators that an IAB is involved.

Handoff behaviors

In some cases, information can be collected related to the amount of time that has occurred between an IAB obtaining access to the environment, and the beginning of follow-on activity. This may include an IAB gaining access, establishing persistence, collecting information from the environment and exfiltrating that to adversary C2. Following this initial activity, the infection may conduct very little malicious activity aside from periodic C2 polling occurring on the system for an extended period of time. After an extended period, additional malicious components may be delivered that establish new C2 connections and new activity may be observed. This type of pattern is indicative that a handoff of access may have occurred and should be investigated further. Similarly, analysis of the behaviors of the threat actor before and after this handoff may strengthen or weaken an assessment as completely different TTPs may be observed between the threat actors involved.

The race to domain admin

Another set of characteristics that may strengthen an assessment that handoff has occurred is by analyzing the series of actions taken once access has been gained. In the case of FIA, for instance, we often observe repeatable processes for attempting to gain domain administrator access as quickly as possible. This makes the access more lucrative for the IAG and more seamlessly enables the deployment of additional malware components, such as ransomware. An FIA group may quickly progress from initial access to domain administrator access in a short period of time with little to no effort spent on identifying high-value targets in the environment. Once domain administrator access has been gained the intrusion activity may stop while the threat actor attempts to monetize that access and facilitate handoff to the threat actor who ultimately purchases it. SIA groups on the other hand, may take a more steady and stealth oriented approach, to conduct reconnaissance and proliferate throughout the victim enterprise without being detected. In many instances an SIA group might conduct initial exfiltration of restricted data, before handing access off to the secondary threat actor.

Dark web tracking

Monitoring hacking forums and darknet marketplaces can be extremely valuable for identifying when an IAB is involved in an intrusion. Since FIA brokers are primarily focused on achieving the maximum profit as quickly as possible, they will often post advertisements for access to environments that they have achieved. In many cases these advertisements include generic information about the company/organization involved such as size (number of employees), rounded financial information based on publicly available sources such as quarterly filings, industry, etc. Locating advertisements that match the profile of the victim of an intrusion can strengthen an assessment that an IAB is involved and provide additional intelligence collection avenues that may be pursued further to collect additional information about the IAB involved, who they typically work with, and more.

C2 analysis

Analysis of C2 infrastructure involved throughout the intrusion presents another opportunity for identifying any handoffs that have occurred. As previously mentioned, in some cases the handoff is performed by delivering a new payload and establishing a new C2 connection with another threat actor’s infrastructure. In the case of frameworks, analysis of the server logs can provide additional information where the same server has been used to administer multiple victims. Administrative panels used to manage malware infections are often useful for informing analysis related to the nature of threat actors involved and the business models they are working within. Some admin panels may be explicitly built for the purpose of facilitating handoffs, RaaS and C2aaS platforms being examples of this.

Case Study: ToyMaker

During the course of performing threat hunting and incident response, Cisco Talos sometimes encounters scenarios where compartmentalized operations involve multiple attackers participating in the same attack kill chain. Using the ToyMaker campaign as an example, we demonstrate how we identified the participation of various attackers during our investigation and utilized the extended Diamond Model to clarify the distinct activities and roles of these attackers across different stages of the attack kill chain.

APT, Cactus or FIA? 

Talos investigated the ToyMaker campaign in 2023. The attackers conducted operations for six consecutive days, during which they compromised a server of the victim organization, exfiltrated credentials and deployed the proprietary LAGTOY backdoor. We consider this “first wave” post-compromise activity. Since we did not find any common financial crime malware in this attack, and the attackers used their proprietary tools and C2 infrastructures, we considered the possibility that it might be the activity of an APT group. However, the TTPs and indicators of compromise (IOCs) did not overlap with previously observed campaigns, so we did not attribute the campaign early in the investigation.

However, during the investigation, Talos identified TTPs and hands-on-keyboard activity consistent with Cactus ransomware activity appearing in the victim’s network almost 3 weeks after the initial compromise. We consider this the “second wave” of malicious activity. After using various tools for lateral movement within the network, the attackers launched a ransomware attack within a matter of days. At this point, Talos started a more in-depth investigation, including exploring the connections and disparities between the ransomware attack and the initial access. We formulated several hypotheses at this point:

• Hypothesis A: Both the initial compromise and subsequent activities were conducted by Cactus ransomware, and therefore LAGTOY might be a tool exclusively used by Cactus.
• Hypothesis B: The initial access might have been carried out by a different attack group and have no relation to Cactus’s activities.
• Hypothesis C: The initial access might have been carried out by a different attack group, but there is some connection to Cactus.

Hypothesis A was the most intuitive assumption at the beginning of the investigation. However, as the investigation progressed, Talos made the following observations:

• Initial access activity removed the created user account before the end of activity: Before the actions following the initial access activity ceased, the attackers deleted the user account they had created.
• Differences in TTPs: Variations in TTPs were observed between the two attack traces, either through differing approaches to similar TTPs or entirely distinct TTPs. For instance, the operators conducting initial access relied on PuTTY for credential exfiltration, while the secondary activity employed Secure Shell (SSH) alongside other tools. In terms of file packaging, the second wave utilized parameters that preserved file paths (-spf), a method not seen in the first set of actions. Furthermore, the second wave predominantly involved off-the-shelf tools, whereas the first wave featured bespoke tools unique to the attackers.
• No tools and IoC overlapping: We found no common tools and shared infrastructure between the two waves of malicious activity.
• No use of LAGTOY: We observed that although the first wave deployed LAGTOY, it was never used throughout the course of the intrusion. Why would a threat actor deploy a custom-made malware immediately after initial compromise but never use it? It is possible that LAGTOY might have been designated as a last resort access channel, if the attackers’ access through compromised credentials was blocked. It is also likely that LAGTOY wasn’t used because it was never meant to be used in the intrusion going forward, i.e. LAGTOY was deployed by a distinct Initial Access Threat Actor, different from Cactus. Furthermore, we had no evidence of Cactus developing and using LAGOTY in their operations. Our assessment was now leaning towards Hypothesis B: The initial access might have been carried out by a different attack group and have no relation to Cactus’s activities.
• Time gap between the first and second waves: There was approximately a gap of 3 weeks with no observed attack activity before the second wave of attacks began. For big-game double extortion threat actors, speed is paramount. A successful initial compromise must be capitalized by performing rapid recon, endpoint and file enumeration, data exfiltration and ransomware deployment. For such operations that tend to focus on a blitz, it is abnormal to see a gap of weeks with lulls in activity. Therefore, we must consider the possibility that there may have been a handoff of access between two distinct threat actors conducting the first and second wave of attacks. Furthermore, a gap of 3 weeks suggests that the first threat actor did not have a secondary actor already aligned/available for immediate access; they had to find Cactus. Talos’ assessment was now leaning towards Hypothesis C: The initial access might have been carried out by a different attack group, but there is some connection to Cactus.

• Shared credentials: Within the first six days of activity, we observed credential harvesting and exfiltration. Three weeks later, the second wave began which we attributed to Cactus. This second wave was kickstarted using the same credentials stolen in the first wave. Therefore, there was indeed a connection between the two waves of activity: the shared stolen credentials.

The totality of patterns and abnormalities collected during our research shifted our assessments toward the hypothesis involving an initial access group, leading us to reanalyze the LAGTOY tool used in the first wave of activities conducted post compromise. We discovered that this backdoor is the same as HOLERUN, which Mandiant reported as being used by UNC961. This finding, combined with the previous public reporting and observations, allows us to confirm that the attack involved two distinct attacker groups (ToyMaker aka UNC961, and Cactus).

Mandiant’s public reporting noted that UNC961’s intrusion activities often preceded the deployment of Maze and Egregor ransomware by distinct follow-on actors. While Egregor is considered a direct successor to Maze, there is no evidence indicating any connection to Cactus. In the campaign we investigated, Cactus used compromised credentials from the first wave of attacks on the victim’s machine. Based on these findings, Talos assesses with high confidence that ToyMaker provided initial access for the Cactus group. Given ToyMaker’s focus on financial gain and their history of selling initial access to ransomware groups, we classify them as an FIA group.

Leveraging the extended Diamond Model for further analysis and defensive strategy

Building on the analysis and context provided, the extended Diamond Model allows Talos to effectively represent the threat actors involved in this campaign, highlighting the intricacies of their collaborative relationships. In Figure 6, we utilize two distinct diamonds to symbolize the ToyMaker group and the Cactus ransomware group. The Relationship Layer plays a crucial role in delineating the connections between ToyMaker’s victims and Cactus’ victims, as well as illustrating the initial access provider-receiver dynamics.

These relationships underscore the importance of carefully reviewing and investigating any capabilities and infrastructure indicators identified on the victim’s machine associated with either threat actor. For example, the hosts infected by LAGTOY are potentially at risk of ransomware attacks, or tools discovered on Cactus’ victims might be from LAGTOY or potentially other initial access groups. 

We can also leverage the relationship information provided by the extended Diamond Model to identify additional potential victims of Cactus ransomware by hunting for hosts infected with the LAGTOY backdoor. Similarly, examining victims associated with ToyMaker can lead to discovering other ransomware attack victims. For defenders, this relationship data is crucial for prioritizing detection efforts and ensuring that the activities of ToyMaker and other initial access groups are not overlooked, as they can serve as precursors to further attacks. By maintaining vigilance and focusing on these initial access indicators, security teams can proactively identify and mitigate threats before they escalate into full-blown ransomware incidents.

Cisco Talos Blog – ​Read More