The 10 Commands · lesson 3 · 2026-09-13

Practical Malware Analysis: The 10 Commands You Need in 2026

▶

Before you start

• A Kali Linux machine or VM (file, strings, xxd, readelf, ldd and objdump are preinstalled).
• A working folder: cd /tmp. The lesson only inspects /bin/ls, a harmless system binary, and saves malware-report.txt.
• Only test systems you own or are authorized to test.

You do not need a malware lab to start analyzing a suspicious file. You need ten ordinary Linux commands, and today we run every one of them for real, on a program that is completely safe.

One rule before anything else. We are analyzing a real, benign, everyday program, the ls command that already lives on this computer. Never run an unknown or untrusted file directly. Every one of these ten commands only reads the file. Nothing here ever executes it.

Step one. Before anything else, what actually is this file?

1 — What kind of file is this?

file /bin/ls

An analyst never trusts a file’s name or its extension. The file command looks inside the file itself and reports what it actually is. A file called photo dot jpg that file identifies as an executable is already a huge red flag.

file, space, slash bin slash l s, and press Enter.

A 64-bit Linux executable, dynamically linked, and stripped of debug information. Every one of those words will matter by the time we finish.

Step two. Give this exact file a fingerprint nobody can fake.

2 — Fingerprint it: SHA-256

sha256sum /bin/ls

Change even one byte of this file and this fingerprint changes completely. Analysts share this fingerprint, called a hash, instead of the file itself, and use it to check whether a file matches something already known to be malicious.

s h a two five six sum, space, slash bin slash l s, and press Enter.

That long string is this file’s fingerprint, and only this exact file will ever produce it.

Step three. An older fingerprint format, and you will still see it everywhere.

3 — The legacy fingerprint: MD5

md5sum /bin/ls

M D5 is weaker and outdated for security purposes, but threat-intelligence reports and malware databases still list it constantly alongside the newer hash. A real analyst recognizes both formats on sight.

m d five sum, space, slash bin slash l s, and press Enter.

Shorter than the last one, and that is simply how M D5 looks. Same file, two different fingerprint formats.

Step four. Now we look inside the file for readable text.

4 — Pull out readable text

strings /bin/ls

A binary file is mostly unreadable machine code, but it is almost never entirely unreadable. Strings finds every run of plain text buried inside it — and malware analysts read this text first, because it is often where a program’s true purpose leaks out.

strings, space, slash bin slash l s, and press Enter.

strings /bin/ls | head -n 15

Function names and library references, all sitting in plain text inside a file that looks, on the surface, like unreadable noise.

Step five. That was a lot of noise. Let’s search it for something specific.

5 — Filter the noise

strings /bin/ls | grep -i GLIBC

A real binary can contain thousands of strings. Piping strings into grep lets you search that flood for exactly what you care about — here, which system library version this program expects. In a real investigation you would search for a suspicious web address instead.

strings, space, slash bin slash l s, space, the pipe symbol, space, grep, space, dash i, space, G L I B C, and press Enter.

strings /bin/ls | grep -i GLIBC | head -n 8

Now instead of thousands of lines, we see exactly the handful that matched. That is the whole value of filtering.

Step six. Skip the interpretation entirely. Look at the raw bytes.

6 — Read the raw bytes

xxd /bin/ls

Every tool so far has interpreted the file for us. xxd shows you the file exactly as it truly is, byte for byte, in hexadecimal. This is how you verify a file’s true type when you trust nothing else.

x x d, space, slash bin slash l s, and press Enter.

xxd /bin/ls | head -n 5

Look at the very first four bytes: 7f, 4 5, 4 c, 4 6. That is spelled out, E L F, and it is the fixed signature every Linux executable begins with, no matter what its file name claims.

Step seven. Now open the file’s own internal structure.

7 — Read the executable’s header

readelf -h /bin/ls

This header is a fixed, structured block every one of these files carries, listing exactly what kind of machine this program was built to run on and where inside the file its code begins.

read e l f, space, dash h, space, slash bin slash l s, and press Enter.

The machine architecture, and the entry point — the exact address where this program starts running the moment it launches. Malware analysts read this before anything else touches the code.

Step eight. What else does this program need to even run?

8 — List its runtime dependencies

ldd /bin/ls

Almost no program is truly self-contained. It loads other shared libraries the moment it starts. Malware often depends on a suspicious or unusual library, and that dependency list alone can be a finding.

l d d, space, slash bin slash l s, and press Enter.

Every one of those is a separate file this program pulls in the instant it launches, before it does anything else at all.

Step nine. Take one careful look at the actual machine code.

9 — Peek at the machine code

objdump -d /bin/ls

This turns the raw, unreadable machine code back into the individual processor instructions it actually is. Full reverse engineering goes far deeper than this, but even a first glance tells you whether a file’s real structure matches what it claims to be.

o b j dump, space, dash d, space, slash bin slash l s, and press Enter.

objdump -d /bin/ls | head -n 20

That is the literal machine code this file runs, instruction by instruction — the layer every other command today was only describing from the outside.

And step ten. A finding nobody wrote down never happened.

10 — Write the finding down

sha256sum /bin/ls > report.txt

The greater than sign redirects a command’s output into a file instead of printing it. This is exactly how you’d log a fingerprint for a report someone else will read later.

s h a two five six sum, space, slash bin slash l s, space, the greater than sign, space, report dot txt, and press Enter.

sha256sum /bin/ls > malware-report.txt && echo Saved.

The fingerprint itself never touched the screen, because it all went straight into the file. Let’s read it back. cat, space, report dot txt, and press Enter.

cat malware-report.txt

Timestamped in your own workflow and shareable with a team. That is the difference between poking at a file and documenting an analysis.

So that is the whole triage checklist, and none of it required running a single unknown file.

How malware analysis starts

• Identify the file type → fingerprint it twice
• Read its strings, then filter them
• Check the raw bytes and the internal header
• List its dependencies → glance at its actual code

Identify what the file actually is. Fingerprint it two different ways. Pull out its readable text, then filter that text for what matters. Check its raw bytes and its structured header. List what it depends on to run. Take one careful look at its real machine code. Then write every finding down.

A professional malware analyst runs exactly this sequence first, on every single file, before anything more advanced ever begins.

And the rule that outranks every command here.

Before you go

• Never run a file you have not verified — analyze it, don’t execute it
• Use a benign, known file to practice, exactly like we did today
• A real unknown sample belongs in an isolated sandbox, never your main machine
• New to the terminal? Start with our beginner Nmap course, linked below

Never run a file you have not verified first. Every command today only read this file — none of them executed it. If you ever handle a real unknown sample, it belongs in an isolated sandbox, never on your everyday computer.

If any of this moved too quickly, our beginner course starts from opening the terminal for the very first time, and it is linked below. Thanks for learning with The Exploit HQ, and I will see you in the next one.