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.
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
Share
17
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.
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.
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.
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.
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.
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.
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.
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.
How a Major Civil Engineering Company Reduced MTTR across Network, Email and the Cloud with Darktrace
Asking more of the information security team
“What more can we be doing to secure the company?” is a great question for any cyber professional to hear from their Board of Directors. After successfully defeating a series of attacks and seeing the potential for AI tools to supercharge incoming threats, a UK-based civil engineering company’s security team had the answer: Darktrace.
“When things are coming at you at machine speed, you need machine speed to fight it off – it’s as simple as that,” said their Information Security Manager. “There were incidents where it took us a few hours to get to the bottom of what was going on. Darktrace changed that.”
Prevention was also the best cure. A peer organization in the same sector was still in business continuity measures 18 months after an attack, and the security team did not want to risk that level of business disruption.
Legacy tools were not meeting the team’s desired speed or accuracy
The company’s native SaaS email platform took between two and 14 days to alert on suspicious emails, with another email security tool flagging malicious emails after up to 24 days. After receiving an alert, responses often took a couple of days to coordinate. The team was losing precious time.
Beyond long detection and response times, the old email security platform was no longer performing: 19% of incoming spam was missed. Of even more concern: 6% of phishing emails reached users’ inboxes, and malware and ransomware email was also still getting through, with 0.3% of such email-borne payloads reaching user inboxes.
Choosing Darktrace
“When evaluating tools in 2023, only Darktrace had what I was looking for: an existing, mature, AI-based cybersecurity solution. ChatGPT had just come out and a lot of companies were saying ‘AI this’ and ‘AI that’. Then you’d take a look, and it was all rules- and cases-based, not AI at all,” their Information Security Manager.
The team knew that, with AI-enabled attacks on the horizon, a cybersecurity company that had already built, fielded, and matured an AI-powered cyber defense would give the security team the ability to fend off machine-speed attacks at the same pace as the attackers.
Darktrace accomplishes this with multi-layered AI that learns each organization’s normal business operations. With this detailed level of understanding, Darktrace’s Self-Learning AI can recognize unusual activity that may indicate a cyber-attack, and works to neutralize the threat with precise response actions. And it does this all at machine speed and with minimal disruption.
On the morning the team was due to present its findings, the session was cancelled – for a good reason. The Board didn’t feel further discussion was necessary because the case for Darktrace was so conclusive. The CEO described the Darktrace option as ‘an insurance policy we can’t do without’.
Saving time with Darktrace / EMAIL
Darktrace / EMAIL reduced the discovery, alert, and response process from days or weeks to seconds .
Darktrace / EMAIL automates what was originally a time-consuming and repetitive process. The team has recovered between eight and 10 working hours a week by automating much of this process using / EMAIL.
Today, Darktrace / EMAIL prevents phishing emails from reaching employees’ inboxes. The volume of hostile and unsolicited email fell to a third of its original level after Darktrace / EMAIL was set up.
Further savings with Darktrace / NETWORK and Darktrace / IDENTITY
Since its success with Darktrace / EMAIL, the company adopted two more products from the Darktrace ActiveAI Security Platform – Darktrace / NETWORK and Darktrace / IDENTITY.
These have further contributed to cost savings. An initial plan to build a 24/7 SOC would have required hiring and retaining six additional analysts, rather than the two that currently use Darktrace, costing an additional £220,000 per year in salary. With Darktrace, the existing analysts have the tools needed to become more effective and impactful.
An additional benefit: Darktrace adoption has lowered the company’s cyber insurance premiums. The security team can reallocate this budget to proactive projects.
Detection of novel threats provides reassurance
Darktrace’s unique approach to cybersecurity added a key benefit. The team’s previous tool took a rules-based approach – which was only good if the next attack featured the same characteristics as the ones on which the tool was trained.
“Darktrace looks for anomalous behavior, and we needed something that detected and responded based on use cases, not rules that might be out of date or too prescriptive,” their Information Security Manager. “Our existing provider could take a couple of days to update rules and signatures, and in this game, speed is of the essence. Darktrace just does everything we need - without delay.”
Where rules-based tools must wait for a threat to emerge before beginning to detect and respond to it, Darktrace identifies and protects against unknown and novel threats, speeding identification, response, and recovery, minimizing business disruption as a result.
Looking to the future
With Darktrace in place, the UK-based civil engineering company team has reallocated time and resources usually spent on detection and alerting to now tackle more sophisticated, strategic challenges. Darktrace has also equipped the team with far better and more regularly updated visibility into potential vulnerabilities.
“One thing that frustrates me a little is penetration testing; our ISO accreditation mandates a penetration test at least once a year, but the results could be out of date the next day,” their Information Security Manager. “Darktrace / Proactive Exposure Management will give me that view in real time – we can run it daily if needed - and that’s going to be a really effective workbench for my team.”
As the company looks to further develop its security posture, Darktrace remains poised to evolve alongside its partner.
Inside Akira’s SonicWall Campaign: Darktrace’s Detection and Response
Introduction: Background on Akira SonicWall campaign
Between July and August 2025, security teams worldwide observed a surge in Akira ransomware incidents involving SonicWall SSL VPN devices [1]. Initially believed to be the result of an unknown zero-day vulnerability, SonicWall later released an advisory announcing that the activity was strongly linked to a previously disclosed vulnerability, CVE-2024-40766, first identified over a year earlier [2].
On August 20, 2025, Darktrace observed unusual activity on the network of a customer in the US. Darktrace detected a range of suspicious activity, including network scanning and reconnaissance, lateral movement, privilege escalation, and data exfiltration. One of the compromised devices was later identified as a SonicWall virtual private network (VPN) server, suggesting that the incident was part of the broader Akira ransomware campaign targeting SonicWall technology.
As the customer was subscribed to the Managed Detection and Response (MDR) service, Darktrace’s Security Operations Centre (SOC) team was able to rapidly triage critical alerts, restrict the activity of affected devices, and notify the customer of the threat. As a result, the impact of the attack was limited - approximately 2 GiB of data had been observed leaving the network, but any further escalation of malicious activity was stopped.
Threat Overview
CVE-2024-40766 and other misconfigurations
CVE-2024-40766 is an improper access control vulnerability in SonicWall’s SonicOS, affecting Gen 5, Gen 6, and Gen 7 devices running SonicOS version 7.0.1 5035 and earlier [3]. The vulnerability was disclosed on August 23, 2024, with a patch released the same day. Shortly after, it was reported to be exploited in the wild by Akira ransomware affiliates and others [4].
Almost a year later, the same vulnerability is being actively targeted again by the Akira ransomware group. In addition to exploiting unpatched devices affected by CVE-2024-40766, security researchers have identified three other risks potentially being leveraged by the group [5]:
*The Virtual Office Portal can be used to initially set up MFA/TOTP configurations for SSLVPN users.
Thus, even if SonicWall devices were patched, threat actors could still target them for initial access by reusing previously stolen credentials and exploiting other misconfigurations.
Akira Ransomware
Akira ransomware was first observed in the wild in March 2023 and has since become one of the most prolific ransomware strains across the threat landscape [6]. The group operates under a Ransomware-as-a-Service (RaaS) model and frequently uses double extortion tactics, pressuring victims to pay not only to decrypt files but also to prevent the public release of sensitive exfiltrated data.
The ransomware initially targeted Windows systems, but a Linux variant was later observed targeting VMware ESXi virtual machines [7]. In 2024, it was assessed that Akira would continue to target ESXi hypervisors, making attacks highly disruptive due to the central role of virtualisation in large-scale cloud deployments. Encrypting the ESXi file system enables rapid and widespread encryption with minimal lateral movement or credential theft. The lack of comprehensive security protections on many ESXi hypervisors also makes them an attractive target for ransomware operators [8].
Victimology
Akira is known to target organizations across multiple sectors, most notably those in manufacturing, education, and healthcare. These targets span multiple geographic regions, including North America, Latin America, Europe and Asia-Pacific [9].
Figure 1: Geographical distribution of organization’s affected by Akira ransomware in 2025 [9].
Common Tactics, Techniques and Procedures (TTPs) [7][10]
Initial Access Targets remote access services such as RDP and VPN through vulnerability exploitation or stolen credentials.
Reconnaissance Uses network scanning tools like SoftPerfect and Advanced IP Scanner to map the environment and identify targets.
Lateral Movement Moves laterally using legitimate administrative tools, typically via RDP.
Persistence Employs techniques such as Kerberoasting and pass-the-hash, and tools like Mimikatz to extract credentials. Known to create new domain accounts to maintain access.
Command and Control Utilizes remote access tools including AnyDesk, RustDesk, Ngrok, and Cloudflare Tunnel.
Exfiltration Uses tools such as FileZilla, WinRAR, WinSCP, and Rclone. Data is exfiltrated via protocols like FTP and SFTP, or through cloud storage services such as Mega.
Darktrace’s Coverage of Akira ransomware
Reconnaissance
Darktrace first detected of unusual network activity around 05:10 UTC, when a desktop device was observed performing a network scan and making an unusual number of DCE-RPC requests to the endpoint mapper (epmapper) service. Network scans are typically used to identify open ports, while querying the epmapper service can reveal exposed RPC services on the network.
Multiple other devices were also later seen with similar reconnaissance activity, and use of the Advanced IP Scanner tool, indicated by connections to the domain advanced-ip-scanner[.]com.
Lateral movement
Shortly after the initial reconnaissance, the same desktop device exhibited unusual use of administrative tools. Darktrace observed the user agent “Ruby WinRM Client” and the URI “/wsman” as the device initiated a rare outbound Windows Remote Management (WinRM) connection to two domain controllers (REDACTED-dc1 and REDACTED-dc2). WinRM is a Microsoft service that uses the WS-Management (WSMan) protocol to enable remote management and control of network devices.
Darktrace also observed the desktop device connecting to an ESXi device (REDACTED-esxi1) via RDP using an LDAP service credential, likely with administrative privileges.
Credential access
At around 06:26 UTC, the desktop device was seen fetching an Active Directory certificate from the domain controller (REDACTED-dc1) by making a DCE-RPC request to the ICertPassage service. Shortly after, the device made a Kerberos login using the administrative credential.
Figure 3: Darktrace’s detection of the of anomalous certificate download and subsequent Kerberos login.
Further investigation into the device’s event logs revealed a chain of connections that Darktrace’s researchers believe demonstrates a credential access technique known as “UnPAC the hash.”
This method begins with pre-authentication using Kerberos’ Public Key Cryptography for Initial Authentication (PKINIT), allowing the client to use an X.509 certificate to obtain a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC) instead of a password.
The next stage involves User-to-User (U2U) authentication when requesting a Service Ticket (ST) from the KDC. Within Darktrace's visibility of this traffic, U2U was indicated by the client and service principal names within the ST request being identical. Because PKINIT was used earlier, the returned ST contains the NTLM hash of the credential, which can then be extracted and abused for lateral movement or privilege escalation [11].
Figure 4: Flowchart of Kerberos PKINIT pre-authentication and U2U authentication [12]
Figure 5: Device event log showing the Kerberos Login and Kerberos Ticket events
Analysis of the desktop device’s event logs revealed a repeated sequence of suspicious activity across multiple credentials. Each sequence included a DCE-RPC ICertPassage request to download a certificate, followed by a Kerberos login event indicating PKINIT pre-authentication, and then a Kerberos ticket event consistent with User-to-User (U2U) authentication.
Darktrace identified this pattern as highly unusual. Cyber AI Analyst determined that the device used at least 15 different credentials for Kerberos logins over the course of the attack.
By compromising multiple credentials, the threat actor likely aimed to escalate privileges and facilitate further malicious activity, including lateral movement. One of the credentials obtained via the “UnPAC the hash” technique was later observed being used in an RDP session to the domain controller (REDACTED-dc2).
C2 / Additional tooling
At 06:44 UTC, the domain controller (REDACTED-dc2) was observed initiating a connection to temp[.]sh, a temporary cloud hosting service. Open-source intelligence (OSINT) reporting indicates that this service is commonly used by threat actors to host and distribute malicious payloads, including ransomware [13].
Shortly afterward, the ESXi device was observed downloading an executable named “vmwaretools” from the rare external endpoint 137.184.243[.]69, using the user agent “Wget.” The repeated outbound connections to this IP suggest potential command-and-control (C2) activity.
Figure 6: Cyber AI Analyst investigation into the suspicious file download and suspected C2 activity between the ESXI device and the external endpoint 137.184.243[.]69.
Figure 7: Packet capture (PCAP) of connections between the ESXi device and 137.184.243[.]69.
Data exfiltration
The first signs of data exfiltration were observed at around 7:00 UTC. Both the domain controller (REDACTED-dc2) and a likely SonicWall VPN device were seen uploading approximately 2 GB of data via SSH to the rare external endpoint 66.165.243[.]39 (AS29802 HVC-AS). OSINT sources have since identified this IP as an indicator of compromise (IoC) associated with the Akira ransomware group, known to use it for data exfiltration [14].
Figure 8: Cyber AI Analyst incident view highlighting multiple unusual events across several devices on August 20. Notably, it includes the “Unusual External Data Transfer” event, which corresponds to the anomalous 2 GB data upload to the known Akira-associated endpoint 66.165.243[.]39.
Cyber AI Analyst
Throughout the course of the attack, Darktrace’s Cyber AI Analyst autonomously investigated the anomalous activity as it unfolded and correlated related events into a single, cohesive incident. Rather than treating each alert as isolated, Cyber AI Analyst linked them together to reveal the broader narrative of compromise. This holistic view enabled the customer to understand the full scope of the attack, including all associated activities and affected assets that might otherwise have been dismissed as unrelated.
Figure 9: Overview of Cyber AI Analyst’s investigation, correlating all related internal and external security events across affected devices into a single pane of glass.
Containing the attack
In response to the multiple anomalous activities observed across the network, Darktrace's Autonomous Response initiated targeted mitigation actions to contain the attack. These included:
Blocking connections to known malicious or rare external endpoints, such as 137.184.243[.]69, 66.165.243[.]39, and advanced-ip-scanner[.]com.
Blocking internal traffic to sensitive ports, including 88 (Kerberos), 3389 (RDP), and 49339 (DCE-RPC), to disrupt lateral movement and credential abuse.
Enforcing a block on all outgoing connections from affected devices to contain potential data exfiltration and C2 activity.
Figure 10: Autonomous Response actions taken by Darktrace on an affected device, including the blocking of malicious external endpoints and internal service ports.
Managed Detection and Response
As this customer was an MDR subscriber, multiple Enhanced Monitoring alerts—high-fidelity models designed to detect activity indicative of compromise—were triggered across the network. These alerts prompted immediate investigation by Darktrace’s SOC team.
Upon determining that the activity was likely linked to an Akira ransomware attack, Darktrace analysts swiftly acted to contain the threat. At around 08:05 UTC, devices suspected of being compromised were quarantined, and the customer was promptly notified, enabling them to begin their own remediation procedures without delay.
A wider campaign?
Darktrace’s SOC and Threat Research teams identified at least three additional incidents likely linked to the same campaign. All targeted organizations were based in the US, spanning various industries, and each have indications of using SonicWall VPN, indicating it had likely been targeted for initial access.
Across these incidents, similar patterns emerged. In each case, a suspicious executable named “vmwaretools” was downloaded from the endpoint 85.239.52[.]96 using the user agent “Wget”, bearing some resemblance to the file downloads seen in the incident described here. Data exfiltration was also observed via SSH to the endpoints 107.155.69[.]42 and 107.155.93[.]154, both of which belong to the same ASN also seen in the incident described in this blog: S29802 HVC-AS. Notably, 107.155.93[.]154 has been reported in OSINT as an indicator associated with Akira ransomware activity [15]. Further recent Akira ransomware cases have been observed involving SonicWall VPN, where no similar executable file downloads were observed, but SSH exfiltration to the same ASN was. These overlapping and non-overlapping TTPs may reflect the blurring lines between different affiliates operating under the same RaaS.
Lessons from the campaign
This campaign by Akira ransomware actors underscores the critical importance of maintaining up-to-date patching practices. Threat actors continue to exploit previously disclosed vulnerabilities, not just zero-days, highlighting the need for ongoing vigilance even after patches are released. It also demonstrates how misconfigurations and overlooked weaknesses can be leveraged for initial access or privilege escalation, even in otherwise well-maintained environments.
Darktrace’s observations further reveal that ransomware actors are increasingly relying on legitimate administrative tools, such as WinRM, to blend in with normal network activity and evade detection. In addition to previously documented Kerberos-based credential access techniques like Kerberoasting and pass-the-hash, this campaign featured the use of UnPAC the hash to extract NTLM hashes via PKINIT and U2U authentication for lateral movement or privilege escalation.
Credit to Emily Megan Lim (Senior Cyber Analyst), Vivek Rajan (Senior Cyber Analyst), Ryan Traill (Analyst Content Lead), and Sam Lister (Specialist Security Researcher)
Appendices
Darktrace Model Detections
Anomalous Connection / Active Remote Desktop Tunnel
Anomalous Connection / Data Sent to Rare Domain
Anomalous Connection / New User Agent to IP Without Hostname
Anomalous Connection / Possible Data Staging and External Upload
Anomalous Connection / Rare WinRM Incoming
Anomalous Connection / Rare WinRM Outgoing
Anomalous Connection / Uncommon 1 GiB Outbound
Anomalous Connection / Unusual Admin RDP Session
Anomalous Connection / Unusual Incoming Long Remote Desktop Session
Anomalous Connection / Unusual Incoming Long SSH Session
Anomalous Connection / Unusual Long SSH Session
Anomalous File / EXE from Rare External Location
Anomalous Server Activity / Anomalous External Activity from Critical Network Device
Anomalous Server Activity / Outgoing from Server
Anomalous Server Activity / Rare External from Server
Compliance / Default Credential Usage
Compliance / High Priority Compliance Model Alert
Compliance / Outgoing NTLM Request from DC
Compliance / SSH to Rare External Destination
Compromise / Large Number of Suspicious Successful Connections
Compromise / Sustained TCP Beaconing Activity To Rare Endpoint
Device / Anomalous Certificate Download Activity
Device / Anomalous SSH Followed By Multiple Model Alerts
Device / Anonymous NTLM Logins
Device / Attack and Recon Tools
Device / ICMP Address Scan
Device / Large Number of Model Alerts
Device / Network Range Scan
Device / Network Scan
Device / New User Agent To Internal Server
Device / Possible SMB/NTLM Brute Force
Device / Possible SMB/NTLM Reconnaissance
Device / RDP Scan
Device / Reverse DNS Sweep
Device / Suspicious SMB Scanning Activity
Device / UDP Enumeration
Unusual Activity / Unusual External Data to New Endpoint
Unusual Activity / Unusual External Data Transfer
User / Multiple Uncommon New Credentials on Device
User / New Admin Credentials on Client
User / New Admin Credentials on Server
Enhanced Monitoring Models
Compromise / Anomalous Certificate Download and Kerberos Login
Device / Initial Attack Chain Activity
Device / Large Number of Model Alerts from Critical Network Device
Device / Multiple Lateral Movement Model Alerts
Device / Suspicious Network Scan Activity
Unusual Activity / Enhanced Unusual External Data Transfer
Antigena/Autonomous Response Models
Antigena / Network / External Threat / Antigena File then New Outbound Block
![Geographical distribution of organization’s affected by Akira ransomware in 2025 [9].](https://cdn.prod.website-files.com/626ff4d25aca2edf4325ff97/68e684a90c107be86fa5c2e0_Screenshot%202025-10-08%20at%207.53.20%E2%80%AFAM.png)
![Flowchart of Kerberos PKINIT pre-authentication and U2U authentication [12].](https://cdn.prod.website-files.com/626ff4d25aca2edf4325ff97/68e53a2b5e9394d5a5cbebb7_Screenshot%202025-10-07%20at%209.04.43%E2%80%AFAM.png)
![Cyber AI Analyst investigation into the suspicious file download and suspected C2 activity between the ESXI device and the external endpoint 137.184.243[.]69.](https://cdn.prod.website-files.com/626ff4d25aca2edf4325ff97/68e53a8ea01e348d5a62a6c3_Screenshot%202025-10-07%20at%209.06.31%E2%80%AFAM.png)
![Packet capture (PCAP) of connections between the ESXi device and 137.184.243[.]69.](https://cdn.prod.website-files.com/626ff4d25aca2edf4325ff97/68e53ae5304f84a4192967db_Screenshot%202025-10-07%20at%209.07.53%E2%80%AFAM.png)
![Cyber AI Analyst incident view highlighting multiple unusual events across several devices on August 20. Notably, it includes the “Unusual External Data Transfer” event, which corresponds to the anomalous 2 GB data upload to the known Akira-associated endpoint 66.165.243[.]39.](https://cdn.prod.website-files.com/626ff4d25aca2edf4325ff97/68e53b26d90343a0a6ab3bb2_Screenshot%202025-10-07%20at%209.09.02%E2%80%AFAM.png)
