Finding the Sweet Spot: How Donut Extortion Group Targets Achilles’ Heel in Cybersecurity

Every organization faces an ongoing battle against cybersecurity threats. Attackers are constantly looking for vulnerabilities to exploit, seeking out the Achilles’ heel that can give them access to your systems and data.  

In this blog post, we’ll explore a real-world use case where a cybersecurity extortion group successfully found and exploited our customer’s Achilles’ heels. We’ll take a closer look at the attack and our investigation and provide recommendations to help you protect your organization from similar threats. 

Achilles’ Heel in Cybersecurity

Cybersecurity is an ongoing battle between attackers and network administrators. Attackers are constantly searching for the Achilles’ heel, looking for unpatched networks, unpatched servers, outdated operating systems, users without multi-factor authentication, etc. Network administrators require ongoing attention to identify and remediate all these security gaps. 

Investigation Following the D0nut’s Crumbs 

In this use case, a customer was the target of a ransomware attack by the D0nut extortion group. The group sent an email informing the customer about the attack and claiming to have exfiltrated data and encrypted servers. This group has been known to deploy ransomware in double extortion attacks on enterprises. 

Double extortion ransomware is a type of cyberattack in which threat actors exfiltrate a victim’s sensitive data in addition to encrypting it, giving the criminal additional leverage to collect ransom payments. A typical ransomware attack will only encrypt a victim’s data. 

Before contacting us, the customer started an investigation and revealed multiple suspected compromised machines, user accounts and encrypted servers.  

So we had suspected compromised machines and users to begin the investigation with an estimated timeframe. Then we started looking into the recent behavior of those users and machines.  

To make it easier to follow, let’s add some names first: 

• Compromised machines: Machine1, Machine2, Machine3 
• Compromised users: USER_A, SVC_USER1, SVC_USER2 (initially, only SVC_USER1 was known by the customer to be compromised) 
• Encrypted servers: Server1, Server2, Server3 

At the beginning of the investigation, we noticed that Machine1 stood out, with an authentication spike that included 1,500 destinations in a short time window. All the authentications were by three users, USER_A, SVC_USER1 and SVC_USER2.
 
Since two of the three users weren’t on the customer’s suspected users list, we immediately notified them and recommended they block their access. This led the customer’s IR team to find that USER_A had downloaded a malicious file to Machine1, making it the attacker’s official starting point.  

Another crumb helping the investigation was that Machine1 is one of a Virtual Desktop Infrastructure (VDI) machines group, which are internet-facing machines. This makes them more exposed to remote cybersecurity attacks.  

Looking at authentications to all the VDIs, we found attempts blocked by MFA to all the VDI machines except for Machine1. Why? Because Machine1 was the only one not protected by Silverfort’s MFA policy. As a result of human error, the customer missed Machine1 in the protection policy, making it their Achilles’ heel for threat actors to find. 

Consequently, the attacker stole SVC_USER1 and SVC_USER2 credentials from the Machine1 machine and used them to move laterally and compromise two additional machines: Machine2 and Machine3.  

With our domain authentications visibility, we could see all the abnormal authentications to and from Machine1, Machine2 and Machine3, including authentications to the encrypted servers Server1, Server2 and Server3 on the day before the email was sent. 

Combining all the findings, we were able to build a more comprehensive picture of the attack surface to follow D0nut’s actions.  

How D0nut group gained access to Machine1, which wasn’t protected by MFA, and moved laterally across the environment.  

Additional Security Gaps Exploited

Threat actors often search for loopholes to exploit when looking for a remote way into a network. The D0nut extortion group found multiple loopholes in their attack campaign. First, they gained access to the organization’s network through an unprotected internet-facing machine. Second, the attacker needed a user account to steal, so they targeted a contractor’s account, USER_A.  
Contractors are typically less monitored and protected than regular employees and do not fall under most protection conventions, making them more vulnerable to compromise.  

Moreover, USER_A was a shadow admin used excessively in the attack, further exploiting a security gap that enabled the attacker to stay hidden. As a result, the attacker successfully stole the credentials of SVC_USER1 and SVC_USER2, both service accounts that allowed the attacker to move laterally and compromise more machines. 

Service accounts and shadow admins, while different from each other, share a common vulnerability: they are highly privileged user accounts that are difficult to monitor and protect. As a result, they are attractive targets for attackers seeking access to critical systems and data.  

Despite the risks, the customer in this use case had not implemented any protection for these accounts. This oversight allowed the attackers to leverage both types of accounts to move laterally within the network, furthering their attack and increasing the damage they could cause. With Silverfort’s comprehensive visibility, this breach could have been prevented, and the customer’s systems and data could have remained secure. 

All these security gaps are common Achilles’ heels for organizations, so we highly recommend implementing protection on them. 

Silverfort Recommendations – Anyone Can Have a D0nut

This showcases just one extortion group looking for an Achilles’ heel in your network – but unfortunately, there are many more. Arm up and protect your organization by implementing Silverfort’s recommendations. 

1. Protecting Internet-Facing Machines with MFA

With Silverfort’s MFA policy, you can protect internet-facing machines and servers from malicious connections. One unprotected machine is all it takes for the attacker to get in, as they found the one missing from the protection group due to a human error. In this customer’s use case, we saw how Silverfort was able to block the attacker’s attempts to compromise protected internet-facing machines. 

2. Using Your SIEM to Monitor Denied MFAs 

Silverfort allows the implementation of multi-factor authentication (MFA) on domain identities, enabling you to have protection and visibility for these identities. You can send the logs Silverfort produces to your SIEM (Security Information and Event Management), which enables another layer of protection.  

In this use case, if denied MFA was monitored, the customer would have been able to notice the attempted attack on all VDIs and catch it sooner. 

3. Protecting Service Accounts 

Silverfort automatically discovers service accounts, learns their behavior, and recommends smart policies. Silverfort’s policies enable the implementation of access management on service accounts, allowing only necessary access and blocking the rest.  

In addition, Silverfort can alert or block real-time access attempts that deviate from the expected behavior of each service account based on Silverfort’s AI risk engine. This allows service accounts to be restricted to their intended purpose with a Zero Trust approach and enforce an automated response to any unauthorized access attempt without modifying the service accounts or rotating their passwords. In this use case, if SVC_USER1 and SVC_USER2 were restricted, the credential theft would have had little to no impact. 

4. Shadow Admins Mitigations 

Silverfort automatically identifies shadow admin accounts that should be reviewed to determine whether their privileges are legitimate. 

Silverfort enables visibility on all Active Directory (AD) and AD entities, including shadow admins. You can have a direct view of why a user is considered a shadow admin and the changes required to have it fixed. If an account’s permissions can’t be changed to avoid the threat, the account can be protected with MFA. 

In this use case, if USER_A wasn’t a shadow admin, it would have been more restricted, making it more difficult for the attacker to move laterally under the radar. 

Don(u)t Know Your Achilles Heel?

In this blog post, I only detailed the relevant security gaps used in this attack path, but many more security gaps can easily turn into your Achilles’ heel. If these gaps apply to your network as well, don’t hesitate – fix them quickly as this could be you. If you currently don’t have the means to protect these gaps, you can request a demo from Silverfort here.