Spotting Forensic Gold in Malware Strings

I mean, to a normal person, it's complete gibberish, right?

Absolutely.

Yeah, exactly.

Right.

Exactly.

And it's all just sitting right there in plain text.

It really is the ultimate needle in a haystack scenario.

It really does.

Grab yourself a hot cup of cutting chai, pull up a chair and, you know, just settle in with us.

Glad you're here with us.

We are we're going back to basics today.

Yep.

And specifically, we're diving into the secret language of strings.

You want to just look at it.

Yeah.

You want to do static analysis, meaning, you know, the files at rest, it is not running.

And I always like to think of analyzing malware by looking at its strings as being exactly like reading the label on a medicine bottle.

Right.

You want to see the active ingredients.

And you want to figure all of that out without having to actually drink the mysterious liquid inside.

Yeah.

In this case, you want to uncover the intent without ever double clicking that binary.

OK.

Yes.

Imagine the label has been shredded into a thousand tiny pieces.

Mixed with a bunch of random paper scraps and then stirred into the medicine itself.

You have to act on it.

You have to actively fish the pieces out, like one by one, and piece them together.

That is a much better and slightly more terrifying way to picture it.

Yeah.

It is a massive head start.

You're going to feel totally confident that you're going to be able to figure it out.

You're going to feel totally confident that you're going to be able to figure it out.

Let's get into it.

Before we can piece together our shredded label, we have to actually understand the language it's printed in, right?

Right.

A string in the context of a compiled binary is simply a sequence of printable characters embedded within that file.

Think of a simple word like T-H-E.

So it's basically the human-readable text hiding inside the computer's native language.

And typically, these strings are stored in one of two formats, ASCII or Unicode.

Because if you only look for one.

If you search for one and ignore the other, you might miss the very clue you need.

Like, keep it really simple.

So ASCII is the older, simpler format.

One byte per character.

Yeah.

Specifically, you know, in hexadecimal memory, it's 0x42 for the letter B, 0x41 for A, and 0x44 for D.

Okay.

What about Unicode?

Two bytes?

So that same word B-D in Unicode looks very different in the raw memory.

Then the A is 0x41, and the D is 0x44 and 0x00.

Go for it.

But in Unicode, it's the letter B, an empty space, the letter A, an empty space, the letter D, an empty space.

Why would Microsoft design a system to waste so much space?

It does seem that way if you only speak English.

ASCII was built for the English alphabet.

Oh, yeah, yeah.

But what if you need to display Japanese characters?

Oh, right.

Exactly.

You cannot fit them into one byte.

So that makes a lot more sense.

So the empty 0x00 space you see when looking at English text in Unicode is just the system reserving that second byte, even if the English letter doesn't technically need it.

It's built for global communication.

The computer needs a way to know when the word is actually finished, right?

You nailed it.

It literally terminates the string.

In ASCII, the N-L-L terminator is a single 0x000.

In Unicode, because everything is double sized.

All right.

But I have to push back here for a second.

Yeah.

Let's hear it.

Well, the source has mentioned that the strings tool ignores context entirely.

None at all.

Every time it sees a sequence of three or more readable ASCII or Unicode characters followed by an N-L-L terminator, it basically says, aha, I found a string and just prints it to the screen.

It is a very blunt instrument.

Pretty much.

If you stare at random computer bytes long enough, pure statistical probability dictates you are bound to find three readable characters.

Just by coincidence.

Sometimes it's an intentional word the malware author wrote, like an IP address.

You've hit the nail on the head.

And it's why this is an actor detective game, not just an automated scan.

The strings tool is incredibly dumb.

So if the tool just blindly grabs everything, how do you deal with the overwhelming wall of text it spits out?

You absolutely do.

In the industry, we often talk about the 90-10 rule.

Let me guess.

What the tool finds in that alphabet soup is complete garbage.

90% of the strings you extract from a standard Windows executable are going to be pure noise.

90%.

It's standard Windows system junk, names of common libraries that every single benign program on earth uses, meaningless memory error codes, and as you pointed out, the random alphabet soup coincidences.

Right.

The signal.

We call those indicators of compromise, or IOCs.

They are the forensic gold we are panning for in that river of junk.

So logically, we need to know what we are panning for.

What categories are we actually scanning that wall of text for?

Three specific categories of information.

Because malware needs to talk.

Malware rarely operates in isolation.

Right.

Exactly.

Okay.

It tells you exactly who the malware is trying to talk to.

So the malware has phoned home to its command and control server, but it can't just exist in a vacuum, right?

Very true.

Yeah.

That brings us to category two.

Host-based activity.

It would explain what it does What kind of things are we looking for there?

For instance, if you see strings pointing to hidden folders, like app data%, or system folders, like System32, that's a huge clue that it's trying to bury itself where standard users don't look.

For that, you look for registry keys.

I think it should have any kind of institution-likeünf.hear,алась, capacity, or an agent in particular.

system right right if you see a string for registry key like software Microsoft Windows current version run you instantly know the malware is intent it is trying to install itself in the run key so that it starts up automatically every single time the computers turn on its establishing persistence that makes perfect sense network activity to phone home host activity to dig in and the third category commands you are looking for the vocabulary of the attacker you are scanning for words that sound like direct instructions like words like download upload cmd.exe key log or sleep if you see those clustered together you are looking at the exact menu of options the malware uses to take orders from the attacker okay this all sounds great in theory but I really want to take this out of theory and see how this plays out in the real world let's turn our listener into a detective right now let's look at the re101 lab mentioned in our epoch zero source materials so let's do it that is a great example of how we can come up with tailored tools that will make up a lecture more for everyone right Korea I did a listen to the author number of all the material you should thank you for joining us right now we did feel a lot more than we had thought me too thank you to all of you for being here today we were very happy to see you Right.

It definitely does.

It doesn't require a password to unlock.

Right, exactly.

Attackers use it because if they try to send raw, messy binary commands over a standard text protocol like HTTP, it can crash the web server or, you know, get flagged by simple firewalls.

That is a brilliant breakdown.

Exactly.

They simply took that XIMAS string, dropped it into a standard decoder tool.

And boom.

There it is.

Flag ops used to use 1337B64 encryption.

But let's escalate this from a lab exercise to a real-world, highly dangerous threat that students face.

Oh, N-J-R-A-T.

This is a notorious remote access trojan.

Very nasty.

They can turn on your webcam, log your keystrokes, steal your files.

And the student reports on analyzing NJRAT are a perfect showcase of the power of string analysis.

What blew my mind in those NJRAT reports wasn't just that they found a generic IP address.

PCP.eu.ngrok.io.

They literally found the attacker's routing tunnel before the malware even woke up.

But attackers love abusing it because it lets them hide their real IP address behind NGROK's infrastructure.

And finding that specific NGROK domain sitting in the strings means that before the malware even runs, you already know exactly what web address you need to block on your company's firewall to neutralize the threat.

It is.

It really is.

The strings also revealed the malware's evasion tactics.

Ah, the MELT command.

I have to ask a mechanical question here because the concept of MELT is fascinating.

As I understand it, the MELT command is an instrument...

...for the malware to delete its original executable file after it has copied itself and hidden deep inside the app data folder.

It melts away its original tracks, so incident responders don't know how the initial infection happened.

Windows usually throws an error and locks active files, doesn't it?

You are absolutely right.

So the malware has to cheat the system.

The malware creates a copy of itself in a hidden folder.

But the original file is still running, right?

Yeah.

Yeah.

This acts as a delay timer.

Right.

It exits.

Oh, wow.

10 seconds later, the ping command finishes, and the next instruction in that hidden command line is a DEL command delete aimed directly at the original, now-closed malware file.

It melts.

It basically hires a temporary hitman to wait in the alleyway until it goes to sleep and then wipes out the evidence.

And we can see all of that intent, the Engrok tunnel, the MELT command, just by reading the shredded label on the bottle.

It is.

What's that?

Right.

The answer, of course, is that they do try to hide them, and that brings us to the packing problem.

This is where the game of cat and mouse gets really interesting for an analyst.

What if I'm a junior analyst, I run the strings tool on a highly suspicious file that I am almost certain is malware.

Just a few lines.

Is that a dead end?

Should I just move on?

Finding no strings is not a dead end.

Really?

Because legitimate, standard Windows programs always have hundreds, if not thousands, of strings.

Right.

Exactly.

Okay, let's unpack packing, so to speak.

Think of packing like compressing a file into a ZIP archive.

Okay.

They scramble the actual binary code into high-entropy gibberish.

So when you look at the file on your hard drive, you aren't actually looking at the malware, you're just looking at the delivery truck.

And the wrapper's only job is to run, when the user double-clicks the file, decompress the hidden malware directly into the computer's memory, and then hand over control to the real malicious code.

That's a great way to picture it.

Mm-hmm.

It's a padlocked, duct-taped bottle.

The duct tape hides the label, but the presence of the tape is your biggest clue.

Give us the signs.

The first is high entropy.

Normal computer code has patterns.

Even empty space has the pattern of repeated zeros.

But compressed or encrypted data is mathematically designed to look completely random.

Okay.

Let's talk about the imports, the shopping list.

Normal programs import dozens of functions from the Windows operating system.

Yeah.

I need the tool to read a file.

The Packed Wrapper doesn't need all that.

A Packed Wrapper program doesn't need to do any of that.

Unpack the real malware into memory.

Yeah.

You got it.

Load Library and Get Toke Address.

Because Load Library is literally the master key.

It is the tool required to secretly order the rest of the tools in the dark once the program is already running.

Yeah.

If you look at a file's imports and it only has Load Library and Get Toke Address, you are almost certainly looking at the unpacking stub of a packed piece of malware.

The silence is the clue.

Exactly.

You are anticipating their moves.

Okay.

We started with the mission, basic static analysis using the strings tool.

We learned that by separating the 90% system noise from the 10% signal, we can map out IP addresses.

We can uncover up to 50% of the malware's intent without ever actually executing it.

We also saw how it works mechanically in the real world, decoding base 64 strings to find hidden flags in the RE101 lab and pulling the exact ngrok command and control server right out of the NJRRAT malware before it ever established a connection.

And we broke down the mechanics of the MELT command.

If we don't see any strings at all, we shouldn't give up.

It gives you a phenomenal head start in your investigation.

But before we wrap up, we've talked a lot about the cat and mouse game today, how attackers adapt.

I want to leave you with where the mouse goes next.

Exactly.

This is where the game gets truly sophisticated.

And this tool exists to solve a very specific, very modern problem called stack strings.

This is the stuff that keeps analysts up at night.

Attackers know that you and I are reading their labels.

So the most advanced attackers are no longer just packing their malware.

Not even compressed.

The string simply does not exist on the hard drive.

It builds the string dynamically on the CPU stack, uses it to connect to the C2 server, and then immediately overwrites it with zeros.

It's wild.

If the malicious label only exists for a single microsecond in the computer's active memory and never once touches the disk, how do you catch it?

It's a fascinating, terrifying problem.

The detective game never stops evolving.

But for now, you know how to read the static labels.

Keep exploring, keep questioning the noise, and we will catch you on the next deep dive.