SpecterOps/MSSQLHound

MSSQLHound

A collector for adding MSSQL attack paths to BloodHound with OpenGraph by Chris Thompson at SpecterOps. Available as both a PowerShell script and a cross-platform Go binary (with concurrent collection, SOCKS5 proxy support, and streaming output).

Introductory blog posts:

• https://specterops.io/blog/2025/08/04/adding-mssql-to-bloodhound-with-opengraph/
• https://specterops.io/blog/2026/01/20/updates-to-the-mssqlhound-opengraph-collector-for-bloodhound/
• https://specterops.io/blog/2026/04/23/mssqlhound-now-available-in-go/

Please hit me up on the BloodHound Slack (@Mayyhem), Twitter (@_Mayyhem), or open an issue if you have any questions I can help with!

Quick Start

# 1) Download the source
git clone https://github.com/SpecterOps/MSSQLHound.git
cd MSSQLHound

# 2) Build the binary (Go 1.25+)
go build -o mssqlhound ./cmd/mssqlhound

On Windows, use .\mssqlhound.exe instead of ./mssqlhound.

Run MSSQLHound with a few common collection patterns:

# Use Windows integrated authentication to query Active Directory for MSSQLSvc SPNs and collect from all discovered MSSQL server instances, ten at a time
./mssqlhound -w 10

# Collect from a specific MSSQL server instance using SQL login credentials
./mssqlhound -t sql.contoso.com -u sa -p password

# Collect through a SOCKS proxy using specified domain controller IP for DNS and LDAP resolution and collect from all discovered MSSQL server instances, 20 at a time
./mssqlhound -u "CONTOSO\sqlaudit" -p "password" -d contoso.com --dc 10.2.10.100 -w 20 --verbose --proxy 127.0.0.1:9050

# Collect from all domain computers using Windows MSSQL login credentials, 25 at a time, then upload schema and results to BloodHound
./mssqlhound -u "CONTOSO\sqlaudit" -p "password" -d contoso.com -w 25 --scan-all-computers -B '<token-id>:<token-key>@https://contoso.bloodhoundenterprise.io'

Table of Contents

• Quick Start
• Overview
  • System Requirements
  • Minimum Permissions
  • Recommended Permissions
• OPSEC
  • Network Connections
  • Authentication Events
  • Subprocesses Executed
  • SQL Queries Executed on Targets
  • Files Created
• Go Version
  • Why a Go Port?
  • Building
  • Go Usage
    • Basic Usage
    • Multiple Servers
    • Full Domain Enumeration
    • DNS and Domain Controller Configuration
    • SOCKS5 Proxy Support
    • Credential Fallback
    • Kerberos Authentication
    • Pass-the-Hash
    • Domain Enum Only (Reconnaissance)
    • Collection
    • Output and Storage Options
    • BloodHound Upload
    • Possible Edge Options
    • Linked Server Options
    • test-epa-matrix Subcommand
    • Shell Completion
  • Go Command Line Options
  • Key Differences from PowerShell Version
  • CVE Detection
  • Known Limitations and Issues (Go)
  • Troubleshooting (Go)
• PowerShell Usage
• PowerShell Command Line Options
• Limitations
• Future Development
• Credits
• MSSQL Graph Model
• MSSQL Nodes Reference
  • Server Level
    • MSSQL_Server
    • MSSQL_Login
    • MSSQL_ServerRole
  • Database Level
    • MSSQL_Database
    • MSSQL_DatabaseUser
    • MSSQL_DatabaseRole
    • MSSQL_ApplicationRole
• MSSQL Edges Reference
  • Edge Classes and Properties
    • MSSQL_CoerceAndRelayToMSSQL
    • MSSQL_AddMember
    • MSSQL_Alter
    • MSSQL_AlterAnyAppRole
    • MSSQL_AlterAnyDBRole
    • MSSQL_AlterAnyLogin
    • MSSQL_AlterAnyServerRole
    • MSSQL_ChangeOwner
    • MSSQL_ChangePassword
    • MSSQL_Connect
    • MSSQL_ConnectAnyDatabase
    • MSSQL_Contains
    • MSSQL_Control
    • MSSQL_ControlDB
    • MSSQL_ControlServer
    • MSSQL_ExecuteAs
    • MSSQL_ExecuteAsOwner
    • MSSQL_ExecuteOnHost
    • MSSQL_GetAdminTGS
    • MSSQL_GetTGS
    • MSSQL_GrantAnyDBPermission
    • MSSQL_GrantAnyPermission
    • MSSQL_HasDBScopedCred
    • MSSQL_HasLogin
    • MSSQL_HasMappedCred
    • MSSQL_HasProxyCred
    • MSSQL_HostFor
    • MSSQL_Impersonate
    • MSSQL_ImpersonateAnyLogin
    • MSSQL_IsMappedTo
    • MSSQL_IsTrustedBy
    • MSSQL_LinkedAsAdmin
    • MSSQL_LinkedTo
    • MSSQL_MemberOf
    • MSSQL_Owns
    • MSSQL_ServiceAccountFor
    • MSSQL_TakeOwnership

Overview

Collects BloodHound OpenGraph compatible data from one or more MSSQL servers into individual temporary files, then zips them in the current directory

• Example: mssql-bloodhound-20250724-115610.zip

System Requirements:

• PowerShell 4.0 or higher
• Target is running SQL Server 2005 or higher
• BloodHound v8.0.0+ with Postgres backend (to use prebuilt Cypher queries): https://bloodhound.specterops.io/get-started/custom-installation#postgresql
• BloodHound v9.0.0+ with OpenGraph Extension Management enabled to use pathfinding
• For Kerberos authentication (-k): krb5-user package on Linux (sudo apt install krb5-user)

Minimum Permissions:

Windows Level:

• Active Directory domain context with line of sight to a domain controller

MSSQL Server Level:

• CONNECT SQL (default for new logins)
• VIEW ANY DATABASE (default for new logins)

Recommended Permissions:

MSSQL Server Level:

• VIEW ANY DEFINITION permission or ##MS_DefinitionReader## role membership (available in versions 2022+)
  • Needed to read server principals and their permissions
  • Without one of these permissions, there will be false negatives (invisible server principals)
• VIEW SERVER PERFORMANCE STATE permission or ##MSS_ServerPerformanceStateReader## role membership (available in versions 2022+) or local Administrators group privileges on the target (fallback for WMI collection)
  • Only used for service account collection

MSSQL Database Level:

• CONNECT ANY DATABASE server permission (available in versions 2014+) or ##MS_DatabaseConnector## role membership (available in versions 2022+) or login maps to a database user with CONNECT on individual databases
  • Needed to read database principals and their permissions
• Login maps to msdb database user with db_datareader role or with SELECT permission on:
  • msdb.dbo.sysproxies
  • msdb.dbo.sysproxylogin
  • msdb.dbo.sysproxysubsystem
  • msdb.dbo.syssubsystems
  • Only used for proxy account collection

OPSEC

This section documents every network connection, authentication event, subprocess, query, and file artifact produced by MSSQLHound so operators can make informed decisions about detection risk.

Network Connections

All TCP connections support SOCKS5 proxy tunneling (--proxy). TLS connections use InsecureSkipVerify=true and cap at TLS 1.2.

TDS Encryption Modes

LDAP Queries Issued

All LDAP searches use subtree scope with 1000-result paging.

Authentication Events

Each authentication below generates log entries on the target system.

Subprocesses Executed

MSSQLHound does not spawn local powershell.exe processes as collection fallbacks. The only PowerShell command constructed by the Go binary is sent through WinRM for the EPA matrix workflow.

SQL Queries Executed on Targets

All queries are read-only. No data is written to any target server.

Server Metadata

Server Principals and Permissions

Databases

Database Principals and Permissions (per database)

Service Accounts

MSSQLHound uses a three-tier resolution strategy to identify the domain account running the SQL Server service:

If all three methods fail, a warning is logged: Could not determine service account (sys.dm_server_services, registry, and SPN lookup all failed).

Encryption and EPA Settings

Credentials and Proxies

Linked Servers

Files Created

No files are written to any target server. All artifacts are created on the operator's machine.

Directory Structure

{system temp or --temp-dir}/
  mssql-bloodhound-YYYYMMDD-HHMMSS/
    mssql-{hostname}.json                    Per-server BloodHound data (default port/instance)
    mssql-{hostname}_{port}.json             Non-default port
    mssql-{hostname}_{port}_{instance}.json  Named instance
    mssql-{hostname}.log                     Per-server log (only if per-target logging enabled)
    computers.json                           AD computer nodes (unless --skip-ad-nodes)
    users.json                               AD user nodes (unless --skip-ad-nodes)
    groups.json                              AD group nodes (unless --skip-ad-nodes)
    ad_edges.json                            Edges touching AD nodes, without source_kind metadata

{current directory or --zip-dir}/
  mssql-bloodhound-YYYYMMDD-HHMMSS.zip      Final output (contains all JSON files above)
  mssql-logs-YYYYMMDD-HHMMSS.zip            Log archive (only if per-target logging enabled)

Naming Conventions

Cleanup

The temporary directory is removed after the zip file is created. The only persistent artifacts are the zip file(s) in --zip-dir (default: current directory).

Go Version

Why a Go Port?

The original MSSQLHound PowerShell script is an excellent tool for SQL Server security analysis, but has some limitations that motivated this Go port:

Evasion

• Proxying: PowerShell execution is easily detected. The Go version allows network traffic to be sent into the target environment through a SOCKS proxy to maintain stealth during offensive operations.

Performance

• Concurrent Processing: The Go version processes multiple SQL servers simultaneously using worker pools, significantly reducing total enumeration time in large environments
• Streaming Output: Memory-efficient JSON streaming prevents memory exhaustion when collecting from servers with thousands of principals
• Compiled Binary: No PowerShell interpreter overhead, faster startup and execution

Portability

• Cross-Platform: Runs on Windows, Linux, and macOS (implicit SSPI is Windows-only; explicit Kerberos with -k works cross-platform)
• Single Binary: No dependencies, easy to deploy and run
• No PowerShell Required: Can run on systems without PowerShell installed

Compatibility

• Full Feature Parity: Produces identical BloodHound-compatible output

Maintainability

• Strongly Typed: Go's type system catches errors at compile time
• Unit Testable: Comprehensive test coverage for edge generation logic
• Modular Architecture: Clean separation between collection, graph generation, and output

Features

• SQL Server Collection: Enumerates server principals (logins, server roles), databases, database principals (users, roles), permissions, and role memberships
• Linked Server Discovery: Maps SQL Server linked server relationships
• Active Directory Integration: Resolves Windows logins to domain principals via LDAP
• BloodHound Output: Produces OpenGraph JSON format compatible with BloodHound CE
• Streaming Output: Memory-efficient streaming JSON writer for large environments
• LDAP Paging: Handles large domains with thousands of computers/SPNs

Building

go build -o mssqlhound.exe ./cmd/mssqlhound

Go Usage

Basic Usage

Collect from a single SQL Server:

# Windows integrated authentication
./mssqlhound -t sql.contoso.com

# SQL authentication
./mssqlhound -t sql.contoso.com -u sa -p password

# Inline credentials (equivalent to the above)
./mssqlhound -t 'sa:[email protected]'

# Named instance
./mssqlhound -t 'sql.contoso.com\INSTANCE'

# Custom port
./mssqlhound -t 'sql.contoso.com:1434'

# Inline credentials with named instance
./mssqlhound -t 'sa:[email protected]\INSTANCE'

# Inline credentials with SPN format
./mssqlhound -t 'CONTOSO\admin:password@MSSQLSvc/sql.contoso.com:1433'

Multiple Servers

# Comma-separated list
./mssqlhound -t 'server1,server2,server3' -u sa -p password

# Comma-separated with inline credentials
./mssqlhound -t 'sa:password@server1,sa:password@server2,sa:password@server3'

# From file (one server per line, supports user:pass@host per line)
./mssqlhound -t servers.txt

# With concurrent workers
./mssqlhound -t servers.txt -w 20

Full Domain Enumeration

# Scan all computers in the domain (not just those with SQL SPNs)
./mssqlhound --scan-all-computers

# With explicit LDAP credentials (recommended for large domains)
./mssqlhound --scan-all-computers --ldap-user "DOMAIN\username" --ldap-password "password"

# Specifying domain controller IP (also used as DNS resolver)
./mssqlhound --scan-all-computers --dc 10.0.0.1 --ldap-user "DOMAIN\username" --ldap-password "password"

# Scan additional candidate SQL ports on every blindly enumerated computer
./mssqlhound --scan-all-computers --scan-all-computer-ports 1433,1434,14330

# Loosen the TCP reachability timeout for slow networks (default is 2 seconds)
./mssqlhound --scan-all-computers --port-check-timeout 5

When --scan-all-computers is set, SPN-discovered SQL Servers still honor their AD-advertised port or instance. The --scan-all-computer-ports list only applies to domain computers without an MSSQLSvc SPN. A per-server worker timeout ensures one wedged target (stuck in nested SQL/LDAP/DNS/SID lookups) cannot keep the worker pool open forever.

DNS and Domain Controller Configuration

# Use a specific DNS resolver for domain lookups
./mssqlhound --scan-all-computers --dns-resolver 10.0.0.1

# Specify DC IP (automatically used as DNS resolver if --dns-resolver is not set)
./mssqlhound --scan-all-computers --dc 10.0.0.1

# Use separate DNS resolver and DC
./mssqlhound --scan-all-computers --dc 10.0.0.1 --dns-resolver 10.0.0.2

SOCKS5 Proxy Support

All network traffic (SQL connections, LDAP queries, EPA tests) can be tunneled through a SOCKS5 proxy:

# Basic SOCKS5 proxy
./mssqlhound -t sql.contoso.com --proxy 127.0.0.1:1080

# With proxy authentication
./mssqlhound -t sql.contoso.com --proxy "socks5://user:[email protected]:1080"

# Combined with domain enumeration
./mssqlhound --scan-all-computers --proxy 127.0.0.1:1080 --dc 10.0.0.1

Note: SQL Browser (UDP) resolution is not supported through SOCKS5 proxies. Named instances must include explicit ports (e.g., sql.contoso.com\INSTANCE:1433).

Credential Fallback

When --ldap-user and --ldap-password are not specified, the tool automatically reuses SQL credentials for LDAP authentication if the --user value contains a domain delimiter (\ or @):

# These domain credentials are used for both SQL and LDAP
./mssqlhound --scan-all-computers -u "DOMAIN\admin" -p "password"

Kerberos Authentication

# Use ccache from KRB5CCNAME env var
./mssqlhound -t sql.contoso.com -k

# Explicit ccache file
./mssqlhound -t sql.contoso.com -k --krb5-credcachefile /tmp/krb5cc_1000

# Use a keytab file
./mssqlhound -t sql.contoso.com -k \
  --user "CONTOSO\svc_mssqlhound" \
  --krb5-keytabfile /etc/mssqlhound.keytab \
  --krb5-realm CONTOSO.COM

# Custom krb5.conf
./mssqlhound -t sql.contoso.com -k --krb5-configfile /etc/krb5_custom.conf

Pass-the-Hash

# Authenticate with an NT hash instead of a plaintext password
./mssqlhound -t sql.contoso.com -u "CONTOSO\admin" --nt-hash aad3b435b51404eeaad3b435b51404ee

# Combined with domain enumeration
./mssqlhound --scan-all-computers --dc 10.0.0.1 \
  -u "CONTOSO\admin" --nt-hash aad3b435b51404eeaad3b435b51404ee

Domain Enum Only (Reconnaissance)

# List SQL servers discovered via SPNs without connecting to them
./mssqlhound --domain-enum-only --dc 10.0.0.1 \
  --ldap-user "CONTOSO\user" --ldap-password "password"

# List all domain computers (not just SPN holders)
./mssqlhound --domain-enum-only --scan-all-computers --dc 10.0.0.1

Collection

# Disable non-traversable edges (attack-path-focused output)
./mssqlhound -t sql.contoso.com --disable-nontraversable-edges

Output and Storage Options

# Save zip file to a specific directory
./mssqlhound -t sql.contoso.com --zip-dir /data/collections/

# Use a custom temporary directory for intermediate files
./mssqlhound -t servers.txt --temp-dir /tmp/mssqlhound

# Stop collecting after 500MB of data
./mssqlhound -t servers.txt --file-size-limit 500MB

# Save per-target log files in a separate zip archive (useful for debugging)
./mssqlhound -t servers.txt --log-per-target

BloodHound Upload

# Shorthand: collect and upload schema + results in one shot
./mssqlhound -t 'sa:[email protected]' \
  -B '<token-id>:<token-key>@https://bloodhound.contoso.com'

# Shorthand with inline target credentials and domain enumeration
./mssqlhound -t 'CONTOSO\admin:[email protected]' -d contoso.com \
  -B '<token-id>:<token-key>@https://bloodhound.contoso.com'

# Via environment variables
export BLOODHOUND_URL=https://bloodhound.contoso.com
export BLOODHOUND_TOKEN_ID=<token-id>
export BLOODHOUND_TOKEN_KEY=<token-key>
./mssqlhound -t sql.contoso.com -u sa -p password --upload-results-only

# Explicit long flags
./mssqlhound -t sql.contoso.com -u sa -p password \
  --bloodhound-url https://bloodhound.contoso.com \
  --token-id <id> --token-key <key> \
  --upload-results-only

# Upload the MSSQL schema once to register edge/node types in BloodHound
./mssqlhound \
  --bloodhound-url https://bloodhound.contoso.com \
  --token-id <id> --token-key <key> \
  --upload-schema-only --skip-collection

Possible Edge Options

# Disable possible edges (stricter pathfinding, fewer false positives)
./mssqlhound -t sql.contoso.com --disable-possible-edges

# Skip AD node creation (still emits AD-touching edges in ad_edges.json)
./mssqlhound -t sql.contoso.com --skip-ad-nodes

Linked Server Options

# Skip linked server enumeration (faster, less noisy)
./mssqlhound -t sql.contoso.com --skip-linked-servers

# Queue discovered linked servers as additional direct targets for later collection passes
./mssqlhound -t sql.contoso.com --collect-from-linked

# Reduce linked server timeout from the default 300s
./mssqlhound -t sql.contoso.com --linked-timeout 60

test-epa-matrix Subcommand

Tests all combinations of Force Encryption, Force Strict Encryption, and Extended Protection by modifying registry settings via WinRM and restarting the SQL Server service. Requires WinRM access and domain credentials.

# Test all EPA setting combinations (12 combinations for SQL Server 2022+)
./mssqlhound test-epa-matrix -t sql.contoso.com -u "CONTOSO\admin" -p "password"

# Named instance, skip strict encryption combos (for pre-SQL Server 2022)
./mssqlhound test-epa-matrix -t "sql.contoso.com\INST" \
  --sql-instance-name INST --skip-strict \
  -u "CONTOSO\admin" -p "password"

# Use HTTPS for WinRM
./mssqlhound test-epa-matrix -t sql.contoso.com --winrm-https \
  -u "CONTOSO\admin" -p "password"

Shell Completion

# Bash
source <(mssqlhound completion bash)

# Zsh
source <(mssqlhound completion zsh)

# Fish
mssqlhound completion fish | source

# PowerShell
mssqlhound completion powershell | Out-String | Invoke-Expression

Go Command Line Options

Authentication

Domain / LDAP

Target Selection

Collection

Output / Storage

BloodHound Upload

Diagnostics

Key Differences from PowerShell Version

Behavioral Differences

Edge Generation Differences

MSSQL_HasLogin Edges

Why Go includes more edges: For security analysis, orphaned SQL logins (where the AD account was deleted but the SQL login remains) still represent valid attack paths. An attacker who can restore or impersonate the deleted account's SID could still authenticate to SQL Server. The Go version captures these potential risks.

HasSession Edges

Why Go skips self-loops: A HasSession edge from a computer to itself (when SQL Server runs as LocalSystem/the computer account) doesn't provide meaningful attack path information.

MSSQL_AddMember Edges

Why Go has fewer edges: The PowerShell version may emit the same AddMember edge multiple times in certain scenarios. Go ensures each unique edge is only emitted once.

Connection Handling

The Go version uses the native go-mssqldb driver with multiple connection strategies for hostname, encryption, and SPN handling:

Native connection: go-mssqldb (fast, cross-platform)

If all native strategies fail, the connection error is returned directly.

LDAP Connection Methods

The Go version tries multiple LDAP connection methods in order:

1. LDAPS (port 636) - TLS encrypted, most secure
2. LDAP + StartTLS (port 389) - Upgrade to TLS
3. Plain LDAP (port 389) - Unencrypted (may fail if DC requires signing)

For --scan-all-computers on Windows with implicit LDAP authentication, computer enumeration may use in-process Go ADSI if LDAP computer enumeration fails. This path does not launch PowerShell.

CVE Detection

The Go version includes detection for SQL Server vulnerabilities:

CVE-2025-49758

Checks if the SQL Server version is vulnerable to CVE-2025-49758 and reports the status:

• VULNERABLE - Server is running an affected version
• NOT vulnerable - Server has been patched

Known Limitations and Issues (Go)

Implicit Windows Authentication on Non-Windows Platforms

Native Windows SSPI is only available on Windows. On Linux/macOS, use SQL authentication or explicit Kerberos material with -k (for example KRB5CCNAME, --krb5-credcachefile, or --krb5-keytabfile).

GSSAPI/Kerberos Authentication Issues

The Go LDAP library's GSSAPI implementation may fail in certain environments with errors like:

LDAP Result Code 49 "Invalid Credentials": 80090346: LdapErr: DSID-0C0906CF,
comment: AcceptSecurityContext error, data 80090346

Common causes:

• Channel binding token (CBT) mismatch between client and server
• Kerberos ticket issues (expired, clock skew, wrong realm)
• Domain controller requires specific LDAP signing/sealing options

Solutions:

1. Use explicit LDAP credentials (recommended for --scan-all-computers):

   ./mssqlhound --scan-all-computers --ldap-user "DOMAIN\username" --ldap-password "password"
   

2. Verify Kerberos tickets:

   klist  # Check current tickets
   klist purge  # Clear and re-acquire tickets
   

3. Check time synchronization - Kerberos requires clocks within 5 minutes

LDAP Size Limits

Active Directory has a default maximum result size of 1000 objects per query. The Go version implements LDAP paging to handle domains with more than 1000 computers or SPNs. If you see "Size Limit Exceeded" errors, ensure you're using the latest version.

SQL Server SSPI Compatibility

Some SQL Server instances with specific SSPI configurations may fail to connect with the native Go driver.

Symptom:

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication

There is no local PowerShell retry path for this condition. Check domain trust, SPN selection, EPA settings, and the selected authentication method; use SQL authentication or explicit Kerberos material where appropriate.

When to Use LDAP Credentials

Use --ldap-user and --ldap-password when:

1. Full domain computer enumeration (--scan-all-computers) - GSSAPI often fails with the Go library due to CBT issues
2. Cross-domain scenarios - When enumerating from a machine in a different domain
3. Service account execution - When running as a service account that may have Kerberos delegation issues
4. Troubleshooting GSSAPI failures - As a workaround when implicit authentication fails

Example:

# Recommended for large domain enumeration
./mssqlhound --scan-all-computers \
  --ldap-user "DOMAIN\svc_mssqlhound" \
  --ldap-password "SecurePassword123" \
  -w 50

Troubleshooting (Go)

Verbose Output

Use -v or --verbose to see detailed connection attempts and errors:

./mssqlhound -t sql.contoso.com -u sa -p password -v

Common Error Messages

Debug LDAP Connection

The verbose output shows which LDAP connection methods are attempted:

LDAPS:636 GSSAPI: <error>
LDAP:389+StartTLS GSSAPI: <error>
LDAP:389 GSSAPI: <error>

This helps identify whether the issue is TLS-related or authentication-related.

PowerShell Usage

The PowerShell collector is the legacy implementation. Current development is focused on the Go binary above, and the script now lives at powershell_deprecated/MSSQLHound.ps1.

Run MSSQLHound from a box where you aren’t highly concerned about resource consumption. While there are guardrails in place to stop the script if resource consumption is too high, it’s probably a good idea to be careful and run it on a workstation instead of directly on a critical database server, just in case.

If you don't already have a specific target or targets in mind, start by running the script with the -DomainEnumOnly flag set to see just how many servers you’re dealing with in Active Directory. Then, use the -ServerInstance option to run it again for a single server or add all of the servers that look interesting to a file and run it again with the -ServerListFile option.

If you don't do a dry run first and collect from all SQL servers with SPNs in the domain (the default action), expect the script to take a very long time to finish and eat up a ton of disk space if there ar a lot of servers in the environment. Based on limited testing in client environments, the file size for each server before they are all zipped ranges significantly from 2MB to 50MB+, depending on how many objects are on the server.

To populate the MSSQL node glyphs in BloodHound, execute powershell_deprecated/MSSQLHound.ps1 -OutputFormat BloodHound-customnodes (or copy the following) and use the API Explorer page to submit the JSON to the custom-nodes endpoint.

{
  "custom_types": {
    "MSSQL_DatabaseUser": {
      "icon": {
        "name": "user",
        "color": "#f5ef42",
        "type": "font-awesome"
      }
    },
    "MSSQL_Login": {
      "icon": {
        "name": "user-gear",
        "color": "#dd42f5",
        "type": "font-awesome"
      }
    },
    "MSSQL_DatabaseRole": {
      "icon": {
        "name": "users",
        "color": "#f5a142",
        "type": "font-awesome"
      }
    },
    "MSSQL_Database": {
      "icon": {
        "name": "database",
        "color": "#f54242",
        "type": "font-awesome"
      }
    },
    "MSSQL_ApplicationRole": {
      "icon": {
        "name": "robot",
        "color": "#6ff542",
        "type": "font-awesome"
      }
    },
    "MSSQL_Server": {
      "icon": {
        "name": "server",
        "color": "#42b9f5",
        "type": "font-awesome"
      }
    },
    "MSSQL_ServerRole": {
      "icon": {
        "name": "users-gear",
        "color": "#6942f5",
        "type": "font-awesome"
      }
    }
  }
}

There are several new edges that have to be non-traversable because they are not abusable 100% of the time, including when:

• the stored AD credentials might be stale/invalid, but maybe they are!
  • MSSQL_HasMappedCred
  • MSSQL_HasDBScopedCred
  • MSSQL_HasProxyCred
• the server principal that owns the database does not have complete control of the server, but maybe it has other interesting permissions
  • MSSQL_IsTrustedBy
• the server is linked to another server using a principal that does not have complete control of the remote server, but maybe it has other interesting permissions
  • MSSQL_LinkedTo
• the service account can be used to impersonate domain users that have a login to the server, but we don’t have the necessary permissions to check that any domain users have logins
  • MSSQL_ServiceAccountFor
  • It would be unusual, but not impossible, for the MSSQL Server instance to run in the context of a domain service account and have no logins for domain users. If you can infer that certain domain users have access to a particular MSSQL Server instance or discover that information through other means (e.g., naming conventions, OSINT, organizational documentation, internal communications, etc.), you can request service tickets for those users to the MSSQL Server if you have control of the service account (e.g., by cracking weak passwords for Kerberoastable service principals).

In the deprecated PowerShell script as currently shipped, these edges are effectively traversable by default because -MakeInterestingEdgesTraversable is initialized on. If you modify the script or explicitly pass the switch as false, that setting controls whether they remain non-traversable.

I also recommend conducting a collection with the -IncludeNontraversableEdges flag enabled at some point if you need to understand what permissions on which objects allow the traversable edges to be created. By default, non-traversable edges are skipped to make querying the data for valid attack paths easier. This is still a work in progress, but look out for the “Composition” item in the edge entity panel for each traversable edges to grab a pastable cypher query to identify the offending permissions.

If the prebuilt Cypher queries are returning failed to translate kinds: unable to map kinds: errors, upload seed_data.json to populate a single fake instance of each new edge class so they can be queried.

PowerShell Command Line Options

For the latest and most reliable information, please execute powershell_deprecated/MSSQLHound.ps1 -Help.

Limitations

• MSSQLHound can discover linked servers and queue them as additional direct targets, but it still does not perform a full node-and-edge collection through an existing linked-server session.
• MSSQLHound doesn’t check DENY permissions broadly. One exception is DENY CONNECT SQL, which is checked to determine whether a principal can remotely log in to the instance at all.
• MSSQLHound stops enumerating at the database level. It does not descend into tables, stored procedures, or columns.
• Separate collections in domains that can’t resolve each other’s principals may not merge cleanly when ingested (for example, one MSSQL_Server node identified by SID and another by hostname may represent the same server).

Future Development:

• Option to zip after every server (to save disk space)
• Full collection through existing linked-server sessions
• Collect across domains and trusts
• Azure extension for SQL Server
• AZUser/Groups for server logins / database users
• Cross database ownership chaining
• DENY permissions
• EXECUTE permission on xp_cmdshell
• UNSAFE/EXTERNAL_ACCESS permission on assembly (impacted by TRUSTWORTHY)

MSSQL Graph Model

MSSQL Nodes Reference

Server Level

Server Instance (MSSQL_Server node)

The entire installation of the MSSQL Server database management system (DBMS) that contains multiple databases and server-level objects

Server Login (MSSQL_Login node)

A type of server principal that can be assigned permissions to access server-level objects, such as the ability to connect to the instance or modify server role membership. These principals can be local to the instance (SQL logins) or mapped to a domain user, computer, or group (Windows logins). Server logins can be added as members of server roles to inherit the permissions assigned to the role.

Server Role (MSSQL_ServerRole node)

A type of server principal that can be assigned permissions to access server-level objects, such as the ability to connect to the instance or modify server role membership. Server logins and user-defined server roles can be added as members of server roles, inheriting the role's permissions.

Database Level

Database (MSSQL_Database node)

A collection of database principals (e.g., users and roles) as well as object groups called schemas, each of which contains securable database objects such as tables, views, and stored procedures.

Database User (MSSQL_DatabaseUser node)

A user that has access to the specific database it is contained in. Users may be mapped to a login or may be created without a login. Users can be assigned permissions to access database-level objects, such as the ability to connect to the database, access tables, modify database role membership, or execute stored procedures. Users and user-defined database roles can be added as members of database roles, inheriting the role's permissions.

Database Role (MSSQL_DatabaseRole node)

A type of database principal that can be assigned permissions to access database-level objects, such as the ability to connect to the database, access tables, modify database role membership, or execute stored procedures. Database users, user-defined database roles, and application roles can be added as members of database roles, inheriting the role's permissions.

Application Role (MSSQL_ApplicationRole node)

A type of database principal that is not associated with a user but instead is activated by an application using a password so it can interact with the database using the role's permissions.

MSSQL Edges Reference

This section includes explanations for edges that have their own unique properties. Please refer to the $script:EdgePropertyGenerators variable in powershell_deprecated/MSSQLHound.ps1 for the following details:

• Source and target node classes (all combinations)
• Requirements
• Default fixed roles with the permission
• Traversability
• Entity panel details (dynamically-generated)
  • General
  • Windows Abuse
  • Linux Abuse
  • OPSEC
  • References
  • Composition Cypher (where applicable)

Edge Classes and Properties

MSSQL_ExecuteAsOwner

MSSQL_GetAdminTGS

MSSQL_HasDBScopedCred

MSSQL_HasMappedCred

MSSQL_HasProxyCred

MSSQL_LinkedAsAdmin

Remaining Edges

Please refer to the $script:EdgePropertyGenerators variable in powershell_deprecated/MSSQLHound.ps1 for the following details:

• Source and target node classes (all combinations)
• Requirements
• Default fixed roles with the permission
• Traversability
• Entity panel details (dynamically-generated)
  • General
  • Windows Abuse
  • Linux Abuse
  • OPSEC
  • References
  • Composition Cypher (where applicable)

All edges based on permissions may contain the With Grant property, which means the source not only has the permission but can grant it to other principals.

Credits

• Original PowerShell version by Chris Thompson (@_Mayyhem) at SpecterOps
• Go port by Javier Azofra at Siemens Healthineers and Chris Thompson