Once you successfully gain access to a target system, the post-exploitation phase begins. Establishing clear rules for this phase ensures you can accurately determine the system's value and maintain access without disrupting the client's day-to-day operations or violating legal boundaries.
This guide covers the ethical guidelines, technical boundaries, and procedural rules you need to establish before diving into post-exploitation activities.
Core Rules of Engagement
The Rules of Engagement (RoE) protect both the client's infrastructure and your testing team. Every action taken after compromising a system must prioritize the confidentiality, integrity, and availability of the client's data.
Never modify critical services without permission. Unless previously agreed upon in writing, do not alter services the client deems "critical." If you need to demonstrate how an attacker might escalate privileges or cause a denial of service, you must obtain explicit consent first.
Protecting the Client
When operating within a compromised environment, follow these strict guidelines to ensure client operations remain safe:
| Rule | Description |
|---|---|
| Document Everything | Keep a detailed, time-stamped log of every action taken and configuration changed. This must be included in your final report. |
| Mask Passwords | Never include plaintext passwords in your reports. Mask them sufficiently so recipients cannot guess or recreate them. |
| Encrypt Gathered Data | All data you extract (pillaging) must be stored on fully encrypted drives controlled by your testing team. |
| Sanitize Evidence | Screenshots, tables, or figures containing sensitive data must be sanitized or permanently masked before being added to reports. |
| Destroy Data | Once the client accepts the final report, all gathered data must be securely destroyed, and proof of destruction provided. |
Protecting Yourself
Due to the sensitive nature of post-exploitation, you must cover your legal and professional bases. Complete this checklist before beginning your engagement:
- 1
Sign the Statement of Work
Ensure the contract explicitly states that your actions on the tested systems are authorized and performed on behalf of the client.
- 2
Review Acceptable Use Policies
Obtain the client's internal policies. Verify that they establish company ownership of all data on the network and provide consent for systems to be searched.
- 3
Verify Legal Restrictions
Confirm local regulations regarding data management. Pay special attention to wiretap laws if you plan to use keylogging, screen capture, or network traffic interception.
- 4
Establish an Incident Response Plan
Discuss exactly what procedures to follow if you discover evidence that a real threat actor has already compromised the network.
Boundaries for Post-Exploitation Activities
Post-exploitation involves gathering data (pillaging), maintaining access (persistence), and moving deeper into the network (pivoting). Each of these activities has strict boundaries.
The Modification Workflow
Whenever you need to alter a system—whether to install a backdoor for persistence or change a routing table to pivot—follow this standard workflow:
flowchart TD
A["Identify desired system change"] --> B{"Is it a critical service?"}
B -- Yes --> C["Obtain explicit client consent"]
B -- No --> D["Document intended changes"]
C --> D
D --> E["Execute the change"]
E --> F["Revert changes post-test"]
F --> G["Log success/failure of reversion in report"]Specific Activity Guidelines
Maintaining Access (Persistence)
Any method used to maintain access (like backdoors or alternate accounts) must employ user authentication, such as digital certificates, SSH keys, or complex login prompts. A reverse connection to a known, controlled IP address is also acceptable. Never leave an open, unauthenticated backdoor on a client system.
Data Exfiltration
When testing data loss prevention (DLP) controls, exfiltrate data only to secure servers fully controlled by your testing team. Simulate real-world threat actor tactics (like archiving into encrypted .7z files before transfer), but ensure the data remains protected at all times.
Handling Passwords & Hashes
Do not use third-party password cracking services (like cloud-cracking platforms) without prior written consent from the client. Sharing client hashes with external entities is a severe breach of confidentiality.
Discovering Prior Compromises
If you find evidence of a previous or active compromise by a real attacker, do not clear or modify any logs. Save all your activity logs, hash them, and immediately provide them to the client so their Incident Response team can take over.
The Cleanup Process
The engagement isn't over until the target environment is returned to its original state. Leaving behind testing artifacts can cause false positives for the client's security team or, worse, create vulnerabilities.
Ensure you complete the following cleanup tasks before closing the engagement:
Remove all uploaded tools: Delete all executables, scripts, and temporary files you transferred to the compromised systems. Use secure deletion methods where possible.
Revert configurations: Return all system settings, routing tables, and application parameters to their original values.
Uninstall persistence mechanisms: Remove any backdoors, rootkits, or scheduled tasks you installed.
Delete testing accounts: Remove any user accounts you created to connect back to the compromised systems.
If a configuration change cannot be successfully reversed, clearly differentiate it in your final report so the client's IT team can manually address it.