Extracting SQL Connection Strings from Binaries: GDB to Lateral Movement

#The Binary That Phones Home to a Database You Can Own#link

You find octopus_checker on a remote machine during an internal assessment. Running it locally prints Attempting Connection followed by a driver error. The binary connects to a SQL Server instance to verify availability. Somewhere in that binary is a connection string. Somewhere in that connection string is a password.

Disassembling with GDB and PEDA

The call to SQLDriverConnect at offset +433 is where the connection string gets passed. Set a breakpoint there. Run the program. The RDX register holds the connection string in plaintext.

The .NET variant: dnSpy and DLL inspection

Not every binary requires GDB. The MultimasterAPI.dll found on another host is a .NET assembly. Get-FileMetaData confirms the .NET framework version. Drag it into dnSpy and navigate to MultimasterAPI.Controllers → ColleagueController. The database connection string with credentials sits in the constructor, plaintext, no obfuscation.

What to do with extracted credentials

Try the SQL credentials against the database server directly. If that fails, spray the password against other services on the network. The same password often appears in multiple connection strings across different applications. Check Active Directory. Check SSH. Check the VPN portal. One credential from a forgotten binary can cascade into full domain compromise.

The binary connected, failed to load the ODBC driver, and printed an error. But the connection string was already in memory. The credentials were already in RDX. The application didn't need to successfully connect for you to extract everything you needed. Next time you find an unfamiliar executable on a share, don't just run it. Debug it.