An awesome list with only the links is found on awesome-malware-persistence.

This repository collects various currently scattered information regarding the detection, the response and the log collection of malware persistence mechanisms.

In short, we look for one of the things which is so common between different malware families: the ability to persist on a target host. Also malware associated with the misleading term "fileless" often persists on the target too, though not through regular files on the file system but through changes in configuration files like Windows Registry or cron jobs.

Unfortunately, many malware blog posts include all the various IP and hash information but only a few highlight the persistence mechanism from an attack, despite that it's one of the more static and more difficult to change information from an attacker's perspective. Using the persistence mechanism to hunt for malware is more robust than the more frequently changed IP addresses or hashes.

If you're only looking for an overview about persistence techniques and some links to useful resources then see overview of often and less often used persistence mechanisms and links and resources for detection. See section tools for some well-known persistence collection tools.

This repository is regularly updated with new detection resources and tools. If you have inputs then pull requests are more then welcome!

• Why bothering with malware persistence?
• Detection
  • Approach
  • Overview of commonly used persistence mechanisms
    • Linux
    • MacOS
    • Windows
    • Cloud
    • All OSes and developer specific changes
  • Overview of difficult to detect persistence mechanisms
  • Persistence through UEFI malware and bootkits
  • Links and resources for detection
  • Examples
• Detection Evasion
• Testing
• Response
• Prevention
• Tools
  • Linux
  • MacOS
  • Windows
• Acknowledgement

If you are an incident responder and have to analyze compromised hosts, do a generic compromise assessment or if you do threat hunting activities in your infrastructure, then you should get into the topic of persistence mechanisms as one way to detect known or unknown malware. It's one of the pieces for looking for during IR activities.

Let's start with the persistence technique description used by MITRE:

The adversary is trying to maintain their foothold.

Persistence consists of techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that let them maintain their foothold on systems, such as replacing or hijacking legitimate code or adding startup code.

One thing in common between different malware families is that they (mostly) try to persist on the target host. Malware associated with the misleading term "fileless" often persists on the target too, though not through regular files on the file system but through changes in configuration files like Windows Registry or cron jobs.

Why use the word mostly above? Because there is rare malware which omit setting persistence mechanism on the victim's host itself but reinfect the host after reboot from another system (e.g. DC, where the system is running longtime on which no persistence is needed at all).

This gold mine of malware persistence information is a fraction of what other log sources produce. Tens to hundreds of events depending of what you looking for versus thousand to ten thousands of entries for process information. Therefore, the analysis of these events reduce the time and the effort compared to other log sources considerably. The signal to noise ratio is also much lower.

So, by becoming and being a persistent persistence hunter, you can make use of this treasury. Though not that kind of persistence hunting described in Wikipedia...

Persistence hunting (sometimes called endurance hunting) is a hunting technique in which hunters, who may be slower than their prey over short distances, use a combination of running, walking, and tracking to pursue prey until it is exhausted. A persistence hunter must be able to run a long distance over an extended period of time.

While there are many ways how malware can persist on a host, malware authors rely mostly on a handful of techniques. Beside these often used techniques some malware families and more targeted attacks use more advanced mechanisms to stay hidden on the system.

Keep in mind that for some persistence techniques escalated privileges are required and therefore malware running under normal users (and privilege escalation left out of consideration) can only set "user mode" persistence. So if the user on the infected host only use a normal user account then first focus on the user level persistence and secondly look for system level techniques.

The analysis process could involve these steps, as with other incident response and threat hunting procedures:

1. Collect the persistence mechanisms using single commands for specific techniques (see links and resources for detection) or use tools for collection of a bunch of them at the same time, see tools.
2. Analyse the command, file hash, file signer and file path information and enrich the information with more information from external services (AV detection rate, correlation with other files, reputation, signer information, known-bad hash check).
3. If the output doesn't help, check the information against other clients in your infrastructure: Is this entry found on other hosts too?
4. Look for anomalies, e.g. an exe file in startup folder where normally only .lnk files should be placed is suspicious or look for IP addresses or web request in cronjobs. See the links below for detection ideas.
5. In the process of the analysis it is important to note too what is NOT found (evidence of absence) and not only what is found, e.g. no cron jobs were found at all.

The used techniques varies from user land persistence mechanisms, to system level persistence, from hiding behind common binary names, to putting malware at unusual but lesser known places. Sometimes only a proxy or other network configuration (i.a. DNS settings) changes were found after infection. Retefe used the latter.

Use the information from section links and resources for detection for specific information for these techniques.

• Often used techniques: startup, rc and init scripts, cron jobs, shell scripts, shell profiles.
• In-depth analysis should further include less frequently used techniques: malicious libraries, loadable kernal modules (LKM), binary replacements or network scripts.

• Often used techniques: launch daemons and agents, startup items, shell scripts, shell profiles.
• In-depth analysis should further include less frequently used techniques: Dylib hijacking.

• Often used techniques: registry run keys, scheduled tasks, services, startup folder.
• In-depth analysis should further include less frequently used techniques: e.g. file handler hijacking (check both HKLM and HKCU), WMI implants, DLL side loading, malicious drivers, LNK files, sneaky way to get persistence through RDP connections on Windows is the use of image hijacks, sometimes known as "sticky keys hijacking" or known as technique "Accessibility Features" in the ATT&CK Matrix, COM Hijacking (check both HKLM and HKCU).

• Shadow Linking: The Persistence Vector of SaaS Identity Threat
• Persisting on Entra ID applications and User Managed Identities with Federated Credentials
• Mapping storage volumes to external storage providers.

• Proxy and other network configuration changes, backdoor accounts and shortcut modifications.
• Developer workstations: e.g. modified IDE software and git hook scripts.

• Malware which omit setting persistence at all on the victim's host but reinfect the host after reboot from another system, e.g. from a DC (a system which is running long time and no persistence is needed at all).
• Persistence, e.g. through registry run keys, is only set shortly before the shutdown command (shutdown command is hooked). Used in Dridex malware in the past. Cool thing, if you knew that, you could cold boot the computer and "deactivate" Dridex.
• Abuse of hooked file handler.
• DLL side loading (file can be anywhere on the system).
• Legitimate binary replacement.
• Firmware changes which then also prevents correct patching. Example.

• (UEFI) firmware malware, bootkits or modified kernel images. These can be detected by checking the signed binaries from the client (Secure Boot). See MoonBounce: the dark side of UEFI firmware for a in depth write up about one particular UEFI bootkit.
  • Analysis has shown that a single component within the inspected firmware’s image was modified by attackers in a way that allowed them to intercept the original execution flow of the machine’s boot sequence and introduce a sophisticated infection chain.
  • See section "Revisiting the current state of the art in persistent attacks" for a brief history of UEFI malware. From this section: In the last year, there have been several public accounts on the ongoing trend of UEFI threats. Notable examples include the UEFI bootkit used as part of the FinSpy surveillance toolset that we reported on, the work of our colleagues from ESET on the ESPectre bootkit, and a little-known threat activity that was discovered within government organisations in the Middle East, using a UEFI bootkit of its own [...] MoonBounce is notable for being the third publicly revealed case of an implant from the latter class of firmware-based rootkits. Previous cases included LoJax and MosaicRegressor, which we reported on during October 2020.

The following resources cover a lot of persistence techniques and more information on how to detect these specific mechanisms.

One of the most comprehensive lists of persistence techniques is the list found in MITRE ATT&CK tactic "TA0003 - Persistence". Besides a description, different mitigations and a detection section is provided. Furthermore, the involved actors using these techniques are listed on the page.

URL: https://attack.mitre.org/tactics/TA0003/

A second gold mine for persistence information is found on Hexacorn's blog where regularly and since long time new techniques and blog posts about persistence mechanisms are published, crazy stuff. You'll also find there the legendary series "Beyond good ol’ Run key".

URL: http://www.hexacorn.com/blog/category/autostart-persistence/

Series about persistence on macOS beyond just the LaunchDaemons or LaunchAgents directories. In the introduction it's also refered to Pasquale Stirparo's posts (here and here) with the name Beyond the good ol' LaunchAgent from 2018.

URL: https://theevilbit.github.io/tags/beyond/

The forensic artifact repository covers different artifacts regarding persistence for different OSes. See yaml files for MacOS, Linux and Windows in the data directory.

URL: https://github.com/ForensicArtifacts/artifacts

Sigma rules also include various rules regarding persistence. Search for persistence rules in Sigma repository or use the filter options of Sigma for either MITRE ATT&CK persistence category itself or for one specific technique:

sigmac --recurse --filter tag=attack.persistence --target splunk --config config/splunk-windows.yml rules

sigmac --recurse --filter tag=attack.t1084 --target splunk --config config/splunk-windows.yml rules

URL: https://github.com/Neo23x0/sigma/search?q=persistence&unscoped_q=persistence

You can learn which Windows persistence mechanisms are possible by looking at the output of Autoruns on your own client (see also tools). In the output you see the categories and the different locations where things were found. To see which entries Autoruns scans at all, you can start a disassembler and look at the strings found in the binary, this covers only a subset.

URL: http://technet.microsoft.com/en-us/sysinternals/bb963902

Another way to find Windows persistence information is to look at the PowerShell implementation of Autoruns, where the locations are found in the source code. Bonus: A history of the covered persistence locations for each version is found there too, which is awesome!

URL: https://github.com/p0w3rsh3ll/AutoRuns/blob/master/AutoRuns.psm1

For macOS there's the KnockKnock persistence tool to look for persistence mechanisms: https://github.com/objective-see/KnockKnock. Specific persistence locations are found in the plugins folder, e.g. LaunchItems or StartupScripts.

PoisonApple is a command-line tool to perform various persistence mechanism techniques on macOS. This tool was designed to be used by threat hunters for cyber threat emulation purposes. Learn about various macOS persistence techniques by looking at the source code of PoisonApple.

Panix- Persistence Against *NIX - Features is a highly customizable Linux persistence tool and includes various persistence techniques.

Various blog posts write about persistence mechanisms, some specific for one technique, others for a broader set of techniques. Here are some for the past years as an inspiration what to look for.

See How malware persists on macOS for macOS persistence locations, General persistence mechanisms: Common malware persistence mechanisms, Malware persistence techniques, WMI: Detecting & Removing an Attacker’s WMI Persistence, Winlogon: Windows Persistence using WinLogon, Kovter: Untangling Kovter’s persistence methods, Threat Spotlight: Kovter Malware Fileless Persistence Mechanism, GlobalFlags in Image File Execution Hijacks: Persistence using GlobalFlags in Image File Execution Options – Hidden from Autoruns.exe, Bootloader persistence: Uncovering a MyKings Variant With Bootloader Persistence via Managed Detection and Response, COM hijacking / CLSID hijacking: gdatasoftware writeup from 2014 or pentestlab writeup from 2020 or Enigma0x3 / Matt Nelson's writeup from 2016 abusing com hijacking in combination with scheduled tasks, Linux cron: Linux Malware Persistence with Cron, Microsoft Exchange and Outlook: Hunting for persistence via Microsoft Exchange Server or Outlook, Shadow Linking: The Persistence Vector of SaaS Identity Threat, Linux Detection Engineering - A primer on persistence mechanisms, Linux LKM Persistence - Rootkit leveraging Linux loadable kernel module (LKM).

In the list from the tactic's page, we can navigate to the technique itself, namely T1168 - local job scheduling and get the description and the needed information about the involved tools and files:

On Linux and macOS systems, multiple methods are supported for creating pre-scheduled and periodic background jobs: cron, at, and launchd.

[...]

System-wide cron jobs are installed by modifying /etc/crontab file, /etc/cron.d/ directory or other locations supported by the Cron daemon, while per-user cron jobs are installed using crontab with specifically formatted crontab files.

Further below the detection ideas are provided. Besides the process monitoring we can spot malicious jobs by comparing the cron files and commands against other hosts or just search for unusual commands.

% grep -r http /etc/cron.daily/*

A writeup on bleepingcomputer regarding a cryptominer on Linux shows an example of such a cron entry. IP changes but the persistence technique using the crontab and a web request stays. So hunt them down!

A second example is the (ab)use of rundll32.exe to load a library through registery keys or other means (T1085 - Rundll32). Ursnif is one of the malware families which use a specific rundll32 command line since long time. Therefore, searching for registry keys containing "rundll32" and "DllRegisterServer" in the command line would catch it or just use "rundll32" as a more generic search pattern.

Example taken from Trendmicro's URSNIF threat encyclopedia

In HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
    dminsenh = "rundll32 "%Application Data%\Microsoft\Appislad\devrusic.dll",DllRegisterServer"

Sneaky persistence through manipulation of exefile file handler. MITRE ATT&CK T1546.001 - Event Triggered Execution: Change Default File Association. Lokibot sample from Nov 2021. Check both HKLM and HKCU.

\REGISTRY\MACHINE\SOFTWARE\Classes\exefile\shell\open\command\ = "C:\\Windows\\svchost.com \"%1\" %*"

and malware was dropped to C:\Windows\svchost.com.

Malware authors abuse different techniques to hide their malware persistence or make the detection more difficult:

• Rootkits hide files or hook registry queries
• Use similar or typosquatted names to OS default binary names
• Hidding entries by abusing program bugs, like the one with the null byte in registry keys which results in error while collection or just missing entries in the output of tools
• Abusing ADS (alternate data streams) in windows
• Using DLL side-loading for well-known binaries
• Using signed binaries which then gets filtered out (depending on the analysis)
• Hidden services when special permissions were set at service creation. Seen in section Installation stealth and persistence in Talos' blog post Threat hunting in large datasets by clustering security events. This blog post references another one from SANS, Red Team Tactics: Hiding Windows Services.
  • In the following steps, the script deletes PowerShell logs and registers the final payload as a Windows service using a long command line with some strange permission settings. A quick Google search reveals that these are used to make the service hidden and unremovable using the regular Windows administration tools, without some additional actions. [Talos]
  • A little known feature of Windows allows the red team or an attacker to hide services from view, creating an opportunity to evade detection from common host-based threat hunting techniques. [SANS]

Use the descriptions and information from the resources in section detection to simulate the persistence.

Furthermore, different tools provide checks to verify if detections work.

Atomic Red Team test suite allows checking for specific MITRE ATT&CK persistence techniques, see e.g. T1044 "File System Permissions Weakness".

hasherezade published demos of various (also non standard) persistence methods used by malware, like COM hijacking.

Use PoisonApple to perform various persistence techniques on macOS.

Use PANIX to perform various persistence techniques against Linux systems, among others Debian and RHEL.

Use Diamorphine, a loadable kernel module (LKM) rootkit for Linux Kernels (x86/x86_64 and ARM64), to test the detection of LKMs.

As an example we use the technique T1183 - "Image File Execution Options Injection" and abuse the "sticky keys" feature for executing a command shell. This would also be triggered before a login.

To test your collection tools, the prevention mechanisms in place and your awesome detections, execute the following for adding a debugger value for the corresponding registry key:

REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v Debugger /t REG_SZ /d "cmd /c tasklist"

Now you can click multiple times on the shift-key on your keyboard to trigger the execution of cmd.

If you respond to an incident and need to clean up malware persistence as a temporary countermeasure, you just have to remove the given information. For files and configuration changes it's mostly done using standard OS commands. Use your EDR or some other frameworks (e.g. for Windows, see PowerSponse).

In special cases like WMI the cleanup is not as straightforward as with other mechanisms, see blog post Removing Backdoors – Powershell Empire Edition:

1. remove the binding using Get-WmiObject __FilterToConsumerBinding -Namespace root\subscription | Where-Object { $_.filter -match 'evil'} | Remove-WmiObject;
2. remove the event consumer using Get-WmiObject CommandLineEventConsumer -Namespace root\subscription -Filter "name='evil'" | Remove-WmiObject
3. remove the event filter using Get-WMIObject -Namespace root\Subscription -Class __EventFilter -Filter "Name='evil'" | Remove-WmiObject -Verbose

Then there were issues with null byte values in the Windows registry and attackers abused that to hide entries in e.g. run keys. Custom tools or the RegDelNull can be used to remove these entries.

This list is in no way comprehensive and just lists some possibilities to prevent malware persistence. The most important thing would be of course to prevent the execution of unknown programs.

• Block file writes to unusual places if possible, e.g. public user profile in Windows.
• Block file types on specific folders where only limited file types are used (e.g. .exe in startup folder where only .lnk files should be placed).
• Use file integrity checking on important config files (e.g. cronjobs).
• Reduce privileges so more advanced persistence techniques would fail due to missing privileges.
• File system permissions should be checked regularly and be as restricted as possible.
• Lock down configuration files (read-only) and on Windows put ACLs on specific registry keys (like for the accessibility features keys).
• Prevent the abuse of third party identity providers, see Shadow Linking: The Persistence Vector of SaaS Identity Threat.

For macOS there's the BlockBlock tool by Patrick Wardle which provides protection by monitoring persistence locations: https://github.com/objective-see/BlockBlock.

You can either collect the needed information once on a (remote) host in case of an incident or collect the information on a regular basis for baselining and threat hunting.

One thing as a reminder and thanks to Harlan Carvey over at windowsir for pointing out similar points too in various blog posts, see Deep Knowledge, and the Pursuit Thereof and Troubleshooting and Deep Knowledge: Be cautious of the results of tools and try to cross check with different tools or check things by hand. Tools only provide you the information in their way and sometimes miss the malicious entry or some options were turned off etc. Autoruns for example can hide Microsoft signed entries, but than some LOLbin (living-of-the-land, abusing system tools so to say) commands were missing. Use it to reduce the amount of entries, but know the limits. There was a null byte issue with the registry and the entries were missing too in the collection. New version fixed the issue. One more: Persistence using GlobalFlags in Image File Execution Options – Hidden from Autoruns.exe.

For collection of specific techniques see links and resources for detection which cover detailed information about the location of different persistence mechanisms.

• I'm not aware of a public available tool to get a bunch of persistence mechanisms. But there are different commands which can be put into a script for easier usage. Depending on the distribution use the corresponding commands for crontab, cat, grep, md5sum, sha1sum, sha256sum, somethingsum and directory listings for most of the techniques.
• Linux Security and Monitoring Scripts - Security and monitoring scripts you can use to monitor your Linux installation for security-related events or for an investigation. Among other finding systemd unit files used for malware persistence.
• For regular collection of persistence mechanisms you can look into osquery or OSSEC.

• KnockKnock uncovers persistently installed software in order to generically reveal such malware. See Github repository too for the source code.
• BlockBlock provides continual protection by monitoring persistence locations.
• Dylib Hijack Scanner or DHS, is a simple utility that will scan your computer for applications that are either susceptible to dylib hijacking or have been hijacked. See Github repository too for the source code.
• Besides the UI tool KnockKnock, I'm not aware of a public available command line tool to get a bunch of persistence mechanisms. But there are different commands which can be put into a script for easier usage. Use the corresponding commands for crontab, cat, grep, md5sum, sha1sum, sha256sum, somethingsum and directory listings for most of the techniques.
• For regular collection of persistence mechanisms you can look into osquery or OSSEC.

• A powerful persistence collection tool on Windows is Autoruns. It collects different categories and persistence information from a live system and in limited ways from offline images. There is a UI and a command line program and the output format can be set to CSV which can then be imported into your log collection system of choice.
• Instead of using CSV output and copy these file to the server, you can use the script AutorunsToWinEventLog.ps1 to convert the Autoruns output to Windows event logs and rely on standard Windows event log forwarding.
• PowerShell version of Autoruns.
• PersistenceSniper is a Powershell module to hunt for persistence implanted in Windows machines.
• RegRipper does also extracts various persistence mechanisms from the registry files directly.
• RECmd using the config file UserClassesASEPs extracts user's CLSID information.
• KAPE has different targets and modules, see KapeFiles which include persistence mechanisms, among others there's a collection of LNK files, scheduled task files and scheduled task listing or a WMI repository auditing module.
• Different AVs and EDR tools also include the detection and prevention of persistence mechanisms

Currently not many things are found with these topics, but if you search for #malware and #persistence the matched repositories are listed: https://github.com/search?q=%23malware+%23persistence&type=

Thanks to my previous employer Swisscom (Github) for allowing me to publish the information which was inspired by my work in the past few years at the @swisscom_csirt.