What Is Memory-Resident Malware on a Network Appliance?

Memory-resident malware is code that runs only in a device's RAM, usually inside a legitimate process, and leaves no executable on disk. On a network appliance such as a firewall or VPN gateway it is especially hard to find, because owners rarely get a root shell, endpoint agents cannot be installed, and a reboot or file scan shows nothing. The PEERSTITCH implant found on FortiGate firewalls in 2026 is a current example.

What is memory-resident malware?

Memory-resident malware is malicious code that lives in the memory of a running process instead of in a file the operating system loads at boot. It survives only as long as that process or the device stays up, unless something reinstalls it.

The term overlaps with "fileless malware", but the two are not identical. Fileless usually describes Windows attacks that abuse built-in tools such as PowerShell or WMI. Memory-resident is the broader idea: whatever the delivery method, the working code exists only in RAM.

How does it get into memory on an appliance?

An attacker needs a way to run code with enough privilege to modify other processes. On an appliance that usually means chaining several steps:

• Initial access through an exposed management service, a VPN bug or stolen admin credentials.
• Privilege escalation from an administrator session to root, often through a bug in the vendor's own CLI or web interface.
• A short-lived loader that writes code into a target process and then deletes itself.

In the FortiOS CVE-2025-61624 PEERSTITCH campaign, Unit 42 described exactly this pattern. Stolen credentials gave admin access, a CLI path traversal gave root-level file access, and a one-shot injector wrote code into the logging daemon and the IKE VPN daemon before removing itself.

Why do attackers target firewall daemons?

Daemons that handle logs and VPN sessions see the traffic and events an attacker most wants to control. Hooking the logging process lets them suppress or filter records. Hooking the VPN process lets them change how sessions are authenticated or inspected.

These processes also already talk to the network. An implant inside them can blend its own messages into traffic the device was always going to send, so there is no new listening port or outbound connection for a defender to spot.

Why is it hard to detect on an appliance?

Most appliance owners have no supported way to inspect process memory. The tools defenders rely on elsewhere either do not exist on the box or do not look in the right place:

• No endpoint agent. EDR products do not run on most firewalls, load balancers or VPN concentrators.
• File integrity checks miss it. Vendor integrity tools usually hash files on disk. A clean disk tells you nothing about a patched process in RAM.
• No new network artifacts. If the implant reuses existing processes and traffic, flow logs and port scans look normal.
• Logs may be part of the attack. If the logging daemon is the one hooked, the device's own records cannot be trusted.

Our piece on why a clean integrity check cannot clear a compromised appliance goes deeper on that last limitation.

Does a reboot remove memory-resident malware?

A reboot clears code that exists only in RAM, but it does not remove the access the attacker used to install it. If the credentials, configuration changes or certificate-based persistence are still in place, the attacker can reinstall the implant afterwards.

That is why a reboot is a containment step, not a fix. In the PEERSTITCH case the actor also kept a self-healing reverse shell through the appliance's certificate renewal module, which a reboot would not touch.

What evidence can defenders actually look for?

Even without a memory dump, an implant and the steps around it leave traces you can check from outside the device:

• Crash records. Failed injection attempts tend to crash the target process. Repeated segmentation faults in a logging or VPN daemon deserve a ticket.
• Configuration history. Look for automation objects, scheduled scripts or admin accounts that were created and then removed.
• Logging gaps. A device that goes quiet for an hour while its traffic counters keep climbing is telling you something. See how to detect firewall logging gaps.
• Unexpected sessions. VPN logins from new locations using valid admin or service credentials.
• Vendor-level forensics. Unit 42's checks for PEERSTITCH included unusual read-write-execute memory regions in the two daemons and overwritten code sections. These need vendor support or an incident response team with root access to the appliance.

How should you respond if you suspect it?

Treat the device as compromised and plan for a rebuild rather than a cleanup. Isolate the management interface, capture whatever logs and configuration history you can before rebooting, and engage the vendor's support or an incident response firm for memory analysis.

Then deal with what the device held. Firewalls store VPN credentials, LDAP or RADIUS bind accounts, certificates and private keys. If one firewall in a centrally managed fleet was implanted, assume the attacker also had the management platform's secrets, as explained in why a firewall manager compromise exposes every device. Rotate those secrets only after the rebuilt device is trusted, so the attacker cannot capture the new ones.

Finally, patch privilege escalation bugs on appliances even when they are rated Medium. In the FortiGate case, a 6.0 CLI flaw was the step that turned stolen admin access into root and made the implant possible.