Hackbook

Active Scanning

2026-05-23T09:07:00-04:00

Active Gathering

These all have a higher chance of detection due to the fact you are actively targeting the organization directly.

Port Scanning

Host Discovery Strategies: https://nmap.org/book/host-discovery-strategies.html

By default, nmap scans top 1000 ports with SYN scan, -sS. This scan is default when ran as root. Without root privs, -sT TCP scan is used instead.

Ports can be open, closed or filtered (unknown / firewall interference)

When identifying issues --packet-trace can be utilized to trace packets and identify the response. Other packet types, such as ICMP, DNS or ARP can be disabled with -Pn, -n and --disable-arp-ping, respectively.

TCP Connect Scan

The TCP connect scan, -sT fully completes the TCP three-way handshake by sending a SYN packet, waiting for a SYN/ACK response, then returning an ACK or RST. This method is highly accurate, but also is less stealthy. As the handshake completes, the connection can trigger alarms in firewall or IDS systems. However, this scan may be required to bypass system firewall rules where inbound is blocked but outbound is allowed.

eric@hackbook:~$ nmap -sT

When to use

accuracy is a priority
stealth is not required
full handshake is needed to prevent errors or instability on target device
target may have a host firewall that drops inbound-only connections

TCP SYN Scan

The SYN scan, -sS is known as a half-open scan or stealth scan, as the scanner only sends a SYN packet and monitors for SYN/ACK as open or RST to determine open/closed. The three-way handshake is not completed, which can potentially evade logs or IDS/IPS solutions.

When to use

stealth is important
speed is important, at the cost of some accuracy

TCP ACK Scan

The ACK scan, -sA sends a packet with only the ACK flag, which means the host must respond with RST for closed/open ports. ACK packets tend to bypass firewall rules as it indicates a connection may already be in progress. However, these scans only return filtered or unfiltered and --packet-trace may be required to make further sense of the results

When to use

firewalls / IPS / IDS are filtering other TCP packets from reaching the destination

TCP FIN, NULL & Xmas Scans

-sN, -sF, and -sX are scans meant to exploit a loophole in TCP's RFC 793 that states any packet missing SYN, RST or ACK should return RST if the port is closed and nothing if the port is open. This scan type will never return a true open status, only open|filtered, closed or filtered. Further investigation will be required on any open|filtered ports to further narrow down the state. Utilizing version detection with -sV defeats the purpose of this scan and is not advised.

When to use

need to sneak through non-stateful firewalls and/or packet filtering routers
stealth is important

UDP Scan

The UDP scan, -sU , exclusively targets UDP ports. It can be used in conjunction with either the TCP connect or SYN scan to scan both TCP and UDP ports in the same run. UDP scanning is tricky, as UDP ports are not required to respond, and there is no handshake. Certain known ports like DNS/SNMP will get a more custom payload to attempt to get a response back. Otherwise, ports receive a packet with an empty payload. Most commonly, ports are seen as open|filtered which means nmap is unsure the true status of the port. Adding version scanning, using -sUV can help further narrow down if the port is open, but increases the time further. This scan can be extremely slow due to rate limiting of unreachable UDP packets. A full 65k port scan on a single linux host can take over 18 hours.

When to use

To specifically check for services on UDP ports

Scripts

Default scripts can be loaded with -sC or --script=default. These include safe scans such as robots.txt, ftp checks, clock skew, dns checks, smb checks. Other scripts can be searched using --script-help <keyword|category>. There are 14 total categories of scripts:

Category	Description
`auth`	Determination of authentication credentials.
`broadcast`	Scripts, which are used for host discovery by broadcasting and the discovered hosts, can be automatically added to the remaining scans.
`brute`	Executes scripts that try to log in to the respective service by brute-forcing with credentials.
`default`	Default scripts executed by using the `-sC` option.
`discovery`	Evaluation of accessible services.
`dos`	These scripts are used to check services for denial of service vulnerabilities and are used less as it harms the services.
`exploit`	This category of scripts tries to exploit known vulnerabilities for the scanned port.
`external`	Scripts that use external services for further processing.
`fuzzer`	This uses scripts to identify vulnerabilities and unexpected packet handling by sending different fields, which can take much time.
`intrusive`	Intrusive scripts that could negatively affect the target system.
`malware`	Checks if some malware infects the target system.
`safe`	Defensive scripts that do not perform intrusive and destructive access.
`version`	Extension for service detection.
`vuln`	Identification of specific vulnerabilities.
### Performance

--initial-rtt-timeout 50ms --max-rtt-timeout 100ms can set the round-trip-time min/max timeout to speed up the scan.
- This can cause an increase in scan speed, but can also cause hosts or ports that respond slower to be mislabeled as down.
--max-retries by default nmap tries 10 times.
- can be lowered to increase scan speed, but again can miss slower responding ports or hosts
--min-rate setting the # of packets to be sent per second can increase scan speed. need to be careful not to set too high and overload the network
-T sets the speed/aggressiveness of the scan 0-5
- this also sets some of the settings above automatically as seen here
- T0 and T1 have 5m and 15s scan delay, respectively. In other words, each packet will have a sleep period in between packets. These are good for IDS evasion and remaining stealthy during scanning
- T5 is the most aggressive that also makes use of max-retries and max-rtt-timeout that can cause some accuracy loss, but is incredibly quick and noisy. IDS or firewalls may block or rate-limit this.
Omitting version detection (no -sV) can also greatly increase performance. Using a basic port scan to find open ports in the first pass, then going back to target version scanning on specific ports can help performance.

Evasion

Firewall/IDS Evasion and Spoofing | Nmap Network Scanning * -sA can be used to carry out a TCP ACK scan to determine filtered state of a port * -D can be used to spoof IPs and setup decoys to mask which IP is the legitimate source of the scan * -D RND:5 creates 5 random IPs to spoof packets from * Decoys do not work with version detection -sV or connect scans -sC * Generally, it's better to specify which IPs as decoys and ensure these IPs are actually online. If the decoy IPs are all down, it becomes trivial to determine which IP was the real scanner, and it can inadvertently SYN flood the target. * --source-port binds activity to a specific port which could evade firewall * for example, binding it to 80/443 will make it look like HTTP traffic instead of a random high port performing port scanning * same logic for port 53, hosts may respond on a DNS request instead of another type.

Cheatsheet

# simple full TCP port scan with version detection
nmap -sSV -p- -oA <output_file> <target>

# nmap with scripts, version detection and all ports saved to file
nmap -sC -sV -p- -oA <output_file> <target> 

# aggressive scan that performs service detection, OS detection, traceroute
# and default scripts. better to use against specific ports
nmap -A -p<port> <target>

# nmap scan IP range and print just online IPs (ICMP / ARP scan)
sudo nmap 10.129.2.0/24 -sn -oA tnet | grep for | cut -d" " -f5

# ICMP echo only, with packet trace (TTL can assist in identifying OS)
nmap 10.129.2.18 -sn -oA host -PE --packet-trace --disable-arp-ping 

# TCP, UDP, with version detection (CAN BE VERY SLOW, NARROWING DOWN PORTS PREFERRED)
nmap -sSUV -p<ports> <target> 

# search for specific scripts
nmap --script-help <keyword|category>

# alternate method of searching for scripts
find / -type f -name ftp* 2>/dev/null | grep scripts

# run a certain category of scripts, like vuln
nmap <target> --script vuln

# run multiple specific scripts
nmap <target> --script banner,smtp-commands

# run specific scripts in a category
nmap <target> --script "discovery and http-*"

Vuln Scanning

Using more detailed scanners like nessus or OpenVas to probe for specific vulns on a target. High likelihood of detection, can be even noisier than a simple port scan

Network Mapping

Using traceroute, nmap to identify multiple hosts and gateways. Medium-High likelihood of detection depending on speed of scanning.

Retrieving service info via banners via nc or curl. Low chance of detection but connection attempts can appear in logs.

OS Fingerprinting

nmap -O Low likelihood of detection, similar to banner grabbing

Service Enumeration

nmap -sV Low likelihood of detection, similar to banner grabbing

Web Spidering

Crawling website to identify pages, directories and files such as with Burp Suite Spider. Low-Medium chance of detection depending on crawler configuration

Reconnaissance

2026-05-23T09:07:00-04:00

Passive Gathering

These have a very low chance of detection as you are using publicly available resources and not directly targeting the organization.

Search Engines / Google Dorking
- using specific queries to attempt to uncover information about a target
WHOIS Lookups
- searching for domain registration information
DNS
- identifying subdomains, mail servers, TXT records and other information about a domain
Web Archive Analysis
- web archivers, like the wayback machine, scan and capture periodic snapshots of websites that can reveal information that may no longer be present
Social Media Analysis
- Employee information or job listings can reveal information about technologies, hierarchy, phishing targets and other organization information
Code Repositories
- GitHub and similar repos can have credentials or source code publicly available for finding vulnerabilities.
Cloud Buckets
- Public Amazon AWS or Azure cloud repositories could have information that is unauthenticated and could be valuable

Footprinting

See [[Footprinting#Infrastructure Enumeration]] for detailed notes on gathering data for external infrastructure. See [[Footprinting#Host Based Enumeration]] for notes on gathering data via various services on a host.

Web Enumeration

see [[Information Gathering - Web]]

Exploits

ExploitDB (searchsploit), Rapid7 DB, Vulnerability Lab or Metasploit can help find exploits for particular applications

Penetration Testing Process

2026-05-23T08:40:00-04:00

Overview

Pre-Engagement

Multiple documents should be reviewed during the pre-engagement period:
- Non-Disclosure Agreement (NDAs)
  - NDAs can come in different types: unilateral, bilateral, multilateral. Each of these will protect only one party, both parties, or multiple parties from disclosing information discovered. Multilateral NDAs could be used for cooperative or hybrid networks that may affect more than one party.
- Scoping Questionnaire
  - Such tests could include: internal pentest, external pentest, internal vuln assessment, external vuln assessment, wireless assessment, physical security assessment, application security assessment, social engineering assessment, web app assessment
    - External pentest is the full picture; Similar to how an attacker would get in, it starts with the attacker on the outside of the environment, probing publicly available infrastructure to attempt to gain a foothold
    - Internal pentest can start after successful exploitation during the external pentest, or can start as part of an "assumed-breach" scenario to test what would happen if the external defenses were breached.
  - Each test should have further questions. Example: for social engineering, should this be restricted to just email phishing? Or are phone calls (vishing), text messages (smishing) or in person attacks acceptable?
- Pentesting Proposal (Contract / Scope of Work)
  - A signed scope of work (SOW) or contract is crucial for setting the guardrails of what can be tested. This should be in writing and signed by a authorized signatory for the target. Validation of the signatory to confirm they are eligible to commence a penetration test is crucial to ensuring the pentester is protected during or after the test.
  - Information about the scope such as # of live hosts, IPs/CIDR ranges, domains, wireless SSIDs, web/mobile apps, targeted users, physical locations, targeting of AD, bypassing of controls (NAC, firewall, AV).etc
  - Define critical infrastructure that is out of scope
- Rules of Engagement (RoE)
  - see below for some of the sections that could be included
- Contractors Agreement
  - required for physical tests if a pentester is caught and police are called
- After-Assessment Reports
  - All the notes from the assessment should be revised and aggregated into a final report

These sections can be a part of multiple of the above documents, particuarly the RoE * Goals * Milestones that must be achieved during the engagement * Pentest Type * Scoping should be exhaustive to determine what type of test is being requested. This can be done with a questionnaire * Methodologies * OWASP, OSSTMM.etc * Pentesting Locations * Internal, or remote.etc * Time Estimation * At least start and end dates for the full engagement * Determining time windows for each phase and if testing should occur during work hours or after * Third Parties * Cloud Providers, ISPs, hosting providers may need to be looped into the agreement depending on the targeted infrastructure * Evasiveness * The stealthiness of the test should also be considered. Should it be evasive and attempt to be undetected the entire time? Should it be a hybrid and start stealthy but can ramp up to determine when the controls are able to detect the activity? Or is stealth not required and tooling can be loud and hammer away, barring denial-of-service or being destructive. * Risks * Risks and consequences should be outlined. While the intent is not to cause a system outage, it is possible that the exploitation of a vulnerability could inadvertently take a system down. * Brute-forcing can cause user accounts to lock-out * Information Handling * Laws and regulations can differ depending on the target's industry and location. All laws need to be researched beforehand to ensure compliance during testing * GDPR is a data privacy regulation that impacts personal data and information disclosure for European entities. The US does not have a national data regulation, but some states such as California have their own version that needs to be considered, if applicable. * Target's industry can impact data disclosure as well. Healthcare organizations in the US have to respect HIPAA. School districts in the US need to be mindful of COPPA. Financial institutions also have other regulations such as SOX or GLBA. * Contact Information * Name, job title, email, phone number and escalation priority order during the engagement * Lines of Communication * What channels should be used during the engagement? Email, phone, in-person meetings.etc

This phase should always boil down to these main points: * Written consent from the owner or authorized agent of the network is required before testing begins, including a range of IPs / domains that are in-scope for testing * The scope can not be breached without additional written and signed addendums to the contract * Exploits should not damage the systems or network being tested * Access to discovered personal or company-confidential data should not be accessed without written consent. This is paramount to complying with the multitude of data disclosure regulations globally. * Intercepting communications (emails, phone calls) needs consent of one of the parties to prevent breach of wire-tapping or monitoring laws * Certain regulatory systems, such as systems under HIPAA, require additional authorization before testing can occur to prevent data disclosure, or downtime of critical infrastructure. For each pentest engagement, a new VM should be stood up. This prevents any traces of data from the last engagement and ensures we are starting with a clean slate. * Kali Linux or ParrotOS come with a breadth of tools to get off the ground running quickly.

It's important to state that during all phases of the process, detailed notes, including any screenshots, logs, commands, files created/removed, policies changed, hosts compromised, accounts compromised.etc, are being taken. Not only to aid during cleanup, but to make the final report easier to assemble.

Information Gathering

Different test types can differ in how much information we start with
- Blackbox is the minimal information provided to start such as external IP ranges and domains. Nothing more.
- Greybox provides an additional layer of information, maybe specific IPs, URLs, hostnames or subnets to focus on
- Whitebox provides a full disclosure. Could be full network topology diagrams, detailed configurations, admin credentials, source code
Different environments can also vary how information is gathered
- Some environments, like IoT or SCADA environments, are more fragile and cannot have automated tooling scanning or it could DoS the entire network.
- Cloud environments mean the cloud provider also may need notified or have additional rules for engagement.
- Mobile devices could be corporate-owned or BYOD, which could be out of scope.
During recon, it is important not to jump ahead at the first potential vulnerability discovered, but ensure as much information is gathered up front. This can help prevent a loss of time if the exploitation of the first vuln fails and won't require falling back into more recon.
- Pentests differ from CTFs in that a pentest is meant to be exhaustive. This stage should be much more meticulous and require more patience to ensure as much information is gathered up front before the exploitation phase starts. CTFs tend to immediately jump into the first vuln/exploit as time is of the essence.
Multiple ways to gather this information including:
- OSINT - reviewing publicly available data with methodologies such as Google Dorking. Does not require polling the target directly.
- Enumeration - utilizing tooling directly on the authorized network ranges to attempt to discover services, hosts and other information.
  - See [[Footprinting]] for more info on methodology

Vulnerability Assessment

Divided into two areas, one is scanning for known vulns using automated tools. The other is analyzing the results to determine a path forward
Analysis can be broken down further into
- Descriptive - describes data set based on characteristics
- Diagnostic - ex. reviewing data to determine root cause of vulnerability
- Predictive - evaluating historical and current data to determine future probabilities or detect trends
- Prescriptive - narrow down what actions to take to eliminate a problem or trigger a certain action

Exploitation

One fork after the assessment stage, requires utilizing the information from the two prior steps to prepare targeted attacks against the found endpoint.
Attacks can be prioritized with the probability of success, complexity and probability of damage. CVSS scoring and NVD calculator can aid in determining the success rate.
Also broken into two main areas: actual exploitation of potential vulnerabilities, and remotely exposed services that could be misconfigured or vulnerable for access
Web exploitation tends to be its own special focus due to the diversity of web frameworks, hosting options, dependencies
There may not be a readily available PoC for a specific vulnerability. This requires setting up a local test VM as close as possible to the target environment. Then, we can attempt to reconstruct the exploit for use in the live test against our target, taking into consideration the easiness and destructiveness of the exploit.

Post-Exploitation

Once exploitation succeeds, access tends to be granted as least-privilege (ie, a locked-down service account specifically used for running the web app).
This stage essentially starts a new chapter for information gathering, as new recon is required to determine the best path forward into privilege escalation and/or lateral movement.
- At the post-exploitation stage, pillaging is a new element for info gathering. This helps understand the role of the system and how it communicates with other systems that could be used for lateral movement or stealing credentials to re-use.
This stage can be the most critical for evasive testing. As simple commands like net user or whoami from a strange account or IP can trigger alerts and cause our comprised user account or host to become quarantined.
Data exfiltration can be an additional step during post-exploitation. This needs to be already stated in the scope, as the type of data could be under other regulations (HIPAA, PCI, GLBA.etc)
- Dummy data could be created to test exfiltration and see if DLP, EDR or firewall systems detect this

Lateral Movement

Succeeds exploitation and part of post-exploitation. One of the available paths forward in further compromising the environment.

Proof-Of-Concept

A detailed writeup on how a vulnerability was exploited, that can be reproduced to confirm the vulnerability exists

Post-Engagement

Clean-up of all exploitation commands
Polishing of notes into a summary report that is detailed and consumable by both executive and technical teams
The role of a pentester is to remain impartial and provide remediation recommendations for all discovered activity. It is not on the pentester to perform any remediation or provide detailed remediation advice. (ie. "sanitize user input" for code vulnerable to SQL injection instead of rewriting and providing a copy of better code)
Regulations may require the evidence from the test be retained for a period of time. Encrypting these results and destroying the VM that was used during the test are critical for maintaining confidentiality.

Getting Started

2026-05-23T08:26:00-04:00

Welcome

This hackbook is a WIP source of truth for me as I go for my OSCP certification. My plan here is to document methodology used to exploit the full kill chain, include references to tools and their syntax.

MITRE ATT&CK

The MITRE ATT&CK framework is a matrix and knowledge base of adversary tactics and techniques. The current version, v19, was released on Apr 28, 2026. It introduced a major change, with the Defense Evasion tactic being split into Stealth and Defense Impairment.

The MITRE ATT&CK framework also serves as a sort of killchain, documenting specific techniques as it progresses across the complete killchain.

This Site

I have seen other sites, such as HackTricks create a similar source of truth for offense security techniques. My goal with this one is to align such methodologies directly with the MITRE ATT&CK as I become familiar with them. This site may not have every technique in the matrix, but as I learn specific methodology I will tie it to those specific techniques. It also will serve as a compendium of notes from related offensive security courses I have taken.

Hackbook

Active Scanning

Active Gathering

Port Scanning

TCP Connect Scan

When to use

TCP SYN Scan

When to use

TCP ACK Scan

When to use

TCP FIN, NULL & Xmas Scans

When to use

UDP Scan

When to use

Scripts

Evasion

Cheatsheet

Vuln Scanning

Network Mapping

Banner Grabbing

OS Fingerprinting

Service Enumeration

Web Spidering

Reconnaissance

Passive Gathering

Footprinting

Web Enumeration

Exploits

Penetration Testing Process

Overview

Pre-Engagement

Information Gathering

Vulnerability Assessment

Exploitation

Post-Exploitation

Lateral Movement

Proof-Of-Concept

Post-Engagement

Getting Started

Welcome

MITRE ATT&CK

This Site