> When Data Mining Conti Leaks Leads to Actual Binaries and to a Hardcoded C2 With an Encryption Key on Tripod.com – Part Five
[AUTHOR: Dancho Danchev]
[DATE: 25/03/2026 12:41]
[LANGUAGE: EN]
Dear blog readers,
Continuing the "When Data Mining Conti Leaks Leads to Actual Binaries and to a Hardcoded C2 With an Encryption Key on Tripod.com - Part Four" blog post series in this post I'll continue analyzing the next malicious software binary which I obtained by data mining Conti Leaks with a lot of success.
The actual malicious software binary location URL:
hxxp://www.delwarren.com/backup/nowin.exe
MD5: 320dd151aed6a181d84e63f78cf801f0SHA-1: 573e93bb5075ec74ec3c45eaf4190af8e315a429SHA-256: c366c4e26ec3d2698a94dc04afb58dad429d6c28dff1820d53e277e108103f8f
Here's the analysis.
High-confidence classification
nowin.exe is a Windows x86 network backdoor whose primary behaviors are:
persistent/repairable multi-threaded C2 beacons (keeps up to 3 concurrent worker threads),
a custom C2 application protocol (length-framed + lightweight obfuscation using a constant marker),
remote command execution (via system() with captured output),
interactive command shell (cmd.exe) over the network,
a secondary, more complex relay-based shell channel negotiated using a SOCKS-like control exchange.
The overall design is typical of a small bespoke RAT/backdoor: connect to a hardcoded controller, identify/beacon, then loop receiving commands which dispatch into a few core capabilities.
Runtime / threading model
Process start and initialization
entry_point (0x40383c) and runtime_init (0x40357c) implement standard CRT initialization and single-init locking.
Initialization uses:
InterlockedCompareExchange guarding a global init lock (g_init_lock at 0x407504),
g_init_state (0x407500) to track initialization progress.
Worker thread redundancy (up to 3 concurrent)
backdoor_worker_thread (0x4019a0) is the main C2 loop.
It increments/decrements g_active_thread_count (0x4074c0) under g_thread_count_lock (0x40749c).
On certain failures or after certain commands, it respawns itself via _beginthread(backdoor_worker_thread, 0, 0) until g_active_thread_count < 3 no longer holds.
This provides resilience: if a connection drops or a thread exits, the malware will try to maintain a small pool of active connections.
C2 infrastructure and basic socket operations
Hardcoded controller address
C2 IP: 88.214.27.52, constructed at 0x401adc (sprintf("%d.%d.%d.%d", 0x58, 0xd6, 0x1b, 0x34)).
Port: 443 (htons(0x1bb)), set in connect_to_c2 (0x402aa0).
Connection procedure (connect_to_c2, 0x402aa0)
Creates TCP socket (via WSASocketA(AF_INET, SOCK_STREAM, IPPROTO_TCP)).
Uses a non-blocking connect pattern:
ioctlsocket(FIONBIO, 1) → nonblocking,
connect,
select(... writefds ..., timeout=10s) to detect connection completion,
ioctlsocket(FIONBIO, 0) restore blocking.
Returns boolean-style success.
This is a common technique for implementing a connect timeout on Windows.
Primary C2 protocol (framing + “AssHole” obfuscation layer)
The malware’s main message channel uses:
4-byte length prefix
encoded payload (obfuscated, not encrypted)
Framing
Receive path: recv_command_from_c2 (0x4027a0)
Reads exactly 4 bytes (the length) via repeated recv.
Allocates/resizes a std::string to that length.
Reads exactly len bytes via recv_exact (0x402a60).
Send path: send_data_to_c2 (0x4028d0)
Builds a string, then sends 4-byte length followed by payload (body send uses send_exact at 0x402a20 for full transmission).
“AssHole” wrapper purpose and mechanics
Literal marker: "AssHole" at 0x405558.
Alphabet used by transform: "0123456789abcdef" at 0x405544.
Both send_data_to_c2 and recv_command_from_c2 incorporate "AssHole" directly into the transform pipeline:
On send: the outgoing buffer is combined with "AssHole" and passed through encode_obfuscated_hex_string (0x4024a0).
On receive: the received blob is combined with "AssHole" and passed through decode_obfuscated_hex_string (0x402620).
What this achieves
It is a lightweight obfuscation/encoding layer that:
makes on-the-wire command tokens/results non-plaintext,
provides a trivial shared constant that must match between sides (a weak “key”/salt),
reduces accidental decoding of arbitrary traffic into meaningful commands.
This is not cryptography; it behaves like reversible per-character nibble transformations over hex-like text.
Command protocol: exact tokens and behaviors
After initial beaconing, backdoor_worker_thread continually:
recv_command_from_c2 → decodes into a command string
compares equality against several hardcoded tokens
dispatches behavior per match
Exact command tokens (as used in comparisons)
The decoded command string is compared against these literal tokens:
Role (renamed)
Token string
Address
kCmd_ShellIO
Csdnma91fggw7
0x405234 (0x407100)
kResp_ShellIO_Ack
Zcvznw8i739
0x405228 (0x407104)
kCmd_StartWorkersAndShell
Fdh9873
0x405220 (0x407108)
kCmd_DropPayload
VCNde92756
0x405214 (0x40710c)
kCmd_ExecAndReturn
NMFVd8w7663
0x405208 (0x407110)
kCmd_SpawnCmdExe
COMM500
0x405200 (0x407114)
kCmd_SelfMoveTrash
JWEdj898
0x4051f4 (0x407118)
Also present in the initial beacon string:
NUDEew97834g at 0x405244 (0x4070fc) (used as part of the initial identification string, not a compare token in the dispatch shown).
Command behaviors (as implemented)
Shell/relay initiation
Matching kCmd_StartWorkersAndShell ("Fdh9873") triggers:
spawning additional workers (up to 3 total),
entering handle_shell_io(s) (0x403360) which negotiates and runs the relay-based shell path.
Matching kCmd_ShellIO ("Csdnma91fggw7") results in sending kResp_ShellIO_Ack ("Zcvznw8i739") back.
Remote exec with output capture
Matching kCmd_ExecAndReturn ("NMFVd8w7663") triggers execute_system_and_capture_output (0x401720):
constructs a temporary file path,
runs system() redirecting output to file,
reads file contents into a std::string,
deletes the file,
sends the output back (with token appended/used as delimiter/prefixing behavior).
Direct interactive cmd.exe
Matching kCmd_SpawnCmdExe ("COMM500") triggers spawn_reverse_shell(&s) (0x402ba0).
Drop/write payload to disk
Matching kCmd_DropPayload ("VCNde92756") triggers write_received_payload_to_file() (0x4011e0):
parses content around a '|' delimiter and writes the trailing data to a file.
then responds to C2 with the same token via send_data_to_c2.
Self-move and exit
Matching kCmd_SelfMoveTrash ("JWEdj898") acks then calls self_move_and_exit() (0x401310), which renames/moves itself to a path with a .trash suffix and exits.
Reverse shell subsystem: two distinct modes
Mode A: inherited-handle cmd.exe over the connected socket
spawn_reverse_shell (0x402ba0) does the classic redirected-shell pattern:
Builds command line "cmd.exe",
Creates process with bInheritHandles=1,
Sets STARTUPINFOA.hStdInput/hStdOutput/hStdError to the socket handle,
Waits for process termination.
This provides a direct interactive shell if the controller can speak to the socket as a console stream.
Mode B: relay-based “secondary shell channel” with control handshake
handle_shell_io (0x403360) implements a more complex path that looks like it supports dynamic connection/relay behavior rather than only reusing the initial C2 socket.
Step 1 — control header handshake (recv_shell_control_header, 0x403280)
On-wire control header:
#pragma pack(push, 1)
typedef struct {
uint8_t magic; // must be 0x05
uint8_t len; // number of payload bytes
uint8_t payload[len]; // expected to include a NUL terminator
} ShellCtrlHeader;
#pragma pack(pop)
Behavior:
reads 2 bytes + len payload bytes,
validates magic==0x05 and len!=0,
validates payload “looks like a C-string” by searching for '\0' from the end,
sends 2-byte ack: [0x05][0x00] if NUL found else [0x05][0xff].
This is a synchronization trigger for the next-stage negotiation.
Step 2 — SOCKS-like relay parameter request (parse_shell_relay_params, 0x402f70)
Immediately after step 1, it reads and validates a structure that is strongly SOCKS5-inspired:
#pragma pack(push, 1)
typedef struct {
uint8_t ver; // must be 0x05
uint8_t cmd; // saved as `useRelay`
uint8_t rsv; // must be 0x00
uint8_t atyp; // 0x01 IPv4, 0x03 DOMAIN, 0x04 IPv6(16B)
// dstaddr follows (size depends on atyp)
// dstport follows (2 bytes)
} ShellRelayReqHdr;
#pragma pack(pop)
If atyp==0x01: reads 4 bytes IPv4 into controllerIp.
If atyp==0x03: reads 1 byte domainLen, reads domainLen bytes, resolves via gethostbyname(), stores first IPv4 into controllerIp.
If atyp==0x04: reads 16 bytes (IPv6-like); downstream connect-back code still appears IPv4-specific.
Reads 2 bytes port into controllerPort.
This function also performs response sends (including a distinct error response sequence when domain resolution fails), consistent with a mini-proxy/SOCKS-style negotiation.
Step 3 — connect-back and relay loop
If useRelay == 1, handle_shell_io:
calls connect_back_to_controller (0x402e80) to create a new socket and connect to the controller-provided endpoint.
Notable detail: it uses *0xffff0000 as the IP source (a global/shared location used as a scratch/parameter channel) and controllerPort for the port.
on success, sends a 10-byte “event packet” via send_shell_event (0x402e20), flips both sockets to non-blocking, and enters socket_relay_loop (0x402cf0) to relay data bidirectionally.
Relay implementation details:
socket_relay_loop uses select() + __WSAFDIsSet to detect readable sockets.
relay_one_direction (0x402c70) transfers up to 0x80e8 bytes and then retries on WSAEWOULDBLOCK/WSAEINPROGRESS with sleeps.
Shell event packet (10 bytes)
send_shell_event (0x402e20) sends exactly 10 bytes:
#pragma pack(push, 1)
typedef struct {
uint32_t magic_and_type; // (arg3 << 8) | 0x01000005 => low byte
0x05, next byte = type
uint32_t ip_be; // 32-bit IPv4 value
uint16_t port_be; // 16-bit port
} ShellEventPacket;
#pragma pack(pop)
Used types observed in handle_shell_io:
type 0 on successful connect-back path,
type 7 on the failure/alternate path.
Operational picture: full C2 communication process
Worker thread starts (backdoor_worker_thread), increases global thread count.
Creates TCP socket → connects to 88.214.27.52:443 with timeout.
Sends initial beacon string (contains NUDEew97834g and local config values separated by |) using the primary framed+obfuscated protocol.
Enters command recv loop:
receive length-prefixed payload,
decode using "AssHole"-salted obfuscated-hex scheme,
compare decoded command token to known strings, execute handler.
Depending on command:
run cmd.exe over the C2 socket,
run a relay-negotiated shell channel using a secondary SOCKS-like control exchange,
execute arbitrary commands via system() and return output,
drop data to file,
self-move and exit,
or spawn additional workers to maintain 3 connections.
Key takeaways for defenders / responders (from a RE standpoint)
Primary network indicators:
88.214.27.52:443 TCP.
Length-prefixed binary messages (4-byte length) containing obfuscated hex-like content salted with "AssHole".
Secondary shell negotiation begins with a 2-byte control header starting with 0x05 and then a SOCKS5-like request (ver=0x05, rsv=0, atyp in {1,3,4}).
The command channel is token-driven; tokens are not human-readable but are fixed literals and can be used for detection after decoding.
The reverse shell path is strong evidence: CreateProcessA("cmd.exe") with stdio set to the socket and inheritable handles.
The post When Data Mining Conti Leaks Leads to Actual Binaries and to a Hardcoded C2 With an Encryption Key on Tripod.com – Part Five appeared first on Security Boulevard.