FLOSS: Recovering Hidden Strings

Strings can give us useful answers very quickly during static analysis. Domains, file paths, registry keys, mutexes, API names, and error messages can shape the first few minutes of an investigation. The obvious limitation is that a normal strings scan can only reveal values that exist in a readable form.

Malware does not have to store important data that way. A value may be constructed at runtime, written to the stack piece by piece, or decoded only when the program needs it. In those cases, an unremarkable strings output does not mean that useful data is absent.

That is where FLOSS comes in.

##What Is FLOSS?

FLOSS stands for FLARE Obfuscated String Solver. Developed by Mandiant's FLARE team, it can extract ordinary ASCII and UTF-16LE strings while also looking for values that are constructed or decoded by the program.

Its output generally separates strings into static, stack, tight, and decoded categories. Static strings already exist in readable form inside the file. Stack strings are built on the stack during execution. Tight strings focus on values produced by compact instruction sequences, while decoded strings appear after a decoding routine transforms previously unreadable data.

That distinction is useful during triage. A string not being visible in the file does not mean the program never uses it.

IMAGE PLACEHOLDER 1: Real FLOSS terminal output showing static, stack, tight, and decoded string categories.

##Where Do the Strings Appear?

Suppose a sample appears to communicate with a C2 server, but the normal strings output contains no useful domain. The address may not be stored as plaintext at all. It could be assembled character by character or recovered from an obfuscated buffer when the malware runs.

At that point, searching the file for more text will not necessarily help. The interesting part becomes the code that produces the string.

A routine may write characters onto the stack, transform bytes inside a loop, or create a readable buffer only after a decoding step. FLOSS tries to recover useful strings from exactly these kinds of patterns.

##How Does FLOSS Recover Them?

For decoded strings, FLOSS does more than scan bytes. It analyzes control flow, looks for functions that may construct or decode strings, and emulates relevant pieces of code.

During that emulation, changes in memory can reveal values that were not readable before the routine ran. A buffer that initially looks meaningless may turn into a domain, file path, or command.

This is not a perfect process. Some decoding routines may be missed, and an emulated path may not behave exactly as it would in the real environment. Even so, it can expose useful data early in static triage without requiring the analyst to manually identify every decoder first.

##Using FLOSS During Initial Triage

The basic command is straightforward:

floss suspicious.exe

For a shorter overview:

floss --summary suspicious.exe

When the output becomes large, it can be narrowed down:

floss --interesting -- suspicious.exe
floss --query "http" -- suspicious.exe

A useful workflow is to begin with the broader output and then filter around anything that stands out. If FLOSS recovers a domain, the next step is not to immediately call it an IOC. I would first check which function produces it and where the value is later used.

IMAGE PLACEHOLDER 2: Comparison between ordinary strings output and a useful string recovered by FLOSS from the same sample.

##Not Every Recovered String Is an IOC

A domain, path, or command appearing in FLOSS output does not automatically confirm behavior. It may belong to an unused code path, come from a library, remain from testing, or have been included to mislead analysis.

The recovered value still needs context. Which function uses it? Is that code path reachable? Does dynamic analysis show the same value? Does network activity support the interpretation?

Extraction gives us a lead; verification is still part of the analysis.

##Conclusion

FLOSS expands string analysis beyond values that are already readable inside the file. Strings built on the stack or recovered through decoding routines can become visible much earlier in the investigation.

That changes one small but useful assumption. When a normal strings scan does not show the value we expect, the next conclusion does not have to be that the value is missing. The program may simply be creating it itself.

FLOSS helps close that gap.

##Source

Mandiant FLARE — FLOSS

Stay with Malrev0x...