Establishing persistence allows you to maintain access to a compromised system across reboots, network interruptions, or user credential changes. During a penetration testing engagement, this ensures you don't lose your hard-earned foothold and can continue your assessment without needing to re-exploit the target.
Client Consent is Mandatory
Never implement any method or device to maintain access that could affect the proper operation of the system or cause downtime without prior written consent from the client. All persistence mechanisms must strictly adhere to your agreed-upon Rules of Engagement.
Securing Your Access
When setting up persistence, you are intentionally leaving a door open into the client's network. It is your responsibility to ensure that only you can walk through that door.
All persistence mechanisms must employ strict access controls:
Authentication: Always require authentication. Use complex passwords at a minimum, though digital certificates or cryptographic keys (like SSH keys) are highly preferred.
Network Restrictions: If using reverse connections, limit them so they can only connect back to a single, known IP address under your control.
Common Persistence Mechanisms
Depending on the target operating system and the scope of your engagement, there are several approved methods for maintaining access. Your chosen backdoor should be designed to survive system reboots whenever possible.
| Mechanism | Description | Security Best Practice |
|---|---|---|
| Service Modification | Modifying existing services (like SSH or RDP) or installing new ones to allow remote access. | Use cryptographic keys instead of passwords where supported. |
| Reverse Connections | Setting up a payload (e.g., using ncat) that actively calls back to your controlled infrastructure. | Restrict the connection to your specific testing IP address. |
| Alternate Accounts | Creating a new, hidden local or domain user account specifically for the assessment. | Use a highly complex, randomly generated password. |
flowchart TD
A[Initial Compromise] --> B{Client Consent Granted?}
B -- Yes --> C[Select Persistence Method]
B -- No --> D[Maintain Active Session Only]
C --> E[Implement Authentication & IP Restrictions]
E --> F[Verify Access Survives Reboot]
F --> G[Perform Post-Exploitation]
G --> H[Complete Cleanup & Removal]Tracking and Documentation
Every action taken to establish persistence must be meticulously documented. This protects both you and the client, ensuring that the system can be fully restored at the end of the engagement.
Keep a running log of every file dropped, setting changed, and account created, along with the exact timestamp. This list should be included as an appendix in your final report.
Post-Engagement Cleanup
Once the penetration test is complete, you must return the system to its original state. Leaving persistence mechanisms behind is a severe security risk.
- 1
Remove Files and Binaries
Delete all executables, scripts, and temporary files you uploaded to the compromised system. Whenever possible, use secure deletion methods to ensure files cannot be recovered.
- 2
Revert System Settings
Restore any system settings, application configuration parameters, or registry keys that were modified during the assessment to their original values.
- 3
Uninstall Backdoors
Completely remove all backdoors, reverse shells, or rootkits that were installed to maintain access.
- 4
Delete Alternate Accounts
Remove any user accounts that were created for the purpose of connecting back to the compromised systems.
What if I cannot revert a configuration change?
If a change cannot be safely returned to its original state without risking system stability, document it clearly. In your final report, explicitly differentiate between changes that were successfully reversed and those that require the client's administrative intervention.