Introduction

Virtual appliances are common in the cloud, 51.9% of cloud environments have at least one virtual appliance and 46.4% of those have exposed at least one virtual appliance to the Internet. They are often Internet-facing and commonly act as key network and security components, such as firewalls, gateways, WAFs, proxies, and SSL VPNs. These appliances also frequently operate with elevated privileges; for example, 65% of organizations using Aviatrix have instances with high control plane privileges. However, despite their critical role, these appliances often operate as “black boxes”. They typically do not support traditional security tooling such as EDR or antivirus agents, creating a significant visibility gap for security teams. The toxic combination of exposure and privilege makes them high-value targets for attackers. The limited monitoring makes them a weakness for defenders. 

What if you could overcome this visibility gap and gain real-time insight into these black boxes, for example, to identify when an attacker is actively exploiting a vulnerability?

Agentless visibility, provided by Wiz, enables proper threat detection, incident investigation and threat hunting capabilities on these critical appliances.

FortiGate, an operative example

FortiGate is Fortinet's series of next-generation firewalls (NGFW). It is widely deployed, with at least one instance found as a virtual appliance in 12% of cloud environments. Wiz Agentless Workload Detection fully supports these devices, extending EDR-like visibility to FortiGate by collecting local logs directly.

Virtual appliances are systematically targeted by adversaries due to the high-value access they provide and FortiGate is no exception. The 2026 FortiBleed campaign compromised credentials for ~75,000 FortiGate devices across 194 countries, roughly half of all internet-facing Fortigate firewalls. FortiGate devices have also been targeted by several campaigns involving vulnerability exploitation:

• Attackers recently exploited a zero-day in FortiOS (CVE-2026-24858) to authenticate, create local super-user accounts and delete logs to obscure movement.

• Amazon Threat Intelligence reported a threat actor scanning Fortigate devices for use of default credentials and exploiting older vulnerabilities (including CVE-2024-55591 and CVE-2024-23113)

• Salt Typhoon, a Chinese state-sponsored group, exploited vulnerabilities in Fortinet FortiClient EMS (CVE-2023-48788) to breach telecommunications networks.

• UNC3886 targeted FortiGate firewalls using CVE-2022-41328.

• Earth Kasha, linked to APT10, has leveraged Fortinet vulnerabilities in campaigns against organizations in Japan and Taiwan

Wiz customers can review a comprehensive list of threat actors that have historically targeted Fortinet products in the Threat Actors page.

Threat Hunting Playbook

Wiz achieves agentless visibility by gathering FortiGate logs that are not typically streamed, parsing these high-value events to expose potential attacker activity. The following section maps observed techniques to detection opportunities, what to hunt for, which events to monitor, and real-world examples from documented campaigns.

Initial Access

Credential Stuffing

Credential stuffing is a common initial access vector for FortiGate devices because internet-facing VPN and administrative login portals give attackers a direct authentication surface to target. Instead of exploiting a software vulnerability, attackers can use leaked or reused username-password pairs to authenticate as legitimate users.

Real-World Examples

During May 2026, Wiz research team detected a coordinated credential stuffing campaign targeting internet-exposed Fortinet admin panels across multiple cloud environments. The attack leveraged a botnet of 78+ shared IPs originating from Eastern European VPS providers, commercial VPNs, and residential proxies. Multiple environments were successfully compromised when attackers authenticated to FortiGate devices using weak or default credentials. 

What to Hunt For

• Successful login events immediately following a burst of failed attempts from the same source.

• Authentication originating from high-risk infrastructure, such as VPS providers (e.g., DigitalOcean, Linode, Vultr), commercial VPNs, IPs marked as malicious or Tor exit nodes.

• "Impossible travel" scenarios, where successive logins occur from geographically distant locations.

• Logins occurring outside of standard business hours or established patterns.

• Authentication attempts targeting default or common Fortigate administrative accounts (e.g., admin, support, backup, root).

Relevant Events

Wiz ingests FortiGate authentication logs that capture login activity in real time. The key events to monitor:

• Log ID 32002 - "Admin login failed" - Fires on every failed admin authentication attempt. Key fields:

  • user - the username being targeted

  • ui - source interface and IP (e.g., GUI(1.2.3.4), SSH(1.2.3.4))

  • reason - failure cause (e.g., name_invalid, passwd_invalid, mfa_failed)

• Log ID 32001 - "Admin login successful" - Fires on successful admin authentication. Key fields:

  • user - the authenticated username

  • ui - source interface and IP

  • method - authentication method (e.g., Password, FortiToken, SSO)

• Log ID 32003 - "Admin login disabled" - Fires when an account is locked due to too many failed attempts. Indicates active brute-force/credential stuffing in progress.

For Wizs’ agentless EDR customers, all those events are visible in the Cloud Event page.

Persistence and Account Manipulation

Admin Account Creation

Attackers who compromise FortiGate devices tend to create local administrator accounts for persistence, ensuring access survives credential resets or session terminations.

Real-World Examples

During active monitoring of CVE-2026-24858, we observed an attack chain that maps directly to the indicators above. The attacker first authenticated via SSO using the built-in sys_sso_forticloud_admin account with a disposable email address (support@openmail.pro) an immediate red flag visible in event “Admin login successful”.

Within minutes, they created a local admin account named backupadmin on the FortiGate device. The account was configured with super_admin privileges, no MFA, and trusthost=0.0.0.0/0 - exactly the weak configuration pattern described above.

What to Hunt For

• New admin accounts with super_admin profile, especially with generic names: support, ssl-admin, helpdesk, backup, itadmin, secadmin, remoteadmin, audit. For example Wiz customers can use this query to search for creation of an admin named helpdesk.

• Admin accounts created within minutes of an SSO or unusual login event (from an unusual IP for example).

• Weak account configuration: Admin accounts created with MFA disabled and trusthost set to 0.0.0.0/0 - this allows access from any IP, a hallmark of attacker-created backdoors (legitimate admins typically enforce MFA and restrict source IPs).
  Wiz customers can use this event query to search for creation of admin account with trusthost set to 0.0.0.0/0

date=2026-06-28 time=02:35:21 eventtime=1782639321258375620 tz=\"-0700\" logid=\"0100044547\" type=\"event\" subtype=\"system\" level=\"information\" vd=\"root\" logdesc=\"Object attribute configured\" user=\"admin\" ui=\"jsconsole([REDACTED])\" action=\"Add\" cfgtid=[REDACTED] cfgpath=\"system.admin\" cfgobj=\"helpdesk\" cfgattr=\"accprofile[super_admin]vdom[root]password[*]trusthost1[0.0.0.0 ---REDACTED---\" msg=\"Add system.admin helpdesk\"

Log entry indicating the creation of an admin user named helpdesk with trusthost set to 0.0.0.0.

Relevant Events

Wiz ingests local FortiGate logs that capture admin account changes in real time. The key events to monitor:

• Log ID 44547 - “Object attribute configured” - Fires when any config object is added, edited, or deleted. For admin account creation, look for cfgpath=system.admin with action=Add. Key fields to inspect:

  • cfgobj - the account name (e.g., ssl-admin, support)

  •  cfgattr - watch for accprofile[super_admin], two-factor[disable], trusthost1[0.0.0.0 255.255.255.0]

• Log ID 32001 - "Admin login successful" - Captures all admin logins, including SSO. Correlate with account creation events within 15 minutes to link the new account to the session that created it.

• Log ID 0021030002 - "CDB event log for object changed" (FortiManager) - Logs object changes pushed through FortiManager with subtype=objcfg. Useful when FortiGate devices are centrally managed.

Wiz customers can use Wiz to hunt for these events directly here or monitor the corresponding threat detection rules here.

Certificate Manipulation

FortiGate supports ACME protocol for automated certificate renewal. Organizations using ACME will see routine certificate events every 60-90 days. Detection logic should distinguish between:

• ACME-managed certificates - renewals are automated, typically logged with ACME-specific fields

• Manual certificate uploads - these should be tied to planned maintenance and performed by expected admin accounts.

Attackers may upload or modify certificates on FortiGate devices to enable man-in-the-middle attacks, establish alternate authentication paths, or maintain persistence. Certificate changes should be planned operations tied to known maintenance windows or automated renewal processes. Unexpected modifications especially following a suspicious login or new admin account creation.

Real-World Examples

While no public reports document attackers actively uploading malicious certificates, several third-party incident response advisories - including IBM X-Force, Beazley Security and S-RM - recommend rotating "admin credentials, including local administrator accounts, API tokens, certificates, and other credentials integrated with the firewall" after any FortiGate compromise.

What to Hunt For

• New or modified local certificates - especially self-signed certificates uploaded outside of normal change windows

• Certificate changes shortly after a suspicious login - correlate with event of “Admin login successful” to identify the session responsible

• Certificates with unusual names or attributes - attackers may use generic names like vpn-cert, ssl-cert, or names mimicking legitimate certificates

• SSL-VPN server certificate changes - modifying the SSL-VPN certificate could enable MitM attacks against connecting clients

date=2026-06-28 time=02:53:54 eventtime=1782640433536470215 tz=\"-0700\" logid=\"0100044548\" type=\"event\" subtype=\"system\" level=\"information\" vd=\"root\" logdesc=\"Action performed\" user=\"admin\" ui=\"jsconsole([REDACTED])\" action=\"Execute\" msg=\"execute vpn certificate local generate rsa attacker-cert3 2048 365 US CA \\\"San Francisco\\\" \\\"Attacker Org\\\" Security attacker3.local admin@attacker.local\"

VPN certificate generation - A local SSL/VPN certificate was created, allowing the attacker to establish persistent, authenticated VPN access to the network.

Relevant Events

• Log ID 41987 - "Certificate updated"

  • Fires when a VPN certificate is updated. Key fields:

    • cert-type - Local (FortiGate's identity) or CA (trust store)

    • name - the certificate name

    • method - operation type (e.g., renewed)

    • reason - why it was updated (e.g., acme for auto-renewal)

    • status - success or failure

• Log ID 41990 - "Certificate update failed"

  • Fires on failed certificate updates - may indicate attacker trial-and-error.

• Log ID 44547 - "Object attribute configured" - 

  • Fires on certificate configuration changes. Look for:

    • cfgpath - vpn.certificate.local (FortiGate's identity, includes private keys) or vpn.certificate.ca (trust store for validating other certificates)

    • cfgobj - the certificate name

    • action - Add, Edit, or Delete

    • user - who made the change:

      • System account (e.g., FGT_ha_admin) - automated/HA activity

      • username@FortiManager - pushed from FortiManager

      • Human admin account - manual change

    • ui - where the change originated:

    • cfgattr - attribute changes in [old->new] format

• Log ID 44548 - "Action performed" - fires when CLI commands are executed. Key fields:

  • action - the operation type (e.g., Execute, Show)

  • msg - the full command executed

  • user - who ran the command

  • ui - where it originated (e.g., jsconsole, ssh, console)

Wiz customers can use this query to search for “Action performed” events related to certificate changes.

Suspicious Admin Email Domains

FortiCloud SSO allows administrators to authenticate using their FortiCloud account email. Attackers exploiting SSO bypass vulnerabilities often use disposable or newly-created email addresses to avoid attribution and evade detection.

Real-World Examples

As mentioned above, in observed attacks, threat actors used disposable email domains to create SSO admin accounts. Wiz customers can use these threat detection rules to detect this kind of activity.

What to Hunt For

• Known malicious email patterns observed in FortiCloud SSO attacks:

  • cloud-init@mail.io, cloud-noc@mail.io

  • *@tutamail.com, *@openmail.pro, *@protonmail.com (privacy-focused providers observed being used by attackers).

• Email anomalies:

  • Disposable email domains - temporary addresses that self-destruct

  • Emails that don't match your organization's domain or known admin accounts

  • Email from domains that were recently registered

• Behavioral pattern: SSO login from unfamiliar email → admin account creation → SSO account deletion (to cover tracks)

• Low actor count domains: A domain used by a small number of actors may indicate a compromised or rogue account

Relevant Events

• Log ID 32001 - "Admin login successful" - Captures all admin logins including FortiCloud SSO. Look for the user field containing the SSO email address. Flag logins where the email domain doesn't match expected organizational domains or appears on disposable email lists.

• Log ID 44547 - "Object attribute configured" - Correlate with action=Delete on cfgpath=system.admin — attackers often delete the SSO user after

• Log ID 0021030002 - “‘CDB event log for object changed” (FortiManager) - Logs SSO admin creation pushed through FortiManager. Key fields:

  • operation - look for add

  • type - sys_sso_forticloud_admin indicates an SSO admin account

  • key - contains the email address (e.g., cloud-noc@mail.io)

  • performed_on - the target device

NAT/Port Forwarding Abuse

Real-World Examples

Detecting the creation of overly permissive firewall policies (e.g., "allow all") or the deletion of logs to hide attacker activity (as seen in the CVE-2026-24858 exploitation). Specifically, hunt for a full device configuration download by identifying logins or actions originating from unusual IPs or external IP addresses.

What to Hunt For

Attackers frequently abuse NAT configurations to establish persistent backdoors. This is a critical detection area often overlooked in traditional security monitoring.

• External DNAT mapping - cfgpath="firewall.vip" with mappedip pointing to external/public IPs 

• Sensitive port forwarding - Port forwards to 22, 3389, 445, 1433, 3306, 5432 

• Allow All VIP - VIP exposing internal services to 0.0.0.0 or "any"

date=2026-06-28 time=03:12:04 eventtime=1782641523790545244 tz=\"-0700\" logid=\"0100044547\" type=\"event\" subtype=\"system\" level=\"information\" vd=\"root\" logdesc=\"Object attribute configured\" user=\"admin\" ui=\"jsconsole([REDACTED])\" action=\"Add\" cfgtid=272105472 uuid=\"8ef09ed4-72d9-51f1-8f90-626a1db31f0c\" cfgpath=\"firewall.vip\" cfgobj=\"backdoor-ssh\" cfgattr=\"extip[0.0.0.0]mappedip[10.100.69.84]extintf[port1]portforward[enable]extport[2222]mappedport[22]\" msg=\"Add firewall.vip backdoor-ssh\"

Port forwarding rule creation, a VIP configuration was added to forward external traffic on port 2222 to an internal server's SSH port (22), allowing anyone on the internet to SSH directly into internal infrastructure through the firewall.

Relevant Events

Wiz ingests FortiGate configuration change logs that capture VIP and firewall policy modifications in real time. The key events to monitor:

• Log ID 44547 - "Object attribute configured" - Fires when NAT/VIP objects are created, modified, or deleted. Key fields:

  • cfgpath - watch for:

    • firewall.vip - Virtual IP (DNAT) configurations

    • firewall.vip6 - IPv6 Virtual IPs

    • firewall.ippool - Source NAT pools

    • firewall.policy - Firewall policies referencing VIPs

  • cfgobj - the VIP or policy name

  • action - Add, Edit, or Delete

  • cfgattr - attribute changes in [old->new] format. Watch for:

  • extip - external IP being mapped

  • mappedip - internal destination IP (attackers may point to external C2)

  • extport - external port

  • mappedport - internal port (watch for 22, 3389, 445, 1433, 3306, 5432)

  • portforward[enable] - port forwarding enabled

  • user - who made the change

  • ui - source interface (GUI, CLI, FortiManager)

• Log ID 44546 - "Configuration changed" - Fires on broader configuration commits. Useful for detecting bulk NAT changes or configuration imports that may include malicious VIPs.

• Log ID 0021030002 - "CDB event log for object changed" (FortiManager) - Logs VIP/policy changes pushed through FortiManager. Key fields:

  • operation - add, edit, or delete

  • category - firewall/vip or firewall/policy

  • performed_on - the target FortiGate device

  • user - the FortiManager admin account

Defense Evasion & Reconnaissance

Configuration Changes and Downloads

Attackers who compromise FortiGate devices often export the configuration file to extract credentials. FortiOS uses reversible encryption for stored credentials - meaning attackers can decrypt embedded service accounts, LDAP bind passwords, VPN pre-shared keys, and certificate private keys.

Real-World Examples

AWS documented a campaign that compromised over 600 FortiGate devices across 55+ countries. Attackers targeted configuration files for SSL-VPN credentials, admin credentials, and network topology. They developed AI-assisted Python scripts to parse and decrypt stolen configurations at scale, then used automated tools to scan internal networks and perform DCSync attacks.

In another Sentinelone investigation, an attacker created a local admin account named ssl-admin, then immediately executed show full-configuration to extract the FortiGate config. They decrypted embedded LDAP credentials for the fortidcagent service account and used those cleartext credentials to authenticate to Active Directory - all within 10 minutes of initial access.

Wiz customers can view those events using this query.

date=2026-06-28 time=03:13:44 eventtime=1782641624262136416 tz=\"-0700\" logid=\"0100044548\" type=\"event\" subtype=\"system\" level=\"information\" vd=\"root\" logdesc=\"Action performed\" user=\"admin\" ui=\"jsconsole([REDACTED])\" action=\"Show\" msg=\"show full-configuration\"

Configuration exfiltration. The full firewall configuration was dumped

What to Hunt For

• Configuration downloads by unexpected users - especially newly-created admin accounts or accounts that don't normally perform backups

• Downloads shortly after suspicious login or admin account creation

• Downloads outside of maintenance windows - legitimate backups are typically scheduled or occur during planned maintenance

• Multiple configuration downloads in a short period - may indicate attacker extracting configs from multiple devices

• Configuration changes to sensitive areas - firewall policies, VPN settings, routing rules, logging settings (attackers may disable logging)

Relevant Events

• Log ID 32095 - "Admin performed an action from GUI" - Fires when an admin performs actions via the GUI. For config downloads, look for:

  • action="download"

  • msg containing "System config file has been downloaded"

  • user - who initiated the download

  • ui - source interface and IP (e.g., GUI(144.31.1.252))

  • status - success or failure

• Log ID 44546 - "Configuration changed" - Fires on broader configuration modifications. Useful for tracking bulk changes.

• Log ID 44547 - "Object attribute configured" - Fires when configuration objects are modified, essentially anything you'd see in show config or change via GUI/CLI settings. Key fields:

  • cfgpath - what was changed (e.g., system.admin, firewall.policy, log.setting)

  • cfgobj - the specific object modified

  • action - Add, Edit, or Delete

  • user - who made the change

  • ui - where it originated from

  • cfgattr - attribute changes in [old->new] format

Lateral Movement and C2 Communication

FortiManager Script Abuse

FortiManager's centralized management capabilities allow administrators to deploy scripts to managed FortiGate devices. Attackers who compromise FortiManager or gain access to a privileged account can abuse this feature to push malicious scripts across the entire fleet.

Real-World Examples

Google Threat Intelligence documented a campaign where UNC3886 (suspected China-nexus actor) compromised FortiManager and used script deployment to push backdoors to FortiGate devices. Scripts exploited CVE-2022-41328 (directory traversal) to deploy the CASTLETAP backdoor, then pivoted to VMware ESXi hypervisors.

What to Hunt For

Hunt for scripts pushed from FortiManager, especially those creating admin accounts or modifying security policies, search for:

• Scripts executed by unexpected users - especially accounts not part of normal change management

• Scripts deployed outside maintenance windows - legitimate deployments are typically planned

• Scripts targeting all devices or unusual device groups - attackers may push to the entire fleet

• Scripts with suspicious content - directory traversal (../), shell commands, or references to /bin/, /tmp

Relevant Events

• Log ID 44548 - “Action performed” - Fires when CLI commands are executed. Key fields:

  • msg - the actual command executed (e.g., diag sys ha checksum show)

  • user - who ran it (admin account, FortiManager, etc.)

  • ui - interface (ha_daemon, fgfmd, CLI, jsconsole)

  • action - command category (Diagnose, Execute, Config)

• Log ID 32052 - "Upload and run a script" - Fires when FortiManager pushes a script to a FortiGate device. Key fields:

  • user - the FortiManager account that deployed the script

  • ui="fgfmd" - FortiGate-FortiManager daemon (confirms script came from FortiManager)

  • msg - contains the script ID (not the script content)

Network Communication Hunting

FortiGate logs provide detailed network flow information - both traffic passing through the firewall and traffic originating from the firewall itself. This data enables hunting for malicious communications that endpoint tools may miss.

Real-World Examples

As mentioned above, UNC3886 deployed the CASTLETAP backdoor (/bin/fgfm) directly on compromised FortiGate devices. The backdoor used ICMP port knocking for covert C2 communication. This traffic originated from the firewall itself, meaning it would appear in subtype="local" logs, not subtype="forward". Hunting for unexpected ICMP traffic (proto=1) from the FortiGate to external IPs could surface this type of compromise.

What to Hunt For

This data enables hunting for:

• Connections to known malicious IP addresses

• Anomalous communication patterns involving unusual ports, protocols or destinations

• Traffic from the FortiGate device itself to unexpected external destinations

High-Value services to hunt for:

• Remote Access Tools - AnyDesk, TeamViewer, LogMeIn, RustDesk, ScreenConnect, Splashtop 

• C2 Frameworks ports - Cobalt Strike (50050), Metasploit (4444), Empire

• Cryptocurrency Mining ports

• Data Exfiltration - FTP, TFTP, SMB to external IPs 

Relevant Events

 Wiz ingest FortiGate traffic logs that capture network flows with different subtypes:

• subtype="forward" - traffic passing through the firewall (e.g., internal host to external server)

• subtype="local" - traffic originating from or destined to the firewall itself (e.g., FortiGuard updates, NTP sync, syslog, or if compromised, C2 communication from a backdoor running on the device)

Both are critical for detection:

• Forward traffic reveals compromised hosts behind the firewall - C2 beacons, exfiltration, lateral movement

• Local traffic reveals a compromised firewall itself - backdoors, unauthorized outbound connections from the device

date=2026-06-28 time=03:17:31 eventtime=1782641850911362543 tz=\"-0700\" logid=\"0001000014\" type=\"traffic\" subtype=\"local\" level=\"notice\" vd=\"root\" srcip=10.100.69.84 identifier=1 srcintf=\"root\" srcintfrole=\"undefined\" dstip=8.8.8.8 dstintf=\"port1\" dstintfrole=\"undefined\" srccountry=\"Reserved\" dstcountry=\"United States\" sessionid=1395 proto=1 action=\"accept\" policyid=0 service=\"PING\" trandisp=\"noop\" app=\"PING\" duration=64 sentbyte=420 rcvdbyte=420 sentpkt=5 rcvdpkt=5

Outbound connectivity example - The firewall pinged Google DNS (8.8.8.8)

Device-Type Behavioral Anomalies

FortiGate's device detection service identifies devices on the network and logs their type in 

traffic logs. Hunting for mismatches between device type and network behavior can surface compromised devices or attackers masquerading as legitimate endpoints.

Real-World Examples

Compromised IoT devices are frequently used as entry points or pivot points because they often have weak security, default credentials, and no endpoint agents. For example, Kaspersky documented an attack where actors, blocked by EDR on workstations, pivoted to an IP camera with outdated firmware to deploy ransomware - bypassing endpoint detection entirely.

What to Hunt For

Hunt for anomalies where a device type exhibits unexpected network behavior, for example:

• A printer initiating SSH connections

• An IoT device connecting to known C2 ports

• New device using suspicious ports

Relevant Events

FortiGate traffic logs include device type information when device detection is enabled. Key fields:

• devtype - source device type (e.g., Windows PC, Linux PC, IP Phone, Printer, Router/NAT Device)

• osname - operating system (e.g., Windows 8.1, Linux, Fortinet OS)

• srcip, srcmac - source identifiers

• dstip, dstport - destination being contacted

• service - protocol/service (e.g., SSH, HTTPS, DNS)

How to enable Agentless Workload Detection?

1. Enable Defend Agentless Workload Detection through the Preview Hub.

2. Verify that workload/machine log ingestion is enabled in the Event Management settings.

3. To ensure Fortigate logs are collected, make sure Non-OS disk scanning is enabled.

Wiz Agentless Workload Detection automatically collects the necessary local logs from these appliances with zero deployment friction and ingests them directly into the Wiz platform for continuous analysis. The logs are correlated with cloud control plane events and runtime signals through built-in threat detection rules to provide deeper context, allowing security researchers to trace lateral movement and group suspicious activities into a complete cloud kill-chain narrative.

Conclusion

Virtual appliances like FortiGate represent a critical blind spot in cloud security: Internet-facing, highly privileged, and incompatible with traditional EDR agents. By leveraging Wiz's agentless log collection, security teams can extend threat hunting capabilities to these devices, detecting post-exploitation persistence, NAT abuse, lateral movement, and coordinated cross-tenant campaigns that would otherwise remain invisible.