Blog
/
Network
/
October 26, 2022

Strategies to Prolong Quantum Ransomware Attacks

Learn more about how Darktrace combats Quantum Ransomware changing strategy for cyberattacks. Explore the power of AI-driven network cyber security!
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
Nicole Wong
Cyber Security Analyst
Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
26
Oct 2022

Within science and engineering, the word ‘quantum’ may spark associations with speed and capability, referencing a superior computer that can perform tasks a classical computer cannot. In cyber security, some may recognize ‘quantum’ in relation to cryptography or, more recently, as the name of a new ransomware group, which achieved network-wide encryption a mere four hours after an initial infection.   

Although this group now has a reputation for carrying out fast and efficient attacks, speed is not their only tactic. In August 2022, Darktrace detected a Quantum Ransomware incident where attackers remained in the victim’s network for almost a month after the initial signs of infection, before detonating ransomware. This was a stark difference to previously reported attacks, demonstrating that as motives change, so do threat actors’ strategies. 

The Quantum Group

Quantum was first identified in August 2021 as the latest of several rebrands of MountLocker ransomware [1]. As part of this rebrand, the extension ‘.quantum’ is appended to filenames that are encrypted and the associated ransom notes are named ‘README_TO_DECRYPT.html’ [2].  

From April 2022, media coverage of this group has increased following a DFIR report detailing an attack that progressed from initial access to domain-wide ransomware within four hours [3]. To put this into perspective, the global median dwell time for ransomware in 2020 and 2021 is 5 days [4]. In the case of Quantum, threat actors gained direct keyboard access to devices merely 2 hours after initial infection. The ransomware was staged on the domain controller around an hour and a half later, and executed 12 minutes after that.   

Quantum’s behaviour bears similarities to other groups, possibly due to their history and recruitment. Several members of the disbanded Conti ransomware group are reported to have joined the Quantum and BumbleBee operations. Security researchers have also identified similarities in the payloads and C2 infrastructure used by these groups [5 & 6].  Notably, these are the IcedID initial payload and Cobalt Strike C2 beacon used in this attack. Darktrace has also observed and prevented IcedID and Cobalt Strike activity from BumbleBee across several customer environments.

The Attack

From 11th July 2022, a device suspected to be patient zero made repeated DNS queries for external hosts that appear to be associated with IcedID C2 traffic [7 & 8]. In several reported cases [9 & 10], this banking trojan is delivered through a phishing email containing a malicious attachment that loads an IcedID DLL. As Darktrace was not deployed in the prospect’s email environment, there was no visibility of the initial access vector, however an example of a phishing campaign containing this payload is presented below. It is also possible that the device was already infected prior to joining the network. 

Figure 1- An example phishing email used to distribute IcedID. If configured, Darktrace/Email would be able to detect that the email was sent from an anomalous sender, was part of a fake reply chain, and had a suspicious attachment containing compressed content of unusual mime type [11].    

 

Figure 2- The DNS queries to endpoints associated with IcedID C2 servers, taken from the infected device’s event log.  Additional DNS queries made to other IcedID C2 servers are in the list of IOCs in the appendices.  The repeated DNS queries are indicative of beaconing.


It was not until 22nd July that activity was seen which indicated the attack had progressed to the next stage of the kill chain. This contrasts the previously seen attacks where the progression to Cobalt Strike C2 beaconing and reconnaissance and lateral movement occurred within 2 hours of the initial infection [12 & 13]. In this case, patient zero initiated numerous unusual connections to other internal devices using a compromised account, connections that were indicative of reconnaissance using built-in Windows utilities:

·      DNS queries for hostnames in the network

·      SMB writes to IPC$ shares of those hostnames queried, binding to the srvsvc named pipe to enumerate things such as SMB shares and services on a device, client access permissions on network shares and users logged in to a remote session

·      DCE-RPC connections to the endpoint mapper service, which enables identification of the ports assigned to a particular RPC service

These connections were initiated using an existing credential on the device and just like the dwelling time, differed from previously reported Quantum group attacks where discovery actions were spawned and performed automatically by the IcedID process [14]. Figure 3 depicts how Darktrace detected that this activity deviated from the device’s normal behaviour.  

Figure 3- This figure displays the spike in active internal connections initiated by patient zero. The coloured dots represent the Darktrace models that were breached, detecting this unusual reconnaissance and lateral movement activity.

Four days later, on the 26th of July, patient zero performed SMB writes of DLL and MSI executables to the C$ shares of internal devices including domain controllers, using a privileged credential not previously seen on the patient zero device. The deviation from normal behaviour that this represents is also displayed in Figure 3. Throughout this activity, patient zero made DNS queries for the external Cobalt Strike C2 server shown in Figure 4. Cobalt Strike has often been seen as a secondary payload delivered via IcedID, due to IcedID’s ability to evade detection and deploy large scale campaigns [15]. It is likely that reconnaissance and lateral movement was performed under instructions received by the Cobalt Strike C2 server.   

Figure 4- This figure is taken from Darktrace’s Advanced Search interface, showing a DNS query for a Cobalt Strike C2 server occurring during SMB writes of .dll files and DCE-RPC requests to the epmapper service, demonstrating reconnaissance and lateral movement.


The SMB writes to domain controllers and usage of a new account suggests that by this stage, the attacker had achieved domain dominance. The attacker also appeared to have had hands-on access to the network via a console; the repetition of the paths ‘programdata\v1.dll’ and ‘ProgramData\v1.dll’, in lower and title case respectively, suggests they were entered manually.  

These DLL files likely contained a copy of the malware that injects into legitimate processes such as winlogon, to perform commands that call out to C2 servers [16]. Shortly after the file transfers, the affected domain controllers were also seen beaconing to external endpoints (‘sezijiru[.]com’ and ‘gedabuyisi[.]com’) that OSINT tools have associated with these DLL files [17 & 18]. Moreover, these SSL connections were made using a default client fingerprint for Cobalt Strike [19], which is consistent with the initial delivery method. To illustrate the beaconing nature of these connections, Figure 5 displays the 4.3 million daily SSL connections to one of the C2 servers during the attack. The 100,000 most recent connections were initiated by 11 unique source IP addresses alone.

Figure 5- The Advanced Search interface, querying for external SSL connections from devices in the network to an external host that appears to be a Cobalt Strike C2 server. 4.3 million connections were made over 8 days, even after the ransomware was eventually detonated on 2022-08-03.


Shortly after the writes, the attack progressed to the penultimate stage. The next day, on the 27th of July, the attackers moved to achieve their first objective: data exfiltration. Data exfiltration is not always performed by the Quantum ransomware gang. Researchers have noted discrepancies between claims of data theft made in their ransom notes versus the lack of data seen leaving the network, although this may have been missed due to covert exfiltration via a Cobalt Strike beacon [20]. 

In contrast, this attack displayed several gigabytes of data leaving internal devices including servers that had previously beaconed to Cobalt Strike C2 servers. This data was transferred overtly via FTP, however the attacker still attempted to conceal the activity using ephemeral ports (FTP in EPSV mode). FTP is an effective method for attackers to exfiltrate large files as it is easy to use, organizations often neglect to monitor outbound usage, and it can be shipped through ports that will not be blocked by traditional firewalls [21].   

Figure 6 displays an example of the FTP data transfer to attacker-controlled infrastructure, in which the destination share appears structured to identify the organization that the data was stolen from, suggesting there may be other victim organizations’ data stored. This suggests that data exfiltration was an intended outcome of this attack. 

Figure 6- This figure is from Darktrace’s Advanced Search interface, displaying some of the data transferred from an internal device to the attacker’s FTP server.

 
Data was continuously exfiltrated until a week later when the final stage of the attack was achieved and Quantum ransomware was detonated. Darktrace detected the following unusual SMB activity initiated from the attacker-created account that is a hallmark for ransomware (see Figure 7 for example log):

·      Symmetric SMB Read to Write ratio, indicative of active encryption

·      Sustained MIME type conversion of files, with the extension ‘.quantum’ appended to filenames

·      SMB writes of a ransom note ‘README_TO_DECRYPT.html’ (see Figure 8 for an example note)

Figure 7- The Model Breach Event Log for a device that had files encrypted by Quantum ransomware, showing the reads and writes of files with ‘.quantum’ appended to encrypted files, and an HTML ransom note left where the files were encrypted.

 

Figure 8- An example of the ransom note left by the Quantum gang, this one is taken from open-sources [22].


The example in Figure 8 mentions that the attacker also possessed large volumes of victim data.  It is likely that the gigabytes of data exfiltrated over FTP were leveraged as blackmail to further extort the victim organization for payment.  

Darktrace Coverage

 

Figure 9- Timeline of Quantum ransomware incident


If Darktrace/Email was deployed in the prospect’s environment, the initial payload (if delivered through a phishing email) could have been detected and held from the recipient’s inbox. Although DETECT identified anomalous network behaviour at each stage of the attack, since the incident occurred during a trial phase where Darktrace could only detect but not respond, the attack was able to progress through the kill chain. If RESPOND/Network had been configured in the targeted environment, the unusual connections observed during the initial access, C2, reconnaissance and lateral movement stages of the attack could have been blocked. This would have prevented the attackers from delivering the later stage payloads and eventual ransomware into the target network.

It is often thought that a properly implemented backup strategy is sufficient defense against ransomware [23], however as discussed in a previous Darktrace blog, the increasing frequency of double extortion attacks in a world where ‘data is the new oil’ demonstrates that backups alone are not a mitigation for the risk of a ransomware attack [24]. Equally, the lack of preventive defenses in the target’s environment enabled the attacker’s riskier decision to dwell in the network for longer and allowed them to optimize their potential reward. 

Recent crackdowns from law enforcement on ransomware groups have shifted these groups’ approaches to aim for a balance between low risk and significant financial rewards [25]. However, given the Quantum gang only have a 5% market share in Q2 2022, compared to the 13.2% held by LockBit and 16.9% held by BlackCat [26], a riskier strategy may be favourable, as a longer dwell time and double extortion outcome offers a ‘belt and braces’ approach to maximizing the rewards from carrying out this attack. Alternatively, the gaps in-between the attack stages may imply that more than one player was involved in this attack, although this group has not been reported to operate a franchise model before [27]. Whether assisted by others or driving for a risk approach, it is clear that Quantum (like other actors) are continuing to adapt to ensure their financial success. They will continue to be successful until organizations dedicate themselves to ensuring that the proper data protection and network security measures are in place. 

Conclusion 

Ransomware has evolved over time and groups have merged and rebranded. However, this incident of Quantum ransomware demonstrates that regardless of the capability to execute a full attack within hours, prolonging an attack to optimize potential reward by leveraging double extortion tactics is sometimes still the preferred action. The pattern of network activity mirrors the techniques used in other Quantum attacks, however this incident lacked the continuous progression of the group’s attacks reported recently and may represent a change of motives during the process. Knowing that attacker motives can change reinforces the need for organizations to invest in preventative controls- an organization may already be too far down the line if it is executing its backup contingency plans. Darktrace DETECT/Network had visibility over both the early network-based indicators of compromise and the escalation to the later stages of this attack. Had Darktrace also been allowed to respond, this case of Quantum ransomware would also have had a very short dwell time, but a far better outcome for the victim.

Thanks to Steve Robinson for his contributions to this blog.

Appendices

References

[1] https://community.ibm.com/community/user/security/blogs/tristan-reed/2022/07/13/ibm-security-reaqta-vs-quantum-locker-ransomware

 

[2] https://www.bleepingcomputer.com/news/security/quantum-ransomware-seen-deployed-in-rapid-network-attacks/

 

[3], [12], [14], [16], [20] https://thedfirreport.com/2022/04/25/quantum-ransomware/

 

[4] https://www.mandiant.com/sites/default/files/2022-04/M-Trends%202022%20Executive%20Summary.pdf

 

[5] https://cyware.com/news/over-650-healthcare-organizations-affected-by-the-quantum-ransomware-attack-d0e776bb/

 

[6] https://www.kroll.com/en/insights/publications/cyber/bumblebee-loader-linked-conti-used-in-quantum-locker-attacks

 

[7] https://github.com/pan-unit42/tweets/blob/master/2022-06-28-IOCs-for-TA578-IcedID-Cobalt-Strike-and-DarkVNC.txt 

 

[8] https://github.com/stamparm/maltrail/blob/master/trails/static/malware/icedid.txt

 

[9], [15] https://www.cynet.com/blog/shelob-moonlight-spinning-a-larger-web-from-icedid-to-conti-a-trojan-and-ransomware-collaboration/

 

[10] https://www.microsoft.com/security/blog/2021/04/09/investigating-a-unique-form-of-email-delivery-for-icedid-malware/

 

[11] https://twitter.com/0xToxin/status/1564289244084011014

 

[13], [27] https://cybernews.com/security/quantum-ransomware-gang-fast-and-furious/

 

[17] https://www.virustotal.com/gui/domain/gedabuyisi.com/relations

 

[18] https://www.virustotal.com/gui/domain/sezijiru.com/relations.

 

[19] https://github.com/ByteSecLabs/ja3-ja3s-combo/blob/master/master-list.txt 

 

[21] https://www.darkreading.com/perimeter/ftp-hacking-on-the-rise

 

[22] https://www.pcrisk.com/removal-guides/23352-quantum-ransomware

 

[23] https://www.cohesity.com/resource-assets/tip-sheet/5-ways-ransomware-renders-backup-useless-tip-sheet-en.pdf

 

[24] https://www.forbes.com/sites/nishatalagala/2022/03/02/data-as-the-new-oil-is-not-enough-four-principles-for-avoiding-data-fires/ 

 

[25] https://www.bleepingcomputer.com/news/security/access-to-hacked-corporate-networks-still-strong-but-sales-fall/

 

[26] https://www.bleepingcomputer.com/news/security/ransom-payments-fall-as-fewer-victims-choose-to-pay-hackers/ 

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
Nicole Wong
Cyber Security Analyst

More in this series

No items found.

Blog

/

/

May 2, 2025

SocGholish: From loader and C2 activity to RansomHub deployment

laptop and hand typingDefault blog imageDefault blog image

Over the past year, a clear pattern has emerged across the threat landscape: ransomware operations are increasingly relying on compartmentalized affiliate models. In these models, initial access brokers (IABs) [6], malware loaders, and post-exploitation operators work together.

Due to those specialization roles, a new generation of loader campaigns has risen. Threat actors increasingly employ loader operators to quietly establish footholds on the target network. These entities then hand off access to ransomware affiliates. One loader that continues to feature prominently in such campaigns is SocGholish.

What is SocGholish?

SocGholish is a loader malware that has been utilized since at least 2017 [7].  It has long been associated with fake browser updates and JavaScript-based delivery methods on infected websites.

Threat actors often target outdated or poorly secured CMS-based websites like WordPress. Through unpatched plugins, or even remote code execution flaws, they inject malicious JavaScript into the site’s HTML, templates or external JS resources [8].  Historically, SocGholish has functioned as a first-stage malware loader, ultimately leading to deployment of Cobalt Strike beacons [9], and further facilitating access persistence to corporate environments. More recently, multiple security vendors have reported that infections involving SocGholish frequently lead to the deployment of RansomHub ransomware [3] [5].

This blog explores multiple instances within Darktrace's customer base where SocGholish deployment led to subsequent network compromises. Investigations revealed indicators of compromise (IoCs) similar to those identified by external security researchers, along with variations in attacker behavior post-deployment. Key innovations in post-compromise activities include credential access tactics targeting authentication mechanisms, particularly through the abuse of legacy protocols like WebDAV and SCF file interactions over SMB.

Initial access and execution

Since January 2025, Darktrace’s Threat Research team observed multiple cases in which threat actors leveraged the SocGholish loader for initial access. Malicious actors commonly deliver SocGholish by compromising legitimate websites by injecting malicious scripts into the HTML of the affected site. When the visitor lands on an infected site, they are typically redirected to a fake browser update page, tricking them into downloading a ZIP file containing a JavaScript-based loader [1] [2]. In one case, a targeted user appears to have visited the compromised website garagebevents[.]com (IP: 35.203.175[.]30), from which around 10 MB of data was downloaded.

Device Event Log showing connections to the compromised website, following by connections to the identified Keitaro TDS instances.
Figure 1: Device Event Log showing connections to the compromised website, following by connections to the identified Keitaro TDS instances.

Within milliseconds of the connection establishment, the user’s device initiated several HTTPS sessions over the destination port 443 to the external endpoint 176.53.147[.]97, linked to the following Keitaro TDS domains:

  • packedbrick[.]com
  • rednosehorse[.]com
  • blackshelter[.]org
  • blacksaltys[.]com

To evade detection, SocGholish uses highly obfuscated code and relies on traffic distribution systems (TDS) [3].  TDS is a tool used in digital and affiliate marketing to manage and distribute incoming web traffic based on predefined rules. More specifically, Keitaro is a premium self-hosted TDS frequently utilized by attackers as a payload repository for malicious scripts following redirects from compromised sites. In the previously noted example, it appears that the device connected to the compromised website, which then retrieved JavaScript code from the aforementioned Keitaro TDS domains. The script served by those instances led to connections to the endpoint virtual.urban-orthodontics[.]com (IP: 185.76.79[.]50), successfully completing SocGholish’s distribution.

Advanced Search showing connections to the compromised website, following by those to the identified Keitaro TDS instances.
Figure 2: Advanced Search showing connections to the compromised website, following by those to the identified Keitaro TDS instances.

Persistence

During some investigations, Darktrace researchers observed compromised devices initiating HTTPS connections to the endpoint files.pythonhosted[.]org (IP: 151.101.1[.]223), suggesting Python package downloads. External researchers have previously noted how attackers use Python-based backdoors to maintain access on compromised endpoints following initial access via SocGholish [5].

Credential access and lateral movement

Credential access – external

Darktrace researchers identified observed some variation in kill chain activities following initial access and foothold establishment. For example, Darktrace detected interesting variations in credential access techniques. In one such case, an affected device attempted to contact the rare external endpoint 161.35.56[.]33 using the Web Distributed Authoring and Versioning (WebDAV) protocol. WebDAV is an extension of the HTTP protocol that allows users to collaboratively edit and manage files on remote web servers. WebDAV enables remote shares to be mounted over HTTP or HTTPS, similar to how SMB operates, but using web-based protocols. Windows supports WebDAV natively, which means a UNC path pointing to an HTTP or HTTPS resource can trigger system-level behavior such as authentication.

In this specific case, the system initiated outbound connections using the ‘Microsoft-WebDAV-MiniRedir/10.0.19045’ user-agent, targeting the URI path of /s on the external endpoint 161.35.56[.]33. During these requests, the host attempted to initiate NTML authentication and even SMB sessions over the web, both of which failed. Despite the session failures, these attempts also indicate a form of forced authentication. Forced authentication exploits a default behavior in Windows where, upon encountering a UNC path, the system will automatically try to authenticate to the resource using NTML – often without any user interaction. Although no files were directly retrieved, the WebDAV server was still likely able to retrieve the user’s NTLM hash during the session establishment requests, which can later be used by the adversary to crack the password offline.

Credential access – internal

In another investigated incident, Darktrace observed a related technique utilized for credential access and lateral movement. This time, the infected host uploaded a file named ‘Thumbs.scf’ to multiple internal SMB network shares. Shell Command File ( SCF) is a legacy Windows file format used primarily for Windows Explorer shortcuts. These files contain instructions for rendering icons or triggering shell commands, and they can be executed implicitly when a user simply opens a folder containing the file – no clicks required.

The ‘Thumbs.scf’ file dropped by the attacker was crafted to exploit this behavior. Its contents included a [Shell] section with the Command=2 directive and an IconFile path pointing to a remote UNC resource on the same external endpoint, 161.35.56[.]33, seen in the previously described case – specifically, ‘\\161.35.56[.]33\share\icon.ico’. When a user on the internal network navigates to the folder containing the SCF file, their system will automatically attempt to load the icon. In doing so, the system issues a request to the specified UNC path, which again prompts Windows to initiate NTML authentication.

This pattern of activity implies that the attacker leveraged passive internal exposure; users who simply browsed a compromised share would unknowingly send their NTML hashes to an external attacker-controlled host. Unlike the WebDAV approach, which required initiating outbound communication from the infected host, this SCF method relies on internal users to interact with poisoned folders.

Figure 3: Contents of the file 'Thumbs.scf' showing the UNC resource hosted on the external endpoint.
Figure 3: Contents of the file 'Thumbs.scf' showing the UNC resource hosted on the external endpoint.

Command-and-control

Following initial compromise, affected devices would then attempt outbound connections using the TLS/SSL protocol over port 443 to different sets of command-and-control (C2) infrastructure associated with SocGholish. The malware frequently uses obfuscated JavaScript loaders to initiate its infection chain, and once dropped, the malware communicates back to its infrastructure over standard web protocols, typically using HTTPS over port 443. However, this set of connections would precede a second set of outbound connections, this time to infrastructure linked to RansomHub affiliates, possibly facilitating the deployed Python-based backdoor.

Connectivity to RansomHub infrastructure relied on defense evasion tactics, such as port-hopping. The idea behind port-hopping is to disguise C2 traffic by avoiding consistent patterns that might be caught by firewalls, and intrusion detection systems. By cycling through ephemeral ports, the malware increases its chances of slipping past basic egress filtering or network monitoring rules that only scrutinize common web traffic ports like 443 or 80. Darktrace analysts identified systems connecting to destination ports such as 2308, 2311, 2313 and more – all on the same destination IP address associated with the RansomHub C2 environment.

Figure 4: Advanced Search connection logs showing connections over destination ports that change rapidly.

Conclusion

Since the beginning of 2025, Darktrace analysts identified a campaign whereby ransomware affiliates leveraged SocGholish to establish network access in victim environments. This activity enabled multiple sets of different post exploitation activity. Credential access played a key role, with affiliates abusing WebDAV and NTML over SMB to trigger authentication attempts. The attackers were also able to plant SCF files internally to expose NTML hashes from users browsing shared folders. These techniques evidently point to deliberate efforts at early lateral movement and foothold expansion before deploying ransomware. As ransomware groups continue to refine their playbooks and work more closely with sophisticated loaders, it becomes critical to track not just who is involved, but how access is being established, expanded, and weaponized.

Credit to Chrisina Kreza (Cyber Analyst) and Adam Potter (Senior Cyber Analyst)

Appendices

Darktrace / NETWORK model alerts

·       Anomalous Connection / SMB Enumeration

·       Anomalous Connection / Multiple Connections to New External TCP Port

·       Anomalous Connection / Multiple Failed Connections to Rare Endpoint

·       Anomalous Connection / New User Agent to IP Without Hostname

·       Compliance / External Windows Communication

·       Compliance / SMB Drive Write

·       Compromise / Large DNS Volume for Suspicious Domain

·       Compromise / Large Number of Suspicious Failed Connections

·       Device / Anonymous NTML Logins

·       Device / External Network Scan

·       Device / New or Uncommon SMB Named Pipe

·       Device / SMB Lateral Movement

·       Device / Suspicious SMB Activity

·       Unusual Activity / Unusual External Activity

·       User / Kerberos Username Brute Force

MITRE ATT&CK mapping

·       Credential Access – T1187 Forced Authentication

·       Credential Access – T1110 Brute Force

·       Command and Control – T1071.001 Web Protocols

·       Command and Control – T1571 Non-Standard Port

·       Discovery – T1083 File and Directory Discovery

·       Discovery – T1018 Remote System Discovery

·       Discovery – T1046 Network Service Discovery

·       Discovery – T1135 Network Share Discovery

·       Execution – T1059.007 JavaScript

·       Lateral Movement – T1021.002 SMB/Windows Admin Shares

·       Resource Deployment – T1608.004 Drive-By Target

List of indicators of compromise (IoCs)

·       garagebevents[.]com – 35.203.175[.]30 – Possibly compromised website

·       packedbrick[.]com – 176.53.147[.]97 – Keitaro TDS Domains used for SocGholish Delivery

·       rednosehorse[.]com – 176.53.147[.]97 – Keitaro TDS Domains used for SocGholish Delivery

·       blackshelter[.]org – 176.53.147[.]97 – Keitaro TDS Domains used for SocGholish Delivery

·       blacksaltys[.]com – 176.53.147[.]97 – Keitaro TDS Domains used for SocGholish Delivery

·       virtual.urban-orthodontics[.]com – 185.76.79[.]50

·       msbdz.crm.bestintownpro[.]com – 166.88.182[.]126 – SocGholish C2

·       185.174.101[.]240 – RansomHub Python C2

·       185.174.101[.]69 – RansomHub Python C2

·       108.181.182[.]143 – RansomHub Python C2

References

[1] https://www.checkpoint.com/cyber-hub/threat-prevention/what-is-malware/socgholish-malware/

[2] https://intel471.com/blog/threat-hunting-case-study-socgholish

[3] https://www.trendmicro.com/en_us/research/25/c/socgholishs-intrusion-techniques-facilitate-distribution-of-rans.html

[4] https://www.proofpoint.com/us/blog/threat-insight/update-fake-updates-two-new-actors-and-new-mac-malware

[5] https://www.guidepointsecurity.com/blog/ransomhub-affiliate-leverage-python-based-backdoor/

[6] https://www.cybereason.com/blog/how-do-initial-access-brokers-enable-ransomware-attacks

[7] https://attack.mitre.org/software/S1124/

[8] https://expel.com/blog/incident-report-spotting-socgholish-wordpress-injection/

[9] https://www.esentire.com/blog/socgholish-to-cobalt-strike-in-10-minutes

Continue reading
About the author
Christina Kreza
Cyber Analyst

Blog

/

/

May 1, 2025

Your Vendors, Your Risk: Rethinking Third-Party Security in the Age of Supply Chain Attacks

man on cellphoneDefault blog imageDefault blog image

When most people hear the term supply chain attack, they often imagine a simple scenario: one organization is compromised, and that compromise is used as a springboard to attack another. This kind of lateral movement is common, and often the entry vector is as mundane and as dangerous as email.

Take, for instance, a situation where a trusted third-party vendor is breached. An attacker who gains access to their systems can then send malicious emails to your organization, emails that appear to come from a known and reputable source. Because the relationship is trusted, traditional phishing defenses may not be triggered, and recipients may be more inclined to engage with malicious content. From there, the attacker can establish a foothold, move laterally, escalate privileges, and launch a broader campaign.

This is one dimension of a supply chain cyber-attack, and it’s well understood in many security circles. But the risk doesn’t end there. In fact, it goes deeper, and it often hits the most important asset of all: your customers' data.

The risk beyond the inbox

What happens when customer data is shared with a third party for legitimate processing purposes for example billing, analytics, or customer service and that third party is then compromised?

In that case, your customer data is breached, even if your own systems were never touched. That’s the uncomfortable truth about modern cybersecurity: your risk is no longer confined to your own infrastructure. Every entity you share data with becomes an extension of your attack surface. Thus, we should rethink how we perceive responsibility.

It’s tempting to think that securing our environment is our job, and securing their environment is theirs. But if a breach of their environment results in the exposure of our customers, the accountability and reputational damage fall squarely on our shoulders.

The illusion of boundaries

In an era where digital operations are inherently interconnected, the lines of responsibility can blur quickly. Legally and ethically, organizations are still responsible for the data they collect even if that data is processed, stored, or analyzed by a third party. A customer whose data is leaked because of a vendor breach will almost certainly hold the original brand responsible, not the third-party processor they never heard of.

This is particularly important for industries that rely on extensive outsourcing and platform integrations (SaaS platforms, marketing tools, CRMs, analytics platforms, payment processors). The list of third-party vendors with access to customer data grows year over year. Each integration adds convenience, but also risk.

Encryption isn’t a silver bullet

One of the most common safeguards used in these data flows is encryption. Encrypting customer data in transit is a smart and necessary step, but it’s far from enough. Once data reaches the destination system, it typically needs to be decrypted for use. And the moment it is decrypted, it becomes vulnerable to a variety of attacks like ransomware, data exfiltration, privilege escalation, and more.

In other words, the question isn’t just is the data secure in transit? The more important question is how is it protected once it arrives?

A checklist for organizations evaluating third-parties

Given these risks, what should responsible organizations do when they need to share customer data with third parties?

Start by treating third-party security as an extension of your own security program. Here are some foundational controls that can make a difference:

Due diligence before engagement: Evaluate third-party vendors based on their security posture before signing any contracts. What certifications do they hold? What frameworks do they follow? What is their incident response capability?

Contractual security clauses: Build in specific security requirements into vendor contracts. These can include requirements for encryption standards, access control policies, and data handling protocols.

Third-party security assessments: Require vendors to provide evidence of their security controls. Independent audits, penetration test results, and SOC 2 reports can all provide useful insights.

Ongoing monitoring and attestations: Security isn’t static. Make sure vendors provide regular security attestations and reports. Where possible, schedule periodic reviews or audits, especially for vendors handling sensitive data.

Minimization and segmentation: Don’t send more data than necessary. Data minimization limits the exposure in the event of a breach. Segmentation, both within your environment and within vendor access levels, can further reduce risk.

Incident response planning: Ensure you have a playbook for handling third-party incidents, and that vendors do as well. Coordination in the event of a breach should be clear and rapid.

The human factor: Customers and communication

There’s another angle to supply chain cyber-attacks that’s easy to overlook: the post-breach exploitation of public knowledge. When a breach involving customer data hits the news, it doesn’t take long for cybercriminals to jump on the opportunity.

Attackers can craft phishing emails that appear to be follow-ups from the affected organization: “Click here to reset your password,” “Confirm your details due to the breach,” etc.

A breach doesn’t just put customer data at risk it also opens the door to further fraud, identity theft, and financial loss through social engineering. This is why post-breach communication and phishing mitigation strategies are valuable components of an incident response strategy.

Securing what matters most

Ultimately, protecting against supply chain cyber-attacks isn’t just about safeguarding your own perimeter. It’s about defending the integrity of your customers’ data, wherever it goes. When customer data is entrusted to you, the duty of care doesn’t end at your firewall.

Relying on vendors to “do their part” is not enough. True due diligence means verifying, validating, and continuously monitoring those extended attack surfaces. It means designing controls that assume failure is possible, and planning accordingly.

In today’s threat landscape, cybersecurity is no longer just a technical discipline. It’s a trust-building exercise. Your customers expect you to protect their information, and rightly so. And when a supply chain attack happens, whether the breach originated with you or your partner, the damage lands in the same place: your brand, your customers, your responsibility.

[related-resource]

Continue reading
About the author
Tony Jarvis
VP, Field CISO | Darktrace
Your data. Our AI.
Elevate your network security with Darktrace AI