Loading story…
Attackers can abuse PowerShell profile scripts to gain persistence on Windows by placing malicious commands in profile.ps1, causing a payload to run automatically whenever a user starts a PowerShell session. A proof-of-concept example showed a helper program creating the WindowsPowerShell profile directory and writing a command that launched a payload, which then executed with powershell.exe as its parent process. The technique has also been linked to real-world activity, with reports noting Turla has used PowerShell profile persistence in the wild.
Microsoft’s documentation shows why the method is effective: PowerShell supports multiple profile locations and scopes, including per-user and all-users profiles and host-specific variants, all of which can execute at startup depending on configuration and privileges. The same documentation also outlines key defensive controls, including enforcing signed scripts through execution policy, using pwsh -NoProfile to prevent profile loading, and understanding that profile behavior differs across platforms and remote sessions, which can affect both attacker tradecraft and defender response.
Get the actors, campaigns, and ATT&CK mapping behind it.
3 events from the most recent confirmed update back to the earliest known activity.
Microsoft Learn publishes documentation describing how PowerShell profiles work, their storage locations and scopes, execution order, execution policy constraints, and the use of pwsh -NoProfile to bypass profile loading. The document also notes that profiles do not automatically run in remote sessions and explains MSIX-related profile limitations.
A blog post demonstrates a Windows persistence technique that writes a payload path into the current user's PowerShell profile so the payload executes when PowerShell starts. The author also presents a C++ helper program, pers.exe, to create the profile directory and write the malicious command into profile.ps1.
The content states that Turla has used PowerShell profile persistence as a real-world technique. No specific date is provided for when this activity occurred.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Security researchers described a Windows persistence technique that abuses **Mandatory User Profiles** by planting a modified `NTUSER.MAN` registry hive in a user profile directory, causing attacker-controlled settings to load into `HKEY_CURRENT_USER` at logon. Because the hive is prepared offline and then consumed by the normal profile-loading process, the method can evade security products that primarily monitor registry API activity such as `RegCreateKey` and `RegSetValue`. The approach is particularly relevant to kiosks, shared workstations, and other environments where mandatory profiles may already be in use. The reporting highlighted proof-of-concept tooling including **Praetorian Swarmer** and **HiveSwarming**, which can transform exported `HKCU` data into an `NTUSER.MAN` hive and add startup persistence such as a **Run** key. Defenders were advised to monitor creation of `NTUSER.MAN` files in user profile paths, correlate those events with **Microsoft-Windows-User Profile Service Operational** events `5` and `67`, and watch for suspicious `Offreg.dll` loads. Researchers characterized the technique as uncommon but stealthy, expanding attention on Windows registry attack surface and profile-handling mechanisms as a path for persistence.
Aug 14, 2026
Public offensive tooling and research continue to show how attackers can weaken PowerShell defenses by bypassing **AMSI**, suppressing **Script Block Logging**, and evading **Constrained Language Mode**. MDSec documented several methods, including flipping the private `.NET` flag `System.Management.Automation.AmsiUtils.amsiInitFailed`, patching `amsi.dll` in memory, forcing `AmsiOpenSession` failures, altering cached Group Policy settings to disable logging, and clearing PowerShell's suspicious signature list to reduce forced logging. The techniques were later operationalized in tools such as **Stracciatella**, a C# runspace launcher that executes PowerShell while attempting to disable AMSI, ETW, and logging at startup, supports encoded input and named-pipe command delivery, and was promoted for use with frameworks including **Cobalt Strike** and **BOF.NET**. Separate research also showed that AMSI itself can be abused for persistence by registering a malicious **AMSI provider** DLL as a COM server under `HKLM`, allowing code to run whenever AMSI-inspected content matches a trigger while still returning `AMSI_RESULT_NOT_DETECTED`. In the demonstrated sample, the provider watched for a specific string and launched `calc.exe`, highlighting how AMSI can be turned from a scanning interface into an execution mechanism. Defenders were advised to monitor unsigned DLL loads by PowerShell and registry changes affecting AMSI provider and `InprocServer32` entries, as these tradecraft patterns can support stealthy post-exploitation and long-term Windows persistence.
Aug 15, 2026
A series of public proof-of-concept posts detailed how attackers can establish persistence on Windows by abusing multiple native mechanisms, including `AppInit_DLLs`, COM hijacking, Windows services, logon scripts, file-association changes, uninstall handlers, Event Viewer help links, shell `CLSID` command handlers, and Accessibility Features such as Sticky Keys. The demonstrations showed malware-like code modifying keys under `HKLM` and `HKCU` to force execution at boot, logon, application launch, or user interaction, with several techniques requiring administrator privileges while others worked in the current user context. The examples included replacing `.txt` open commands, setting `HKCU\Environment\UserInitMprLogonScript`, creating malicious `InprocServer32` registrations for COM objects, altering `UninstallString` values for installed software, redirecting Event Viewer online help to a local executable, and using either Image File Execution Options or symbolic links to hijack `sethc.exe`. The posts also tied several methods to known threat activity, citing groups and malware such as **APT28**, **APT39**, **Turla**, **Kimsuky**, **APT3**, **APT29**, **APT32**, **APT38**, **APT41**, Ramsay, Attor, Zebrocy, Mosquito, and SILENTTRINITY as examples of similar persistence tradecraft seen in the wild.
Aug 14, 2026