Crash in x86 version

[Jonas Vestberg]

Description

Running sql-info or sql-query in a x86 beacon results in a crash.

Steps to reproduce

Start x64 beacon (reproduced with stageless x86 exe).

beacon> sql-info asd

beacon> sql-query asd asd

Watch beacon die and review Application Eventlog for crash.

Faulting application name: https_x86.exe, version: 0.0.0.0, time stamp: 0x00000000
Faulting module name: msvcrt.dll, version: 7.0.22621.2506, time stamp: 0xd9bf2a9a
Exception code: 0xc0000005
Fault offset: 0x0007e6de
Faulting process ID: 0x0x7FC
Faulting application start time: 0x0x1DAA7D8E039336E
Faulting application path: C:\[redacted]\https_x86.exe
Faulting module path: C:\Windows\System32\msvcrt.dll
Report ID: 2a799cca-6f49-4643-b944-ea70ed563a6f
Faulting package full name: 
Faulting package-relative application ID: 

Test environment

• OS: Microsoft Windows [Version 10.0.22631.3447]
• CobaltStrike: 4.9.1
• Kits: None
• Profile: webbug

[Matt Creel]

This is actually a much larger issue with the x86 BOFs, regardless of supplied arg values. The problem within msvcrt.dll that your eventlog referenced was occuring on this line in sql.c

MSVCRT$sprintf((char*)connstr, "DRIVER={SQL Server};SERVER=%s;DATABASE=%s;Trusted_Connection=Yes;", server, dbName);

Fixed this in a new branch (fix/x86-crash) dedicated to this issue, however, it's not the only x86 specific problem. It also appears that this call to SQLDriverConnect is returning a SQL_INVALID_HANDLE error. Again, this does not affect the x64 BOFs for some reason.

[Matt Creel]

Traced the issue back a bit farther today. Looks like the connection handle (SQLHDBC dbc) is being corrupted between its allocation and when it's passed to the ODBC32$SQLDriverConnect call

How the SQLDriverConnect call looks in API monitor when compiled to query.x86.exe (working)

How the SQLDriverConnect call looks in API monitor when compiled to query.x86.o and run via COFFLoader

The handle is getting successfully allocated by the ODBC32$SQLAllocHandle(SQL_HANDLE_DBC, *env, &dbc); call

Confirmed this code works fine for:

• x64 BOF
• x64 Exe
• x86 EXE

But consistently has this handle corruption behavior for the x86 BOF