StealBit Analysis and LockBit Associations

Original work: July 2, 2024

Investigation context

I prepared this malware-analysis report and accompanying presentation for a Security Joes technical assessment in July 2024. My role covered investigation, reverse engineering, report writing, and detection recommendations. This archive summarizes the analysis exercise; it does not claim that I operated the incident-response environment described in the supplied scenario.

Following the evidence

The investigation connected a suspicious Windows process with evidence from memory, a packet capture, and the executable itself. I examined the process tree, executable location, network activity, decoded strings, and Windows API usage to establish what the program could do and what the available capture actually showed.

The packet-capture analysis also identified port-scanning activity. The original work was titled LockBit / StealBit Threat Detection and Malware Analysis.

The reverse-engineering work documented:

• An anti-debugging check involving NtGlobalFlag, followed by an EB FE infinite-loop branch.
• Runtime string decoding and dynamic resolution of Windows APIs.
• Filesystem exclusions and environment checks that affected execution.
• A console title identifying StealBit and the named pipe STEALBIT-MASTER-PIPE used for communication.
• Networking operations involving WSAIoctl.

Findings and confidence

The report associated the observed tool and indicators with StealBit and discussed connections to LockBit 2.0. The supplied evidence did not demonstrate ransomware execution or a sensitive-file transfer. The available indicators also did not establish a LockBit 3.0 campaign attribution.

This distinction matters: identifying a tool associated with an actor is different from proving which campaign used it, and capability does not establish that a particular action occurred in the captured interval.

Defensive output

The updated report included a YARA rule and recommendations for correlating process, named-pipe, and network evidence. File-content matching and network monitoring serve different purposes; a YARA string match alone does not prove an outbound connection or exfiltration.

This work connects to my malware-analysis methodology and binary reverse-engineering demonstration.

Technical context: weighing different kinds of evidence

This interpretation explains the existing report’s reasoning; it does not add another execution, capture, or detection result.

The investigation draws on artifacts that answer different questions. A memory image is a snapshot of state. A packet capture covers activity visible at a particular collection point and interval. Static code exposes possible behavior, including paths that may not have run. Their agreement can strengthen a conclusion, while their differences often reveal the limits of collection.

Making detection claims precise

A rule should describe the data it actually inspects. A YARA match on an embedded address is a match on bytes, not an observation of a live connection to that address. The YARA rule documentation explains string declarations and conditions; operational network evidence must come from an appropriate telemetry source.

A detection idea also needs evaluation against relevant benign material and related variants before broader use. A distinctive string can be absent in another build, and a generic string can occur in unrelated files. The archived report’s rule is therefore part of its defensive output, not evidence of a measured production detection rate.

The strongest conclusion remains the bounded one: explain the behavior and associations supported by the supplied artifacts, preserve alternative explanations, and identify what further evidence would resolve them.

A transparent string-matching example

This small example illustrates the boundary between a byte match and a behavioral finding. It uses synthetic byte arrays; it is neither the report’s YARA rule nor a validated malware detector.

marker = b'STEALBIT-MASTER-PIPE'

def contains_pipe_marker(data):
    return marker in data

assert contains_pipe_marker(b'demo:' + marker)
assert not contains_pipe_marker(b'ordinary synthetic text')

A positive result establishes only that the supplied bytes contain the exact marker. It does not prove a pipe was created. Encoding, runtime decoding, or a changed string could prevent this exact match; benign documentation could contain it. The investigation must connect the artifact with code references and execution evidence before drawing a stronger conclusion.

Archive record

Adapted from my July 2024 report and presentation correspondence. This public summary omits host identities, private correspondence, and the original assessment files.