netanelcyber / netanelcyber/AdPentestAI-Python
🛡️ AdPentest — Golden Ticket Security Audit & Detection
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 5
- Forks
- 2
- Avg merge
- 22h 25m
- Merged PRs (30d)
- 7
Description
Golden Ticket Security Audit & Detection
Objective
Add a defensive Kerberos audit module for identifying indicators and configuration conditions associated with Golden Ticket abuse.
Proposed capabilities
- 🔎 Analyze Kerberos authentication indicators
- 🏰 Assess Domain Controller / domain security signals
- 👤 Identify anomalous privileged authentication patterns
- 📊 Correlate available Kerberos security events
- ⚠️ Generate
PASS / REVIEW / FAILfindings - 📄 Export findings to JSON
- 💻 Keep CLI and JSON results consistent
- 🧪 Support synthetic fixtures and isolated AD lab validation
CLI
adpentest kerberos golden-ticket --mode audit --target <authorized-domain>
Example result
{
"module": "kerberos",
"check": "golden_ticket_risk",
"status": "REVIEW",
"severity": "HIGH",
"evidence": [],
"recommendations": []
}
Safety
This feature is detection/audit oriented. The default workflow must not create, forge, inject, or distribute usable Kerberos tickets or extract credential material. Validation should use synthetic data or explicitly authorized AD laboratory environments.
Testing
- Unit tests
- Synthetic Kerberos event fixtures
- AD lab integration tests
- JSON schema validation
- CLI regression tests
- CI validation
Roadmap
- Kerberos anomaly detection
- Privileged authentication analysis
- Domain security checks
- Event correlation
- JSON reporting
- CLI integration
- AD lab tests
- Documentation
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start from the proposed CLI entry point, adpentest kerberos golden-ticket --mode audit --target <authorized-domain>, and review the existing module structure before choosing an implementation boundary. Use synthetic Kerberos event fixtures and the listed unit, JSON schema, CLI regression, and CI tests as validation targets. Done means defensive audit findings, consistent CLI and JSON output, and no ticket creation or credential extraction.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- authentication, cli, security, testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100