Theory

Briefing: what malware analysis is

Welcome to Malware Analysis

A malware analyst answers one question: what does this suspicious program actually do? Answer it well and defenders can detect the threat, block it, and clean up after it.

How we study a sample, safely

We use static analysis: inspecting a file without ever running it. Tools like strings, file and xxd read the raw bytes and surface clues such as text, URLs, hostnames and error messages. Everything you need in this lab is sitting in the files as text, so you never have to execute anything.

Rule number one: never run malware you do not fully understand, and never on your own machine. The few professionals who do need to watch a sample execute only ever do it inside dedicated, disposable, network-isolated sandboxes built for exactly that. We will not run anything here.

Why we chase network indicators

Most modern malware "phones home" to a Command and Control (C2) server to receive orders or to exfiltrate stolen data. The address of that server, its FQDN (Fully Qualified Domain Name, like api.ipify.org), is one of the most useful Indicators of Compromise (IOCs) there is. Hand it to a firewall and the malware is cut off from its operator.

A quick glossary you will use:

FQDN: the complete hostname of a server, for example cdn.badguy.net.
Port 80 / HTTP: ordinary, unencrypted web traffic.
Port 443 / HTTPS: the same, wrapped in TLS encryption.
Ingress / Egress: data coming in to a system / data going out of it.

Your toolbox

strings <file> prints the readable text hidden inside a binary. Authors often leave hostnames and URLs in plain sight. Pipe it to grep to filter, for example strings /shared/malware/file1 | grep -i http.
curl <url> and wget <url> make web requests straight from the terminal.

The safe trick that makes this lab work

This environment has no real internet. So when you point curl or wget at a hostname you pulled out of the malware, DNS cannot resolve it and you get back something like:

curl: (6) Could not resolve host: cdn.badguy.net

That is not a failure. It is the proof that you found the real address the malware uses, and because nothing resolves, you never actually contact a live malicious server. You get the win and stay completely safe.

One warning: binaries sometimes split, pad or lightly scramble their text, so a hostname can show up broken across lines or mixed with junk. Look carefully and piece it back together.

Ready? Start by finding the plain HTTP server.

Fqdn 1

Four suspicious binaries were pulled from infected machines and dropped in /shared/malware/file1 through file4. Your first job: work out who they talk to.

A little theory
Most malware needs to reach a Command and Control (C2) server to get orders or ship out stolen data. That server is named by its FQDN (Fully Qualified Domain Name), for example bad.example.com. Plain, unencrypted web traffic travels over HTTP on port 80. The FQDN is a prime Indicator of Compromise (IOC): block it and the malware goes deaf.

Your task
Find the FQDN of the HTTP (port 80) server used by some of the four samples, then query it with curl.

How to find it
Pull the readable text out of each binary with strings (no need to run anything). Try strings /shared/malware/file1 | grep -i http on each file and look for a hostname.Why curl "fails" here, and why that is the point: this lab has no real internet, so when you curl the real hostname the name cannot resolve and you get Could not resolve host: .... That line confirms you found the right FQDN, and nothing ever connects to a live malicious server. You are analysing safely.

💡 Hint: Hostnames and URLs are stored as plain text inside the binary, so strings will reveal them. Keep in mind that some strings might be incorrectly displayed or parsed, so look carefully.

Fqdn 2

Sample file2 is sneakier: it talks over HTTPS, so its traffic is encrypted on the wire. The hostname it dials, though, still lives inside the binary.

A little theory
HTTPS is HTTP wrapped in TLS encryption, and it runs on port 443. Encryption hides the content of the traffic, not its destination: the server's FQDN is chosen by the malware author and is usually sitting in the file as a plain string. Watch out for a common trick: malware often first asks a legitimate service for the victim's public IP address before reporting home, so not every hostname you see is the villain.

Your task
Find the FQDN of the HTTPS (port 443) server used by /shared/malware/file2 and query it with curl. As before, Could not resolve host: ... confirms the catch.

How to find it

Surface candidate hostnames with strings /shared/malware/file2 | grep -i https.
Several candidates may appear. Reason about which one a sample would call for command and control, versus a harmless IP-lookup helper.

💡 Hint: The hostname is stored as plain text inside the binary, so strings will reveal it. Some strings might be incorrectly displayed or parsed, and some are decoys that are not related to what you are looking for.

Ingress

Samples file1 and file4 do not just check in: they push data to a specific route on their server.

A little theory
In networking, Ingress means data entering a system and Egress means data leaving it. From the malware server's point of view, the endpoint that receives the uploaded data is its ingress route, for example http://bad.example.com/upload. Mapping these routes tells a defender exactly where stolen data is being sent, which is gold for an incident report and for writing detection rules.

Your task
Find the full URL of the ingress endpoint used by file1 and file4 (include the scheme and FQDN, for example http://host/path) and request it with wget to get your flag.

How to find it
Combine what you already learned: recover the FQDN from the strings, then look for the path (the part after the hostname) that the sample appends when it sends data. Join them into one complete URL.

💡 Hint: A URL has three parts here: the scheme (http://), the FQDN (the host) and the path (the /route after it). You need all three joined together.

Theory

Debrief: turning samples into defence

Debrief: what you just did

You just ran the core loop of real malware network analysis:

Extracted host and URL indicators from unknown binaries, statically, by reading the strings inside them without ever running them.
Confirmed them safely, letting the DNS failure prove the target without ever contacting it.
Separated the real C2 destination from a harmless lookup, and mapped an ingress route used to exfiltrate data.

Every FQDN and URL you found is an IOC a defender can act on right away: block it at the firewall, hunt for it in proxy and DNS logs, and bake it into detection rules. That is how analysing a single sample can protect a whole network.

Where to go next

Dig deeper with file, xxd and a disassembler to understand how each sample builds its requests.
Learn to read packet captures with tcpdump and Wireshark, to study traffic that was recorded from a sample detonated inside a proper isolated sandbox.
Practise turning indicators into detection rules: YARA for files, Suricata for network traffic.