April 17, 2024

Cerber Ransomware: Dissecting the three heads

Cerber ransomware's Linux variant is actively exploiting CVE-2023-22518 in Confluence servers. It uses three UPX-packed C++ payloads: a primary stager, a log checker for environment assessment, and an encryptor that renames files with a .L0CK3D extension.

Written by

Nate Bill

Threat Researcher

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

Nate Bill

Threat Researcher

Apr 2024

Introduction: Cerber ransomware

Researchers at Cado Security Labs (now part of Darktrace) received reports of the Cerber ransomware being deployed onto servers running the Confluence application via the CVE-2023-22518 exploit. [1] There is a large amount of coverage on the Windows variant, however there is very little about the Linux variant. This blog will discuss an analysis of the Linux variant. 

Cerber emerged and was at the peak of its activity around 2016, and has since only occasional campaigns, most recently targeting the aforementioned Confluence vulnerability. It consists of three highly obfuscated C++ payloads, compiled as a 64-bit Executable and Linkable Format (ELF, the format for executable binary files on Linux) and packed with UPX. UPX is a very common packer used by many threat actors. It allows the actual program code to be stored encoded in the binary, and at runtime extracted into memory and executed (“unpacked”). This is done to prevent software from scanning the payload and detecting the malware.

Pure C++ payloads are becoming less common on Linux, with many threat actors now employing newer programming languages such as Rust or Go. [2] This is likely due to the Cerber payload first being released almost 8 years ago. While it will have certainly received updates, the language and tooling choices are likely to have stuck around for the lifetime of the payload.

Initial access

Cado researchers observed instances of the Cerber ransomware being deployed after a threat actor leveraged CVE-2023-22518 in order to gain access to vulnerable instances of Confluence [3]. It is an improper authorization vulnerability that allows an attacker to reset the Confluence application and create a new administrator account using an unprotected configuration restore endpoint used by the setup wizard.

[19/Mar/2024:15:57:24 +0000] - http-nio-8090-exec-10 13.40.171.234 POST /json/setup-restore.action?synchronous=true HTTP/1.1 302 81796ms - - python-requests/2.31.0 
[19/Mar/2024:15:57:24 +0000] - http-nio-8090-exec-3 13.40.171.234 GET /json/setup-restore-progress.action?taskId= HTTP/1.1 200 108ms 283 - python-requests/2.31.0

Once an administrator account is created, it can be used to gain code execution by uploading & installing a malicious module via the admin panel. In this case, the Effluence web shell plugin is directly uploaded and installed, which provides a web UI for executing arbitrary commands on the host.

Web Shell recreation — Figure 1: Recreation of installing a web shell on a Confluence instance

The threat actor uses this web shell to download and run the primary Cerber payload. In a default install, the Confluence application is executed as the “confluence” user, a low privilege user. As such, the data the ransomware is able to encrypt is limited to files owned by the confluence user. It will of course succeed in encrypting the datastore for the Confluence application, which can store important information. If it was running as a higher privilege user, it would be able to encrypt more files, as it will attempt to encrypt all files on the system.

Primary payload

Summary of payload:

Written in C++, highly obfuscated, and packed with UPX
Serves as a stager for further payloads
Uses a C2 server at 45[.]145[.]6[.]112 to download and unpack further payloads
Deletes itself off disk upon execution

The primary payload is packed with UPX, just like the other payloads. Its main purpose is to set up the environment and grab further payloads in order to run.

Upon execution it unpacks itself and tries to create a file at /var/lock/0init-ld.lo. It is speculated that this was meant to serve as a lock file and prevent duplicate execution of the ransomware, however if the lock file already exists the result is discarded, and execution continues as normal anyway. 

It then connects to the (now defunct) C2 server at 45[.]145[.]6[.]112 and pulls down the secondary payload, a log checker, known internally as agttydck. It does this by doing a simple GET /agttydcki64 request to the server using HTTP and writing the payload body out to /tmp/agttydck.bat. It then executes it with /tmp and ck.log passed as arguments. The execution of the payload is detailed in the next section.

Once the secondary payload has finished executing, the primary payload checks if the log file at /tmp/ck.log it wrote exists. If it does, it then proceeds to delete itself and agttydcki64 from the disk. As it is still running in memory, it then downloads the encryptor payload, known internally as agttydcb, and drops it at /tmp/agttydcb.bat. The packing on this payload is more complex. The file command reports it as a DOS executable and the bat extension would imply this as well. However, it does not have the correct magic bytes, and the high entropy of the file suggests that it is potentially encoded or encrypted. Indeed, the primary payload reads it in and then writes out a decoded ELF file back using the same stream, overwriting the content. It is unclear the exact mechanism used to decode agttydcb. The primary payload then executes the decoded agttydcb, the behavior of which is documented in a later section.

2283  openat(AT_FDCWD, "/tmp/agttydcb.bat", O_RDWR) = 4 
… 
2283  read(4, "\353[\254R\333\372\22,\1\251\f\235 'A>\234\33\25E3g\335\0252\344vBg\177\356\321"..., 450560) = 450560 
… 
2283  lseek(4, 0, SEEK_SET)             = 0 
2283  write(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0X\334F\0\0\0\0\0"..., 450560) = 450560 
… 
2283  close(4)                          = 0

Truncated strace output for the decoding process

Log check payload - agttydck

Summary of payload:

Written in C++, highly obfuscated, and packed with UPX
Tries to write the phrase “success” to a given file passed in arguments
Likely a check for sandboxing, or to check the permission level of the malware on the system

The log checker payload, agttydck, likely serves as a permission checker. It is a very simple payload and was easy to analyze statically despite the obfuscation. Like the other payloads, it is UPX packed.

When run, it concatenates each argument passed to it and delimits with forward slashes in order to obtain a full path. In this case, it is passed /tmp and ck.log, which becomes /tmp/ck.log. It then tries to open this file in write mode, and if it succeeds writes the word “success” and returns 0. If it does not succeed, it returns 1.

cleaned-up routine — Figure 2: Cleaned-up routine that writes out the success phrase

The purpose of this check isn’t exactly clear. It could be to check if the tmp directory is writable and that it can write, which may be a check for if the system is too locked down for the encryptor to work. Given the check is run in a process separate to the primary payload, it could also be an attempt to detect sandboxes that may not handle files correctly, resulting in the primary payload not being told about the file created by the child.

Encryptor - agttydck

Summary of payload:

Written in C++, highly obfuscated, and packed with UPX
Writes log file /tmp/log.0 on start and /tmp/log.1 on completion, likely for debugging
Walks the root directory looking for directories it can encrypt
Writes a ransom note to each directory
Overwrites all files in directory with their encrypted content and adds a .L0CK3D extension

The encryptor, agttydcb, achieves the goal of the ransomware, which is to encrypt files on the filesystem. Like the other payloads, it is UPX packed and written with heavily obfuscated C++. Upon launch, it deletes itself off disk so as to not leave any artefacts. It then creates a file at /tmp/log.0, but with no content. As it creates a second file at /tmp/log.1 (also with no content) after encryption finishes, it is possible these were debug markers that the attacker mistakenly left in.

The encryptor then spawns a new thread to do the actual encryption. The payload attempts to write a ransom note at /<directory>/read-me3.txt. If it succeeds, it will walk all files in the directory and attempt to encrypt them. If it fails, it moves on to the next directory. The encryptor chooses to pick which directories to encrypt by walking the root file system. For example, it will try to encrypt /usr, and then /var, etc.

‍

Cerber ransom note — Figure 3: Ransom note left by Cerber

When it has identified a file to encrypt, it opens a read-write file stream to the file and reads in the entire file. It is then encrypted in memory before it seeks to the start of the stream and writes the encrypted data, overwriting the file content, and rendering the file fully encrypted. It then renames the file to have the .L0CK3D extension. Rewriting the same file instead of making a new file and deleting the old one is useful on Linux as directories may be set to append only, preventing the outright deletion of files. Rewriting the file may also rewrite the data on the underlying storage, making recovery with advanced forensics also impossible.

2290  openat(AT_FDCWD, "/home/ubuntu/example", O_RDWR) = 6 
… 
2290  read(6, "file content"..., 3691) = 3691 
… 
2290  write(6, "\241\253\270'\10\365?\2\300\304\275=\30B\34\230\254\357\317\242\337UD\266\362\\\210\215\245!\255f"
..., 3691) = 3691 
2290  close(6)                          = 0 
2290  rename("/home/ubuntu/example", "/home/ubuntu/example.L0CK3D") = 0

Truncated strace of the encryption process

Once this finishes, it tries to delete itself again (which fails as it already deleted itself) and creates /tmp/log.1. It then gracefully exits. Despite the ransom note claiming the files were exfiltrated, Cado researchers did not observe any behavior that showed this.

Conclusion

Cerber is a relatively sophisticated, albeit aging, ransomware payload. While the use of the Confluence vulnerability allows it to compromise a large amount of likely high value systems, often the data it is able to encrypt will be limited to just the confluence data and in well configured systems this will be backed up. This greatly limits the efficacy of the ransomware in extracting money from victims, as there is much less incentive to pay up.

IoCs

The payloads are packed with UPX so will match against existing UPX Yara rules.

Hashes (sha256)

cerber_primary 4ed46b98d047f5ed26553c6f4fded7209933ca9632b998d265870e3557a5cdfe

agttydcb 1849bc76e4f9f09fc6c88d5de1a7cb304f9bc9d338f5a823b7431694457345bd

agttydck ce51278578b1a24c0fc5f8a739265e88f6f8b32632cf31bf7c142571eb22e243

IPs

C2 (Defunct) 45[.]145[.]6[.]112

References

https://confluence.atlassian.com/security/cve-2023-22518-improper-authorization-vulnerability-in-confluence-data-center-and-server-1311473907.html

https://www.proofpoint.com/uk/threat-reference/cerber-ransomware

https://nvd.nist.gov/vuln/detail/CVE-2023-22518

‍

Written by

Nate Bill

Threat Researcher

Inside the SOC

Written by

Nate Bill

Threat Researcher

Associate Principal Analyst & Regional Consultancy Lead

•

March 26, 2026

The Darktrace Community

Watch the NIS2 Webinar

Blog

Network

March 26, 2026

Phantom Footprints: Tracking GhostSocks Malware

Why are attackers using residential proxies?

In today's threat landscape, blending in to normal activity is the key to success for attackers and the growing reliance on residential proxies shows a significant shift in how threat actors are attempting to bypass IP detection tools.

The increasing dependency on residential proxies has exposed how prevalent proxy services are and how reliant a diverse range of threat actors are on them. From cybercriminal groups to state‑sponsored actors, the need to bypass IP detection tools is fundamental to the success of these groups. One malware that has quietly become notorious for its ability to avoid anomaly detection is GhostSocks, a malware that turns compromised devices into residential proxies.

What is GhostSocks?

Originally marketed on the Russian underground forum xss[.]is as a Malware‑as‑a‑Service (MaaS), GhostSocks enables threat actors to turn compromised devices into residential proxies, leveraging the victim's internet bandwidth to route malicious traffic through it.

How does Ghostsocks malware work?

The malware offers the threat actor a “clean” IP address, making it look like it is coming from a household user. This enables the bypassing of geographic restrictions and IP detection tools, a perfect tool for avoiding anomaly detection. It wasn’t until 2024, when a partnership was announced with the infamous information stealer Lumma Stealer, that GhostSocks surged into widespread adoption and alluded to who may be the author of the proxy malware.

Written in GoLang, GhostSocks utilizes the SOCKS5 proxy protocol, creating a SOCKS5 connection on infected devices. It uses a relay‑based C2 implementation, where an intermediary server sits in between the real command-and-control (C2) server and the infected device.

How does Ghostsocks malware evade detection?

To further increase evasion, the Ghostsocks malware wraps its SOCKS5 tunnels in TLS encryption, allowing its malicious traffic to blend into normal network traffic.

Early variants of GhostSocks do not implement a persistence mechanism; however, later versions achieve persistence via registry run keys, ensuring sustained proxy operational time [1].

While proxying is its primary purpose, GhostSocks also incorporates backdoor functionality, enabling malicious actors to run arbitrary commands and download and deploy additional malicious payloads. This was evident with the well‑known ransomware group Black Basta, which reportedly used GhostSocks as a way of maintaining long‑term access to victims’ networks [1].

Darktrace’s detection of GhostSocks Malware

Darktrace observed a steady increase in GhostSocks activity across its customer base from late 2025, with its Threat Research team identifying multiple incidents involving the malware. In one notable case from December 2025, Darktrace detected GhostSocks operating alongside Lumma Stealer, reinforcing that the partnership between Lumma and GhostSocks remains active despite recent attempts to disrupt Lumma’s infrastructure.

Darktrace’s first detection of GhostSocks‑related activity came when a device on the network of a customer in the education sector began making connections to an endpoint with a suspicious self‑signed certificate that had never been seen on the network before.

The endpoint in question, 159.89.46[.]92 with the hostname retreaw[.]click, has been flagged by multiple open‑source intelligence (OSINT) sources as being associated with Lumma Stealer’s C2 infrastructure [2], indicating its likely role in the delivery of malicious payloads.

Figure 1: Darktrace’s detection of suspicious SSL connections to retreaw[.]click, indicating an attempted link to Lumma C2 infrastructure.

Less than two minutes later, Darktrace observed the same device downloading the executable (.exe) file “Renewable.exe” from the IP 86.54.24[.]29, which Darktrace recognized as 100% rare for this network.

Figure 2: Darktrace’s detection of a device downloading the unusual executable file “Renewable.exe”.

Both the file MD5 hash and the executable itself have been identified by multiple OSINT vendors as being associated with the GhostSocks malware [3], with the executable likely the backdoor component of the GhostSocks malware, facilitating the distribution of additional malicious payloads [4].

Following this detection, Darktrace’s Autonomous Response capability recommended a blocking action for the device in an early attempt to stop the malicious file download. In this instance, Darktrace was configured in Human Confirmation Mode, meaning the customer’s security team was required to manually apply any mitigative response actions. Had Autonomous Response been fully enabled at the time of the attack, the connections to 86.54.24[.]29 would have been blocked, rendering the malware ineffective at reaching its C2 infrastructure and halting any further malicious communication.

Figure 3: Darktrace’s Autonomous Response capability suggesting blocking the suspicious connections to the unusual endpoint from which the malicious executable was downloaded.

As the attack was able to progress, two days later the device was detected downloading additional payloads from the endpoint www.lbfs[.]site (23.106.58[.]48), including “Setup.exe”, “,.exe”, and “/vp6c63yoz.exe”.

Figure 4: Darktrace’s detection of a malicious payload being downloaded from the endpoint www.lbfs[.]site.

Once again, Darktrace recognized the anomalous nature of these downloads and suggested that a “group pattern of life” be enforced on the offending device in an attempt to contain the activity. By enforcing a pattern of life on a device, Darktrace restricts its activity to connections and behaviors similar to those performed by peer devices within the same group, while still allowing it to carry out its expected activity, effectively preventing deviations indicative of compromise while minimizing disruption. As mentioned earlier, these mitigative actions required manual implementation, so the activity was able to continue. Darktrace proceeded to suggest further actions to contain subsequent malicious downloads, including an attempt to block all outbound traffic to stop the attack from progressing.

Figure 5: An overview of download activity and the Autonomous Response actions recommended by Darktrace to block the downloads.

Around the same time, a third executable download was detected, this time from the hostname hxxp[://]d2ihv8ymzp14lr.cloudfront.net/2021-08-19/udppump[.]exe, along with the file “udppump.exe”.While GhostSocks may have been present only to facilitate the delivery of additional payloads, there is no indication that these CloudFront endpoints or files are functionally linked to GhostSocks. Rather, the evidence points to broader malicious file‑download activity.

Shortly after the multiple executable files had been downloaded, Darktrace observed the device initiating a series of repeated successful connections to several rare external endpoints, behavior consistent with early-stage C2 beaconing activity.

Cyber AI Analyst’s investigation

Figure 7: Darktrace’s detection of additional malicious file downloads from malicious CloudFront endpoints.

Throughout the course of this attack, Darktrace’s Cyber AI Analyst carried out its own autonomous investigation, piecing together seemingly separate events into one wider incident encompassing the first suspicious downloads beginning on December 4, the unusual connectivity to many suspicious IPs that followed, and the successful beaconing activity observed two days later. By analyzing these events in real-time and viewing them as part of the bigger picture, Cyber AI Analyst was able to construct an in‑depth breakdown of the attack to aid the customer’s investigation and remediation efforts.

Figure 8: Cyber AI Analyst investigation detailing the sequence of events on the compromised device, highlighting its extensive connectivity to rare endpoints, the related malicious file‑download activity, and finally the emergence of C2 beaconing behavior.

Conclusion

The versatility offered by GhostSocks is far from new, but its ability to convert compromised devices into residential proxy nodes, while enabling long‑term, covert network access—illustrates how threat actors continue to maximise the value of their victims’ infrastructure. Its growing popularity, coupled with its ongoing partnership with Lumma, demonstrates that infrastructure takedowns alone are insufficient; as long as threat actors remain committed to maintaining anonymity and can rapidly rebuild their ecosystems, related malware activity is likely to persist in some form.

Credit to Isabel Evans (Cyber Analyst), Gernice Lee (Associate Principal Analyst & Regional Consultancy Lead – APJ)
Edited by Ryan Traill (Content Manager)

Appendices

References

1. https://bloo.io/research/malware/ghostsocks

2. https://www.virustotal.com/gui/domain/retreaw.click/community

3. https://synthient.com/blog/ghostsocks-from-initial-access-to-residential-proxy

4. https://www.joesandbox.com/analysis/1810568/0/html

5. https://www.virustotal.com/gui/url/fab6525bf6e77249b74736cb74501a9491109dc7950688b3ae898354eb920413

Darktrace Model Detections

Real-time Detection Models

Anomalous Connection / Suspicious Self-Signed SSL

Anomalous Connection / Rare External SSL Self-Signed

Anomalous File / EXE from Rare External Location

Anomalous File / Multiple EXE from Rare External Locations

Compromise / Possible Fast Flux C2 Activity

Compromise / Large Number of Suspicious Successful Connections

Compromise / Large Number of Suspicious Failed Connections

Compromise / Sustained SSL or HTTP Increase

Autonomous Response Models

Antigena / Network / Significant Anomaly / Antigena Significant Anomaly from Client Block

Antigena / Network / External Threat / Antigena Suspicious File Block

Antigena / Network / Significant Anomaly / Antigena Controlled and Model Alert

Antigena / Network / External Threat / Antigena File then New Outbound Block

Antigena / Network / Significant Anomaly / Antigena Alerts Over Time Block

Antigena / Network / External Threat / Antigena Suspicious Activity Block

MITRE ATT&CK Mapping

Tactic – Technique – Sub-Technique

Resource Development – T1588 - Malware

Initial Access - T1189 - Drive-by Compromise

Persistence – T1112 – Modify Registry

Command and Control – T1071 – Application Layer Protocol

Command and Control – T1095 – Non-application Layer Protocol

Command and Control – T1071 – Web Protocols

Command and Control – T1571 – Non-Standard Port

Command and Control – T1102 – One-Way Communication

List of Indicators of Compromise (IoCs)

86.54.24[.]29 - IP - Likely GhostSocks C2

http[://]86.54.24[.]29/Renewable[.]exe - Hostname - GhostSocks Distribution Endpoint

http[://]d2ihv8ymzp14lr.cloudfront[.]net/2021-08-19/udppump[.]exe - CDN - Payload Distribution Endpoint

www.lbfs[.]site - Hostname - Likely C2 Endpoint

retreaw[.]click - Hostname - Lumma C2 Endpoint

alltipi[.]com - Hostname - Possible C2 Endpoint

w2.bruggebogeyed[.]site - Hostname - Possible C2 Endpoint

9b90c62299d4bed2e0752e2e1fc777ac50308534 - SHA1 file hash – Likely GhostSocks payload

3d9d7a7905e46a3e39a45405cb010c1baa735f9e - SHA1 file hash - Likely follow-up payload

10f928e00a1ed0181992a1e4771673566a02f4e3 - SHA1 file hash - Likely follow-up payload

About the author

Gernice Lee

Associate Principal Analyst & Regional Consultancy Lead

Blog

AI

March 27, 2026

State of AI Cybersecurity 2026: 92% of security professionals concerned about the impact of AI agents

The findings in this blog are taken from Darktrace's annual State of AI Cybersecurity Report 2026.

AI is already embedded in day-to-day enterprise activity, with 78% of participants in one recent survey reporting that their organizations are using generative AI in at least one business function. Generative AI now acts as an always-on assistant, researcher, creator, and coach across an expanding array of departments and functions. Autonomous agents are performing multi-step operational workflows from end to end. AI features have been layered on top of every SaaS application. And vibe coding is making it possible for employees without deep technical expertise to build their own AI-powered automations.

According to Gartner, more than 80% of enterprises will have deployed GenAI models, applications, or APIs in production environments by the end of this year, up from less than 5% in 2023. Companies report a 130% increase in spending on AI over the same period, with 72% of business leaders using AI tools at least weekly. The outsized efficiency and productivity gains that were once a future vision are quickly becoming everyday reality.

AI is currently driving business growth and innovation, and organizations risk falling behind peers if they don’t keep up with the pace of adoption, but it is also quietly expanding the enterprise attack surface. The modern CISO is challenged to both enable innovation and protect the business from these emerging threats.

AI agents introduce new risks and vulnerabilities

AI agents are playing growing roles in enterprise production environments. In many cases, these agents act with broad permissions across multiple software systems and platforms. This means they’re granted far-reaching access – to sensitive data, business-critical applications, tokens and APIs, and IT and security tools. With this access comes risk for security leaders – 92% are concerned about the use of AI agents across the workforce and their impact on security.

These agents must be governed as identities, with least-privilege access and ongoing monitoring. They can’t be thought of as invisible aspects of the application estate. Understanding how AI agents behave, and how to manage their permissions, control their behavior, and limit their data access will be a top security priority throughout 2026.

Generative AI prompts: The next frontier

Prompts are how users – both human and agentic – interact with AI systems, and they’re where natural language gets translated into model behavior. Natural language is infinite in its potential combinations and permutations, making this aspect of the attack surface open-ended and far more complex than traditional CVEs. With carefully crafted prompts, bad actors may be able to coax models into disclosing sensitive data, bypassing guardrails, or initiating undesirable actions.

Among security leaders, the biggest worries about AI usage in their environments all involve ways that systems might be manipulated to bypass traditional controls.

61% are most concerned about the exposure of sensitive data
56% are most concerned about potential data security and policy violations
51% are most concerned about the misuse or abuse of AI tools

The more employees rely on AI in their day-to-day workflows, the more critical it becomes for security teams to understand how prompt behavior determines model behavior – and where that behavior could go wrong.

What does “securing AI” mean in practice?

AI adoption opens new security risks that blur the boundaries between traditional security disciplines. A single malicious interaction with an AI model could involve identity misuse, sensitive data exposure, application logic abuse, and supply chain risk – all within a single workflow. Protecting this dynamic and rapidly evolving attack surface requires an approach that spans identity security, cloud security, application security, data security, software development security, and more.

The task for security leaders is to implement the tools, policies, and frameworks to mitigate these novel, expansive, and cross-disciplinary risks.

However, within most enterprises, AI policy creation remains in its infancy. Just 37% of security leaders report that their organization has a formal AI policy, representing a small but worrisome decrease from last year. Conversations about AI abound: in 52% of organizations, there’s discussion about an AI policy. Still, talk is cheap, and leaders will need to take action if they’re to successfully enable secure AI innovation.

To govern and protect their AI systems, organizations must take a multi-pronged approach. This requires building out policies, but it also demands that they are able to:

Monitor the prompts driving GenAI assistants and agents in real time. Organizations must be able to inspect prompts, sessions, and responses across enterprise GenAI tools, low- and high-code environments, and SaaS and SASE so that they can detect clever conversational prompt attacks and malicious chaining.
Secure all business AI agent identities. Security teams need to identify all the agents acting within their environment and supply chain, map their connections and interactions via MCP and services like Amazon S3, and audit their behavior across the cloud, SaaS environments, and on the network and endpoint devices.
Maintain centralized, comprehensive visibility. Understanding intent, assessing risks, and enforcing policies all require that security teams have a single view that spans AI interactions across the entire business.
Discover and control shadow AI. Teams need to be able to identify unsanctioned AI activities, distinguish the misuse of legitimate tools from their appropriate use, and apply policies to protect data, while guiding users towards approved solutions.

Scaling AI safely and responsibly

The approach that most cybersecurity vendors have taken – using historical patterns to predict future threats – doesn’t work well for AI systems. Because AI changes its behavior in response to the information it encounters while taking action, previous patterns don’t indicate what it will do next. Looking at past attacks can’t tell you how complex models will behave in your individual business.

Securing AI requires interpreting ambiguous interactions, uncovering subtleties that reveal intent within extended conversations, understanding how access accumulates over time, and recognizing when behavior – both human and machine – begins to drift towards areas of risk. To do this, you need to understand what “normal” looks like in each unique organization: how users, systems, applications, and AI agents behave, how they communicate, and how data flows between them.

Darktrace has spent more than a decade designing AI-powered solutions that can understand and adapt to evolving behavior in complex environments. This technology learns directly from the environment it protects, identifying malicious actions that deviate from normal operations, so that it can stop AI-related threats on the very first encounter.

As AI adoption reshapes enterprise operations, humans and machines will collaborate more and more often. This collaboration might dramatically expand the attack surface, but it also has the potential to be a force multiplier for defenders.

‍

Explore the full State of AI Cybersecurity 2026 report for deeper insights into how security leaders are responding to AI-driven risks.

Learn more about securing AI in your enterprise.

‍

[related-resource]

About the author

The Darktrace Community

Your data. Our AI.

Elevate your network security with Darktrace AI

Get a demo

Check out this article by Darktrace: Cerber Ransomware: Dissecting the three heads

Cerber Ransomware: Dissecting the three heads

Introduction: Cerber ransomware

Initial access

Primary payload

Log check payload - agttydck

Encryptor - agttydck

Conclusion

IoCs

IPs

References

Phantom Footprints: Tracking GhostSocks Malware

State of AI Cybersecurity 2026: 92% of security professionals concerned about the impact of AI agents

Enjoying the blog?

More in this series

Inside Cloud Compromise: Investigating Attacker Activity with Darktrace / Forensic Acquisition & Investigation

React2Shell Reflections: Cloud Insights, Finance Sector Impacts, and How Threat Actors Moved So Quickly

Runtime Is Where Cloud Security Really Counts: The Importance of Detection, Forensics and Real-Time Architecture Awareness

Blog

Network

March 26, 2026

Phantom Footprints: Tracking GhostSocks Malware

Why are attackers using residential proxies?

What is GhostSocks?

How does Ghostsocks malware work?

How does Ghostsocks malware evade detection?

Darktrace’s detection of GhostSocks Malware

Cyber AI Analyst’s investigation

Conclusion

Appendices

References

Darktrace Model Detections

MITRE ATT&CK Mapping

List of Indicators of Compromise (IoCs)

Blog

AI

March 27, 2026

State of AI Cybersecurity 2026: 92% of security professionals concerned about the impact of AI agents

AI agents introduce new risks and vulnerabilities

Generative AI prompts: The next frontier

What does “securing AI” mean in practice?

Scaling AI safely and responsibly

Log check payload - agttydck

Encryptor - agttydck