What happens when FormBook establishes persistence through dropped scripts and renamed executables?

Once persistence is in place, the malware can relaunch after reboot, reinfect if part of the chain is removed, and keep using trusted Windows processes to blend into normal activity. The article shows dropped VBS and executable files in user and program directories, plus multiple persistence entries. That means cleanup must remove both the files and the launch points, not just the visible process.

How FormBook keeps coming back after the first process is killed

persistence changes the cleanup problem from “stop the running process” to “remove the restart path.” When FormBook drops scripts and renamed executables, it creates alternate launch points that can survive reboot or user logon. In practice, that means a partial cleanup often only hides the symptom briefly while the underlying persistence mechanism remains in place.

The key detail is that the dropped files are not just payload debris, they are part of the startup chain. If the script, executable, or its launch reference is left behind, the malware can execute again without needing the original visible process. That is why responders must treat the file system, startup locations, and any related scheduled or registry-based trigger as a single problem.

Renaming executables also helps the malware blend into routine Windows activity and frustrate simple filename-based detection. A trusted-looking process name does not make it legitimate, but it can reduce suspicion long enough for the malware to re-establish control. In other words, persistence plus name camouflage gives the operator both durability and concealment.

Why dropped scripts matter in the persistence chain

Dropped scripts such as VBS files are often used as lightweight launchers. They can re-create the malware state, invoke the renamed executable, or restore execution through a trusted interpreter. That makes the script itself part of the malicious mechanism, not merely a helper file.

From a defender’s perspective, the important distinction is between the visible process and the hidden bootstrapping logic. A cleanup that deletes only the main executable can still fail if the script is intact and points back to a replacement payload or a renamed copy in another directory. The reverse is also true: removing the script but leaving the executable reachable through another autorun path can leave persistence active.

This is why containment and eradication need to cover both the launch artifact and the payload artifact. When the persistence chain spans user directories and program directories, the response must assume multiple copies, multiple names, and multiple execution routes until proven otherwise.

Why the visible process is not the whole compromise

FormBook’s use of renamed executables means the analyst cannot rely on a single process name, parent-child relationship, or file hash seen during initial triage. The malware may relaunch under a different name or from a different path after each reboot, which makes the active infection look intermittent even when the persistence mechanism is stable.

That behaviour creates a common failure mode: teams remove the process, confirm the endpoint is quiet, and then stop before verifying the autorun chain. The result is reinfection from the same host, often after the next reboot or user session. For identity threat detection and response, this is the kind of pattern that rewards looking for persistence artifacts, not just active execution.

The defensive conclusion is straightforward. If the malware can relaunch independently, then process termination is only suppression, not eradication. True cleanup requires finding the dropped files, tracing their launch points, and confirming that no secondary executable or script can reintroduce the payload.

Risk and Threat Considerations

This persistence pattern raises the risk of repeated compromise because the malware can survive routine remediation, reboot, and superficial file deletion. Renamed executables and dropped scripts also make it easier for the infection to hide in ordinary Windows activity, which delays detection and increases the chance of data theft or follow-on payload delivery.

Failure mechanism: A dropped script or renamed executable remains reachable through an autorun, logon, or other startup reference, so the malware can execute again even after the visible process has been removed.

Impact: Cleanup becomes incomplete, the host can reinfect itself after reboot, and defenders may mistake temporary quiet periods for successful eradication while the persistence chain is still intact.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1037 — Boot or Logon Initialization Scripts	Dropped scripts are used to relaunch FormBook at startup or logon.
	T1053 — Scheduled Task/Job	Persistence through recurring execution is a common relaunch mechanism to check for.
	T1036 — Masquerading	Renamed executables are meant to blend into normal Windows activity and evade notice.
Recommendation — Hunt for startup-script persistence and remove the trigger, not just the payload. Review scheduled execution paths for malicious relaunch and delete compromised jobs. Validate suspicious filenames and paths rather than trusting process names.
NIST SP 800-53 Rev 5	CM-5 — Access Restrictions for Change	Persistence removal requires controlling unauthorized changes to startup and execution paths.
	SI-4 — System Monitoring	Detecting relaunches and hidden persistence depends on monitoring execution and startup artifacts.
Recommendation — Restrict who can modify autoruns, scripts, and executable launch paths. Monitor for repeated execution from unexpected scripts, paths, and parent processes.

Practitioner Guidance

What to verify: Confirm that every launch point is removed, not just the currently running binary. That includes the dropped script, the renamed executable, and any startup reference that can recreate execution after reboot or logon.

Common mistake: Treating a renamed file as benign because its name looks normal, or declaring success after killing the process once. For this pattern, the file identity and the execution path matter more than the live process list at one point in time.

Practitioner takeaway: Eradication is only credible when the persistence mechanism is broken end to end, because FormBook-style relaunch chains make single-artifact cleanup unreliable.