April 12, 2023

P2Pinfect - New Variant Targets MIPS Devices

A new P2Pinfect variant compiled for the Microprocessor without Interlocked Pipelined Stages (MIPS) architecture has been discovered. This demonstrates increased targeting of routers, Internet of Things (IoT) and other embedded devices by those behind P2Pinfect.

Written by

The Darktrace Community

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

The Darktrace Community

Apr 2023

Introduction: P2PInfect

Since July 2023, researchers at Cado Security Labs (now part of Darktrace) have been monitoring and reporting on the rapid growth of a cross-platform botnet, named “P2Pinfect”. As the name suggests, the malware - written in Rust - acts as a botnet agent, connecting infected hosts in a peer-to-peer topology. In early samples, the malware exploited Redis for initial access - a relatively common technique in cloud environments. 

There are a number of methods for exploiting Redis servers, several of which appear to be utilized by P2Pinfect. These include exploitation of CVE-2022-0543 [1] - a sandbox escape vulnerability in the LUA scripting language (reported by Unit42 [2]), and, as reported previously by Cado Security Labs, an unauthorized replication attack resulting in the loading of a malicious Redis module.  

Researchers have since encountered a new variant of the malware, specifically targeting embedded devices based on 32-bit MIPS processors, and attempting to brute force SSH access to these devices. It’s highly likely that by targeting MIPS, the P2Pinfect developers intend to infect routers and IoT devices with the malware. Use of MIPS processors is common for embedded devices and the architecture has been previously targeted by botnet malware, including high-profile families like Mirai [3], and its variants/derivatives.

Not only is this an interesting development in that it demonstrates a widening of scope for the developers behind P2Pinfect (more supported processor architectures equals more nodes in the botnet itself), but the MIPS32 sample includes some notable defense evasion techniques. 

This, combined with the malware’s utilization of Rust (aiding cross-platform development) and rapid growth of the botnet itself, reinforces previous suggestions that this campaign is being conducted by a sophisticated threat actor.

Initial access

Cado researchers encountered the MIPS variant of P2Pinfect after triaging files uploaded via SFTP and SCP to a SSH honeypot. Although earlier variants had been observed scanning for SSH servers, and attempting to propagate the malware via SSH as part of its worming procedure, researchers had yet to observe successful implantation of a P2Pinfect sample using this method - until now.

In keeping with similar botnet families, P2Pinfect includes a number of common username/password pairs embedded within the MIPS binary itself. The malware will then iterate through these pairs, initiating a SSH connection with servers identified during the scanning phase to conduct a brute force attack. 

It was assumed that SSH would be the primary method of propagation for the MIPS variant, due to routers and other embedded devices being more likely to utilize SSH. However, additional research shows that it is in fact possible to run the Redis server on MIPS. This is achievable via an OpenWRT package named redis-server. [4]

It is unclear what use-case running Redis on an embedded MIPS device solves, or whether it is commonly encountered in the wild. If such a device is compromised by P2Pinfect and has the Redis-server package installed, it is perfectly feasible for that node to then be used to compromise new peers via one of the reported P2Pinfect attack patterns, involving exploitation of Redis or SSH brute-forcing.

Static analysis

The MIPS variant of P2Pinfect is a 32-bit, statically-linked, ELF binary with stripped debug information. Basic static analysis revealed the presence of an additional ELF executable, along with a 32-bit Windows DLL in the PE32 format - more on this later. 

This piqued the interest of Cado analysts, as it is unusual to encounter a compiled ELF with an embedded DLL. Consequently, it was a defining feature of the original P2Pinfect samples.

Figure 1: Embedded Windows PE32 executable

Further analysis of the host executable revealed a structure named “BotnetConf” with members consistent in naming with the original P2Pinfect samples. 

Figure 2: Example of a partially populated version of the BotnetConf struct

As the name suggests, this structure defines the configuration of the malware itself, whilst also storing the IP addresses of nodes identified during the SSH and Redis scans. This, in combination with the embedded ELF and DLL, along with the use of the Rust programming language allowed for positive attribution of this sample to the P2Pinfect family.

Updated evasion - consulting tracerpid

One of the more interesting aspects of the MIPS sample was the inclusion of a new evasion technique. Shortly after execution, the sample calls fork() to spawn a child process. 

The child process then proceeds to access /proc using openat(), determines its own Process Identifier (PID) using the Linux getpid() syscall, and then uses this PID to consult the relevant /proc subdirectory and read the status file within that. Note that this is likely achieved in the source code by resolving the symbolic link at /proc/self/status.

‍

Figure 3: Example contents of /proc/pid/status when process not being traced

/proc/<pid>/status contains human-readable metadata and other information about the process itself, including memory usage and the name of the command currently being run. Importantly, the status file also contains a field TracerPID:. This field is assigned a value of 0 if the current process is not being traced by dynamic analysis tools, such as strace and ltrace.

Figure 4: Example MIPS disassembly showing reading of /proc/pid/status file

If this value is non-zero, the MIPS variant of P2Pinfect determines that it is being analyzed and will immediately terminate both the child process and its parent. 

read(5, "Name:\tmips_embedded_p\nUmask:\t002", 32) = 32 
read(5, "2\nState:\tR (running)\nTgid:\t975\nN", 32) = 32 
read(5, "gid:\t0\nPid:\t975\nPPid:\t1\nTracerPid:\t971\nUid:\t0\t0\t0\t0\nGid:\t0\t0\t0\t0", 64) = 64 
read(5, "\nFDSize:\t32\nGroups:\t0 \nNStgid:\t975\nNSpid:\t975\nNSpgid:\t975\nNSsid:\t975\nVmPeak:\t    3200 kB\nVmSize:\t    3192 kB\nVmLck:\t       0 kB\n", 128) = 128 
read(5, "VmPin:\t       0 kB\nVmHWM:\t    1564 kB\nVmRSS:\t    1560 kB\nRssAnon:\t      60 kB\nRssFile:\t    1500 kB\nRssShmem:\t       0 kB\nVmData:\t     108 kB\nVmStk:\t     132 kB\nVmExe:\t    2932 kB\nVmLib:\t       8 kB\nVmPTE:\t      16 kB\nVmSwap:\t       0 kB\nCoreDumping:\t0\nThre", 256) = 256 
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x77ff1000 
read(5, "ads:\t1\nSigQ:\t0/1749\nSigPnd:\t00000000000000000000000000000000\nShdPnd:\t00000000000000000000000000000000\nSigBlk:\t00000000000000000000000000000000\nSigIgn:\t00000000000000000000000000001000\nSigCgt:\t00000000000000000000000000000600\nCapInh:\t0000000000000000\nCapPrm:\t0000003fffffffff\nCapEff:\t0000003fffffffff\nCapBnd:\t0000003fffffffff\nCapAmb:\t0000000000000000\nNoNewPrivs:\t0\nSeccomp:\t0\nSpeculation_Store_Bypass:\tunknown\nCpus_allowed:\t1\nCpus_allowed_list:\t0\nMems_allowed:\t1\nMems_allowed_list:\t0\nvoluntary_ctxt_switches:\t92\nn", 512) = 512 
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x77fef000 
munmap(0x77ff1000, 4096)                = 0 
read(5, "onvoluntary_ctxt_switches:\t0\n", 1024) = 29 
read(5, "", 995)                        = 0 
close(5)                                = 0 
munmap(0x77fef000, 8192)                = 0 
sigaltstack({ss_sp=NULL, ss_flags=SS_DISABLE, ss_size=8192}, NULL) = 0 
munmap(0x77ff4000, 12288)               = 0 
exit_group(-101)                        = ? 
+++ exited with 155 +++

Strace output demonstrating TracerPid evasion technique

Updated evasion - disabling core dumps

Interestingly, the sample will also attempt to disable Linux core dumps. This is likely used as an anti-forensics procedure as the memory regions written to disk as part of the core dump can often contain internal information about the malware itself. In the case of P2Pinfect, this would likely include information such as IP addresses of connected peers and the populated BotnetConf structure mentioned previously. 

It is also possible that the sample prevents core dumps from being created to protect the availability of the MIPS device itself. Low-powered embedded devices are unlikely to have much local storage available and core dumps could quickly fill what little storage they do have, affecting performance of the device itself.

A screen shot of a computer codeAI-generated content may be incorrect. — Image 5

This procedure can be observed during dynamic analysis, with the binary utilising the prctl() syscall and passing the parameters PR_SET_DUMPABLE, SUID_DUMP_DISABLE.

munmap(0x77ff1000, 4096)                = 0 
prctl(PR_SET_DUMPABLE, SUID_DUMP_DISABLE) = 0 
prlimit64(0, RLIMIT_CORE, {rlim_cur=0, rlim_max=0}, NULL) = 0

Example strace output demonstrating disabling of core dumps

Embedded DLL

As mentioned in the Static Analysis section, the MIPS variant of P2Pinfect includes an embedded 64-bit Windows DLL. This DLL acts as a malicious loadable module for Redis, implementing the system.exec functionality to allow the running of shell commands on a compromised host.

Figure 6: Disassembly of the Redis module entrypoint, mapping the system.exec command to a handler

This is consistent with the previous examples of P2Pinfect, and demonstrates that the intention is to utilize MIPS devices for the Redis-specific initial access attack patterns mentioned throughout this blog. 

Interestingly, this embedded DLL also includes a Virtual Machine (VM) evasion function, demonstrating the lengths that the P2Pinfect developers have taken to hinder the analysis process. In the DLLs main function, a call can be observed to a function helpfully labelled anti_vm by IDAs Lumina feature.

Figure 7: Decompiler output showing call to anti_vm function

Viewing the function itself, it can be seen that researchers Christopher Gardner and Moritz Raabe have identified it as a known VM evasion method in other malware samples.

Figure 8: IDA’s graph view for the anti_vm function showing Lumina annotations

Conclusion

P2Pinfect’s continued evolution and broadened targeting appear to be the utilization of a variety of evasion techniques demonstrate an above-average level of sophistication when it comes to malware development. This is a botnet that will continue to grow until it’s properly utilized by its operators. 

While much of the functionality of the MIPS variant is consistent with the previous variants of this malware, the developer’s efforts in making both the host and embedded executables as evasive as possible show a continued commitment to complicating the analysis procedure. The use of anti-forensics measures such as the disabling of core dumps on Linux systems also supports this.

Indicators of compromise (IoCs)

Files SHA256

MIPS ELF 8b704d6334e59475a578d627ae4bcb9c1d6987635089790350c92eafc28f5a6c

Embedded DLL Redis Module  d75d2c560126080f138b9c78ac1038ff2e7147d156d1728541501bc801b6662f

References:

[1] https://nvd.nist.gov/vuln/detail/CVE-2022-0543

[2] https://unit42.paloaltonetworks.com/peer-to-peer-worm-p2pinfect/

[3] https://unit42.paloaltonetworks.com/mirai-variant-iz1h9/

[4] https://openwrt.org/packages/pkgdata/redis-server

Written by

The Darktrace Community

Inside the SOC

Written by

The Darktrace Community

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: P2Pinfect - New Variant Targets MIPS Devices

P2Pinfect - New Variant Targets MIPS Devices

Introduction: P2PInfect

Initial access

Static analysis

Updated evasion - consulting tracerpid

Updated evasion - disabling core dumps

Embedded DLL

Conclusion

Indicators of compromise (IoCs)

Files SHA256

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