Let the Dominos Fall! SOC and IR Metrics for ROI

Vendors are scrambling to compare MTTD metrics laid out in the latest MITRE Engenuity ATT&CK® Evaluations. But this analysis is reductive, ignoring the fact that in cybersecurity, there are far more metrics that matter.
Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
John Bradshaw
Sr. Director, Technical Marketing
Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
25
Jun 2024

One of the most enjoyable discussions (and debates) I engage in is the topic of Security Operations Center (SOC) and Incident Response (IR) metrics to measure and validate an organization’s Return on Investment (ROI). The debate part comes in when I hear vendor experts talking about “the only” SOC metrics that matter, and only list the two most well-known, while completely ignoring metrics that have a direct causal relationship.

In this blog, I will discuss what I believe are the SOC/IR metrics that matter, how each one has a direct impact on the others, and why organizations should ensure they are working towards the goal of why these metrics are measured in the first place: Reduction of Risk and Costs.

Reduction of Risk and Costs

Every security solution and process an organization puts in place should reduce the organization’s risk of a breach, exposure by an insider threat, or loss of productivity. How an organization realizes net benefits can be in several ways:

  • Improved efficiencies can result in SOC/IR staff focusing on other areas such as advanced threat hunting rather than churning through alerts on their security consoles. It may also help organizations dealing with the lack of skilled security staff by using Artificial Intelligence (AI) and automated processes.
  • A well-oiled SOC/IR team that has greatly reduced or even eliminated mundane tasks attracts, motivates, and retains talent resulting in reduced hiring and training costs.
  • The direct impact of a breach such as a ransomware attack can be devastating. According to the 2024 Data Breach Investigations Report by Verizon, MGM Resorts International reported the ALPHV ransomware cost the company approximately $100 million[1].
  • Failure to take appropriate steps to protect the organization can result in regulatory fines; and if an organization has, or is considering, purchasing Cyber Insurance, can result in declined coverage or increased premiums.

How does an organization demonstrate they are taking proactive measures to prevent breaches? That is where it's important to understand the nine (yes, nine) key metrics, and how each one directly influences the others, play their roles.

Metrics in the Incident Response Timeline

Let’s start with a review of the key steps in the Incident Response Timeline:

Seven of the nine key metrics are in the IR timeline, while two of the metrics occur before you ever have an incident. They occur in the Pre-Detection Stage.

Pre-Detection stage metrics are:

  • Preventions Per Intrusion Attempt (PPIA)
  • False Positive Reduction Rate (FPRR)

Next is the Detect and Investigate stage, there are three metrics to consider:

  • Mean Time to Detection (MTTD)
  • Mean Time to Triage (MTTT)
  • Mean Time to Understanding (MTTU)

This is followed by the Remediation stage, there are two metrics here:

  • Mean Time to Containment (MTTC)
  • Mean Time to Remediation / Recovery (MTTR)

Finally, there is the Risk Reduction stage, there are two metrics:

  • Mean Time to Advice (MTTA)
  • Mean Time to Implementation (MTTI)

Pre-Detection Stage

Preventions Per Intrusion Attempt

PPIA is defined as stopping any intrusion attempt at the earliest possible stage. Your network Intrusion Prevention System (IPS) blocks vulnerability exploits, your e-mail security solution intercepts and removes messages with malicious attachments or links, your egress firewall blocks unauthorized login attempts, etc. The adversary doesn’t get beyond Step 1 in the attack life cycle.

This metric is the first domino. Every organization should strive to improve on this metric every day. Why? For every intrusion attempt you stop right out of the gate, you eliminate the actions for every other metric. There is no incident to detect, triage, investigate, remediate, or analyze post-incident for ways to improve your security posture.

When I think about PPIA, I always remember back to a discussion with a former mentor, Tim Crothers, who discussed the benefits of focusing on Prevention Failure Detection.

The concept is that as you layer your security defenses, your PPIA moves ever closer to 100% (no one has ever reached 100%). This narrows the field of fire for adversaries to breach into your organization. This is where novel, unknown, and permuted threats live and breathe. This is where solutions utilizing Unsupervised Machine Learning excel in raising anomalous alerts – indications of potential compromise involving one of these threats. Unsupervised ML also raises alerts on anomalous activity generated by known threats and can raise detections before many signature-based solutions. Most organizations struggle to find strong permutations of known threats, insider threats, supply chain attacks, attacks utilizing n-day and 0-day exploits. Moving PPIA ever closer to 100% also frees your team up for conducting threat hunting activities – utilizing components of your SOC that collect and store telemetry to query for potential compromises based on hypothesis the team raises. It also significantly reduces the alerts your team must triage and investigate – solving many of the issues outlined at the start of this paper.

False Positive Reduction Rate

Before we discuss FPRR, I should clarify how I define False Positives (FPs). Many define FPs as an alert that is in error (i.e.: your EDR alerts on malware that turns out to be AV signature files). While that is a FP, I extend the definition to include any alert that did not require triage / investigation and distracts the SOC/IR team (meaning they conducted some level of triage / investigation).

This metric is the second domino. Why is this metric important? Every alert your team exerts time and effort on that is a non-issue distracts them from alerts that matter. One of the major issues that has resonated in the security industry for decades is that SOCs are inundated with alerts and cannot clear the backlog. When it comes to PPIA + FPRR, I have seen analysts spend time investigating alerts that were blocked out of the gate while their screen continued to fill up with more. You must focus on Prevention Failure Detection to get ahead of the backlog.

Detect and Investigate Stages

Mean Time to Detection

MTTD, or “Dwell Time”, has decreased dramatically over the past 12 years. From well over a year to 16 days in 2023[2]. MTTD is measured from the earliest possible point you could detect the intrusion to the moment you actually detect it.

This third domino is important because the longer an adversary remains undetected, the more the odds increase they will complete their mission objective. It also makes the tasks of triage and investigation more difficult as analysts must piece together more activity and adversaries may be erasing evidence along the way – or your storage retention does not cover the breach timeline.

Many solutions focusing solely on MTTD can actually create the very problem SOCs are looking to solve.  That is, they generate so much alerting that they flood the console, email, or text messaging app causing an unmanageable queue of alerts (this is the problem XDR solutions were designed to resolve by focusing on incidents rather than alerts).

Mean Time to Triage

MTTT involves SOCs that utilize Level 1 (aka Triage) analysts to render an “escalate / do not escalate” alert verdict accurately. Accuracy is important because Triage Analysts typically are staff new to cyber security (recent grad / certification) and may over escalate (afraid to miss something important) or under escalate (not recognize signs of a successful breach). Because of this, a small MTTT does not always equate to successful handling of incidents.

This metric is important because keeping your senior staff focused on progressing incidents in a timely manner (and not expending time on false positives) should reduce stress and required headcount.

Mean Time to Understanding

MTTU deals with understanding the complete nature of the incident being investigated. This is different than MTTT which only deals with whether the issue merits escalation to senior analysts. It is then up to the senior analysts to determine the scope of the incident, and if you are a follower of my UPSET Investigation Framework, you know understanding the full scope involves:

U = All compromised accounts

P = Persistence Mechanisms used

S = All systems involved (organization, adversary, and intermediaries)

E = Endgame (or mission objective)

T = Techniques, Tactics, Procedures (TTPs) utilized by the adversary

MTTU is important because this information is critical before any containment or remediation actions are taken. Leave a stone unturned, and you alert the adversary that you are onto them and possibly fail to close an avenue of access.

Remediation Stages

Mean Time to Containment

MTTC deals with neutralizing the threat. You may not have kicked the adversary out, but you have halted their progress to their mission objective and ability to inflict further damage. This may be through use of isolation capabilities, termination of malicious processes, or firewall blocks.

MTTC is important, especially with ransomware attacks where every second counts. Faster containment responses can result in reduced / eliminated disruption to business operations or loss of data.

Mean Time to Remediation / Recovery

The full scope of the incident is understood, the adversary has been halted in their tracks, no malicious processes are running on any systems in your organization. Now is the time to put things back to right. MTTR deals with the time involved in restoring business operations to pre-incident stage. It means all remnants of changes made by the adversary (persistence, account alterations, programs installed, etc.) are removed; all disrupted systems are restored to operations (i.e.: ransomware encrypted systems are recovered from backups / snapshots), compromised user accounts are reset, etc.

MTTR is important because it informs senior management of how fast the organization can recover from an incident. Disaster Recovery and Business Continuity plans play a major role in improving this score.

Risk Reduction Stages

Mean Time to Advice

After the dust has settled from the incident, the job is not done. MTTA deals with identifying and assessing the specific areas (vulnerabilities, misconfigurations, lack of security controls) that permitted the adversary to advance to the point where detection occurred (and any actions beyond). The SOC and IR teams should then compile a list of recommendations to present to management to improve the security posture of the organization so the same attack path cannot be used.

Mean Time to Implement

Once recommendations are delivered to management, how long does it take to implement them? MTTI tracks this timeline because none of it matters if you don’t fix the holes that led to the breach.

Nine Dominos

There are the nine dominos of SOC / IR metrics I recommend helping organizations know if they are on the right track to reduce risk, costs and improve morale / retention of the security teams. You may not wish to track all nine, but understanding how each metric impacts the others can provide visibility into why you are not seeing expected improvements when you implement a new security solution or change processes.

Improving prevention and reducing false positives can make huge positive impacts on your incident response timeline. Utilizing solutions that get you to resolution quicker allows the team to focus on recommendations and risk reduction strategies.

Whichever metrics you choose to track, just be sure the dominos fall in your favor.

References

[1] 2024 Verizon Data Breach Investigations Report, p83

[2] Mandiant M-Trends 2023

Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
John Bradshaw
Sr. Director, Technical Marketing

More in this series

No items found.

Blog

/

AI

/

December 5, 2025

Simplifying Cross Domain Investigations

Default blog imageDefault blog image

Cross-domain gaps mean cross-domain attacks  

Organizations are built on increasingly complex digital estates. Nowadays, the average IT ecosystem spans across a large web of interconnected domains like identity, network, cloud, and email.  

While these domain-specific technologies may boost business efficiency and scalability, they also provide blind spots where attackers can shelter undetected. Threat actors can slip past defenses because security teams often use different detection tools in each realm of their digital infrastructure. Adversaries will purposefully execute different stages of an attack across different domains, ensuring no single tool picks up too many traces of their malicious activity. Identifying and investigating this type of threat, known as a cross-domain attack, requires mastery in event correlation.  

For example, one isolated network scan detected on your network may seem harmless at first glance. Only when it is stitched together with a rare O365 login, a new email rule and anomalous remote connections to an S3 bucket in AWS does it begin to manifest as an actual intrusion.  

However, there are a whole host of other challenges that arise with detecting this type of attack. Accessing those alerts in the respective on-premise network, SaaS and IaaS environments, understanding them and identifying which ones are related to each other takes significant experience, skill and time. And time favours no one but the threat actor.  

Anatomy of a cross domain attack
Figure 1: Anatomy of a cross domain attack

Diverse domains and empty grocery shelves

In April 2025, the UK faced a throwback to pandemic-era shortages when the supermarket giant Marks & Spencer (M&S) was crippled by a cyberattack, leaving empty shelves across its stores and massive disruptions to its online service.  

The threat actors, a group called Scattered Spider, exploited multiple layers of the organization’s digital infrastructure. Notably, the group were able to bypass the perimeter not by exploiting a technical vulnerability, but an identity. They used social engineering tactics to impersonate an M&S employee and successfully request a password reset.  

Once authenticated on the network, they accessed the Windows domain controller and exfiltrated the NTDS.dit file – a critical file containing hashed passwords for all users in the domain. After cracking those hashes offline, they returned to the network with escalated privileges and set their sights on the M&S cloud infrastructure. They then launched the encryption payload on the company’s ESXi virtual machines.

To wrap up, the threat actors used a compromised employee’s email account to send an “abuse-filled” email to the M&S CEO, bragging about the hack and demanding payment. This was possibly more of a psychological attack on the CEO than a technically integral part of the cyber kill chain. However, it revealed yet another one of M&S’s domains had been compromised.  

In summary, the group’s attack spanned four different domains:

Identity: Social engineering user impersonation

Network: Exfiltration of NTDS.dit file

Cloud: Ransomware deployed on ESXI VMs

Email: Compromise of user account to contact the CEO

Adept at exploiting nuance

This year alone, several high-profile cyber-attacks have been attributed to the same group, Scattered Spider, including the hacks on Victoria’s Secret, Adidas, Hawaiian Airlines, WestJet, the Co-op and Harrods. It begs the question, what has made this group so successful?

In the M&S attack, they showcased their advanced proficiency in social engineering, which they use to bypass identity controls and gain initial access. They demonstrated deep knowledge of cloud environments by deploying ransomware onto virtualised infrastructure. However, this does not exemplify a cookie-cutter template of attack methods that brings them success every time.

According to CISA, Scattered Spider typically use a remarkable variety of TTPs (tactics, techniques and procedures) across multiple domains to carry out their campaigns. From leveraging legitimate remote access tools in the network, to manipulating AWS EC2 cloud instances or spoofing email domains, the list of TTPs used by the group is eye-wateringly long. Additionally, the group reportedly evades detection by “frequently modifying their TTPs”.  

If only they had better intentions. Any security director would be proud of a red team who not only has this depth and breadth of domain-centric knowledge but is also consistently upskilling.  

Yet, staying ahead of adversaries who seamlessly move across domains and fluently exploit every system they encounter is just one of many hurdles security teams face when investigating cross-domain attacks.  

Resource-heavy investigations

There was a significant delay in time to detection of the M&S intrusion. News outlet BleepingComputer reported that attackers infiltrated the M&S network as early as February 2025. They maintained persistence for weeks before launching the attack in late April 2025, indicating that early signs of compromise were missed or not correlated across domains.

While it’s unclear exactly why M&S missed the initial intrusion, one can speculate about the unique challenges investigating cross-domain attacks present.  

Challenges of cross-domain investigation

First and foremost, correlation work is arduous because the string of malicious behaviour doesn’t always stem from the same device.  

A hypothetical attack could begin with an O365 credential creating a new email rule. Weeks later, that same credential authenticates anomalously on two different devices. One device downloads an .exe file from a strange website, while the other starts beaconing every minute to a rare external IP address that no one else in the organisation has ever connected to. A month later, a third device downloads 1.3 GiB of data from a recently spun up S3 bucket and gradually transfers a similar amount of data to that same rare IP.

Amid a sea of alerts and false positives, connecting the dots of a malicious attack like this takes time and meticulous correlation. Factor in the nuanced telemetry data related to each domain and things get even more complex.  

An analyst who specialises in network security may not understand the unique logging formats or API calls in the cloud environment. Perhaps they are proficient in protecting the Windows Active Directory but are unfamiliar with cloud IAM.  

Cloud is also an inherently more difficult domain to investigate. With 89% of organizations now operating in multi-cloud environments time must be spent collecting logs, snapshots and access records. Coupled with the threat of an ephemeral asset disappearing, the risk of missing a threat is high. These are some of the reasons why research shows that 65% of organisations spend 3-5 extra days investigating cloud incidents.  

Helpdesk teams handling user requests over the phone require a different set of skills altogether. Imagine a threat actor posing as an employee and articulately requesting an urgent password reset or a temporary MFA deactivation. The junior Helpdesk agent— unfamiliar with the exception criteria, eager to help and feeling pressure from the persuasive manipulator at the end of the phoneline—could easily fall victim to this type of social engineering.  

Empowering analysts through intelligent automation

Even the most skilled analysts can’t manually piece together every strand of malicious activity stretching across domains. But skill alone isn’t enough. The biggest hurdle in investigating these attacks often comes down to whether the team have the time, context, and connected visibility needed to see the full picture.

Many organizations attempt to bridge the gap by stitching together a patchwork of security tools. One platform for email, another for endpoint, another for cloud, and so on. But this fragmentation reinforces the very silos that cross-domain attacks exploit. Logs must be exported, normalized, and parsed across tools a process that is not only error-prone but slow. By the time indicators are correlated, the intrusion has often already deepened.

That’s why automation and AI are becoming indispensable. The future of cross-domain investigation lies in systems that can:

  • Automatically correlate activity across domains and data sources, turning disjointed alerts into a single, interpretable incident.
  • Generate and test hypotheses autonomously, identifying likely chains of malicious behaviour without waiting for human triage.
  • Explain findings in human terms, reducing the knowledge gap between junior and senior analysts.
  • Operate within and across hybrid environments, from on-premise networks to SaaS, IaaS, and identity systems.

This is where Darktrace transforms alerting and investigations. Darktrace’s Cyber AI Analyst automates the process of correlation, hypothesis testing, and narrative building, not just within one domain, but across many. An anomalous O365 login, a new S3 bucket, and a suspicious beaconing host are stitched together automatically, surfacing the story behind the alerts rather than leaving it buried in telemetry.

How threat activity is correlated in Cyber AI Analyst
Figure 2: How threat activity is correlated in Cyber AI Analyst

By analyzing events from disparate tools and sources, AI Analyst constructs a unified timeline of activity showing what happened, how it spread, and where to focus next. For analysts, it means investigation time is measured in minutes, not days. For security leaders, it means every member of the SOC, regardless of experience, can contribute meaningfully to a cross-domain response.

Figure 3: Correlation showcasing cross domains (SaaS and IaaS) in Cyber AI Analyst

Until now, forensic investigations were slow, manual, and reserved for only the largest organizations with specialized DFIR expertise. Darktrace / Forensic Acquisition & Investigation changes that by leveraging the scale and elasticity of the cloud itself to automate the entire investigation process. From capturing full disk and memory at detection to reconstructing attacker timelines in minutes, the solution turns fragmented workflows into streamlined investigations available to every team.

What once took days now takes minutes. Now, forensic investigations in the cloud are faster, more scalable, and finally accessible to every security team, no matter their size or expertise.

Continue reading
About the author
Benjamin Druttman
Cyber Security AI Technical Instructor

Blog

/

Network

/

December 5, 2025

Atomic Stealer: Darktrace’s Investigation of a Growing macOS Threat

Default blog imageDefault blog image

The Rise of Infostealers Targeting Apple Users

In a threat landscape historically dominated by Windows-based threats, the growing prevalence of macOS information stealers targeting Apple users is becoming an increasing concern for organizations. Infostealers are a type of malware designed to steal sensitive data from target devices, often enabling attackers to extract credentials and financial data for resale or further exploitation. Recent research identified infostealers as the largest category of new macOS malware, with an alarming 101% increase in the last two quarters of 2024 [1].

What is Atomic Stealer?

Among the most notorious is Atomic macOS Stealer (or AMOS), first observed in 2023. Known for its sophisticated build, Atomic Stealer can exfiltrate a wide range of sensitive information including keychain passwords, cookies, browser data and cryptocurrency wallets.

Originally marketed on Telegram as a Malware-as-a-Service (MaaS), Atomic Stealer has become a popular malware due to its ability to target macOS. Like other MaaS offerings, it includes services like a web panel for managing victims, with reports indicating a monthly subscription cost between $1,000 and $3,000 [2]. Although Atomic Stealer’s original intent was as a standalone MaaS product, its unique capability to target macOS has led to new variants emerging at an unprecedented rate

Even more concerning, the most recent variant has now added a backdoor for persistent access [3]. This backdoor presents a significant threat, as Atomic Stealer campaigns are believed to have reached an around 120 countries. The addition of a backdoor elevates Atomic Stealer to the rare category of backdoor deployments potentially at a global scale, something only previously attributed to nation-state threat actors [4].

This level of sophistication is also evident in the wide range of distribution methods observed since its first appearance; including fake application installers, malvertising and terminal command execution via the ClickFix technique. The ClickFix technique is particularly noteworthy: once the malware is downloaded onto the device, users are presented with what appears to be a legitimate macOS installation prompt. In reality, however, the user unknowingly initiates the execution of the Atomic Stealer malware.

This blog will focus on activity observed across multiple Darktrace customer environments where Atomic Stealer was detected, along with several indicators of compromise (IoCs). These included devices that successfully connected to endpoints associated with Atomic Stealer, those that attempted but failed to establish connections, and instances suggesting potential data exfiltration activity.

Darktrace’s Coverage of Atomic Stealer

As this evolving threat began to spread across the internet in June 2025, Darktrace observed a surge in Atomic Stealer activity, impacting numerous customers in 24 different countries worldwide. Initially, most of the cases detected in 2025 affected Darktrace customers within the Europe, Middle East, and Africa (EMEA) region. However, later in the year, Darktrace began to observe a more even distribution of cases across EMEA, the Americas (AMS), and Asia Pacific (APAC). While multiple sectors were impacted by Atomic Stealer, Darktrace customers in the education sector were the most affected, particularly during September and October, coinciding with the return to school and universities after summer closures. This spike likely reflects increased device usage as students returned and reconnected potentially compromised devices to school and campus environments.

Starting from June, Darktrace detected multiple events of suspicious HTTP activity to external connections to IPs in the range 45.94.47.0/24. Investigation by Darktrace’s Threat Research team revealed several distinct patterns ; HTTP POST requests to the URI “/contact”, identical cURL User Agents and HTTP requests to “/api/tasks/[base64 string]” URIs.

Within one observed customer’s environment in July, Darktrace detected two devices making repeated initiated HTTP connections over port 80 to IPs within the same range. The first, Device A, was observed making GET requests to the IP 45.94.47[.]158 (AS60781 LeaseWeb Netherlands B.V.), targeting the URI “/api/tasks/[base64string]” using the “curl/8.7.2” user agent. This pattern suggested beaconing activity and triggered the ‘Beaconing Activity to External Rare' model alert in Darktrace / NETWORK, with Device A’s Model Event Log showing repeated connections. The IP associated with this endpoint has since been flagged by multiple open-source intelligence (OSINT) vendors as being associated with Atomic Stealer [5].

Darktrace’s detection of Device A showing repeated connections to the suspicious IP address over port 80, indicative of beaconing behavior.
Figure 1: Darktrace’s detection of Device A showing repeated connections to the suspicious IP address over port 80, indicative of beaconing behavior.

Darktrace’s Cyber AI Analyst subsequently launched an investigation into the activity, uncovering that the GET requests resulted in a ‘503 Service Unavailable’ response, likely indicating that the server was temporarily unable to process the requests.

Cyber AI Analyst Incident showing the 503 Status Code, indicating that the server was temporarily unavailable.
Figure 2: Cyber AI Analyst Incident showing the 503 Status Code, indicating that the server was temporarily unavailable.

This unusual activity prompted Darktrace’s Autonomous Response capability to recommend several blocking actions for the device in an attempt to stop the malicious activity. However, as the customer’s Autonomous Response configuration was set to Human Confirmation Mode, Darktrace was unable to automatically apply these actions. Had Autonomous Response been fully enabled, these connections would have been blocked, likely rendering the malware ineffective at reaching its malicious command-and-control (C2) infrastructure.

Autonomous Response’s suggested actions to block suspicious connectivity on Device A in the first customer environment.
Figure 3: Autonomous Response’s suggested actions to block suspicious connectivity on Device A in the first customer environment.

In another customer environment in August, Darktrace detected similar IoCs, noting a device establishing a connection to the external endpoint 45.94.47[.]149 (ASN: AS57043 Hostkey B.V.). Shortly after the initial connections, the device was observed making repeated requests to the same destination IP, targeting the URI /api/tasks/[base64string] with the user agent curl/8.7.1, again suggesting beaconing activity. Further analysis of this endpoint after the fact revealed links to Atomic Stealer in OSINT reporting [6].

Cyber AI Analyst investigation finding a suspicious URI and user agent for the offending device within the second customer environment.
Figure 4:  Cyber AI Analyst investigation finding a suspicious URI and user agent for the offending device within the second customer environment.

As with the customer in the first case, had Darktrace’s Autonomous Response been properly configured on the customer’s network, it would have been able to block connectivity with 45.94.47[.]149. Instead, Darktrace suggested recommended actions that the customer’s security team could manually apply to help contain the attack.

Autonomous Response’s suggested actions to block suspicious connectivity to IP 45.94.47[.]149 for the device within the second customer environment.
Figure 5: Autonomous Response’s suggested actions to block suspicious connectivity to IP 45.94.47[.]149 for the device within the second customer environment.

In the most recent case observed by Darktrace in October, multiple instances of Atomic Stealer activity were seen across one customer’s environment, with two devices communicating with Atomic Stealer C2 infrastructure. During this incident, one device was observed making an HTTP GET request to the IP 45.94.47[.]149 (ASN: AS60781 LeaseWeb Netherlands B.V.). These connections targeted the URI /api/tasks/[base64string, using the user agent curl/8.7.1.  

Shortly afterward, the device began making repeated connections over port 80 to the same external IP, 45.94.47[.]149. This activity continued for several days until Darktrace detected the device making an HTTP POST request to a new IP, 45.94.47[.]211 (ASN: AS57043 Hostkey B.V.), this time targeting the URI /contact, again using the curl/8.7.1 user agent. Similar to the other IPs observed in beaconing activity, OSINT reporting later linked this one to information stealer C2 infrastructure [7].

Darktrace’s detection of suspicious beaconing connectivity with the suspicious IP 45.94.47.211.
Figure 6: Darktrace’s detection of suspicious beaconing connectivity with the suspicious IP 45.94.47.211.

Further investigation into this customer’s network revealed that similar activity had been occurring as far back as August, when Darktrace detected data exfiltration on a second device. Cyber AI Analyst identified this device making a single HTTP POST connection to the external IP 45.94.47[.]144, another IP with malicious links [8], using the user agent curl/8.7.1 and targeting the URI /contact.

Cyber AI Analyst investigation finding a successful POST request to 45.94.47[.]144 for the device within the third customer environment.
Figure 7:  Cyber AI Analyst investigation finding a successful POST request to 45.94.47[.]144 for the device within the third customer environment.

A deeper investigation into the technical details within the POST request revealed the presence of a file named “out.zip”, suggesting potential data exfiltration.

Advanced Search log in Darktrace / NETWORK showing “out.zip”, indicating potential data exfiltration for a device within the third customer environment.
Figure 8: Advanced Search log in Darktrace / NETWORK showing “out.zip”, indicating potential data exfiltration for a device within the third customer environment.

Similarly, in another environment, Darktrace was able to collect a packet capture (PCAP) of suspected Atomic Stealer activity, which revealed potential indicators of data exfiltration. This included the presence of the “out.zip” file being exfiltrated via an HTTP POST request, along with data that appeared to contain details of an Electrum cryptocurrency wallet and possible passwords.

Read more about Darktrace’s full deep dive into a similar case where this tactic was leveraged by malware as part of an elaborate cryptocurrency scam.

PCAP of an HTTP POST request showing the file “out.zip” and details of Electrum Cryptocurrency wallet.
Figure 9: PCAP of an HTTP POST request showing the file “out.zip” and details of Electrum Cryptocurrency wallet.

Although recent research attributes the “out.zip” file to a new variant named SHAMOS [9], it has also been linked more broadly to Atomic Stealer [10]. Indeed, this is not the first instance where Darktrace has seen the “out.zip” file in cases involving Atomic Stealer either. In a previous blog detailing a social engineering campaign that targeted cryptocurrency users with the Realst Stealer, the macOS version of Realst contained a binary that was found to be Atomic Stealer, and similar IoCs were identified, including artifacts of data exfiltration such as the “out.zip” file.

Conclusion

The rapid rise of Atomic Stealer and its ability to target macOS marks a significant shift in the threat landscape and should serve as a clear warning to Apple users who were traditionally perceived as more secure in a malware ecosystem historically dominated by Windows-based threats.

Atomic Stealer’s growing popularity is now challenging that perception, expanding its reach and accessibility to a broader range of victims. Even more concerning is the emergence of a variant embedded with a backdoor, which is likely to increase its appeal among a diverse range of threat actors. Darktrace’s ability to adapt and detect new tactics and IoCs in real time delivers the proactive defense organizations need to protect themselves against emerging threats before they can gain momentum.

Credit to Isabel Evans (Cyber Analyst), Dylan Hinz (Associate Principal Cyber Analyst)
Edited by Ryan Traill (Analyst Content Lead)

Appendices

References

1.     https://www.scworld.com/news/infostealers-targeting-macos-jumped-by-101-in-second-half-of-2024

2.     https://www.kandji.io/blog/amos-macos-stealer-analysis

3.     https://www.broadcom.com/support/security-center/protection-bulletin/amos-stealer-adds-backdoor

4.     https://moonlock.com/amos-backdoor-persistent-access

5.     https://www.virustotal.com/gui/ip-address/45.94.47.158/detection

6.     https://www.trendmicro.com/en_us/research/25/i/an-mdr-analysis-of-the-amos-stealer-campaign.html

7.     https://www.virustotal.com/gui/ip-address/45.94.47.211/detection

8.     https://www.virustotal.com/gui/ip-address/45.94.47.144/detection

9.     https://securityaffairs.com/181441/malware/over-300-entities-hit-by-a-variant-of-atomic-macos-stealer-in-recent-campaign.html

10.   https://binhex.ninja/malware-analysis-blogs/amos-stealer-atomic-stealer-malware.html

Darktrace Model Detections

Darktrace / NETWORK

  • Compromise / Beaconing Activity To External Rare
  • Compromise / HTTP Beaconing to New IP
  • Compromise / HTTP Beaconing to Rare Destination
  • Anomalous Connection / New User Agent to IP Without Hostname
  • Device / New User Agent
  • Compromise / Sustained TCP Beaconing Activity To Rare Endpoint
  • Compromise / Slow Beaconing Activity To External Rare
  • Anomalous Connection / Posting HTTP to IP Without Hostname
  • Compromise / Quick and Regular Windows HTTP Beaconing

Autonomous Response

  • Antigena / Network / Significant Anomaly::Antigena Alerts Over Time Block
  • Antigena / Network / Significant Anomaly::Antigena Significant Anomaly from Client Block
  • Antigena / Network / External Threat::Antigena Suspicious Activity Block

List of IoCs

  • 45.94.47[.]149 – IP – Atomic C2 Endpoint
  • 45.94.47[.]144 – IP – Atomic C2 Endpoint
  • 45.94.47[.]158 – IP – Atomic C2 Endpoint
  • 45.94.47[.]211 – IP – Atomic C2 Endpoint
  • out.zip - File Output – Possible ZIP file for Data Exfiltration

MITRE ATT&CK Mapping:

Tactic –Technique – Sub-Technique

Execution - T1204.002 - User Execution: Malicious File

Credential Access - T1555.001 - Credentials from Password Stores: Keychain

Credential Access - T1555.003 - Credentials from Web Browsers

Command & Control - T1071 - Application Layer Protocol

Exfiltration - T1041 - Exfiltration Over C2 Channel

Continue reading
About the author
Isabel Evans
Cyber Analyst
あなたのデータ × DarktraceのAI
唯一無二のDarktrace AIで、ネットワークセキュリティを次の次元へ