Als je het geposte WMI-snippet volgt kun je het hele malwarepakket binnenhalen.
code:
1
| hxxp://107.179.67.243:8000/ma6.ps1 |
Dat is een PowerShell-script met twee regels. De eerste bevat de payload DLLs/executables/utility scripts (als de variabele '$fa'), de laatste is de (obfuscated) worm zelf.
De worm heb ik een heel eind
gedeobfuscate. Daar kun je ook uit afleiden hoe je de payloads/utilities uit
$fa extraheert
PowerShell:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| function reload ($a){
$b=""
$size=[Math]::Floor($a.Length/1000)
for($i=$size-1;$i -ge 0;$i--)
{
$b+=$a.Substring($i*1000,1000)
}
$b+=$a.Substring($size*1000)
return $b
}
$fa=reload $fa
$mimi=$fa.Substring(0,1131864)
$mon=$fa.Substring(1131866,357720)
$vcp=$fa.Substring(1489588,880172)
$vcr=$fa.Substring(2369762,1284312)
$funs=$fa.Substring(3654076,497360)
$sc=$fa.Substring(4151438) |
Je moet dus eerst
$fa opsplitsen in blocks van 1000 bytes, dan zet je de lijst blocks achterstevoren (het laatste block van 670 bytes behoudt zijn positie). Vervolgens kun je de payloads extracten:
- mimi is Mimikatz (DLL)
- mon is een cryptominer (XML/Monero)
- vcp en vcr is Microsoft's Visual C++ runtime
- funs bevat PowerShell-code voor oa. reflective DLL loading en EternalBlue
- sc is de shellcode voor EternalBlue
Met de malware zelf. Het is een worm, geschreven in PowerShell. De payload is een cryptominer (XMR).
De globale werking is als volgt:
- De 'mon' payload wordt gestart, indien deze nog niet draait. Dit is de cryptominer
- Mimikatz wordt dynamisch geladen (aka. 'reflective DLL loading' in allerlei PowerShell-frameworks). Nu heeft het alle credentials en hashes buitgemaakt.
- Voor alle netwerkadapters wordt het subnet afgescand naar Windowsmachines
- Met de buitgemaakte credentials probeert het zichzelf te verspreiden via WMI; lukt dat niet dan wordt er gescand op, en indien mogelijk gebruikgemaakt van MS17-010 aka. EternalBlue
Overigens kijken we of het mogelijk is om een specialistisch bedrijf in te schakelen.
Hoewel niemand je garanties kan bieden, wijst alles in dit topic op een XMR (Monero?) mining-campgne. Waarschijnlijk heb je nu al 99% van alle details en voldoende handvatten om het zelf op te ruimen.
Steek vervolgens het uitgespaarde geld in kennis/software om dit in het vervolg (proberen te) voorkomen.
Verder, gooi deze hosts in je firewall, samen met poort 14444; als je een hit krijgtheb je het blijkbaar niet goed opgeruimd:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| 107.179.67.243:8000
172.247.116.8:8000
118.184.48.95:8000
miner:
stratum+tcp://xmr-eu1.nanopool.org:14444
stratum+tcp://xmr-eu2.nanopool.org:14444
stratum+tcp://xmr-us-east1.nanopool.org:14444
stratum+tcp://xmr-us-west1.nanopool.org:14444
stratum+tcp://xmr-asia1.nanopool.org:14444
stratum+tcp://mine.moneropool.com:80
stratum+tcp://mine.xmrpool.net:80
Hier mist nog een subdomein of een poort:
fee.xmrig.com
.nicehash.com |
Maak ook een regel aan voor tcp 14444, die gebruikt de miner namelijk. En vraag je af waarom je machines uberhaupt het internet op die poorten mogen bereiken.
Deze snippets uit het malwarescript zijn ook interessant, al dan niet als indicator of compromise:
code:
1
2
3
4
5
| S`chTaSKs /delete /tn yastcat /f
if (teSt-pATH ($env:SystemRoot+('MRbtempMRby1.bat').rePlAce('MRb',[STRInG][cHar]92))){remoVE-iTem -Path ($env:SystemRoot+(('{0}temp{0}y1.bat')-f [chaR]92)) -Force}
poWercFG /CHANGE -standby-timeout-ac 0
poWERCFg /CHANGE -hibernate-timeout-ac 0
PoweRcFG -SetAcValueIndex 381b4222-f694-41f0-9685-ff5bb260df2e 4f971e89-eebd-4455-a8de-9e59040e7347 5ca83367-6e45-459f-a27b-476b1d01c936 000 |
Check dus ook de scheduled tasks, en zet de powersettings terug om wat bomen te sparen. Hij zet overigens ook UseLogonCredential=1 in het register (zie Microsoft.com)
De bron van de besmetting is trouwens wel gevonden en is gedicht.
Vertel eens, dat valt hier namelijk niet uit te herleiden..
Alle domain admin accounts zijn direct gewijzigd. Al vraag ik me af of er echt domain admin accounts zijn gebruikt.
Hij gebruikt alles wat 'ie vinden kan met Mimikatz. Dus die domain admins heeft 'ie allang als hij op je DCs zit - en dientengevolge je hele netwerk.
Het wijzigen van wachtwoorden is natuurlijk verplicht, maar wel een leuk filosofisch vraagstuk; de malware lijkt namelijk echt 'fire-and-forget'; de buitgemaakte credentials worden enkel gebruikt voor het verspreiden en niet doorgestuurd.
Zelf vermoed ik dat het system account is gebruikt, eerlijk is eerlijk, ik weet niet zeker of dat genoeg is om WMI classes aan te maken.
Ik zou dat als de wiedeweerga eens grondig uitzoeken als je wilt voorkomen dat je de volgende keer tegen dezelfde lamp loopt.
Gezien je het enkel 'vermoed': heb je de authenticatielogs op je domain controllers al bekeken? Ik ben geen Windowsbeheerder, maar volgens mij zou je daar moeten kunnen zien op welk punt in de tijd er voor het eerst een groot aantal authenticatiepogingen werd gedaan (de worm die zich begint te verspreiden) en met welk account dat gebeurde.
Als je systemen netjes up-to-date waren (MS17-010) dan waren er op de machine van de initiële infectie ofwel domain admin credentials aanwezig, of een buitgemaakt lokaal administrator account bleek ook te werken op andere machines.
:strip_icc():strip_exif()/u/154154/crop5faeab1bc08b6.jpeg?f=community)
:strip_exif()/u/24090/hekje.gif?f=community)
/u/28468/librarian2.png?f=community)
/u/38159/DirkJan.png?f=community)
. Wellicht ooit als test gebruikt, maar nooit dicht gezet. Intern wordt hier natuurlijk ook over gesproken.:strip_icc():strip_exif()/u/33065/crop59d32fcf38790_cropped.jpeg?f=community)
/u/35508/crop61e6aa7b579e2_cropped.png?f=community)