Run Software at Logon

What This Persistence Method Does

Run software at logon is a persistence technique that causes a program to start when a user signs in. It survives a reboot or logout by tying execution to logon-time mechanisms that the operating system or user profile will revisit automatically.

Because it blends into normal user activity, this technique is attractive to attackers who want malware to relaunch without needing a new exploit each time. The core security issue is not the logon event itself, but the trust defenders often place in scripts, shortcuts, startup paths and other autostart locations.

Common Logon Autostart Paths

Attackers can abuse several families of logon-triggered execution paths, including startup folders, logon scripts, profile initialization files and other autorun locations that are read during sign-in. Persistence Techniques Guide covers this broader class of autostart methods, including run keys, startup folder abuse and related mechanisms that defenders commonly inspect.

The important practical point is that these mechanisms are often legitimate administration features first and persistence techniques second. That makes the file path, parent process, command line and write location more important than the fact that a logon action occurred.

Why It Is Effective for Attackers

Logon persistence is effective because it gives an attacker a simple re-entry point after session end, system restart or user reboot. If the malicious launcher is hidden in a user-writable location, the attacker may not need elevated privileges to keep regaining execution.

This technique also benefits from frequency and familiarity: logon is a routine event, so malicious execution can look like ordinary user initialization unless the autorun content is reviewed carefully. Persistence that depends on user sign-in can be especially useful on shared workstations and endpoints where the same profile signs in repeatedly.

How Defenders Find and Reduce Exposure

Defenders should inventory all logon-triggered execution points across endpoints and compare them with expected software, user profile scripts and approved administrative tooling. Investigation should focus on unexpected startup entries, recently changed scripts, executables in writable paths and commands that point to unusual locations or renamed binaries.

For detection and hunt coverage, map the behaviour to MITRE ATT&CK Enterprise Matrix so logon persistence is analyzed alongside adjacent persistence and execution techniques. Baseline visibility into NIST SP 800-53 Rev 5 Security and Privacy Controls helps formalize review of configuration, integrity monitoring and audit logging for these startup locations.

When suspicious autoruns are found, the response should include removal of the persistence point and a review for the original dropper, adjacent scheduled tasks, altered scripts, and any secondary payloads that may have been staged alongside the logon mechanism.

Risk and Threat Considerations

Logon persistence matters because it creates a durable foothold that can re-launch malware every time the user signs in. That makes it a common post-compromise mechanism for maintaining access after a reboot or cleanup of the obvious payload.

Failure mechanism: An attacker places a launcher in a startup folder, logon script or equivalent autorun location, then relies on normal sign-in processing to execute the payload again before the user notices.

Impact: The attacker regains execution after logout or reboot, which can support credential theft, command-and-control re-establishment, follow-on payload delivery and repeated data access.

Practitioner Guidance

What to watch for: Treat any logon-time execution from writable or user-controlled locations as suspicious until it is tied to a known business application or approved script. Review changes in context, especially when the command line, signer, parent process or storage location does not match the environment’s normal logon profile.

Practitioner takeaway: The strongest control is not just blocking one startup folder, but maintaining a baseline of every logon execution path that exists in the estate.

Related resources from NHI Mgmt Group

• How can organisations tell whether EOL software is still safe enough to run temporarily?
• What breaks when organisations allow unapproved RMM software to run?
• What breaks when a decoy app is allowed to run as trusted software?
• What breaks when nodes run different versions of blockchain software during a protocol change?