In September 2024, attackers gained control of a centralized FortiManager appliance operated by a telecommunications organization. According to Palo Alto Networks’ Unit 42, the intrusion involved cluster CL-STA-0954, also associated with UNC5820, and exposed information tied to more than 500 managed FortiGate firewalls.
The affected firewalls guarded both the provider’s infrastructure and customer networks. Yet the investigation did not establish that every customer environment was entered. What Unit 42 confirmed was theft of configuration and credential data, followed by unauthorized activity on downstream systems.
That distinction is crucial. It prevents the findings from being overstated while still showing how compromising a central management layer can magnify risk across an entire managed-service operation.
A central appliance opened the door
Initial access came through CVE-2024-47575, a FortiManager flaw also known as FortiJump. By sending specially formed traffic to the management channel, someone without valid FortiManager credentials could obtain command-level control.
Unit 42 saw the threat actors introduce a bogus virtual appliance under the name `localhost`. The registration originated from attacker-controlled infrastructure and was attached to the organization’s central FortiManager shortly before the theft began.
The attackers then placed a configuration archive named `.tm` inside the FortiManager file system and removed it from the appliance. Its contents included active firewall configurations, cryptographic assets and database files covering more than 500 FortiGate devices.
For defenders, this is more than a single-server compromise. FortiManager served as a control point for a large defensive estate. Once attackers reached it, they could obtain device details and sensitive secrets without separately breaching each firewall.
Stolen data enabled movement downstream
Following an extended period inside the management system, the attackers sent unauthorized sniffing rules to several FortiGate firewalls under its control. Those rules collected plaintext web traffic alongside communications from 11 designated services across a range of TCP ports.
The objective was twofold: observe sensitive traffic and understand where network boundaries lay. Unit 42 also found that the stolen configurations contained credentials protected with reversible encryption. Researchers successfully reconstructed administrative and SSL/VPN passwords from those files.
Those recovered passwords were not merely evidence of exposure. The attackers put them to use, opening FortiGate SSL/VPN sessions from external staging infrastructure. Unit 42 determined that the resulting authenticated sessions reached internal network-management areas.
The sequence shows why management-plane output needs protection beyond ordinary file controls. Exported configurations can reveal topology, active services and reusable access material. In this case, that information supported both immediate password recovery and later movement toward internal systems.
PEERSTITCH exploited trusted activity
The attackers also used CVE-2025-61624, a FortiOS auto-script path-traversal weakness, to move from administrative access to root privileges on the underlying operating system. A restricted FortiOS administrator normally has no shell access or direct control over operating-system files and processes, but the flaw crossed that boundary.
Unit 42 observed the deployment of PEERSTITCH, novel ARM64 malware designed to remain in memory. It leaves no malware binary behind on disk, creates no listening socket and generates no outbound connection of its own.
Instead, PEERSTITCH conducts its communication through activity produced by legitimate software running on the infected host. That design can evade conventional detection methods centered on suspicious file creation, exposed ports or plainly visible command-and-control traffic.
Another element expanded the attackers’ reach: they posed as FortiManager when interacting with firewalls belonging to other hosts in the targeted network. Their approach combined appliance exploitation, credential recovery, downstream surveillance and abuse of an expected management relationship.
Why the management layer warrants special protection
The case illustrates a broader management-plane risk. Compromising an ordinary server may expose one application or dataset. Compromising a central appliance can instead provide a blueprint for many protected systems and a path toward their access credentials.
For the telecommunications provider, that meant both internal infrastructure and client environments sat within the potential blast radius. The confirmed findings should not be reframed as evidence of intrusion into every customer network. Still, the attackers did more than collect a database: they recovered credentials, opened management sessions and pushed unauthorized configurations to downstream firewalls.
Managed-service providers face an additional trust challenge. Customers may assume that specialist operators are protecting both the firewalls and the credentials needed to administer them. A breach of the central manager weakens that assumption because one exposed secret may work across multiple separately administered environments.
Decision checklist: assess the exposure
- Determine whether the FortiManager installation was exposed to CVE-2024-47575, then review management records for signs of unauthorized access.
- Compare the complete virtual-appliance inventory with expected registrations. Unit 42 found one named `localhost`, but defenders should investigate any unexplained device rather than limit the search to that label.
- Examine configuration archives, backups, cryptographic material and credential databases retained by FortiManager.
- Replace administrative, SSL/VPN and other reusable secrets that may have appeared in exposed management data.
- Review FortiGate SSL/VPN logs for established sessions originating from unfamiliar external systems, particularly when valid credentials were used.
- Check downstream firewalls for unauthorized packet-capture rules, auto-script modifications and path-traversal activity linked to CVE-2025-61624.
- Hunt for PEERSTITCH-related behavior without relying solely on disk artifacts, open ports or obvious outbound sessions.
- Identify whether the stolen credentials or management sessions led to access beyond the firewalls already associated with the compromised provider.
What to watch next
Several questions remain important: how many downstream firewalls received unauthorized commands, whether further customer credentials can be reconstructed, whether attacker-created sessions or scripts remain active and whether any PEERSTITCH instances survive in memory.
Defenders should also watch for a repeatable pattern elsewhere. The attackers benefited from a centralized manager, exposed device configurations, recoverable credentials and the ability to appear as a trusted FortiManager system. Any organization with a similarly concentrated management architecture should consider how one stolen configuration archive could affect numerous downstream defenses.
Unit 42 did not conclude that every protected customer network was breached. The evidence does show that compromising one management appliance can reveal and threaten an entire defensive estate. Centralized control demands security controls proportionate to that reach.
Key takeaways
- View centralized management appliances as high-value repositories of reusable secrets, not simply administrative servers.
- Rotate administrative and VPN credentials when stored configurations, archives or databases may have been exposed.
- Inspect downstream firewalls for unauthorized packet capture, auto-script abuse and unexpected management sessions.
- Keep confirmed configuration exposure separate from confirmed customer-network intrusion while acting on both risks.
- Build detection around behavior rather than assuming malware will create files, ports or direct outbound connections.
Frequently asked questions
Did the attackers enter every client network managed by the provider?
There is no such finding. Unit 42 investigated the provider’s environment but did not inspect the customer networks. The report documents exposed configurations and credentials, plus unauthorized activity involving downstream firewalls.
How did the attackers first reach FortiManager?
They exploited CVE-2024-47575. Special requests to the FortiManager management channel enabled command execution without authentication.
Why was PEERSTITCH hard to detect?
The malware remains in memory and leaves no persistent binary on disk. It creates no listening ports or direct outbound connections, relying instead on traffic associated with legitimate host processes.
What should defenders inspect on affected FortiGate systems?
Look for unauthorized packet-capture rules, auto-script changes, unusual VPN sessions and activity suggesting FortiManager impersonation. Detection should also account for malware that avoids obvious files, sockets and direct outbound connections.