Writeup — Investigating Windows (TryHackMe)

OS: Windows Server 2016 Datacenter (build 14393)
Difficoltà: Easy
Data: 13 settembre 2026

Sommario

macchina Windows già compromessa, nessuna exploitation da fare: si entra in RDP con credenziali fornite dalla room (Administrator / letmein123!) e si lavora solo di analisi del sistema per rispondere a 16 domande investigative. non ci sono flag da raccogliere, ogni risposta è un parametro forense diverso (versione OS, account, orari di logon, task pianificate, chiavi di run, file droppati, regole firewall, log eventi, hosts file), e il senso della room è proprio quello: costringerti a toccare sedici posti diversi dove un attaccante lascia tracce, invece di darti una singola catena da seguire.

la macchina è un EC2 Windows Server 2016 con hostname EC2AMAZ-I8UH076. l'attaccante è entrato via webshell .jsp caricata nella root IIS, ha ottenuto privilegi elevati, ha aggiunto Guest e Jenny agli amministratori locali, ha dumpato le credenziali con mimikatz rinominato, ha piazzato tre meccanismi di persistenza indipendenti fra loro (chiave Run, scheduled task e script vbs), ha aperto due porte sul firewall e infine ha avvelenato il file hosts per neutralizzare antivirus e update e dirottare google.com sul proprio C2

strumenti e metodologie aggiuntive

durante la sessione è stato utilizzato un llm: per recupero dettagli su CVE, interpretazione di output grezzi, suggerimenti su vettori inesplorati in caso di blocco, spiegazione dettagliata di concetti tecnici e correzione di sintassi in comandi lunghi. l'esecuzione e le scelte operative erano mie. il writeup è stato scritto da me e successivamente ripulito con lo stesso strumento.

per la sintassi dei comandi di enumerazione locale e per il significato degli event ID ho fatto riferimento alla documentazione Microsoft:
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/net-localgroup
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4672

Premessa

Kali virtualizzata su Linux Mint, VPN TryHackMe con sudo openvpn --config ~/thm.ovpn e verifica con ip a show tun0.

primo intoppo prima ancora di iniziare: la connessione RDP dalla mia Kali non è mai andata.

xfreerdp /v:10.112.158.69 /u:Administrator /p:'letmein123!' /cert:ignore /dynamic-resolution +clipboard
[ERROR][com.freerdp.core] - [get_next_addrinfo]: ERRCONNECT_CONNECT_FAILED [0x00020006]
[ERROR][com.freerdp.core.transport] - ConnectLayer 10.112.158.69:3389 [15000ms] failed

tun0 era su e con IP assegnato (192.168.134.214/18), quindi la VPN non c'entrava. la macchina semplicemente non rispondeva sulla 3389 da fuori, e ho dovuto ripiegare sulla VM in-browser di TryHackMe per tutta la sessione. questo ha pesato molto più di quanto pensassi: niente copia incolla fra host e target,quindi ogni comando riscritto a mano e ogni output riletto a schermo o via screenshot. con query XPath lunghe è un problema serio, e su quella tastiera virtuale le parentesi graffe e l'asterisco non erano digitabili affatto, cosa che ha bloccato per un pezzo la parte sui log (dettaglio in Fase 8).

l'ambiente è quello di un sistema già compromesso e lasciato sporco: sul desktop non c'era quasi nulla se non Wireshark installato e un documento di testo con un dump di hash NTLM in formato pwdump, e in Network compariva tsclient.

Administrator:500:NO PASSWORD******:31D6CFE0D16AFA21B73C59D7E02A89C0:::
Guest:501:NO PASSWORD******:NO PASSWORD******:::
trinity:1002:NO PASSWORD******:A4A9436B46F7E948A2427335B6322C5C:::
HomeGroupUser$:1006:NO PASSWORD*********:E37B4DD2729A37EB5C581C8B9D70153C:::

quel file da solo dice già che qualcuno ha dumpato la SAM, ma gli utenti elencati (trinity, HomeGroupUser$) non esistono su questa macchina: è output portato da un altro host, non generato qui. l'ho annotato e messo da parte, e infatti la conferma del tool usato è arrivata dopo, da C:\TMP

Fase 1 — Inquadramento del sistema

systeminfo

Host Name: EC2AMAZ-I8UH076
OS Name: Microsoft Windows Server 2016 Datacenter
OS Version: 10.0.14393 N/A Build 14393
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Server
Original Install Date: 3/2/2019, 4:06:35 PM
System Boot Time: 9/13/2026, 12:25:12 PM
System Manufacturer: Amazon EC2
Domain: WORKGROUP
Time Zone: (UTC) Coordinated Universal Time

prima risposta presa: Windows Server 2016 Datacenter.

due cose interessanti oltre alla risposta. la data di installazione è 3/2/2019 alle 16:06, cioè lo stesso giorno in cui poi si scoprirà essere avvenuto il compromesso: la macchina è stata preparata e bucata nello stesso pomeriggio, il che spiega perché quasi tutti gli artefatti abbiano timestamp ravvicinati.
e il fuso è UTC, quindi tutti gli orari dei log sono confrontabili direttamente senza conversioni, cosa che semplifica la timeline.
il sistema è standalone in WORKGROUP, niente dominio: tutta l'enumerazione utenti resta locale.

Fase 2 — Account e privilegi

net user

Administrator DefaultAccount Guest
Jenny John ssm-user

sei account. Administrator, Guest e DefaultAccount sono built-in, ssm-user è l'account di AWS Systems Manager e su un EC2 è normale. restano John e Jenny come account creati.

net user John

User name John
Password last set 3/2/2019 5:48:19 PM
Last logon 3/2/2019 5:48:32 PM
Local Group Memberships *Users
Global Group memberships *None

net user Jenny

User name Jenny
Password last set 3/2/2019 4:52:25 PM
Last logon Never
Local Group Memberships *Administrators *Users
Global Group memberships *None

qui vengono fuori tre risposte insieme e un indizio grosso.
John ha fatto l'ultimo logon il 3/2/2019 alle 5:48:32 PM, ed è anche l'ultimo utente ad aver effettuato l'accesso al sistema in assoluto.
Jenny invece non si è mai loggata, ma è in Administrators. un account che non ha mai fatto login e che sta nel gruppo amministratori non è un account usato da una persona: è un account creato o promosso da qualcun altro. la password è stata impostata alle 16:52, quindi dentro la finestra del compromesso.

per elencare il gruppo il primo tentativo è fallito:

net localgroup Administrators
The specified local group does not exist.

sembrava assurdo visto che net localgroup senza argomenti elencava regolarmente Administrators fra gli alias. il motivo è banale ma me lo segno perché ci ho perso qualche minuto: ero in una console PowerShell, non in cmd, e il parsing dell'argomento si comportava diversamente. il cmdlet nativo risolve senza discussioni:

Get-LocalGroupMember -Group Administrators

Administrator
Guest
Jenny
ssm-user

Comment: admin have complete and unrestricted access to the computer/domain

Guest dentro Administrators è l'anomalia più pesante di tutta la fase. l'account Guest è disabilitato e privo di privilegi per design, promuoverlo ad amministratore non ha nessuna ragione legittima ed è una tecnica di persistenza classica proprio perché nessuno pensa a controllarlo.
escludendo Administrator (esplicitamente escluso dalla domanda) e ssm-user (account di servizio AWS legittimo, presente dalla creazione dell'istanza), gli account con privilegi amministrativi aggiunti sono Guest e Jenny.

Fase 3 — Task pianificate

le task pianificate sono uno dei posti più comuni dove piazzare persistenza. schtasks è il comando nativo per interrogarle, e con /fo table /nh si ottiene una lista compatta. il problema è che una Windows Server ne ha centinaia di legittime, tutte sotto \Microsoft\Windows\, quindi ho filtrato via quelle:

schtasks /query /fo table /nh | findstr /v Microsoft

Folder: \
Amazon Ec2 Launch - Instance Initializat N/A Disabled
Amazon Ec2 Launch - Userdata Execution N/A Ready
BADR N/A Ready
BadrClient N/A Ready
check logged in 9/13/2026 4:59:43 PM Ready
Clean file system 9/13/2026 4:55:17 PM Ready
falshupdate22 9/13/2026 12:45:04 PM Ready
npcapwatchdog N/A Ready
update windows N/A Ready

nella cartella root ci sono nove task e almeno cinque hanno nomi sospetti. le due Amazon Ec2 Launch sono legittime dell'AMI, npcapwatchdog è di Npcap ed è coerente col Wireshark installato.
restano BADR, BadrClient, check logged in, Clean file system, falshupdate22, update windows. falshupdate22 è un typo evidente di flash update, un classico camuffamento, e update windows è invertito rispetto al vero nome Microsoft.

la domanda ne chiede una sola, quindi ho controllato quella con nome più innocuo e con next run time attivo:

schtasks /query /tn "Clean file system" /fo list /v

HostName: EC2AMAZ-I8UH076
TaskName: \Clean file system
Next Run Time: 9/13/2026 4:55:17 PM
Status: Ready
Logon Mode: Interactive only
Last Run Time: 9/13/2026 12:28:29 PM
Author: EC2AMAZ-I8UH076\Administrator
Task To Run: C:\TMP\nc.ps1 -l 1348
Comment: A task to clean old files of the system
Scheduled Task State: Enabled
Run As User: Administrator
Schedule Type: Daily
Start Time: 4:55:17 PM
Start Date: 3/2/2019
Days: Every 1 day(s)

tre risposte in un colpo solo.
il nome è quello che sembra pulizia di sistema, la descrizione pure ("A task to clean old files of the system"), ma il comando eseguito è C:\TMP\nc.ps1 -l 1348, cioè netcat in versione PowerShell messo in listening sulla porta 1348. gira ogni giorno, come Administrator, a partire dal 3/2/2019.
un bind shell schedulata quotidianamente: se l'attaccante perde l'accesso, gli basta ricollegarsi sulla 1348 il giorno dopo.
il percorso C:\TMP è la cosa che mi ha interessato di più, perché non è una cartella standard di Windows e da qui in poi è diventata il centro dell'indagine.

le altre task sospette non le ho aperte una per una per questione di tempo, ma i nomi restano annotati come persistenza multipla: BADR e BadrClient si ricollegano allo start-badr.vbs trovato dopo nelle chiavi di run, quindi sono lo stesso impianto visto da due punti diversi.

Fase 4 — Chiavi di run

la domanda sull'IP contattato all'avvio indirizza direttamente alle autorun. la chiave macchina è quella:

reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"

UpdateSvc REG_SZ C:\TMP\p.exe -s \10.34.2.3 'net user' > C:\TMP\o2.txt
BadrClient REG_SZ wscript.exe "C:\badr\start-badr.vbs" //B //Nologo

l'IP contattato all'avvio è 10.34.2.3

la voce si chiama UpdateSvc per sembrare un servizio di aggiornamento ma esegue p.exe con la sintassi tipica di PsExec (-s per girare come SYSTEM, \host come target), lancia net user sulla macchina remota e redirige l'output in C:\TMP\o2.txt. non è quindi una connessione verso un C2 esterno, è movimento laterale verso un host interno con raccolta di utenti: 10.34.2.3 è nella rete privata.
questo è un punto che vale la pena non appiattire, perché più avanti c'è una domanda sul C2 esterno e la risposta è un IP completamente diverso. i due indirizzi hanno due funzioni distinte e confonderli è l'errore facile della room.

la seconda voce è la controparte della task BadrClient vista prima: uno script vbs eseguito con wscript in modalità silenziosa (//B //Nologo, nessuna finestra, nessun banner). persistenza numero due.

Fase 5 — Il toolkit in C:\TMP

dir C:\TMP

Mode LastWriteTime Length Name
-a---- 3/2/2019 4:37 PM 9673 d.txt
-a---- 3/2/2019 4:37 PM 3389 mim-out.txt
-a---- 3/2/2019 4:37 PM 663552 mim.exe
-a---- 3/2/2019 4:45 PM 176148 moutput.tmp
-a---- 3/2/2019 4:37 PM 36864 nbtscan.exe
-a---- 3/2/2019 4:37 PM 37640 nc.ps1
-a---- 3/2/2019 4:37 PM 381816 p.exe
-a---- 3/2/2019 4:46 PM 0 scan1.tmp
-a---- 3/2/2019 4:46 PM 0 scan2.tmp
-a---- 3/2/2019 4:46 PM 0 scan3.tmp
-a---- 3/2/2019 4:45 PM 7022 schtasks-backdoor.ps1
-a---- 3/2/2019 4:45 PM 40464394 somethingwindows.dmp
-a---- 3/2/2019 4:46 PM 11950 sys.dmp
-a---- 3/2/2019 4:37 PM 19998 wMIBackdoor.ps1
-a---- 3/2/2019 4:37 PM 843776 xCmd.exe

questa è la cartella di lavoro dell'attaccante e da sola ricostruisce mezzo attacco.

mim.exe con accanto mim-out.txt è mimikatz rinominato: la risposta alla domanda sul tool usato per prendere le password è mimikatz. il nome accorciato serve a non farsi intercettare da controlli banali sul nome file, ma l'output affiancato non lascia dubbi ed è coerente col dump di hash trovato sul desktop in premessa.
p.exe è PsExec, quello richiamato dalla chiave Run.
nc.ps1 è il netcat PowerShell della scheduled task.
nbtscan.exe e i tre scan*.tmp vuoti sono ricognizione di rete NetBIOS, i file a zero byte dicono che le scansioni sono state lanciate ma non hanno prodotto risultati.
xCmd.exe è un altro tool di esecuzione remota, alternativa a PsExec.
wMIBackdoor.ps1 e schtasks-backdoor.ps1 sono le altre due vie di persistenza, WMI event subscription e task pianificate.
somethingwindows.dmp da 40 MB e sys.dmp sono dump di memoria, materiale da cui estrarre credenziali offline.
d.txt l'ho aperto pensando contenesse configurazione o indirizzi, e invece è un listato ricorsivo del filesystem (partiva da C:\MSOCache con tutti i pacchetti Office e continuava per pagine). è ricognizione del disco, non contiene nulla di utile alle domande, e lo annoto proprio come esclusione: mi ha fatto perdere tempo perché il nome breve faceva pensare a un file di configurazione.

tutti i timestamp stanno fra le 16:37 e le 16:46 del 3/2/2019, quindi la data del compromesso è 03/02/2019 e la finestra operativa è di una decina di minuti scarsi. questo è il riferimento temporale su cui ho poi cercato negli event log.

Fase 6 — Webshell e vettore di ingresso

la domanda parla di shell caricata via sito, quindi root IIS di default:

dir C:\inetpub\wwwroot

b.jsp
shell.gif
tests.jsp

estensione: .jsp

due file jsp in una wwwroot di IIS sono già anomali di per sé, e shell.gif accanto è il classico file caricato con estensione immagine per superare un filtro sull'upload e poi rinominato o interpretato altrimenti.
il webserver in realtà non risultava attivo sulla macchina al momento dell'analisi, la room lo simula lasciando solo gli artefatti su disco. l'ho verificato perché ho provato a cercare riferimenti a URL dentro tests.jsp con findstr /i "http" e non è uscito niente: i file sono presenti ma svuotati di contenuto utile.
questa è comunque la porta d'ingresso: upload non filtrato su applicazione Java esposta, poi esecuzione di comandi dalla shell.

Fase 7 — Firewall e hosts file

netsh advfirewall firewall show rule name=all | findstr /i "Rule Name LocalPort"

l'output è lunghissimo perché elenca tutte le regole predefinite di Windows, ma fra Network Discovery e le regole delle app Microsoft ne spuntano due che non appartengono a nessun set standard:

Rule Name: Allow outside connections for development
LocalPort: 1337
Rule Name: Service Firewall
LocalPort: 8888

entrambe aggiunte a mano. il nome della prima è quasi una firma, "allow outside connections for development" è la scusa che si scrive per giustificare un buco. la seconda si maschera da regola di servizio generica.
la risposta all'ultima porta aperta è 1337. inizialmente avevo puntato su 8888 ragionando sull'ordine in cui comparivano nell'elenco, ma l'ordine di output di netsh non riflette l'ordine di creazione, e la room considera l'ultima nella catena delle inbound aggiunte quella sulla 1337. lo tengo come nota metodologica: per determinare davvero l'ordine cronologico di creazione delle regole servirebbe il registro o gli event log del firewall, netsh da solo non lo dice.

poi il file hosts, che è dove si controlla un eventuale avvelenamento DNS locale:

type C:\Windows\System32\drivers\etc\hosts

127.0.0.1 localhost
::1 localhost
0.2.2.2 update.microsoft.com
127.0.0.1 www.virustotal.com
27.0.0.1 www.www.com
27.0.0.1 dci.sophosupd.com
0.2.2.2 update.microsoft.com
127.0.0.1 www.virustotal.com
27.0.0.1 www.www.com
27.0.0.1 dci.sophosupd.com
76.32.97.132 google.com
76.32.97.132 www.google.com

due risposte qui, e vanno separate bene perché la tentazione è di dare la stessa per entrambe.

le voci verso 127.0.0.1, 0.2.2.2 e 27.0.0.1 sono sabotaggio difensivo, non redirezione: puntano a indirizzi locali o inesistenti per impedire alla macchina di raggiungere Windows Update, VirusTotal e i server di aggiornamento Sophos. servono a tenere il sistema cieco e non aggiornato, e le escludo dalla domanda sul sito targhettizzato proprio perché non dirottano da nessuna parte, bloccano e basta.
l'unica voce che punta a un IP pubblico reale è google.com (e www.google.com) verso 76.32.97.132. quello è l'unico dirottamento vero, quindi il sito targhettizzato dal DNS poisoning è google.com e l'IP del server di command and control esterno è 76.32.97.132.

prima di arrivarci avevo cercato il C2 nel posto sbagliato: dentro d.txt, dentro i jsp e perfino cercando un eventuale pcap sul disco (con Wireshark installato sembrava sensato). ls C:\Users -r -fi .pcap non ha restituito niente. il C2 era nel file più banale del sistema

Fase 8 — Event log e la caccia al 4672

l'ultima domanda chiede l'orario in cui Windows ha assegnato per la prima volta privilegi speciali a un nuovo logon durante il compromesso. l'event ID di riferimento è 4672 (Special privileges assigned to new logon), che viene generato quando un account riceve un token con privilegi sensibili tipo SeDebugPrivilege o SeTakeOwnershipPrivilege.

questa singola domanda mi ha preso più tempo di tutte le altre quindici messe insieme, quindi la scrivo per intero perché il valore è nel percorso, non nella risposta.

primo tentativo, il modo standard:

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4672} -MaxEvents 5

No events found that match criteria.

il problema qui non era la query ma la tastiera: sulla VM in-browser le parentesi graffe non erano digitabili, quindi la hashtable non è mai arrivata a destinazione integra. me ne sono accorto tardi.

secondo tentativo con Get-EventLog:

Get-EventLog Security -InstanceId 4672 -Newest 5
Get-EventLog : No matches found

terzo con XPath dentro Get-WinEvent:

Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4672]]" -Oldest -MaxEvents 1
No events found

quarto con pipeline e filtro lato client:

Get-WinEvent -LogName Security -Oldest | ? Id -eq 4672 | select -First 1 TimeCreated

questo è rimasto appeso all'infinito: il Security log aveva 99.196 eventi e filtrare lato client significa scorrerli tutti. l'ho interrotto.

quello che ha funzionato è wevtutil, che filtra a livello di log e non enumera niente:

wevtutil qe Security /q:"*[System[(EventID=4672)]]" /c:1 /rd:false /f:text

Event[0]:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 2026-09-13T13:16:01.601
Event ID: 4672
Task: Special Logon
Special privileges assigned to new logon.
Subject:
Security ID: S-1-5-21-3685962493-259677494-3116396707-500
Account Name: Administrator
Privileges: SeSecurityPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeTakeOwnershipPrivilege
SeDebugPrivilege
...

funziona, ma la data è 2026: sono i miei stessi accessi RDP di oggi. su quell'istanza il log era ruotato e i 4672 del 2019 erano stati sovrascritti dagli eventi generati durante le tre ore di sessione, in Event Viewer ne restavano cinque in tutto e tutti odierni.

ho riavviato la lab machine per ripartire da uno snapshot fresco, e lì gli eventi storici c'erano:

Date: 2019-02-13T08:14:30.347
Event ID: 4672
Account Name: SYSTEM

ma il primo in assoluto è di febbraio e appartiene a SYSTEM, quindi non è quello del compromesso. ho ristretto alla giornata:

wevtutil qe Security /q:"*[System[(EventID=4672) and TimeCreated[@SystemTime>='2019-03-02T00:00:00' and @SystemTime<='2019-03-03T00:00:00']]]" /c:1 /f:text

Date: 2019-03-02T16:02:58.125
Account Name: SYSTEM

ancora SYSTEM. ho provato a escludere il SID S-1-5-18 e mi è uscito NETWORK SERVICE, poi filtrando su SubjectUserName='Administrator' sono arrivato a 16:09:34, che è già dentro la finestra giusta ma non è il primo.

la risposta corretta è saltata fuori rilanciando la query base su una istanza appena avviata, senza aver ancora dato conferma alla finestra di dialogo iniziale che compare al primo login: in quelle condizioni wevtutil restituisce molti più 4672 storici rispetto a quelli visibili dalla GUI dopo (che ne mostrava solo cinque, tutti recenti). presumibilmente quel passaggio iniziale innesca attività che riempie il log e spinge fuori i record vecchi.

Date: 2019-03-02T16:04:49

risposta: 03/02/2019 4:04:49 PM.

due lezioni concrete da qui. la prima è che su un log da centomila eventi la differenza fra filtrare lato server (wevtutil, XPath dentro la query) e lato client (pipeline con Where-Object) non è di stile, è la differenza fra un secondo e mai. la seconda è che su una macchina forense il tempo di uptime è esso stesso un fattore distruttivo: più la tieni accesa, più i log storici che devi analizzare vengono sovrascritti dalla tua stessa attività di analisi. su un caso reale la prima cosa sarebbe esportare il Security.evtx, non interrogarlo dal vivo.

Catena completa

timeline ricostruita dell'attacco, tutti gli orari in UTC del 2 marzo 2019.

16:04:49 primo assegnamento di privilegi speciali a un nuovo logon (4672), l'attaccante ottiene un token con privilegi elevati dopo essere entrato tramite la webshell .jsp caricata in C:\inetpub\wwwroot
16:37 drop del toolkit in C:\TMP: mim.exe (mimikatz), p.exe (PsExec), xCmd.exe, nc.ps1, nbtscan.exe, wMIBackdoor.ps1
16:37 esecuzione di mimikatz, output in mim-out.txt, dump credenziali del sistema
16:45 creazione dei dump di memoria somethingwindows.dmp e sys.dmp e di schtasks-backdoor.ps1
16:46 ricognizione di rete con nbtscan, scan1/2/3.tmp restituiscono vuoti
16:47 prime scheduled task malevole registrate
16:52 password impostata per l'account Jenny, che viene aggiunta ad Administrators insieme a Guest senza aver mai fatto login
16:55 task "Clean file system" schedulata giornaliera, esegue C:\TMP\nc.ps1 -l 1348, bind shell permanente
-- chiave Run HKLM UpdateSvc: p.exe verso 10.34.2.3 per movimento laterale interno, output in o2.txt
-- chiave Run HKLM BadrClient: wscript su C:\badr\start-badr.vbs in modalità silenziosa
-- regole firewall inbound aggiunte a mano, 8888 e infine 1337
-- hosts file avvelenato: update.microsoft.com, virustotal e sophosupd neutralizzati verso indirizzi locali, google.com dirottato sul C2 esterno 76.32.97.132
17:48:32 ultimo logon di John, ultimo accesso utente registrato sul sistema

in sintesi: ingresso via upload di webshell su IIS, escalation a privilegi amministrativi, furto credenziali con mimikatz, persistenza ridondante su tre fronti (run key, scheduled task, WMI/vbs), apertura di porte in ingresso e infine accecamento delle difese più dirottamento DNS locale verso il proprio server di comando.

Risposte della room

1. Windows Server 2016 Datacenter
2. Administrator
3. 03/02/2019 5:48:32 PM
4. 10.34.2.3
5. Guest, Jenny
6. Clean file system
7. C:\TMP\nc.ps1
8. 1348
9. Never
10. 03/02/2019
11. 03/02/2019 4:04:49 PM
12. mimikatz
13. 76.32.97.132
14. .jsp
15. 1337
16. google.com

Lezioni apprese

la parte tecnica di questa room è tutta enumerazione nativa e nessun passaggio è difficile in sé. quello che rende sedici domande faticose è il contesto: senza copia incolla, con una tastiera che non digita metà dei caratteri speciali e con un log da centomila eventi, la differenza la fa scegliere lo strumento giusto al primo colpo invece di insistere su quello familiare. ho perso quaranta minuti su Get-WinEvent quando wevtutil rispondeva in un secondo.

l'altra cosa che mi porto dietro è metodologica e vale al di là della room. su un sistema compromesso i due IP trovati (10.34.2.3 e 76.32.97.132) hanno ruoli opposti, e la sola presenza di un indirizzo non dice niente: uno è movimento laterale interno via PsExec, l'altro è il C2 esterno nel file hosts. stessa cosa per le voci del hosts file, dove sabotare gli aggiornamenti e dirottare un dominio sembrano la stessa azione ma rispondono a due domande diverse. distinguere serve più che trovare

Tool utilizzati

RDP (VM in-browser TryHackMe), systeminfo, net user, net localgroup, Get-LocalGroupMember, schtasks, reg query, dir, findstr, type, netsh advfirewall, Get-WinEvent, Get-EventLog, wevtutil, Event Viewer