Ransomware 1: Obnova dat aneb štěstí v neštěstí

Byl začátek jara. V práci jsem si zrovna užíval chvíli nižšího pracovního nasazení. Výkyvy v množství práce jsou u nás vskutku tak vysoké, až někdy podezřívám naše zákazníky, že se na nás domlouvají.

V půli týdne (středa) se nám ozval nový zákazník s neurčitým požadavkem o pomoc při obnově dat. Schůzka byla domluvena hned na poledne dalšího dne (čtvrtek). Na schůzce jsem se dozvěděl, že mají již od víkendu zašifrovaná data ze sdílených složek na Hyper-V serveru (infrastruktura: Hyper-V server se dvěma virtuály [DC a Terminál server s IS]) a nejsou si schopni pomoci vlastními silami.

V takovémto případě je nejlepší cestou provést obnovu ze záloh … ty však byly několik měsíců staré, a proto se hledala jiná cesta.

Nefunkční nebo nedostatečné zálohy jsou mnohem častějším prohřeškem, než byste si mysleli 😊

Jak útočníci napadli server

Případu jsem se chopil sám, jelikož mne profesně velice zajímal. Nejprve bylo nutné zjistit typ ransomware a způsob, jakým byl server prolomen. Všichni, co mě znají, vědí, že když se do něčeho pustím, nepřestanu, dokud není hotovo nebo nepadnu vysílením. Okolo deváté hodiny večerní jsem měl většinu informací a připravený report pro zákazníka. Kvůli závažnosti jsem domluvil schůzku hned na další ráno (pátek). Co jsem tedy zjistil:

• Metoda průniku: jednalo se o slovníkový útok na port-forwardované RDP Hyper-V serveru. Útok začal v 1:34 ráno a skončil po 38 minutách uhodnutím hesla k uživateli Administrátor. Ze zvědavosti jsem si udělal dump NTLM hashe a zkusil heslo prolomit sám (díky útoku přímo na hash se mi to podařilo za 2,5 minuty). Když jsem pak spatřil, jaké heslo měl uživatel administrátor nastavené, divil jsem se, že zákazníkův server nebyl napaden už dříve (heslo bylo „Password1“). Následně se útočníci 3x ručně přihlásili na server (z IP z Ruska, Ukrajiny a Lucemburska) přes RDP a nasadili na server Ransomware.
• Cryptolocker: na základě přípony zašifrovaných souborů a podoby ransom note (vyděračského dopisu) jsem bohužel špatně detekoval ransomware jako novou variantu Globe3, pro kterou v té době neexistoval nástroj pro dešifrování. E-mailová adresa pro komunikaci s útočníky byla již nefunkční a nebylo možné zaplatit výkupné.
• Další postřehy:
  • Útočníci kromě ransomware nasadili i malware pro těžbu bitcoinu (asi drobný přivýdělek k výkupnému).
  • Nepodařilo se mi najít známky toho, že by se pokoušeli dostat i na další zařízení/servery v síti. Měli pouze lokálního administrátora a ten neměl přístup dále. Mohli sice stopnout virtuál s DC a kompromitovat jej, ale neudělali to.
  • Lokálního uživatele administrátor, kterého útočníci zneužili, nikdo nevyužíval. Byl to jen zapomenutý účet od prvotní instalace nějakým původním IT dodavatelem. Od té doby se na účet všichni nejspíše báli sáhnout, aby něco nepřestalo fungovat. Na screenshotu je vidět, kdy mu bylo změněno heslo. Dle rozhovoru se zákazníkem je to v době dodávky serveru. Datum „naposledy přihlášen“ je datem, kdy došlo k průniku.

Štěstí v neštěstí

V pátek ráno jsem se zákazníkem probral vše, co jsem zjistil, jaké kroky musíme provést abychom odstranili nákazu a mohli serveru/síti opět důvěřovat. Vše jsme realizovali během pátku a části víkendu. V pondělí mohl zákazník opět pracovat. Zatím však stále neměl data ze sdílených složek, která byla zašifrovaná. Zde jsme chtěli počkat pár týdnů, než se objeví aktualizovaná verze programu na dešifrování Globe3.

Zákazník však měl štěstí v neštěstí:

• Díky „lajdáctví“ útočníků, nedošlo k zašifrování virtuálních serverů, které byly na Hyper-V hostu. A to z toho důvodu, že byly spuštěné a ransomware k nim nezískal od OS právo přístupu.
• S pomocí fóra BLEEPINGCOMPUTER se mi podařilo identifikovat správnou verzi ransomware a najít program pro dešifrování. Díky tomu jsme zvládli obnovit veškerá zašifrovaná data.

Jak se mohlo útoku předejít?

Pro vznik většiny incidentů je třeba řetězec událostí, které se musí stát, aby k incidentu došlo. U tohoto zákazníka by stačilo, kdyby alespoň jedno z níže uvedených opatření bylo dodrženo:

• Nepoužívat slovníková hesla: základní pravidlo. Nespoléhejte se ani na to, že česká slova útočníci používat nebudou. Často se setkávám, že správci vypínají vynucení komplexity a délky hesel v AD (podmínka nutná, nikoliv postačující). Toto je opravdu velice špatný krok. Sítě, které pak přebíráme obsahují např. hesla, co mají jen 3 znaky nebo jsou křestním jménem uživatele…
• Zakázat výchozí uživatele: všechny náhodné slovníkové útoky (tzn. útočník neví, na koho útočí) se snaží prolomit účty, se známými uživatelskými jmény jako jsou administrator, admin, remote, support. Ideální je tyto uživatelské účty vůbec nevytvářet nebo zakázat. U nás monitorovacím systémem kontrolujeme každý den, že tito uživatelé neexistují.
• Sledovat nepoužívané uživatelské účty: pokud se nějaký uživatelský účet nepoužívá, je zbytečné, aby byl aktivní. V síti často zůstávají aktivní uživatelské účty zaměstnanců, kteří ve firmě pár let nepracují, jenže takto mohou přistoupit k firemním datům. My jsme si tuto kontrolu doprogramovali do monitorovacího systému a sledujeme všechny účty, na které se nikdo 3 měsíce nepřihlásil.
• Omezit port-forwardy: pokud to není potřeba, tak port-forwardy nedělejte. Pokud je již děláte, tak je omezte např. jen na konkrétní IP adresy. (TIP: na routerech FortiGate lze omezit přístup na základě země, ze které je IP. Když například firma funguje jenom v ČR, tak povolíme přístup na terminálový server jen z ČR. Útoky chodí hlavně ze zahraničních IP).