Skip to main content

​
Architecture

Bounty uses a two-process architecture: a Wails desktop application (Go backend + React-TS frontend) and a Windows service that manages encrypted database operations.

​
Components

​
Desktop Application (Wails)

The main Bounty application provides the user interface and all AD interaction logic:
ComponentTechnologyPurpose
FrontendReact + TypeScriptDashboard, scan management, affected users tables, policy configuration
BackendGoAD authentication, LDAP/RPC queries, scan execution, analysis, SIEM forwarding
AD LibraryProprietaryLDAP connection management and query abstraction

​
Database Service

A standalone Windows service that provides encrypted storage for all Bounty data:
ComponentTechnologyPurpose
DatabaseProprietaryEmbedded key-value store with encryption at rest
CommunicationgRPC over mTLSSecure inter-process communication between the app and service
EncryptionWindows DPAPIMachine-bound encryption key for database operations
CertificatesAuto-generated TLSmTLS key pair for gRPC authentication

​
Data Flow

User
  |
  v
Bounty Desktop (Wails)
  |
  ├──► Active Directory (LDAP/ADWS/RPC/SMB)
  |     - User enumeration
  |     - Hash extraction (DCSync/RPC)
  |     - Group/OU/SPN queries
  |     - Policy reads
  |
  ├──► Bounty Database Service (gRPC/mTLS)
  |     - Store scan results
  |     - Track affected accounts (by SID)
  |     - Persist policies and settings
  |
  ├──► SIEM Platforms
  |     - Forward findings and events
  |     - Splunk, Elastic, Sentinel, QRadar, etc.
  |
  └──► KrakenTech API
        - License validation (HWID-bound)

​
Security Model

​
Encryption Key Lifecycle

  1. On first launch, Bounty generates a random AES encryption key
  2. The key is encrypted using Windows DPAPI (CryptProtectData) — binding it to the current machine and user
  3. The encrypted key is stored at %PROGRAMDATA%\Bounty\svc.enc
  4. The database service decrypts the key at startup using DPAPI
  5. All database operations use the decrypted key for BadgerDB encryption

​
Service Communication

  1. On first launch, Bounty generates a TLS certificate and key pair
  2. Both are stored in the secure certificates directory
  3. The desktop app and database service authenticate each other via mTLS
  4. All gRPC calls are encrypted in transit

​
Account Tracking

Bounty tracks all affected accounts by their Security Identifier (SID) rather than sAMAccountName. This ensures findings remain valid even if accounts are renamed.

​
Directory Structure

%LOCALAPPDATA%\Bounty\           # User-specific data
%PROGRAMDATA%\Bounty\            # Shared service data
  ├── svc.enc                    # DPAPI-encrypted database key
  ├── certs/
  │   ├── bounty.crt             # mTLS certificate
  │   └── bounty.key             # mTLS private key
  └── db/                        # Encrypted BadgerDB data

​
Protocols

Bounty communicates with Active Directory using multiple protocols depending on the scan type:
ProtocolUse Case
LDAPUser/group/OU enumeration, attribute queries, SPN discovery
ADWSAlternative to LDAP for environments where LDAP access is restricted
MS-DRSR (DCSync)NT hash extraction via directory replication
MS-SAMR (RPC)NT hash extraction via SAM remote interface
SMBNTDS.dit extraction, SYSVOL access

​
SIEM Event Format

Bounty forwards structured events to configured SIEM platforms. Events include:
FieldDescription
event_typeScan type (breached, reuse, asrep, kerberoast, pre2k)
severityFinding severity level
account_sidAffected account SID
account_namesAMAccountName
privilegedWhether the account is a member of a privileged group
first_detectedWhen the finding was first discovered
scan_idJob ID of the scan that produced the finding
domainDomain FQDN
timestampEvent timestamp
Supported platforms use native integrations — Splunk HEC, Elastic bulk API, Sentinel workspace API, QRadar syslog, Wazuh syslog, ArcSight CEF, Huntress API, and a generic custom webhook endpoint.