View on GitHub
Feel free to contribute!
As you can see, I have just started, and there are hundreds of persistence mechanisms to cover.
Your effort will be appreciated, and is never too small to be helpful :)

If need some tips how to contribute, here you have it:


  1. Persistence mechanism - configuration change, making the arbitrary code to run automatically, or in a way making it likely to happen unexpectedly due to typical user actions such as right-click on files etc.
  2. Configuration change - change of a file content, registry settings, database data, etc.
  3. Scope - Windows systems currently supported or popular. Exceptions may happen if the mechanism relies on very common non-OS dependencies such as Microsoft Office, Google Chrome etc.
  4. Exclusions - replacement of a binary file with another binary file may count as a persistence mechanism, but will be not reflected in the repository as possibilities are endless and not really interesting.
  5. Entries are defined by the configuration change LOCATION, not the configuration change itself. Two very different entries within the Run registry key count as one persistence mechanism.


  1. Permissions
    1. User (👨‍💼) - standard user permissions are good enough to create the persistence
    2. Admin - standard user permissions are NOT good enough to create the persistence
  2. Security context
    1. User - code runs as the user being logged-on within the user session
    2. System - code runs as the localsystem
    3. Other - code runs in the security context not described above
  3. Persistence type
    1. Files only - it is enough to drop a file to make code run
    2. Registry - reasonably simple registry changes are required to make code run
    3. Other - something more than registry and files is required
  4. Code type
    1. EXE - EXE file is executed as a new process
    2. DLL - DLL is loaded by a processes (not being result of any persistence mechanism) in a way making code run.
    3. Other - scripts etc.
    4. Fileless - no new files are put on disk to create a persistence mechanisms
  5. Launch type
    1. Automatic (⚙) - it is enough to start windows to make code run
    2. Any logon required - any user must log on to make code run
    3. Same logon required - same user must log on to make code run
    4. User initiated - user must log on and perform some actions to make code run
    5. Other - other scenarios
  6. Impact
    1. Destructive - typical OS functionalities are negatively affected by creating a persistence mechanism
    2. Non-destructive - typical OS functionalities are NOT negatively affected by creating a persistence mechanism
  7. OS version
    1. All OS versions - it is enough to have any current Windows version
    2. Windows Server - Windows Server required
    3. Other - all other cases
  8. Dependencies
    1. OS Only - standard OS installation is enough to make persistence happen
    2. Additional components required - some unusual Windows components are required, such as server roles, non-standard features etc
    3. Additional software required - non-OS software components are required to make persistence method work
  9. Toolset
    1. Scriptable - built-in OS tools and zero clicking is enough to create a persistence
    2. PowerShell - built-in OS tools are not enough but PowerShell can do the job and the script exists
    3. Non-scriptable - built-in OS tools only, but some clicking is required to create a persistence
    4. Own toolkit required - anything else