Skip to content
Digital Sentinel
All walkthroughs
LetsDefendEasyFull solution

LetsDefend: Kernel Exploit — working a forensic image with find and grep

A forensic image and a privilege escalation to reconstruct. Where I look first, how to use VirusTotal properly, and the two commands that do most of the work.

5 min read
Watch the video walkthrough

Anomalous traffic from a critical transaction processing server, a suspected breach, and a forensic image to go digging in.

I do a lot of these challenges — the goal is one a day at the weekend — so this one is about building the instincts that make the next one faster.

The commands that do most of the work

find . -type f -name "ps*"
cat [file name] | grep "al14m"
cat uname_-n.txt

That is genuinely most of it. Let me explain how I got to each one.

What file was downloaded to escalate privileges?

After extracting the challenge files, I went straight to /tmp.

Not because a hint said to. Because of instinct built from doing these repeatedly: if I wanted to drop something on a machine, the temporary folder is exactly where I would put it. World-writable, unremarkable, cleaned up on reboot.

And there it was: exploit.

When was it first submitted to VirusTotal?

If you haven't used VirusTotal, it analyses files, URLs and hashes against a large set of engines.

I uploaded the file itself rather than the hash — drag it in and it analyses automatically.

Then: Details → scroll down → History. First submission date is right there.

While you're in Details you also get the associated CVE, which is the answer to a later question. Two birds.

Finding the process ID

The question wants a five-digit PID. So: where do process IDs live?

If I didn't know, I'd Google "what file would contain process IDs". I do know ps lists running processes, so a file named after it is a fair bet.

find . -type f -name "ps*"

-type f means files. (For directories it'd be -type d.)

This is just a faster version of what I'd otherwise do by hand: open the challenge folder, open every subfolder, and look. The find gets me to live_response/process in one step.

I opened the .txt there, and it's a proper process table — username, PID, parent PID, time, and the command. I scrolled to the top to see the column layout first, because the answer format tells you what to look for.

Then two filters at once. Five digits, and an odd-looking username. A normal account name doesn't have digits jammed into it. al14m stood out.

cat [file name] | grep "al14m"

Scroll down that filtered output and there's exploit being executed — which confirms the file from question one and gives me the PID.

The parent process ID is in the same table, one column over: 1686.

The operating system and kernel version

Same question again: which file would hold this?

The uname command reports hostname, kernel and OS — so I went looking for a saved copy of its output.

find . -type f -name "*uname*"
cat uname_-n.txt

It's under live_response/system, and it gives you the OS and the kernel version — 6.5.0-27-generic.

Honest moment: I completely missed the kernel version the first time. It was on screen, in the file I already had open, and I skimmed straight past it because I was fixated on finding the OS. I had to go back for it.

What did we learn?

  1. Check /tmp first on a Linux box. It is where things get dropped.
  2. find . -type f -name "ps*" beats clicking through folders.
  3. .ps is PostScript. Not the same as ps.
  4. Re-analyse on VirusTotal, then read Details → History for first submission — and grab the CVE while you're there.
  5. A process table gives you username, PID and parent PID together.
  6. Odd usernames with digits in them are worth grepping for.
  7. uname output holds the OS and the kernel version in one place.

How I actually work

I Google everything. I keep notes as I go, and I'm building a file of every command I use with a short explanation of what it does.

I do wander into files I don't strictly need, just because I want to see what's in them. That curiosity is not wasted time — it is how you build the instinct that made /tmp the first place I looked.

And I'm perfectly comfortable reading the hint — after I've spent real time trying. That's how I learn.

One thing I'd push back on though: don't lean on AI to hand you the answers. You have to learn to think critically, and you don't get that from being told.

I hope this was as fun for you as it was for me!

TagsLetsDefendLinuxforensicsprivilege escalationblue team