phobos ransomware

 ( peta | 2019. február 4., hétfő - 10:13 )

Üdv Fórumtársak!

Valahogy sikerült belefutni a címben említett zsarolóvírusba. A gépet egyedül én használom arra, hogy egy dvr-ről fájlokat töltsek le, a dvr-hez tartozó programon kívül még egy chrome volt telepítve rá, de a kérdéses időben nem használta senki a gépet.

A gépen található fájlokon túl egy hálózati meghajtót is titkosított, de azt az előző napi backupból vissza is raktam, semmilyen fontos adat nem veszett el, nem is akarok szórakozni az adatok visszanyerésével, csak kíváncsi volnék hogy jutott a gépre.

A gép rdp-n volt elérhető nem default porton jelszóval védve.

A .phobos fájlok létrehozási dátuma, és a samba audit logja is mutatja, hogy 2019.02.02 13:05 körül lett aktív a vírus.

Ezt megelőző bind log:

02-Feb-2019 08:28:12.053 client 192.168.0.15#53663 (update.googleapis.com): query: update.googleapis.com IN A + (192.168.0.1)
02-Feb-2019 08:39:20.537 client 192.168.0.15#50948 (teredo.ipv6.microsoft.com): query: teredo.ipv6.microsoft.com IN A + (192.168.0.1)
02-Feb-2019 12:29:40.661 client 192.168.0.15#61459 (teredo.ipv6.microsoft.com): query: teredo.ipv6.microsoft.com IN A + (192.168.0.1)
02-Feb-2019 12:33:24.452 client 192.168.0.15#49883 (go.microsoft.com): query: go.microsoft.com IN A + (192.168.0.1)
02-Feb-2019 12:33:24.526 client 192.168.0.15#62610 (www.bing.com): query: www.bing.com IN A + (192.168.0.1)
02-Feb-2019 12:33:31.290 client 192.168.0.15#57811 (ocsp.msocsp.com): query: ocsp.msocsp.com IN A + (192.168.0.1)
02-Feb-2019 12:33:32.549 client 192.168.0.15#61638 (dotnetdownloadservice.azurewebsites.net): query: dotnetdownloadservice.azurewebsites.net IN A + (192.168.0.1)
02-Feb-2019 12:33:54.378 client 192.168.0.15#61400 (www.google.com): query: www.google.com IN A + (192.168.0.1)
02-Feb-2019 12:33:57.518 client 192.168.0.15#49245 (clientservices.googleapis.com): query: clientservices.googleapis.com IN A + (192.168.0.1)
02-Feb-2019 12:33:57.522 client 192.168.0.15#52841 (accounts.google.com): query: accounts.google.com IN A + (192.168.0.1)
02-Feb-2019 12:33:59.026 client 192.168.0.15#50465 (ssl.gstatic.com): query: ssl.gstatic.com IN A + (192.168.0.1)
02-Feb-2019 12:34:08.774 client 192.168.0.15#52965 (ocsp.digicert.com): query: ocsp.digicert.com IN A + (192.168.0.1)
02-Feb-2019 12:34:10.026 client 192.168.0.15#57282 (www.gstatic.com): query: www.gstatic.com IN A + (192.168.0.1)
02-Feb-2019 12:34:28.586 client 192.168.0.15#52239 (consent.google.com): query: consent.google.com IN A + (192.168.0.1)
02-Feb-2019 12:34:30.360 client 192.168.0.15#56242 (id.google.com): query: id.google.com IN A + (192.168.0.1)
02-Feb-2019 12:34:32.535 client 192.168.0.15#51079 (adservice.google.com): query: adservice.google.com IN A + (192.168.0.1)
02-Feb-2019 12:34:33.346 client 192.168.0.15#57327 (apis.google.com): query: apis.google.com IN A + (192.168.0.1)
02-Feb-2019 12:34:36.679 client 192.168.0.15#50762 (www.microsoft.com): query: www.microsoft.com IN A + (192.168.0.1)
02-Feb-2019 12:34:39.122 client 192.168.0.15#53300 (c.s-microsoft.com): query: c.s-microsoft.com IN A + (192.168.0.1)
02-Feb-2019 12:34:39.124 client 192.168.0.15#60706 (ajax.aspnetcdn.com): query: ajax.aspnetcdn.com IN A + (192.168.0.1)
02-Feb-2019 12:34:39.124 client 192.168.0.15#56627 (assets.onestore.ms): query: assets.onestore.ms IN A + (192.168.0.1)
02-Feb-2019 12:34:39.140 client 192.168.0.15#50840 (statics-uhf-eus.akamaized.net): query: statics-uhf-eus.akamaized.net IN A + (192.168.0.1)
02-Feb-2019 12:34:39.142 client 192.168.0.15#55649 (az725175.vo.msecnd.net): query: az725175.vo.msecnd.net IN A + (192.168.0.1)
02-Feb-2019 12:34:39.143 client 192.168.0.15#52823 (mem.gfx.ms): query: mem.gfx.ms IN A + (192.168.0.1)
02-Feb-2019 12:34:39.423 client 192.168.0.15#55887 (img-prod-cms-rt-microsoft-com.akamaized.net): query: img-prod-cms-rt-microsoft-com.akamaized.net IN A + (192.168.0.1)
02-Feb-2019 12:34:42.090 client 192.168.0.15#52917 (web.vortex.data.microsoft.com): query: web.vortex.data.microsoft.com IN A + (192.168.0.1)
02-Feb-2019 12:34:44.177 client 192.168.0.15#50214 (uhf.microsoft.com): query: uhf.microsoft.com IN A + (192.168.0.1)
02-Feb-2019 12:34:53.541 client 192.168.0.15#57922 (login.live.com): query: login.live.com IN A + (192.168.0.1)
02-Feb-2019 12:34:55.377 client 192.168.0.15#50023 (auth.gfx.ms): query: auth.gfx.ms IN A + (192.168.0.1)
02-Feb-2019 12:35:10.229 client 192.168.0.15#54279 (download.microsoft.com): query: download.microsoft.com IN A + (192.168.0.1)
02-Feb-2019 12:35:13.392 client 192.168.0.15#57913 (login.microsoftonline.com): query: login.microsoftonline.com IN A + (192.168.0.1)
02-Feb-2019 12:35:22.616 client 192.168.0.15#57643 (clients1.google.com): query: clients1.google.com IN A + (192.168.0.1)
02-Feb-2019 12:35:49.124 client 192.168.0.15#57363 (clients2.google.com): query: clients2.google.com IN A + (192.168.0.1)
02-Feb-2019 12:38:09.815 client 192.168.0.15#51145 (safebrowsing.googleapis.com): query: safebrowsing.googleapis.com IN A + (192.168.0.1)
02-Feb-2019 12:40:04.597 client 192.168.0.15#62054 (update.googleapis.com): query: update.googleapis.com IN A + (192.168.0.1)
02-Feb-2019 12:40:44.070 client 192.168.0.15#61537 (redirector.gvt1.com): query: redirector.gvt1.com IN A + (192.168.0.1)
02-Feb-2019 12:40:44.560 client 192.168.0.15#62297 (r3---sn-c0q7lns7.gvt1.com): query: r3---sn-c0q7lns7.gvt1.com IN A + (192.168.0.1)
02-Feb-2019 12:43:26.716 client 192.168.0.15#52030 (storage.googleapis.com): query: storage.googleapis.com IN A + (192.168.0.1)
02-Feb-2019 12:44:35.119 client 192.168.0.15#58236 (clients4.google.com): query: clients4.google.com IN A + (192.168.0.1)
02-Feb-2019 12:44:43.811 client 192.168.0.15#54891 (teredo.ipv6.microsoft.com): query: teredo.ipv6.microsoft.com IN A + (192.168.0.1)
02-Feb-2019 12:52:09.706 client 192.168.0.15#50914 (web.vortex.data.microsoft.com): query: web.vortex.data.microsoft.com IN A + (192.168.0.1)
02-Feb-2019 12:52:37.797 client 192.168.0.15#56494 (crl.microsoft.com): query: crl.microsoft.com IN A + (192.168.0.1)
02-Feb-2019 12:53:19.795 client 192.168.0.15#54268 (sv.symcd.com): query: sv.symcd.com IN A + (192.168.0.1)
02-Feb-2019 12:53:25.585 client 192.168.0.15#61779 (crl.pki.goog): query: crl.pki.goog IN A + (192.168.0.1)
02-Feb-2019 12:53:31.662 client 192.168.0.15#53897 (ocsp.pki.goog): query: ocsp.pki.goog IN A + (192.168.0.1)

mshta.exe a neve a programnak.

A windows naplóban nem látok szokatlan dolgot. Ja igen, a windows egy nem frissített Windows 7 build 7601. Szerintetek?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

windows egy nem frissített Windows 7 build 7601
A gép rdp-n volt elérhető

Ennyi.
--
zrubi.hu

Rendben, ezt elfogadom. De hogyan? Ha rdp-n jött az áldás, akkor azt miért nem látom a windows naplóban? Vagy lehet látom, csak elvés a sok sorban?

A zsarolo virusok egyik tipikus tamadasi lehetosege pont az RDP... az kiengedni, default porton... nem velemenyezem, de ne csodalkozz... :/

Valoszinuleg hagytak egy email cimet es egy megalmodott osszeget, jo esellyel Bitcoinban

A valoszinusitheto lehetosegeid:
- Meg lehet kezdeni az alkudozast,
- visszaallitas backupbol,
- reinstall

Nem default portot írt, de szerintem a port átírás az maximum a nice to have kategória. Egyébként mi ez a nagy konszenzus ezzel az RDPvel kapcsolatban? Insecure a protokoll, vagy ami csinálja a windowsban a protokollt, az szokott fos lenni?

Ja, és utolsó lépésként levenni az Internet felől a direkt csatlakozási lehetőségeket és betenni elé egy pl. OpenVPN -t

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Pontosan erre lennék én is kíváncsi.

Egyébként mi ez a nagy konszenzus ezzel az RDPvel kapcsolatban? Insecure a protokoll, vagy ami csinálja a windowsban a protokollt, az szokott fos lenni?

Több probléma is van:
- bármilyen lokálisan futó process-t direktbe kitenni az internetre, magával vonja azt, hogy ha abban az egy programban hiba van, akkor egyből hozzáférést kap a támadó a gépre.
Ezt a rizikót természetesen lehet csökkenteni többféle megoldással, pl sandbox, unpriviliged mode, stb.
Azonban az RDP esetében egyik sem játszik, hiszen eleve arra való hogy beengedjen... Így nagyon könnyen local user acces-t lehet tőle kapni, rosszabb esetben egyből admin jogokkal.
(eddig mondjuk egy ssh is pont ugyan akkora rizikót jelent.)

- az MS reputációja biztonság téren eléggé szánalmas, így lehet bármilyen secure maga a protokol, ha az implementációt az MS készítette. Ezesetben mindkettő MS találmány :D

- az RDP mint protokol kezdetben szinte semmilyen biztonsági megoldást nem kínált, ami később (TLS) javult persze, de a default megoldás továbbra sem nevezhető biztonságosnak.

- az MS adminisztrátorok/felhasználók (sokszor sajnos nincs különbség) "megszokásai" (pl jelszó policy) szintén egyértelműen lefelé húzzák a megoldás biztonsági szintjét.

levenni az Internet felől a direkt csatlakozási lehetőségeket és betenni elé egy pl. OpenVPN
Igen, ez a fent felsorolt problémák több pontján is segít:
- külön process, külön protokol
(így az egyik hibája nem azonnali fail)
- nem MS implementáció :D
- security by design.

még jobb, ha külön gépen van VPN.

De ha mindenképp "RDP only" megoldás kell, akkor az elé is lehet tenni RDP concentrátort/proxy-t, ami nagyban növeli a megoldás biztonságát. (Persze, így marad az MS only implementáció)

Disclaimer: I am not speaking on behalf of my employer, this is my personal opinion

--
zrubi.hu

Az RDP-hez kell egy 2FA oszt csokolom.

Mindenfele hekkeles nelkul 2 perc alatt beallithato.

Nyilván ez jó irány, és néhány problémán segít is, de:

- a klienseket is érinti. Akár pénzügyi, akár hozzáértési, akár csak "kényelmetlenségi" szinten.
- implementációs hibák ellen nem véd
- protokollbeli hibák ellen sem véd.

--
zrubi.hu

Mint írtam nem default porton lógott a gép, és még csak nem is admin:admin user:pass párossal. Csodálkozni végkép nem csodálkodom.

Azt is írtam, hogy fontos adat nem volt a gépen, eszem ágában sincs alkudozni, a gép törölve lesz, csak technikailag lennék kíváncsi hogyan történt ez.

Bocsánat, jogos! Még a reggeli kávé előtt olvastam... valahogy átsiklottam a NEM szón, elnézést.

Semmi gond.

Internetről elérhető volt, akkor szépen ráengedtek néhány RDP sebezhetőséget, az egyik betalált és kész. Az hogy nem default porton volt az RDP az senkit nem érdekel manapság :) Portscan alapján megtalálnak.
A zsarolóvírusok közül olyan is volt, aki a sima user-ből csinált administratort és mindent titkosított, mert kihasznált egy nem ismert Windows sebezhetőséget!

A gond az, hogy napi szinten törnek fel valamit és kerülnek ki jelszavak a netre. Ha a világon más is kitalálta ugyanazt a jelszót, amit Te, és őt törik fel, a jelszó akkor is kikerül a netre. Tehát ilyen alapon akár a oijhjhF=/79d56465Z.*HGKfh jelszó is lehet könnyű, ha az már bele került jelszó adatbázisokba.

https://blog.avast.com/ransomware-attacks-via-rdp
https://haveibeenpwned.com/
https://hup.hu/cikkek/20180226/ismerd_meg_az_ellenseg_fegyvertarat_rdp_brute_force_toro_es_szkennelo_250_dollarert

A 7601-es Win 7 az az SP1. 2011-es kiadás. Ha nem frissített gép volt akkor nagyon sok kritikus sebezhetőséggel üzemelt, többek között RDP-n keresztül is támadható volt.

2015-ben javította az MS azt a kritikus RDP sebezhetőséget aminek segítségével megtörhették a gépet:
https://docs.microsoft.com/en-us/security-updates/securitybulletins/2015/ms15-067

Ebben a történetben az a meglepő, hogy eddig bírta. Sajnos komoly esély van rá, hogy már korábban is ki-be járkáltak a gépen.

Ha már úgyis megszívtad vele, futtass le légyszi egy clamav-ot rajta. Nekem a windowsos chrome megnyitásánál folyton riaszt az immunet, hogy a googleapis.com infected fájlt tesz a gépre. Ugyan semmi köze szerintem, de kíváncsiságból jó lenne.

--
openSUSE 42.2 x86_64

Clamwint tudtam futtatni, a clamav nem találta a clamav.conf -ot, pedig oda raktam ahova kérte. A clamwin a memória vizsgálat során nem talált semmit. Most indítottam egy file vizsgálatot is, de gyanús, hogy az se fog találni semmit is.

Csak egy kósza ötlet volt, mert nekem mindig arra vergődik, amikor chromeot nyitok, hogy a chrome cache mappából egy gz fájlt kiránt, ami egy googleapis.com-ra irányító javascript halmaz és a domain logokban nálad feltűnt ugyanaz a googleapis.com domain.

--
openSUSE 42.2 x86_64

A ClamAV nálam hátrább került a megbízható listán.
2017 novemberében elküldtem nekik az Unlock92 2.0 csúfságot, és a mai napig sem ismeri fel.

Nagyon szepen fogalmaztal, de ha egyertelmuek es vilagosak akarunk lenni akkor azt kell mondani hogy a ClamAV a sajat adatbazisat hasznalva (barmifele 3rd party adatbazis nelkul) egy nagy halom semmivel egyenlo. Csak es kizarolag 3rd party db-vel jut el a hasznalhato kategoriaba.

De az fizetős.

A nálam működő immunet clamav alapon megy, a kérdésem pedig arra a konkrét esetre vonatkozott. Mellesleg, a panda av, avast ccleaner mappáiból is kiszedi a trójaikat, amik a friss telepítésüktől kezdve ott vannak. Virustotal-t szoktam használni felülvizsgálni, és 99%-ban az is pozitív jelzést ad.

--
openSUSE 42.2 x86_64

Megnézted a Virustotal linkjét a zsarolóra? Elsőnek küldtem be oda.
Te kiváncsi voltál, hogy megtalálja-e, én meg jeleztem, hogy van amiről lassan másfél éve nem tudnak, pedig elküldtem nekik. Azért linkeltem, be, hogy ha nem találja, az nem jelenti, hogy nincs ott.