Thick Client Pentesting: Reverse Engineering Binaries for Credentials

0s8 min★ 40 XP

Lesson 19Interactive lesson

Thick Client Pentesting: Reverse Engineering Binaries for Credentials

A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.

Lesson format18 sections3 code blocks1 practice itemUpdated Aug 27, 2026

#The Executable on the SMB Share That Contains Hardcoded Creds#link

Thick clients aren't web apps. They're installed locally. They store data on disk. They communicate with servers over HTTP or TCP. And they frequently contain hardcoded credentials in their source code or configuration files. Unlike web apps, you can't just view source in a browser—you need to reverse engineer.

Two-tier vs three-tier: why it matters for your attack

In two-tier architecture, the application communicates directly with the database. No intermediary. If you can intercept traffic or reverse engineer the binary, you get the connection string and credentials immediately. In three-tier architecture, the client talks to an application server first, which then talks to the database. The database credentials live server-side, not in the client binary.

Two-tier is less secure but gives you more as an attacker. Three-tier hides the database from direct client access. Most enterprise thick clients use three-tier, but legacy applications and internal tools still ship with two-tier designs. Check the architecture before you waste time looking for SQL connection strings in a three-tier client.

The RestartOracle-Service.exe scenario

You gain access to an exposed SMB share. The NETLOGON folder contains RestartOracle-Service.exe among other files. You download it, run it locally, and nothing visible happens. No window. No output. But ProcMon64 reveals it creates a temp file in AppData\Local\Temp.

Monitoring the executable with ProcMon

root@vulnarex:~#ProcMon64.exe /BackingFile C:\temp\procmon.pml /Filter "Process Name is Restart-OracleService.exe"

The batch file gets created and immediately deleted. To capture it, you change the Temp folder permissions to disallow file deletions. Disable inheritance, convert to explicit permissions, deselect Delete subfolders and files. Run the executable again. The batch file persists.

Extracting the hidden executable

powershell

$salida = $null
$fichero = (Get-Content C:\ProgramData\oracle.txt)
foreach ($linea in $fichero) { $salida += $linea }
$salida = $salida.Replace(" ", "")
[System.IO.File]::WriteAllBytes("c:\programdata\restart-service.exe", [System.Convert]::FromBase64String($salida))

The batch file drops base64-encoded content into oracle.txt, then a PowerShell script decodes it into restart-service.exe. Remove the deletion commands from the batch, run it, and you get the final executable. Running it displays a banner: Restart Oracle created by HelpDesk back in 2010.

Memory mapping and credential extraction with x64dbg

Strings analysis on the memory dump

root@vulnarex:~#strings64.exe restart-service_00000000001E0000.bin | findstr /i "password user sql"

The memory-mapped region with protection -RW-- and type MAP contains the .NET executable. Double-clicking reveals MZ magic bytes. Export the dump, run strings, and there it is: a SQL connection string with sa credentials. De4Dot deobfuscates the .NET assembly. dnSpy reveals the full source code—a custom runas.exe that restarts Oracle using hardcoded credentials.

STRICT SECURE AUDIT RULE

Thick client apps store credentials in local files, memory, registry keys, and configuration XML. Check all of them. The fatty-client.jar scenario showed credentials in beans.xml, a Spring configuration file with the secret clarabibiclarabibiclarabibi hardcoded in plaintext.

★ 40 XP

quiz BLOCK (★ 40 XP)

In a two-tier thick client architecture, where do database credentials typically reside?

Select your proof vectors above

Thick clients are everywhere in enterprise environments. Project management tools. Inventory systems. Custom internal utilities. They're less scrutinized than web apps because they're not internet-facing. But they sit on workstations, on SMB shares, in NETLOGON folders. And they almost always contain something useful. Would you download and reverse every unfamiliar executable you find on a share?

Lesson completion

Ready to resolve this lesson?

Finish the lesson once you have worked through the material. This awards ★ 40 XP.

Previous lesson

Lesson tools

Workspace

0% read

Lab notes

Notes persist per lesson.

The Executable on the SMB Share That Contains Hardcoded Creds

Content

Last updated

August 27, 2026

Agent Setup

Access lesson content programmatically for AI agents, LLMs, and automated pipelines.

Fetch as Markdown (Accept header)

curl -H "Accept: text/markdown" "/api/content/lessons?courseSlug=attacking-common-applications&lessonSlug=19-thick-client-attacks&lang=en&format=markdown"

MCP Server Config (mcp.json)

{
  "mcpServers": {
    "vulnarex": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-fetch"],
      "env": { "MCP_FETCH_URL": "https://vulnarex.com" }
    }
  }
}

MCP Server Card/.well-known/mcp.json A2A Agent Card/.well-known/agent-card.json API Catalog/.well-known/api-catalog robots.txt/robots.txt

Laboratory sanity code

Isolate active probes on matched virtual networks and keep execution streams sandboxed.

$salida = $null

$fichero = (Get-Content C:\ProgramData\oracle.txt)

foreach ($linea in $fichero) { $salida += $linea }

$salida = $salida.Replace(" ", "")

[System.IO.File]::WriteAllBytes("c:\programdata\restart-service.exe", [System.Convert]::FromBase64String($salida))