> For the complete documentation index, see [llms.txt](https://106-sam.gitbook.io/ejptv2-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://106-sam.gitbook.io/ejptv2-notes/crto/getting-started/engagement-planning/tradecraft-dos-and-donts.md).

# Tradecraft do's & don'ts

It's important for red teams to have documented guidance for their operators in order to maintain a high quaility and consistently professional team.

### Do

 \-->  Log all actions\
\
The collections of logs is one of the most important aspects of an engagemnet, not only to facilitate a full and complete report, but also to avoid deconfliction. Not capturing all of your actions is one of the most common mistakes you can make.

* Most commercial C2 frameworks maintain a log of commands issued through its implants and a way to export them later.
* Ensure that your terminal history is logged, e.g. your bash or zsh history.
* Taking screenshots before, during, and after the execution of an important action can often carry more weight, particularly for business executives, comparted to text-based output.
* Maintain your own log of actions you take, why you took them, and what the result/output was. The following template form redteam guide may be useful.

{% file src="/files/YjE56USPZ5NIy8OxBs3Q" %}

\
\--> Understand your tools

know how a tool or technique interacts with a target, what changes it may make, what network traffic it may generate,a nd what artefacts it may leave behind. This is important as:

* You may need to undo a system change the tool made, e.g. an added registry key.
* You don't want to leave a system in a vulnerable or broken state.
* You don't want to get caught by the blue team because you didn't understand an artefact the tool would produce.

\--> Be aware<br>

* Always perform situational awareness after gaining access to a new system. Not only is this vital to ensure the system is still in scope as defined by the ROE, but it will also tell you what protections exist (if any) and who may be logged in, etc, which are all useful steps in the attack lifecycle.

### Don't

* **Use untested or pre-compiled tools**
  * Public and open-source tools should go through an internal vetting process before they are used in anger on an engagement. Studying a tool is obviously required as per the 'do' above, but it's also important to ensure a tool won't have any overtly negative impact to a system such as making unauthorised changes, crashing it entirely, or even adding backdoors.
* **Use unencrypted channels for C2**
  * Command and control data must be always encrypted. Tools like netcat are great when studying for your OSCP, etc, they are inappropriate for use by red teams. Not only is plaintext data easier to pickup by IDS/IPS, sending cleartext credentials across an unencrypted channel leaves them vulnerable to sniffing by third parties.
* **Exfiltrate restricted data**
  * Many organizations will hold sensitive datasets such as PII (Protected Identifier Information), PCI (Payment Card Industry) and HIPAA (A law protecting the PHI Protected Health Information.
  * A good rule of thumb is to obtain proof of access, and not the access the data itself.&#x20;
  * Removing such data could constitute a data breach and have serious consequences for all parties involved
* **Disable security controls**
  * A pet peeve of mine is those who go around disabling security controls such as anti-virus and firewalls. As outlined in my 'primum non nocere' section a red team should not place unnecessary risk upon their client.