Professional guidelines for using ADscan in security assessments and penetration tests

This guide provides best practices for using ADscan professionally in security assessments, penetration tests, and authorized security research.

Pre-Engagement Planning

Scope Verification

Before starting ADscan, ensure you have:

Written authorization to test the target environment
Clear scope definition including IP ranges and domains
Rules of engagement defining what actions are permitted
Emergency contacts for the client organization
Agreed testing windows and blackout periods

Environment Preparation

Set up your testing environment properly:

Initial workspace and baseline checks

  (ADscan:client ~/.adscan/workspaces/client) > workspace create client_2024_pentest # Create isolated workspace for the engagement
  (ADscan:client ~/.adscan/workspaces/client) > system ping -c 3 <target_dc_ip> # Verify network connectivity
  (ADscan:client ~/.adscan/workspaces/client) > system ip addr show # Document baseline interface information
  (ADscan:client ~/.adscan/workspaces/client) > system route -n # Document current routing table

Backup Your Tools

Before critical operations, ensure your tooling is backed up:

# Backup ADscan configuration
cp ~/.adscan/config.json ~/.adscan/config.json.backup

# Note your current workspace state
ls -lah ~/.adscan/workspaces/client_2024_pentest/

Operational Security

Network Isolation

Use dedicated testing infrastructure - Don't mix client data with other engagements
VPN/Network segmentation - Ensure traffic is properly isolated
Document IP addresses - Keep records of your testing source IPs

Stealth Considerations

ADscan is designed for authorized testing, not stealth operations. However, for realistic red team scenarios:

# Use verbose mode to understand what's being executed
(ADscan:workspace) > set verbose true

# Review operations before automated execution
# Consider manual execution of sensitive commands via 'system'

Note: ADscan's automated workflows are optimized for efficiency, not stealth. For highly sensitive engagements requiring operational security, consider manual execution of individual techniques.

Attack paths-first workflow

In production engagements, treat ADscan as a decision engine:

Enumerate quickly (prefer start_auth when you have credentials).
Review attack paths from the accounts you control.
Execute only what you intend (especially in strict rules of engagement).
Repeat: new credentials and new access often unlock additional paths.

Recommended operator loop:

set auto False
start_auth

# Primary review loop
attack_paths <domain> owned
attack_steps <domain>

Notes:

attack_paths focuses on high‑value targets by default. Use --all if you want to include everything.
If you compromise additional accounts during the engagement, revisit attack_paths <domain> owned to see what changed.

Workspace Organization

Naming Conventions

Use consistent, meaningful workspace names:

Workspace naming examples

  (ADscan:client ~/.adscan/workspaces/client) > # Good workspace names
  (ADscan:client ~/.adscan/workspaces/client) > workspace create acme_corp_2024_pentest
  (ADscan:client ~/.adscan/workspaces/client) > workspace create healthcare_internal_audit_jan2024
  (ADscan:client ~/.adscan/workspaces/client) > workspace create goad_lab_training
  (ADscan:client ~/.adscan/workspaces/client) > # Avoid generic names
  (ADscan:client ~/.adscan/workspaces/client) > workspace create test # Too vague
  (ADscan:client ~/.adscan/workspaces/client) > workspace create workspace1 # No context
  (ADscan:client ~/.adscan/workspaces/client) > workspace create temp # Suggests temporary/disposable

One Domain Per Workspace

Best practice: Create separate workspaces for each target domain

Separate workspaces per domain

  (ADscan:multidomain ~/.adscan/workspaces/multidomain) > # Multiple domains - use separate workspaces
  (ADscan:multidomain ~/.adscan/workspaces/multidomain) > workspace create corp_domain
  (ADscan:multidomain ~/.adscan/workspaces/multidomain) > start_unauth 10.10.10.0/24
  (ADscan:multidomain ~/.adscan/workspaces/multidomain) > # Later, different domain
  (ADscan:multidomain ~/.adscan/workspaces/multidomain) > workspace create dev_domain
  (ADscan:multidomain ~/.adscan/workspaces/multidomain) > start_unauth 10.20.20.0/24

Why? Isolating domains prevents:

Credential cross-contamination
Confusing enumeration data
Reporting errors
Data integrity issues

Regular Workspace Information Checks

Monitor workspace state throughout your engagement:

Workspace status

  (ADscan:client ~/.adscan/workspaces/client) > workspace info # Check what you have collected so far

Output - Workspace Info (Example)

  Workspace: client_2024
  ───────────────────────────────────────────
  Path:        ~/.adscan/workspaces/client_2024
  Created:     2025-02-10 09:30:45
  Size:        45 MB
  Domain:      htb.local
  Credentials: 9 accounts
  Users:       19 discovered
  Computers:   1 discovered
  BloodHound:  Data collected

Review discovered credentials

  (ADscan:client ~/.adscan/workspaces/client) > creds show # Review all credentials stored in the workspace

Output - Discovered Credentials (Example)

  ╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
  │                                                   Credentials for domain htb.local                                                 │
  │ ╭──────────────────────┬──────────────┬──────────────────────────────────┬────────────────────────────┬────────────────────────────╮ │
  │ │ User                 │ Domain       │ Credential                       │ Source                     │ Notes                      │ │
  │ ├──────────────────────┼──────────────┼──────────────────────────────────┼────────────────────────────┼────────────────────────────┤ │
  │ │ Administrator        │ htb.local    │ 32693b11e6aa90eb43d32c72a07ceea6 │ DCSync                     │ Domain Admin               │ │
  │ │ svc-alfresco         │ htb.local    │ s3***ce                          │ AS-REP Roasting            │ Masked cleartext password  │ │
  │ │ krbtgt               │ htb.local    │ 819af826bb148e603acb0f33d17632f8 │ DCSync                     │ KRBTGT account             │ │
  │ │ sebastien            │ htb.local    │ Ob********bi                     │ DCSync / Password cracking │ Masked cleartext password  │ │
  │ │ lucinda              │ htb.local    │ Th***************0l              │ DCSync / Password cracking │ Masked cleartext password  │ │
  │ │ santi                │ htb.local    │ pl*******hb                      │ DCSync / Password cracking │ Masked cleartext password  │ │
  │ │ andy                 │ htb.local    │ 29dfccaf39618ff101de5165b19d524b │ DCSync                     │ User NTLM hash             │ │
  │ │ mark                 │ htb.local    │ 9e63ebcb217bf3c6b27056fdcb6150f7 │ DCSync                     │ User NTLM hash             │ │
  │ │ $331000-VK4ADACQNUCA │ htb.local    │ 31d6cfe0d16ae931b73c59d7e0c089c0 │ DCSync                     │ Disabled computer account  │ │
  │ ╰──────────────────────┴──────────────┴──────────────────────────────────┴────────────────────────────┴────────────────────────────╯ │
  ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Credential Handling

Secure Credential Management

ADscan stores discovered credentials in the variables.json file inside each workspace. Protect this data:

# Workspace state (including credentials) stored here:
# ~/.adscan/workspaces/<workspace>/variables.json

# Verify permissions (should be restrictive)
ls -la ~/.adscan/workspaces/client_2024/variables.json
# Should show: -rw------- (600) or -rw-r----- (640)

# If permissions are too open, restrict them:
chmod 600 ~/.adscan/workspaces/*/variables.json

Credential Testing Strategy

Test credentials systematically to avoid account lockouts:

Select credentials safely

  (ADscan:forest ~/.adscan/workspaces/forest) > creds select htb.local # 1. Start with least-privilege accounts

Output - Select Low-Privilege Credential (Example)

  ? Select credential for domain htb.local:
  1) svc-alfresco@s3***ce (AS-REP Roasting)
  2) Administrator@32693b11e6aa90eb43d32c72a07ceea6 (DCSync)
  3) sebastien@Ob********bi
  4) lucinda@Th***************0l
  5) santi@pl*******hb
  Select an option (1-5): 1
  ✓ Selected credential: [email protected]
  ℹ  Subsequent authenticated enumeration will use this account.

Enumerate before privilege escalation

  (ADscan:forest ~/.adscan/workspaces/forest) > start_auth htb.local 10.129.2.124 svc-alfresco s3rvice # 2. Enumerate before attempting privilege escalation

Output - Authenticated Enumeration (Example)

  [+] Credentials validated successfully for [email protected]
  ℹ  Enumerating domain privileges and ACLs for user svc-alfresco
  ⚠ There is an ACE with GenericAll on 'Exchange Windows Permissions'
  Do you want to exploit the GenericAll/GenericWrite privilege on Exchange Windows Permissions? [y/n] (y):

Avoid Account Lockouts

Know the account lockout policy before password attacks
Use discovered credentials instead of brute forcing when possible
Limit authentication attempts - ADscan's automated workflows are conservative
Monitor for lockouts - Watch for authentication failures

Data Protection

Encrypt Sensitive Data

For highly sensitive engagements, encrypt workspace data at rest:

# Create encrypted volume for workspaces
# Example using LUKS (Linux)
sudo cryptsetup luksFormat /dev/sdX
sudo cryptsetup open /dev/sdX adscan_vault
sudo mkfs.ext4 /dev/mapper/adscan_vault
sudo mount /dev/mapper/adscan_vault /mnt/secure_workspaces

# Move ADscan workspaces to encrypted volume
sudo mv ~/.adscan/workspaces /mnt/secure_workspaces/
ln -s /mnt/secure_workspaces ~/.adscan/workspaces

Secure Transport

When transferring data:

# Use SCP with encryption for workspace backups
scp -r ~/.adscan/workspaces/client_2024 secure-backup-server:/backups/

# Or use rsync over SSH
rsync -avz -e ssh ~/.adscan/workspaces/client_2024/ backup:/secure/

Data Retention

Follow your organization's data retention policies:

Clean up workspace data

  (ADscan:client ~/.adscan/workspaces/client) > # After engagement completion and reporting
  (ADscan:client ~/.adscan/workspaces/client) > clear_all # Securely clear ADscan state for this workspace
  (ADscan:client ~/.adscan/workspaces/client) > # Then remove the workspace definition
  (ADscan:client ~/.adscan/workspaces/client) > workspace delete client_2024

# For secure deletion of sensitive files on disk
shred -vfz -n 3 ~/.adscan/workspaces/client_2024/variables.json

Post-Engagement Cleanup

Workspace Archival

Before deleting data, archive for records:

# Create timestamped archive
tar -czf client_2024_final_$(date +%Y%m%d).tar.gz \
  ~/.adscan/workspaces/client_2024/

# Encrypt the archive
gpg --symmetric --cipher-algo AES256 client_2024_final_20240115.tar.gz

# Store encrypted archive securely
mv client_2024_final_20240115.tar.gz.gpg /secure/archives/

Data Sanitization

Remove workspace data after archival:

# Clear workspace contents
(ADscan:client_2024) > clear_all

# Delete workspace
(ADscan) > workspace delete client_2024

# Verify deletion
ls ~/.adscan/workspaces/

ADscan writes BloodHound-compatible exports under each workspace at ~/.adscan/workspaces/<ws>/domains/<domain>/attack_graph.json. Removing the workspace directory removes that data. If you imported the JSON into your own BloodHound CE instance, use that instance's data-management UI to delete the corresponding dataset.

Legal and Compliance

Documentation Requirements

Maintain detailed records of your testing:

# ADscan logs all operations
tail -f ~/.adscan/logs/adscan.log

# Keep logs for your records
cp ~/.adscan/logs/adscan.log ./engagement_logs/adscan_$(date +%Y%m%d_%H%M%S).log

Authorized Use Only

CRITICAL REMINDER:

ADscan must only be used on systems you are authorized to test
Unauthorized access to computer systems is illegal in most jurisdictions
Always obtain written permission before testing
Respect scope limitations and rules of engagement
Stop testing immediately if you encounter systems outside your scope

Incident Response

If you accidentally compromise a production system or cause disruption:

Stop testing immediately
Notify the client contact
Document exactly what happened
Preserve logs and evidence
Follow the incident response plan agreed in rules of engagement

Performance Optimization

Target Scope Optimization

Reduce scan time by targeting specific systems:

# Instead of scanning entire /24
(ADscan:htb_forest) > set hosts 10.129.2.0/24

# Target only the Forest DC
(ADscan:htb_forest) > set hosts 10.129.2.124

Network Latency Considerations

High-latency connections (VPN, international links) affect performance:

# Check latency to target
(ADscan:workspace) > system ping -c 10 <dc_ip>

# If latency is high (>100ms), expect slower enumeration
# Consider adjusting timeouts or running during off-hours

Resource Monitoring

Monitor system resources during large scans:

# Watch memory and CPU usage
(ADscan:workspace) > system htop

# Check disk space for large environments
(ADscan:workspace) > system df -h ~/.adscan/

Attack-path Analysis Best Practices

Data Collection Strategy

# Standard collection — ADscan's native graph collector runs as part of start_auth
(ADscan:workspace) > start_auth domain.local <dc_ip> user password

# Inspect paths directly from the ADscan CLI (no external UI required)
(ADscan:workspace) > attack_paths domain.local owned
(ADscan:workspace) > attack_paths domain.local owned --tier0-only

If you prefer the graph UI, load ~/.adscan/workspaces/<ws>/domains/<domain>/attack_graph.json into your own BloodHound CE instance.

Query Strategy

High-leverage attack-path queries:

Shortest Path to Domain Admins — from a compromised user
Kerberoastable Users — high-value SPN targets for credential attacks
AS-REP Roastable Users — unauthenticated attack opportunities
Unconstrained Delegation — high-impact misconfigurations
DCSync Rights — direct domain compromise paths

Regular Data Refresh

Update the attack graph as you gain new access:

# After gaining new credentials, re-run the authenticated scan
(ADscan:workspace) > creds select domain.local/new_user
(ADscan:workspace) > start_auth domain.local <dc_ip> new_user <password>

# attack_graph.json is rebuilt automatically with the new perspective

Common Mistakes to Avoid

1. Mixing Multiple Engagements in One Workspace

Wrong:

(ADscan:test) > start_auth client1.local 10.10.10.1 user pass
(ADscan:test) > start_auth client2.local 10.20.20.1 user pass
# Credentials and data are now mixed

Right:

(ADscan) > workspace create client1_engagement
(ADscan:client1_engagement) > start_auth client1.local 10.10.10.1 user pass

(ADscan) > workspace create client2_engagement
(ADscan:client2_engagement) > start_auth client2.local 10.20.20.1 user pass

2. Not Backing Up Before Risky Operations

Wrong:

(ADscan:critical_client) > clear_all
# Oops, lost all data

Right:

# Backup first
$ tar -czf backup_before_cleanup.tar.gz ~/.adscan/workspaces/critical_client/

# Then proceed
(ADscan:critical_client) > clear_all

3. Ignoring Scope Boundaries

Always verify you're targeting authorized systems:

# Check your target range
(ADscan:workspace) > system nmap -sn 10.10.10.0/24

# Compare with authorized scope from rules of engagement
# If anything is out of scope, adjust your targets

4. Not Reviewing Logs

Check logs regularly for errors or unexpected behavior:

# Monitor logs in real-time during scans
$ tail -f ~/.adscan/logs/adscan.log

# Review logs after completion
$ less ~/.adscan/logs/adscan.log

Quick Reference Checklist

Before starting an engagement:

Written authorization obtained
Scope clearly defined and documented
Testing infrastructure prepared and isolated
Dedicated workspace created with meaningful name
Network connectivity to target verified
Emergency contacts documented
Backup procedures tested

During engagement:

Monitor workspace info regularly
Document findings as you progress
Test credentials systematically (avoid lockouts)
Keep attack-path data updated after each privilege gain
Watch for scope boundaries
Review logs for errors

After engagement:

Archive workspace data securely
Generate reports from collected data
Clean up sensitive data per retention policy
Verify all data is properly secured or deleted
Document lessons learned

✅ Best Practices

On this page