Author: BackdoorAli - Github.com/BackdoorAli

This document defines the security expectations for the Active Directory Exploitation Educational Guide repository.

The project contains offensive-security concepts, laboratory commands, attack-path examples, detection guidance, and defensive recommendations. Because material of this nature can involve credentials, hashes, tickets, certificates, logs, scripts, and potentially sensitive infrastructure details, the repository should be maintained carefully.

This policy covers:

• Reporting security issues in the repository
• Handling secrets and credentials
• Safe use of example data
• Repository integrity
• Dependency and tooling considerations
• Responsible disclosure
• Contribution security expectations
• Sensitive output handling
• Scope of project support

Security reports are welcome when they relate directly to this repository or material distributed through it.

Examples include:

• Accidentally committed credentials
• Exposed API keys or access tokens
• Private keys committed to the repository
• Sensitive laboratory data that should have been sanitised
• Malicious or unsafe code introduced into project files
• Compromised download links
• Dependency confusion or package substitution risks
• Unsafe installation instructions
• Repository configuration issues
• Supply-chain concerns affecting referenced project tooling
• Incorrect guidance that could unintentionally damage a properly configured lab environment
• Sensitive information included in screenshots or examples

This policy is not intended to provide security support for unrelated third-party tools, products, organisations, or infrastructures.

If you discover a security issue affecting this repository, do not disclose sensitive details publicly before the issue can be reviewed.

Where possible, provide:

Issue summary

Affected file or component

Relevant path

Steps required to reproduce the issue

Expected behaviour

Observed behaviour

Potential security impact

Suggested remediation

Any relevant logs or evidence

Do not include real credentials, authentication material, customer data, private keys, or other unnecessary sensitive information in a public issue.

Where GitHub private vulnerability reporting is available for this repository, it should be preferred for repository-specific security concerns.

No real credentials or authentication material should be committed to this project.

This includes:

Passwords
NTLM hashes
Kerberos tickets
Kerberos credential caches
LSASS dumps
SAM database material
SYSTEM registry hive material
API keys
Access tokens
Session cookies
SSH private keys
TLS private keys
Certificate private keys
VPN credentials
Cloud credentials
Personal access tokens
Recovery codes
Real service-account passwords
Real domain administrator credentials

All examples should use laboratory or fictional values.

Documentation should use clearly fictional or isolated laboratory identifiers.

Preferred examples include:

Domain: lab.local
Forest: lab.local
Domain Controller: dc01.lab.local
Workstation: ws01.lab.local
Member Server: srv01.lab.local
User: student
Administrator: labadmin
Service Account: svc_sql
Attacker Host: kali.lab.local

Example IP addresses should also be selected carefully.

Where practical, use private address ranges assigned only to the demonstration laboratory, for example:

10.10.10.0/24
10.20.20.0/24
192.168.56.0/24

Do not "accidentally" publish real client or employer infrastructure ;)

Terminal output may reveal more than the command itself.

Before committing captured output, review it for:

• Real usernames
• Real employee names
• Email addresses
• Internal hostnames
• Internal domain names
• Internal IP addresses
• Public IP addresses associated with private infrastructure
• Passwords
• Hashes
• Tickets
• Tokens
• Certificates
• Session identifiers
• File paths containing personal information
• Organisation names
• VPN gateways
• Cloud tenant identifiers
• Customer information

Where information is not necessary to explain the technique, replace it with laboratory values.

Screenshots require the same level of review as text.

Before adding an image to the repository, inspect:

Terminal title bars
Browser address bars
Bookmarks
Desktop notifications
Usernames
Hostnames
IP addresses
Open tabs
Shell history
Passwords
Tokens
Directory paths
Virtual machine names
Cloud tenant names
Client names
Chat windows
Email addresses
System clocks and metadata

Crop or redact information that does not belong in the repository.

Project files should be reviewed before being committed.

Particular attention should be given to:

PowerShell scripts
Python scripts
Shell scripts
Batch files
Registry files
Configuration files
Sigma rules
Detection queries
Lab deployment scripts
Docker files
Virtual machine provisioning files
Third-party installation commands
Binary downloads

A script included for educational purposes should make its intended behaviour understandable.

Avoid unnecessary obfuscation in project-owned scripts.

If obfuscated content is required for explaining a security concept, clearly identify it as such and explain the relevant behaviour.

This repository may reference established offensive and defensive security tools.

Examples may include:

BloodHound
SharpHound
PowerView
PowerSploit
Impacket
Rubeus
Mimikatz
Certipy
Certify
NetExec
CrackMapExec
Windows administrative utilities
PowerShell

The presence of a tool in this repository does not mean the project controls or guarantees that tool.

Before downloading third-party software:

• Verify the official project location
• Review the repository owner
• Check release information
• Review checksums or signatures where available
• Avoid unofficial mirrors
• Avoid unknown precompiled binaries
• Review installation commands before execution
• Consider testing unfamiliar software inside an isolated virtual machine

Tool ownership and release locations can change over time.

Always verify the current official source.

Commands copied from documentation should be read before execution.

Be particularly cautious with commands that:

Download and immediately execute remote scripts
Use elevated privileges
Modify security settings
Disable antivirus protection
Disable logging
Change firewall rules
Modify Group Policy
Change Active Directory permissions
Create privileged accounts
Modify certificate services
Install kernel-level components
Alter system-wide configuration

Laboratory instructions should explain significant environmental changes whenever practical.

Some Active Directory security tooling requires elevated privileges.

Documentation should identify when a command requires:

Local Administrator
Domain privileges
Specific Active Directory permissions
SeDebugPrivilege
Directory replication rights
Certificate enrolment rights
Remote administration permissions

Users should not automatically execute an entire guide from an elevated shell when elevation is unnecessary.

Use the minimum privilege required for the laboratory objective.

Some exercises may modify Active Directory state.

Examples include:

Group membership changes
ACL modifications
Password resets
Object ownership changes
SPN modifications
Delegation changes
Certificate template modifications
Computer object creation
User creation
Trust-related configuration

Where an exercise makes a persistent change, the documentation should identify the change and where practical, provide a clean-up procedure.

Before performing exercises that modify Active Directory, take a snapshot or equivalent backup when the lab platform supports it.

A typical workflow is:

Known-good lab state
        |
        v
Create snapshot
        |
        v
Perform exercise
        |
        v
Review attacker and defender evidence
        |
        v
Run clean-up procedure
        |
        v
Restore snapshot if required

Snapshots are particularly useful when experimenting with:

• Domain Controller configuration
• Group Policy
• Certificate Services
• Delegation
• Trusts
• ACLs
• Persistence
• Authentication policies

The educational goals of this project generally do not require destructive behaviour.

Avoid unnecessary techniques that could:

• Destroy data
• Corrupt Active Directory
• Cause widespread account lock-outs
• Interrupt authentication services
• Disable Domain Controllers
• Damage certificate infrastructure
• Remove security logs
• Cause denial of service
• Prevent administrators from recovering the laboratory

If a potentially disruptive concept is discussed, the associated risk should be clearly identified and communicated to the subject giving authorisation, to said authorised pentests, etc.

Detection material should be tested before being presented as reliable.

Detection examples may include:

Sigma rules
Windows Event ID logic
PowerShell queries
SIEM queries
Kerberos monitoring
NTLM monitoring
Directory Service auditing
Group membership monitoring
ACL change detection
Certificate Services monitoring

Detection logic can generate false positives or false negatives.

Documentation should distinguish between:

Example detection logic
Lab-validated detection logic
Production-ready detection engineering

A laboratory rule should not automatically be treated as production-ready.

Avoid presenting security claims with greater certainty than the evidence supports.

For example, instead of stating:

This event proves Kerberoasting occurred.

prefer language such as:

This event can contribute to detecting Kerberoasting when correlated
with additional authentication, account, process, and network telemetry.

Active Directory behaviour varies across environments.

If scripts in this repository eventually require external libraries or packages:

• Pin versions where appropriate
• Prefer established package sources
• Avoid unnecessary dependencies
• Document required packages
• Review dependency names carefully
• Consider dependency confusion risks
• Avoid installing similarly named packages from untrusted repositories (please pay attention to what you install on your machines...)
• Update dependencies when justified by security or compatibility requirements

Dependencies should support the educational objective rather than unnecessarily expanding the attack surface of the project.

Where possible, this repository should not redistribute third-party security binaries.

Instead, documentation should direct users to the recognised upstream project.

This helps reduce:

• Supply-chain risk
• Stale binaries
• Modified executables
• Licensing problems
• Unverifiable artefacts

If a project-owned binary is ever distributed, the repository should clearly explain how it was produced and provide source code where practical.

Deleting a secret from the latest version of a file does not necessarily remove it from Git history.

If sensitive material is accidentally committed:

1. Treat the secret as compromised.
2. Revoke or rotate it immediately.
3. Remove the secret from the working tree.
4. Remove it from repository history where appropriate.
5. Review forks, pull requests, logs, and automated systems that may have copied it.
6. Document the incident privately where required.

Credential rotation should not be delayed while repository history is being cleaned.

Contributors should review their changes before submitting them.

A pull request should not contain:

Real credentials
Real customer information
Employer infrastructure details
Unlicensed proprietary material
Malicious dependencies
Unexplained binaries
Unnecessary obfuscated scripts
Copied private assessment material
Confidential penetration-test reports
Client screenshots
Real password hashes
Real Kerberos tickets

Contributors should also preserve attribution when material is based substantially on external research.

Before a new module is considered complete, it should ideally be checked for:

Technical accuracy
Lab scope
Command safety
Required permissions
Environmental assumptions
Sensitive example data
Expected changes
Clean-up requirements
Detection coverage
Mitigation coverage
Source attribution

This review process helps keep offensive material educational, reproducible, and responsible.

If project research leads to discovery of a real vulnerability in a third-party product or service, follow the affected vendor's vulnerability disclosure process where one exists.

Do not publish:

• Active exploitation details prematurely
• Credentials
• Private customer information
• Unnecessary proof-of-concept data
• Confidential correspondence

The objective should be to enable remediation while minimising additional risk.

The project is educational material.

It does not guarantee that:

• A command will work in every environment
• A detection rule will identify every attack
• A mitigation is sufficient for every organisation
• A third-party tool is safe
• A technique remains unchanged across software versions
• A laboratory configuration represents every production Active Directory environment

Users should validate material against their own authorised environment and current vendor documentation, policies, guidelines, etc.

This file should be read together with:

ETHICS.md

ETHICS.md defines the authorised-use and ethical principles of the project.

SECURITY.md defines how the repository itself should be handled safely.

Together, they establish the baseline for responsible use and maintenance of this guide.

Do not expose real secrets.

Do not trust unknown binaries.

Understand commands before executing them and doing possible irreversible damage. (If you don't fully understand something, there's nothing wrong with asking or searching the proper methods first!)

Document changes before making them.

Use isolated laboratories for risky experiments.

Validate detections before relying on them.

Test only where you are authorised.