phobos ransomware

Microsoft Windows

Ü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?

  • 2194 megtekintés

( zrubi v | 2019. 02. 04., h – 09:18 )

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

Ennyi.
--
zrubi.hu

( djsilas | 2019. 02. 04., h – 09:24 )

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

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

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.

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_…

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/201…

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.

( lajos22 | 2019. 02. 05., k – 10:49 )

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

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 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.