Blog
/
/
July 9, 2019

Insights on Shamoon 3 Data-Wiping Malware

Gain insights into Shamoon 3 and learn how to protect your organization from its destructive capabilities.
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
Max Heinemeyer
Global Field CISO
Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
09
Jul 2019

Responsible for some of the “most damaging cyber-attacks in history” since 2012, the Shamoon malware wipes compromised hard drives and overwrites key system processes, intending to render infected machines unusable. During a trial period in the network of a global company, Darktrace observed a Shamoon-powered cyber-attack on December 10, 2018 — when several Middle Eastern firms were impacted by a new variant of the malware.

While there has been detailed reporting on the malware files and wiper modules that these latest Shamoon attacks employed, the complete cyber kill chain involved remains poorly understood, while the intrusions that led to the malware’s eventual “detonation” last December has not received nearly as much coverage. As a consequence, this blog post will focus on the insights that Darktrace’s cyber AI generated regarding (a) the activity of the infected devices during the “detonation” and (b) the indicators of compromise that most likely represent lateral movement activity during the weeks prior.

A high-level overview of major events leading up to the detonation on December 10th.

In the following, we will dive into that timeline more deeply in reverse chronological order, going back in time to trace the origins of the attack. Let’s begin with zero hour.

December 10: 42 devices “detonate”

A bird's-eye perspective of how Darktrace identified the alerts in December 2018.

What immediately strikes the analyst’s eye is the fact that a large accumulation of alerts, indicated by the red rectangle above, took place on December 10, followed by complete network silence over the subsequent four days.

These highlighted alerts represent Darktrace’s detection of unusual network scans on remote port 445 that were conducted by 42 infected devices. These devices proceeded to scan more machines — none of which were among those already infected. Such behavior indicates that the compromised devices started scanning and were wiped independently from each other, instead of conducting worming-style activity during the detonation of the malware. The initial scanning device started its scan at 12:56 p.m. UTC, while the last scanning device started its scan at 2:07 p.m. UTC.

Not only was this activity readily apparent from the bird’s-eye perspective shown above, the detonating devices also created the highest-priority Darktrace alerts over a several day period: “Device / Network Scan” and “Device / Expanded Network Scan”:

Moreover, when investigating “Devices — Overall Score,” the detonating devices rank as the most critical assets for the time period December 8–11:

Darktrace AI generated all of the above alerts because they represented significant anomalies from the normal ‘pattern of life’ that the AI had learned for each user and device on the company’s network. Crucially, none of the alerts were the product of predefined ‘rules and signatures’ — the mechanism that conventional security tools rely on to detect cyber-threats. Rather, the AI revealed the activity because the scans were unusual for the devices given their precise nature and timing, demonstrating the necessity of the such a nuanced approach in catching elusive threats like Shamoon. Of further importance is that the company’s network consists of around 15,000 devices, meaning that a rules-based approach without the ability to prioritize the most serious threats would have drowned out the Shamoon alerts in noise.

Now that we’ve seen how cyber AI sounded the alarms during the detonation itself, let’s investigate the various indicators of suspicious lateral movement that precipitated the events of December 10. Most of this activity happened in brief bursts, each of which could have been spotted and remediated if Darktrace had been closely monitored.

November 19: Unusual Remote Powershell Usage (WinRM)

One such burst of unusual activity occurred on November 19, when Darktrace detected 14 devices — desktops and servers alike — that all successfully used the WinRM protocol. None of these devices had previously used WinRM, which is also unusual for the organization’s environment as a whole. Conversely, Remote PowerShell is quite often abused in intrusions during lateral movement. The devices involved did not classify as traditional administrative devices, making their use of WinRM even more suspicious.

Note the clustering of the WinRM activity as indicated by the timestamp on the left.

October 29–31: Scanning, Unusual PsExec & RDP Brute Forcing

Another burst of likely lateral movement occurred between October 29 and 31, when two servers were seen using PsExec in an unusual fashion. No PsExec activity had been observed in the network before or after these detections, prompting Darktrace to flag the behavior. One of the servers conducted an ICMP Ping sweep shortly before the lateral movement. Not only did both servers start using PsExec on the same day, they also used SMBv1 — which, again, was very unusual for the network.

Most legitimate administrative activity involving PsExec these days uses SMBv2. The graphic below shows several Darktrace alerts on one of the involved servers — take note of the chronology of detections at the bottom of the graphic. This clearly reads like an attacker’s diary: ICMP scan, SMBv1 usage, and unusual PsExec usage, followed by new remote service controls. This server was among the top five highest ranking devices during the analyzed time period and was easy to identify.

Following the PsExec use, the servers also started an anomalous amount of remote services via the srvsvc and svcctl pipes over SMB. They did so by starting services on remote devices with which they usually did not communicate — using SMBv1, of course. Some of the attempted communication failed due to access violation and access permission errors. Both are often seen during malicious lateral movement.

Additional context around the SMBv1 and remote srvsvc pipe activity. Note the access failure.

Thanks to Darktrace’s deep packet inspection, we can see exactly what happened on the application layer. Darktrace highlights any unusual or new activity in italics below the connections — we can easily see that the SMB activity is not only unusual because of SMBv1 being used, but also because this server had never used this type of SMB activity remotely to those particular destinations before. We can also observe remote access to the winreg pipe — likely indicating more lateral movement and persistence mechanisms being established.

The other server conducted some targeted address scanning on the network on October 29, employing typical lateral movement ports 135, 139 and 445:

Another device was observed to conduct RDP brute forcing on October 29 around the same time as the above address scan. The desktop made an unusual amount of RDP connections to another internal server.

A clear plateau in increased internal connections (blue) can be seen. Every colored dot on top represents an RDP brute force detection. This was again a clear-cut detection not drowned in other noise — these were the only RDP brute force detections for a several-month monitoring time window.

October 9–11: Unusual Credential Usage

Darktrace identifies the unusual use of credentials — for instance, if administrative credentials are used on client device on which they are not commonly used. This might indicate lateral movement where service accounts or local admin accounts have been compromised.

Darktrace identified another cluster of activity that is likely representing lateral movement, this time involving unusual credential usage. Between October 9 and 11, Darktrace identified 17 cases of new administrative credentials being used on client devices. While new administrative credentials were being used from time to time on devices as part of normal administrative activity, this strong clustering of unusual admin credential usage was outstanding. Additionally, Darktrace also identified the source of some of the credentials being used as unusual.

Conclusion

Having observed a live Shamoon infection within Darktrace, there are a few key takeaways. While the actual detonation on December 10 was automated, the intrusion that built up to it was most likely manual. The fact that all detonating devices started their malicious activity roughly at the same time — without scanning each other — indicates that the payload went off based on a trigger like a scheduled task. This is in line with other reporting on Shamoon 3.

In the weeks leading up to December 10, there were various significant signs of lateral movement that occurred in disparate bursts — indicating a ‘low-and-slow’ manual intrusion.

The adversaries used classic lateral movement techniques like RDP brute forcing, PsExec, WinRM usage, and the abuse of stolen administrative credentials.

While the organization in question had a robust security posture, an attacker only needs to exploit one vulnerability to bring down an entire system. During the lifecycle of the attack, the Darktrace Enterprise Immune System identified the threatening activity in real time and provided numerous suggested actions that could have prevented the Shamoon attack at various stages. However, human action was not taken, while the organization had yet to activate Antigena, Darktrace’s autonomous response solution, which could have acted in the security team’s stead.

Despite having limited scope during the trial period, the Enterprise Immune System was able to detect the lateral movement and detonation of the payload, which was indicative of the malicious Shamoon virus activity. A junior analyst could have easily identified the activity, as high-severity alerts were consistently generated, and the likely infected devices were at the top of the suspicious devices list.

Darktrace Antigena would have prevented the movement responsible for the spread of the virus, while also sending high-severity alerts to the security team to investigate the activity. Even the scanning on port 445 from the detonating devices would have been shut down, as it presented a significant deviation from the known behavior of all scanning devices, which would have further limited the virus’s spread, and ultimately, spared the company and its devices from attack.

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
Max Heinemeyer
Global Field CISO

More in this series

No items found.

Blog

/

Identity

/

July 3, 2025

Top Eight Threats to SaaS Security and How to Combat Them

Default blog imageDefault blog image

The latest on the identity security landscape

Following the mass adoption of remote and hybrid working patterns, more critical data than ever resides in cloud applications – from Salesforce and Google Workspace, to Box, Dropbox, and Microsoft 365.

On average, a single organization uses 130 different Software-as-a-Service (SaaS) applications, and 45% of organizations reported experiencing a cybersecurity incident through a SaaS application in the last year.

As SaaS applications look set to remain an integral part of the digital estate, organizations are being forced to rethink how they protect their users and data in this area.

What is SaaS security?

SaaS security is the protection of cloud applications. It includes securing the apps themselves as well as the user identities that engage with them.

Below are the top eight threats that target SaaS security and user identities.

1.  Account Takeover (ATO)

Attackers gain unauthorized access to a user’s SaaS or cloud account by stealing credentials through phishing, brute-force attacks, or credential stuffing. Once inside, they can exfiltrate data, send malicious emails, or escalate privileges to maintain persistent access.

2. Privilege escalation

Cybercriminals exploit misconfigurations, weak access controls, or vulnerabilities to increase their access privileges within a SaaS or cloud environment. Gaining admin or superuser rights allows attackers to disable security settings, create new accounts, or move laterally across the organization.

3. Lateral movement

Once inside a network or SaaS platform, attackers move between accounts, applications, and cloud workloads to expand their foot- hold. Compromised OAuth tokens, session hijacking, or exploited API connections can enable adversaries to escalate access and exfiltrate sensitive data.

4. Multi-Factor Authentication (MFA) bypass and session hijacking

Threat actors bypass MFA through SIM swapping, push bombing, or exploiting session cookies. By stealing an active authentication session, they can access SaaS environments without needing the original credentials or MFA approval.

5. OAuth token abuse

Attackers exploit OAuth authentication mechanisms by stealing or abusing tokens that grant persistent access to SaaS applications. This allows them to maintain access even if the original user resets their password, making detection and mitigation difficult.

6. Insider threats

Malicious or negligent insiders misuse their legitimate access to SaaS applications or cloud platforms to leak data, alter configurations, or assist external attackers. Over-provisioned accounts and poor access control policies make it easier for insiders to exploit SaaS environments.

7. Application Programming Interface (API)-based attacks

SaaS applications rely on APIs for integration and automation, but attackers exploit insecure endpoints, excessive permissions, and unmonitored API calls to gain unauthorized access. API abuse can lead to data exfiltration, privilege escalation, and service disruption.

8. Business Email Compromise (BEC) via SaaS

Adversaries compromise SaaS-based email platforms (e.g., Microsoft 365 and Google Workspace) to send phishing emails, conduct invoice fraud, or steal sensitive communications. BEC attacks often involve financial fraud or data theft by impersonating executives or suppliers.

BEC heavily uses social engineering techniques, tailoring messages for a specific audience and context. And with the growing use of generative AI by threat actors, BEC is becoming even harder to detect. By adding ingenuity and machine speed, generative AI tools give threat actors the ability to create more personalized, targeted, and convincing attacks at scale.

Protecting against these SaaS threats

Traditionally, security leaders relied on tools that were focused on the attack, reliant on threat intelligence, and confined to a single area of the digital estate.

However, these tools have limitations, and often prove inadequate for contemporary situations, environments, and threats. For example, they may lack advanced threat detection, have limited visibility and scope, and struggle to integrate with other tools and infrastructure, especially cloud platforms.

AI-powered SaaS security stays ahead of the threat landscape

New, more effective approaches involve AI-powered defense solutions that understand the digital business, reveal subtle deviations that indicate cyber-threats, and action autonomous, targeted responses.

[related-resource]

Continue reading
About the author
Carlos Gray
Senior Product Marketing Manager, Email

Blog

/

/

July 2, 2025

Pre-CVE Threat Detection: 10 Examples Identifying Malicious Activity Prior to Public Disclosure of a Vulnerability

Default blog imageDefault blog image

Vulnerabilities are weaknesses in a system that can be exploited by malicious actors to gain unauthorized access or to disrupt normal operations. Common Vulnerabilities and Exposures (or CVEs) are a list of publicly disclosed cybersecurity vulnerabilities that can be tracked and mitigated by the security community.

When a vulnerability is discovered, the standard practice is to report it to the vendor or the responsible organization, allowing them to develop and distribute a patch or fix before the details are made public. This is known as responsible disclosure.

With a record-breaking 40,000 CVEs reported for 2024 and a predicted higher number for 2025 by the Forum for Incident Response and Security Teams (FIRST) [1], anomaly-detection is essential for identifying these potential risks. The gap between exploitation of a zero-day and disclosure of the vulnerability can sometimes be considerable, and retroactively attempting to identify successful exploitation on your network can be challenging, particularly if taking a signature-based approach.

Detecting threats without relying on CVE disclosure

Abnormal behaviors in networks or systems, such as unusual login patterns or data transfers, can indicate attempted cyber-attacks, insider threats, or compromised systems. Since Darktrace does not rely on rules or signatures, it can detect malicious activity that is anomalous even without full context of the specific device or asset in question.

For example, during the Fortinet exploitation late last year, the Darktrace Threat Research team were investigating a different Fortinet vulnerability, namely CVE 2024-23113, for exploitation when Mandiant released a security advisory around CVE 2024-47575, which aligned closely with Darktrace’s findings.

Retrospective analysis like this is used by Darktrace’s threat researchers to better understand detections across the threat landscape and to add additional context.

Below are ten examples from the past year where Darktrace detected malicious activity days or even weeks before a vulnerability was publicly disclosed.

ten examples from the past year where Darktrace detected malicious activity days or even weeks before a vulnerability was publicly disclosed.

Trends in pre-cve exploitation

Often, the disclosure of an exploited vulnerability can be off the back of an incident response investigation related to a compromise by an advanced threat actor using a zero-day. Once the vulnerability is registered and publicly disclosed as having been exploited, it can kick off a race between the attacker and defender: attack vs patch.

Nation-state actors, highly skilled with significant resources, are known to use a range of capabilities to achieve their target, including zero-day use. Often, pre-CVE activity is “low and slow”, last for months with high operational security. After CVE disclosure, the barriers to entry lower, allowing less skilled and less resourced attackers, like some ransomware gangs, to exploit the vulnerability and cause harm. This is why two distinct types of activity are often seen: pre and post disclosure of an exploited vulnerability.

Darktrace saw this consistent story line play out during several of the Fortinet and PAN OS threat actor campaigns highlighted above last year, where nation-state actors were seen exploiting vulnerabilities first, followed by ransomware gangs impacting organizations [2].

The same applies with the recent SAP Netweaver exploitations being tied to a China based threat actor earlier this spring with subsequent ransomware incidents being observed [3].

Autonomous Response

Anomaly-based detection offers the benefit of identifying malicious activity even before a CVE is disclosed; however, security teams still need to quickly contain and isolate the activity.

For example, during the Ivanti chaining exploitation in the early part of 2025, a customer had Darktrace’s Autonomous Response capability enabled on their network. As a result, Darktrace was able to contain the compromise and shut down any ongoing suspicious connectivity by blocking internal connections and enforcing a “pattern of life” on the affected device.

This pre-CVE detection and response by Darktrace occurred 11 days before any public disclosure, demonstrating the value of an anomaly-based approach.

In some cases, customers have even reported that Darktrace stopped malicious exploitation of devices several days before a public disclosure of a vulnerability.

For example, During the ConnectWise exploitation, a customer informed the team that Darktrace had detected malicious software being installed via remote access. Upon further investigation, four servers were found to be impacted, while Autonomous Response had blocked outbound connections and enforced patterns of life on impacted devices.

Conclusion

By continuously analyzing behavioral patterns, systems can spot unusual activities and patterns from users, systems, and networks to detect anomalies that could signify a security breach.

Through ongoing monitoring and learning from these behaviors, anomaly-based security systems can detect threats that traditional signature-based solutions might miss, while also providing detailed insights into threat tactics, techniques, and procedures (TTPs). This type of behavioral intelligence supports pre-CVE detection, allows for a more adaptive security posture, and enables systems to evolve with the ever-changing threat landscape.

Credit to Nathaniel Jones (VP, Security & AI Strategy, Field CISO), Emma Fougler (Global Threat Research Operations Lead), Ryan Traill (Analyst Content Lead)

References and further reading:

  1. https://www.first.org/blog/20250607-Vulnerability-Forecast-for-2025
  2. https://cloud.google.com/blog/topics/threat-intelligence/fortimanager-zero-day-exploitation-cve-2024-47575
  3. https://thehackernews.com/2025/05/china-linked-hackers-exploit-sap-and.html

Related Darktrace blogs:

*Self-reported by customer, confirmed afterwards.

**Updated January 2024 blog now reflects current findings

Continue reading
About the author
Your data. Our AI.
Elevate your network security with Darktrace AI