Locky (és egyéb crypt Ransomware) szűrése hogyan ?

Spam, Adathalászat

Több téma is volt már ezzel kapcsolatban HUP-on (és máshol is), de igazán jó megoldást sehol nem láttam (eddig? :) ).

Sajnos nagyon elszaporodtak a különböző crypt ransomware-ek, és igen nehéz ellenük a védekezés.
A kliens oldallal most ne foglalkozzunk, az érdekelne ki milyen módon próbálja megoldani a kliensek előtt (SMTP, DNS, Proxy, ....) a "védekezést".

Az a tapasztalat hogy sajnos a fízetős termékek sem állnak jelenleg a helyezet magaslatán, tehát 100%-os (de akár csak 90%-os) megoldás sem igazán van, gmail-ba is be-be szalad egy egy ilyen levél, pedig ott biztosan van rá erőforrás.

Klienseket alapvetően a következőképpen lehetne védeni:
- SMTP szűrés (spam és vírus) - ne kapjon ilyen levelet
- DNS alapú "szűrés" - ha megkapta a levelet, ne tudja elérni a forrás szervereket
- HTTP(S) proxy szűrés, ha megkapta a levelet, ne tudja elérni a forrás szervereket, ne tudja letölteni a fertöző JS kódot

Az alkalmazások azok úgy gondolom mindenkinél adottak, mindenkinek megvan a kedvenc SMTP, spamd, antivírus, DNS, proxy alkalmazása, de ezeknek szükségük van megbízható, gyorsan frissülő adatbázisokra, ilyeneket keresek.

Nem feltétlenül ingyeneseket, hiszen ezeknél a x..oknál órák is számítanak.

Hasonlókra gondolok mint:
- http://sanesecurity.com/
- https://malwarepatrol.net/

  • 21923 megtekintés

( tigrincs | 2016. 03. 29., k – 13:26 )

DNS alapu szuresen mire gondolsz?
Miket zarsz ki? A dropper nem feltetlenul a black netrol jon. Illetve ha mas fertozesek alapjan zarsz ki honnan tudod hogy nem te leszel az elso aki talalkozik vele? ergo te itt meg nem leszel vedett.

Vannak DNS alapú blacklistek, pl. a fentebb említett malwarepatrol-on is:https://malwarepatrol.net/open-source.shtml
Ha olyan host-ra menne kliens ami szerepel a listán, akkor helyi DNS valami mást ad neki vissza (hasonló mint OpenDNS, csak helyben)

más, de innen jutott eszembe, mi elég sok helyen használunk suricata-t, hozzá is már elég sok locky pattern van.
emergingthreats.net-en (suricata rule forrás) pedig elég jó IP blacklist van:
https://rules.emergingthreats.net/fwrules/

( Tassadar v | 2016. 03. 29., k – 13:54 )

"- HTTP(S) proxy szűrés, ha megkapta a levelet, ne tudja elérni a forrás szervereket, ne tudja letölteni a fertöző JS kódot"

A JS kód a levél mellékletében van, ZIP-be csomagolni.
Ez a JS egy futtatható binárist tölt le, ezt tudod proxy-n tiltani, MIME alapú szűréssel.
A JS-be levő URL változékony és megpróbálják elrejteni:

(("shapes","sleeve","h")+("howls","mouse","monotone","about","tt")+"p:"+("marmalade","stockholm","mexican","//")+"sc"+("fortify","smirk","apologetic","dominoes","orpena")+".c"+"om/7"+"65"+"f4"+"6vb.exe","hIhgYthUsm");

Magára a JS-re a forgalomba levő vírusirtók elég pocsék találati arányt produkálnak.

Amit írtal az jó, csak lehet hogy 2 nap múlva már nem sok mindenre passzol :)
Igazából ezért keresnék valamilyen "listás" megoldást, önmagában víruskereső nem elegendő.
Mivel elég sok és jellemzően nem homogén ezközt tartunk karban a néha felveszünk egy új szabályt sem kényelmes (automazálható minden, de akkor is).

Próbálkozunk most több fizetős ClamAV DB forrással, de kéne egy második szürési kör is.
Mivel ezeknek a szaroknak a nagyrésze levélben érkezik, ott kellene erősíteni.

Nem víruskergetőről írtam és az IP/hosztok is olyan gyorsan változnak, hogy nem lesz hatékony a pusztán erre alapozott védelem.

Arra céloztam, hogy a ZIP-be csomagolt JS fájlok tilthatóak, akár úgy, hogy a címzett értesítést kap róla, az aláíratlan Office makrókra ez ugyanúgy érvényes.
Ez mellett tilthatód a futtatható binárisokat Windows alatt is.

( Celtic v | 2016. 03. 29., k – 15:09 )

Legbiztosabb: beszopja, kirugni.

20+ eve elhangzik, hogy ne nyiss meg ismeretlen forrasbol szarmazo es/vagy nem vart mellekletet.
Tenyleg elegem van az egybites userbol "mert kivancsi volt".

Egyebkent nalunk az ESET megfogja munkaallomasokon(nagyjabol), clam meg nem a szerveren.
De nem foghatom mindenki kezet, ha hulye, akkor dogoljon meg.

Mint regebben:
- vartal _barmifele: visszaigaolast az USA postatol?
- nem....
- Tudsz egyaltalan alapszinten angolul?
- nem....
- Akkor mi a fasznak nyitottad meg????

Megtortent eset, akkor kirugassal lett fenyegetve az illeto. Most mar alapbol kirugas, nem engedhetjuk meg magunknak, hoyg debileket alkalmazzunk.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Nem tudom, meg nem talalkoztam idiotaval. Antiszocialis alakkal mar igen, gyorsan tavozott.
IT ceg, szoval elvarhato, hogy ha azt mondom, "ne nyiss meg olyan mellekletet, amirol nem is sejted, m ilehet", akkoe felfogja. Ha nem fogja fel, akkor nyilvan idiota.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

En voltakeppen azt nem ertem, ha valaki _barmilyen_ listaval akarja megfogni.
Mi garantalja, hogy ami ot perce nem volt a listan, most sincs ?

En tenyleg nem latok mas megoldast, mint a felhasznalokat megvalogatni. Nyilvan mas a helyzet, ha mondjuk egy nagykereskedelmi cegrol van szo, tele 50+ eladoval, akik e-mailhez fernek es mas egy IT-ceg, ahova bizonyos elvarasokkal kerulnek az emberek. De az egyik cegtol is szoltak, hoyg onmaguktol kapnak levelet (mittomen, 30 user, negy telephely, kereskedok), ott sem nyitottak meg vadul, hanem szoltak. SPF-t beallitottam, maris nem kapnak maguktol levelet. Nyilvan nem garancia ra, hoyg xy@xy.com nem jon be, de ott is vannak annyira gyanakvoak, hoyg nem nyitjak meg.

Jaigen, es megint mas nyilvan egy ISP helyzete, arra otletem sincs, mit tehetne. De fenntartom, hogy "nem allhat minden pofon mellett egy kozlekedesi rendor", ahogy az usereket se lehet folyamatosan patyolgatni.

(Nyilvan az igazi gond ott van, ha angol nyelvu partnertol var levelet...veszelyes helyzet. De magyar nyelvu subjectben meg nem lattam ezt a Lockyt)

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Most bunko leszek (bar gondolom, mas szerint eddig is az voltam). En ennek orulok. Nagyon sok szerencsetlennek elkapja a gepet, ami mondjuk eddig fasza resze volt egy kis botnetnek: fizetni ugysem fog, viszont ujra kell huzni. Talan egy kicsit csokken a botnetekbol jovo spam mennyisege.
Aztan majd megirhatja a facebookon, hoyg a "kormany/ellenzek titkositotta a gepet, mert nem tudta megfigyelni" vagy hasonlo csodalatos bejegyzest.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Neeem....Komolyan, csak nekem furcsa, hoyg alapelvaras, hogy ne nyisson meg minden szart? Van ugyan MPP spamszuronk (benne a clamav), de az nem igazi, atengedi. A munkatarsak 90%-a nem levelezik, hanem fejleszt. Maradk 10% az adminisztracio, PM-ek, el lett mondva, hoyg vigyazzanak. Amit megosztasra raknak, arrol Baculaval mentes keszul, amit sajat gepen tartanak, azzal ugy jartak, ha megis beszopnak.
De eddig meg senkinek sem sikerult, de parszor mar szoltak az admin lanyok, hoyg sajat maguktol kaptak levelet, amit biztos nem kuldtek. Csak nekem furcsa, hogy ertelmes emberekkel vagyok korulveve ?

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Idezet a Fight Clubbol:

"Illusion of safety"

Pont az olyan melluket vero egyenek mint Te szoktak beszopni valamit, aztan masokra fogjak a hibat. Orulok, hogy Te nem kattintasz mindenre amit emailben kapsz, hidd el en sem. Viszont az is teny, hogy az end userek kreativitasa es hiszekenysege tultesz minden virus/ransomware megelozo javaslatodon. Ha nem emailben, akkor maskepp talalnak modot.
Vagy akkor is kirugjatok az "idiotat", ha egy legit oldalon rakattint egy bannerre, amiben fertozo kod van?

Ah, mar latom, kulfold es egeszsegugy. Akkor sokkal nehezebb a helyzet, elismerem. (Itt van 40+ ember es mind IT-s szinte).

Igen, hat vegulis nyilvan fugg a cegtol is, ahol ilyen gond felmerul...Sztem max. annyit lehet, hoyg dolgozzon kozos meghajtora es onnan backup. Bar, ha orvosi gepek eredmenyei is vannak...nem egyszeru.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Ah, és el is olvastad a cikket :) remek.
Bár ha ennyire vágod a cégednél mi a téma, és gondolom segíted is a céged működését .. akkor teszel /gondolom/ ellene hogy ne rúgjanak ki senkit kéretlen levelek miatt (vagy nem? vagy te vagy a cégvezető)

Bár nem kívánom senkinek és neked se hogy lockyval kelljen küzdenie!

Kanyarodjunk vissza az eredeti kérdéskörhöz !

Az usereket nem lehet megvállogatni, ezért mert valaki megnyit valamit akár a tiltás ellenére attól még nem biztos hogy idóta ... (X kor felett örül ha tudja kezelni a word-ot, de a saját szakterületén ettől még jól teljesítt).

Ha olyan cégnél dolgozol ahol sok a külföldi partner, és sok a számla, akár még életszerű is hogy megnyít egy ilyet, szintén nem azért mert idióta, ezzel a megközelítéssel nem jutunk előrébb !

Ha az adott cég ügyvezetője nyal be egy ilyet én meg azt mondom hogy 1 bites idióta vagy, akkor másnap szerződés bont velünk ... itt a megelőzés a cél, nem megmutatni azt hogy én vagyok az informatikai kiskirály !

Az a helyzet, hogy a juzereket nagyon kell képezni és tájékoztatni ilyen témában. Szintén tapasztalat, hogy imádnak klikkelni és utána nem értik. Ráadásul mérgesek se lehettünk rá, sőt védhetetlen a helyzet. Az illetőnek pont az a munkája, hogy az ismeretlenektől érkező állásra jelentkezéseket szortírozza, megnézze.

Ami az igazán szomorú és bosszantó, hogy nagyon sokan nem frissítik, sőt kikapcsolják direkt a bármilyen frissítést a gépünk mert hiszen biztosan elront valamit.

"Ha olyan cégnél dolgozol ahol sok a külföldi partner, és sok a számla, akár még életszerű is hogy megnyít egy ilyet, szintén nem azért mert idióta, ezzel a megközelítéssel nem jutunk előrébb !"

Teljesen jogos. En is csak abbol indultam ki, hogy furcsa, az emberek nem tudjak megerteni 20 eve sem, hogy nem nyitogatunk meg minden szart es ugy altalaban ovatosak vagyunk.

Egyebkent oenteken este fel otkor (mikor maskor) irtak egy cegtol, hogy surgosen erdekli oket, van-e mentesuk, mert bekaptak egy lockyt.
Jo, indultam volna haza, de lelkiismeretes vagyok, ezert valaszoltam, van mentes, hogyan kaptak be, kinek a gepen, hol latszik, stb.
Kedd ugye elso munkanap, femnti kerdeseket ujra feltettem. Ma valaszoltak, mondtak a Sambas serveren par konyvtarat, ahol .locky fileok vannak.

Megneztem, csodas volt: 03.02 a datum....Es ezt 03.25-en keso delutan veszik eszre.... Term. a legregebbi mentesuk (most) 03.05-ei...Ha egy hettel elobb szolnak, minden visszaallithato.

Nyilvan nem kellene oket idiotaknak neveznem, de a tokom kivan vele, hogy ilyenkor rogton ugranom kell, de valaszolni egy kerdesre basznak.
Ha javaslatot teszek, hogyan lehetne javitani valamin, leszarjak
Ha baj van, fogjak a fejuket.

Nem tudom maskent, mint idiotakent minositeni oket.

"Ha az adott cég ügyvezetője nyal be egy ilyet én meg azt mondom hogy 1 bites idióta vagy, akkor másnap szerződés bont velünk ... itt a megelőzés a cél, nem megmutatni azt hogy én vagyok az informatikai kiskirály !"

Itt nem tudom, ki volt, de en nagyon orulnek, ha tobbet nem talalkoznek veluk. Meg van meg 1-2 ilyen ceg, az 5-10 desktop geppel, max egy samba serverrel. Jo lenne oket elhajtani, mert amilyen keves munkat adnak, azt annyira "mostrogton"

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Ilyenkor szimplán elég védeni a segged. Ki kell ajánlani preventíve a megfelelő mentési megoldást (napi, heti, havi, fél éves visszatöltéssel), ehhez szükséges hw, sw, munkaidő, ez nekik mennyibe lenne, emailben elküldeni, cc főnök, és kb ennyi. Onnantól lehet mutogatni rá, h már anno megmondtad, és hát szarrágás/beleszarás minősített esete volt.
Nálunk is most került elő (van mentés, de nem lenne elég jó egy locky ellen), úgyhogy jövő héten file server vastag bővítése, zfs+snapshot. Nem akart rá költeni, fennti metódust végigtoltam, innen nem az én dolgom, ha leszarja.

az semmi. egyik ugyfelnel most vettek eszre hogy tavaly nyaron (!) lekodolodott egy teljes projekt konyvtar (100 gigas samba share, 5 evnyi munkajukkal). nem locky volt, hanem valamelyik cryptobit ami nem nevezte at a fileokat. logokbol arra kovetkeztetek hogy valamelyik egysegsugaru bekapta a virust ami par napig garazdalkodott aztan velhetoen a symantec kinyirta. mert nekunk nem szoltak akkor es vszinu eszre sem vettek.

mentes van persze par heti, meg egy 1 evvel ezelotti, megkaptak az utobbit, de fel evet igy is buktak. de legalabb idopont alapjan ossze diffeltem nekik melyik fileok valtoztak vagy ujak a mentes ota, igy tudjak mi veszett oda. szerencsere nem sok, mert mar lezart projekt volt.

btw gondolkoztam rajta hogy samba serveren be kene allitani a verziozast, elvileg tud olyat (vagy legalabbis van egy ilyen plugin) hogy torleskor, modositaskor keszit egy mentest egy felhasznalok elol rejtett konyvtarba.

A'rpi

Van egy olyan erzesem, hogyha xy be is kapja vagy le is torli, nem szol rola...mert mondjuk fel (az mas kerdes, hogy joggal fel vagy nem). Aztan mire kiderul, tobbszor annyi kar van, mintha azonnal szolt volna. Ettol felek igazan, hogy nalunk valami nagypofaju (mert azert a sales/marketing reszleg nem teljesen tartozik szvsz a nem-idiota kategoriaba, hogy megfeleloen polkorrekt legyek) beszedi es nem szol rola, aztan mire kiderul, mar kikopnak a mentesek....Kiderulni meg valoszinuleg kiderul, ha ujrahuzza a gepet, domainbe leptetni mar nem tudja...

--
http://www.micros~1
Rekurzió: lásd rekurzió.

( ncc1701 | 2016. 03. 29., k – 15:48 )

Lokális gép egyértelműen elesett, nem lehet már megvédeni tutira. Valaki úgyis el fog indítani valamit.
File szerveren pedig zfs+snapshot.

( BognarB v | 2016. 03. 29., k – 16:26 )

Kicsit off

.locky kiterjesztesu allomanyokon kivul mit lehet meg erdemes keresni? CTB es tarsainak vannak/voltak konnyen azonosithato jelei, akar file nevben, akar kiterjesztesben?
Leszogeznem, hogy a halozat vedelme nem az en feladatom.

Koszonom!

udv
letix

-----------------------------------------
Linux alapparancsok, kezdőknek

Koszi a valaszod. A rendszert nem en vedem, en csupan cifs-en keresztul keresgelek, neha sajnos tobb (mint kevesebb) sikerrel.

A Locky nevu feregnel en ugy latom eleg konstans a .locky kiterjesztes, illetve a mappankenti Recovery instructions text file.

A kerdes igazabol arra iranyult volna, hogy a tapasztalatotok alapjan mostanaban vannak-e hasonlo mukodesu crypto cuccok (pl allando kiterjesztessel), amikre akar file keresessel is ra lehet bukkanni.

Koszi!
udv
letix

-----------------------------------------
Linux alapparancsok, kezdőknek

Fentebb irtam, hogy en csupan nezelodom, nem az enyem a rendszer.
Azt a helyzetet viszont siman el tudom kepzelni, hogy Marika ebedszunet elott szepen lefuttat egy fertozott ZIP-et, es mivel o a makro engedelyezesen tul semmi erdekeset nem eszlel, szepen elmegy ebedelni, vagy epp meeting-re. 1-1 ora elteltevel jobb esetben csak a home-ja, rossz esetben akar egy rakas network share is szejjel van mar csiszolva.

Ha viszont idoben kapunk egy mailt (erre mar volt precedens a locky masodik verziojanal) ugy esetleg lehet csokkenteni a kart/visszallitasra forditott idot.

Azt, hogy a szakiknak milyen fogast kell(ene) talalniuk a leveleken, sajnos nem tudom.

udv
letix

-----------------------------------------
Linux alapparancsok, kezdőknek

Két ötlet, egyiket sem valósítottam meg. Még. De a másodikon gondolkozom.
https://moiristo.wordpress.com/2009/08/10/samba-logging-user-activity/

Illetve aknamező telepítése ahol minden felhasználó csak egy-egy foldert vagy fájlt lát/ír. Ezt viszonylag gyorsan át lehet nézni.

Egyébként a helyes védekezés a snapshot.

Tehat a sehogynal az en megoldasom is jobb mint a semmi. Vagyis elkepzelheto, hogy megsem folosleges eroforras pazarlas.

Alapvetoen orankent find-olok, de gondolkoztam updatedb-n is. kb 10TB-nal az updatedb 25-35 perc alatt fut le 0-ról, és 250-300MB-os kimenet keszul. Kerdes, hogy mar meglevo db mellett a "frissites" meddig tart es pontosan milyen db is keszul. Pl torli-e a remote fs-bol mar torolt allomanyok bejegyzeseit. Igy a kereses nyilvan sokkal egyszerubb/gyorsabb.

Find eseten a futasi ido 15-25 perc korul van.

Mindezt Gbit-es halon, es egy microserverrol.

udv
letix

-----------------------------------------
Linux alapparancsok, kezdőknek

Ismerősnél fél óra alatt 40 ezer fájlt titkosított. Így az óránként ránézek, elég gyenge védelemnek tűnik.
Volt mentés. Gyakorlatilag egy óra pánik, 2 óra visszaállítással (kliens újratelepítéssel) megúszták.
Viszont több helyről hallom, hogy beszívták, és nincs mentés.
Úgy tűnik néha kell egy ilyen, hogy az "értelmetlenebbek", felelőtlenebbek is felfogják, hogy kell mentés, nem viccből mondja mindenki, hogy nem nyitunk meg bármit...

Tassadar: jelenleg csak nehany kiterjesztesre, de tervezem kiterjeszteni az ismertebb elnevezesekre.

opt: igen, lehet hogy az orankenti futtatasa eleg gyenge. De mint fentebb irtam, nyilvan jobb a semminel. Ti pl hogyan ertesultok/ertesulnetek arrol, hogy valamelyik kliens epp 20 megosztasban titkosit? A usertol, aki konstatalja hogy elvesztek a munkai?

Megtehetnem azt is hogy folyamatosan tekerem a mernokok szervereit, de eros a gyanum, hogy windows alol fs szinten is meg lehetne oldalni. Vagy nem?

-----------------------------------------
Linux alapparancsok, kezdőknek

Csak otletelek:
En elsore incronnal figylenem az FS-t iraskor es a modositott fileokrol probalnam eldonteni, hogy eppen titkositodnak-e.

Barmi ilyet nem inditanek az alapjan, hogy nagy az IO load. Kepzeld el, hogy csinalsz valamit ami mar onmagaban lefogja a fileserveredet es raiinditasz findet (vagy akr mit), hogy meg lassabb legyen.

--
http://blog.htmm.hu/

Saját ötlet: (Python, vagy Perl) szkriptből "vmstat 1" folyamatos outputjának real-time feldolgozása. Magas IO esetén smbstatus futtatása. Smbstatus outputjából samba session-ök szerinti bontásban szűrés regexp-pel fájlnevekre, amiknél a kiterjesztés legalább 4 karakter (és több ilyen is nyitva van a sessionben; ismertebb négy betűs formátumok (docx, xlsx, mobi, epub, stb. whitelist-elése)). Lehetséges reakciók: ip cím szerinti tiltás, user tiltása (ha nincs címtár, akkor smbpasswd segítségével), admin értesítése.

Perfmonnal szerintem elég könnyű felállitani egy baselinet és utána alertet rakni, ha egy küszöböt átlépi egy adott share-en a mért érték.
Szóva jöhet az SMB Server Shares\write requesest/sec, file opened/sec és még pár.

Ezeket share-enként finomhangolni is lehet, vagy lehet az SMB server sessions alól is ugyanezeket a countereket figyelni és akkor csak egy adott kliens session-jéhez viszonyitva nézi ezeket a számokat, az talán biztonságosabb, mert nem fog fals alertet generálni, ha véletlen egyszerre 10 user indit el valami sok file-os másolást a share-re.

Koszonom, jo otletnek tunik, bar meg nem minden teljesen vilagos. Sot.

De ameddig atragom magam a fentieken, arra gondoltam, hogy tarthatnek fent mlocate (updatedb) altal letrehozott adatbazist is, szerverenkent.
Az iment meregettem, 800GB-os cifs-en futtatva durvan 7perc alatt lefut, 0-rol, a kimeneti db pedig 35MB.
Ami idoben soknak tunhet, de ugye a kovetkezo futaskor mar lehet, hogy ennek a toredeke. Sot ha nem microserveren futtatnam, talan meg jobb lehetne.

A kerdes mar csak az, hogy a tavoli fs-ben tortent modositasok egy db frissiteskor le lesznek-e kovetve. Illetve hogy ebben a db-ben mennyire lehet konnyeden keresni 80-100 fele file-tipust.

-----------------------------------------
Linux alapparancsok, kezdőknek

Az egy hónappal ezelőtt kapott emailjeink mellékletei is vígan futkorásznak és titkosítanak mellette... Ugyan azt is meg kell jegyezni, hogy nem tudom a CTB-, Crypto-, Tesla-, whateverLocker melyik változatát és típusát tölti le a js-fájl, de így ez pont nem több a semminél...

( andrej_ v | 2016. 03. 29., k – 22:32 )

No újabb öröm ért. Találkoztam az RDP-n keresztül érkező (megszerzett juzer+jelszó) verzióval. Más már futott bele?

Nyilván olyan gépről ahol be volt állítva, ezzel nem lehet sokat kezdeni.

Rendszeres, hogy a csoda PPTP VPN nem megy innen-onnan, de az RDP igen. Annál már jóval nagyobb a méret, hogy hipphopp átálljunk másra, akár csak más módszerre. Tudom a PPTP-t is el kéne felejtenünk... :( Már voltak lépések, de még nem 100-as a dolog.

( quash | 2016. 03. 29., k – 23:26 )

Igen elkanyarodtunk a témától, mivel egyenlőre jobb megoldást nem találtunk, brute megoldással szabadulunk meg tölük.

Az összes szűrésen átjött tömörített fájlban (zip, rar) mindig .js a probléma forássa, ezeket validáljuk (ha zip-ben van javascript kód) és dobjuk is ki.

Őszintén nem tudom (majd rákérdek), letöltöttek valamit webes felületről (szerintem régebben kitöltött xkr kiterjesztésű "nyomtatvány" lehetett) amire ha elvileg rákattintanak kettőt beimportálja az ÁNYK, ezt a műveletet valószínűleg valami scripttel intézheti, mert letiltott Scripting Hosttal csak felvillant a Parancssor. :)

Ez futna le az xkr kiterjesztés esetén (gondolom meg is van a magyarázat letiltva miért nem :))

@cscript "C:/Users/Public/abevjava/gen_abevjava_import.vbs" %1 "C:/Users/Public/abevjava/abevjava.jar"

Csak tud ez a zseniális oprendszer olyat, hogy csak a direkt futtatást szeretném letiltani (azaz a .js/.vbs scripteket ne lehessen elindítani, csak így, cscript paramétereként)?
Nyilván meg lehet szüntetni pl. a .js -> cscript összerendelést, esetleg a notepad-et lehet inkább helyette hozzárendelni, és akkor hiába kattint a paraszt a .js scriptre, az inkább megjelenni fog :D (a többi hasonló szarságnál dettó ugyanezt el lehet játszani, a kutya nem akar .vbs fájlokat direktben indítgatni)

A jelenlegiek ellen jó lehet az összerendelés megszüntetése, de akkor átrakják egy bat file-ba, ami már cscript-el együtt futtatja.

Szerintem a legjobb megoldás az volna, ha a WSH trust policy-jét 2-esre emelnénk és aláirnánk az ÁNYK scriptjeit. És amilyen szerencsénk lesz, gondolom minden ÁNYK frissités felülirja ezeket a scripteket és akkor újra alá kell irni :)

Hmm...

Mire jó amúgy ez a Windows Scripting Host, hogy egy ÁNYK-nak ebbe kell belehívogatni ahelyett, hogy a saját kódja intézné el a funkciót?

Egyébként ha kell másnak kár letiltani, de a fájl hozzárendeléseket akkor sem értem (az összes általad felsorolthoz). Miért jó, ha egy js fájlra kattintva az lefut? Nem elég ha az aki nagyon akar futtatgatni kézzel beírja, hogy wscript.exe lofing.js?
Aki nem ért hozzá hogy beírja ezt, valószínűleg nem is való neki a js fájlok futtatgatása nem?

Mennyi problémát meg lehetne oldani ha ezek a fájl társítások nem léteznének...

( sj | 2016. 03. 30., sze – 20:08 )

valaki tudna mutatni egy ilyen levelet teljes fejleccel?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Ha nagyon kell akkor a headereket is ki tudom mazsolázni, de az problémásabb :/ De egyébként igen, Invoice* ból jött nagyon sok.
Amióta van a .zip -ben .js tiltás egész jó aránnyal dobálom ki az összes ilyen sz.rt.. Most eljött a .zip.doc* ideje.

Bizonyos okok miatt ezeket nem dobálhatom ki, de asszem meg fogom tudni győzni az illetékeseket, hogy ezeket is dobáljuk el a francba.

( sj | 2016. 03. 30., sze – 22:51 )

az smtp-n mit lehet tenni reszhez par gondolat, amit egy ~1000-es mintan lattam (kossz elod):

- a malware donto resze botnetek felol jon, amelyek ptr-je egyreszt arulkodo (pl. c-98-196-146-108.hsd1.tx.comcast.net, host176-14-static.13-188-b.business.telecomitalia.it), masreszt nem konzisztens a ptr -> a, a -> ptr feloldas. Az 1000 level eseten 5 volt olyan, amikor nem ilyen gepek felol jott a cucc, azaz egy jo policy demonnal / check_client_access szabalyokkal (postfix terminologia) 99,5% ilyen leveltol meg lehet szabadulni - mar smtp szinten.

- az alabbi 6 db subject-re illeszkedo (regex) mintaval kiszurheto a malware 75%-a:

(Payment|Invoice) (Copy|Incoices|Receipt)
Overdue (Incoices)
Document (1).pdf
Document2
Delivery Confirmation Receipt
FW:$

Hirtelen felindulasbol eszembe jutott az is, hogy mi lenne, ha a mail szerverek - amolyan razor/cloudmark jelleggel - egy kozponti db-bol ellenoriznek*, hogy az adott melleklet sha256 sum-jat hanyszor lattak mar [a mail szerverek]? Nem tudom, mennyire valtozik ugyanaz a melleklet, de ketlem, hogy pl. a Document2.zip minden cimzettnel egyedi lenne.

*: ha valaki nem akar a 4567. lenni a 'Kisvallalkozas irodai kiszolgaloja debian alapokon' c. szakdolgozatot beadok nepes taboraban, akkor ez egy nagyon jo tema, foleg ha meg melle is tesz egy PoC kodot kliens ill. szerver oldalon :-)

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

dns konzisztenciával az a gond hogy vannak akik még ma is magasról tesznek rá, ezért nem is zavarom el őket alapból, csak a spamassassin flag-eli őket, elég nagy score-al ahoz hogy spam-nak nyilvánítsa.

Az antivírusok nem tudták elég gyorsan detektálni őket. Központi adatbázissal lehetne próbálkozni csak kérdés hogy azt hányan használnák.

A tegnapi arhívumban találtam egyébként 3 személyes aliast. Egyike a linkedin-es (tőlük tudjuk hogy ellopták az adatbázist), másik a direct2drive, harmadik meg savage (játék).

dns konzisztenciával az a gond hogy vannak akik még ma is magasról tesznek rá

nevelni kell oket. En birka turelemmel irtam vissza, hogy mit kene a dns-ben beallitani, ha levelet akar nekunk kuldeni. A tobbseg fejlodokepes, a maradek meg masnal is beveri a fejet ebbe a korlatba. Nalam mindenesetre pusztan ez a beallitas gyonyoruen szorja el a szemet eleg jo %-at.

Központi adatbázissal lehetne próbálkozni csak kérdés hogy azt hányan használnák.

minel tobben, annal jobb. Kb. igy mukodik a commtouch, cloudmark fingerprint alapu cucca is.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

A regexpek alapján grepelgettem néhány a mai és tegnapi mailözönben és csupa legitim emailt találtam. Az egyik juzer a paypaltól kap értesítést, a másik saját rendszere küldi így a számlát stb. Ezek a malware küldő arcok nagyon ráéreztek a nehezen szűrhetőségre.

Ami egy-egy ilyet megfogott az a kiterjesztés alapú szabálycsoport clamavba (eximesként azzal tudok belenézni a tömörített csatolmányba) és a clamavhoz bekapcsolt sanesecurity szabályok letöltése. Ezen kívül csináltam szabályt, ami a klienst rögtön visszacsapja ha a szerver saját IP címét mondja helo name-nek, bár biztos lesz olyan, aki szerint ezt már 20 éve is be kellett volna vezetni. :P Ez viszont ma 111 nev1_nev2@valami.com szerű mailt vágott vissza önmagában. Végre a reverze nélküli arcokat is folyamatos deferrel csapom vissza, nincs kegyelem és nagyon hasonló a minta az előzőhöz. A bónusz az lett, hogy csináltam egy szabálycsoportot, ami az N-nél több blacklisten szereplő klienseket visszacsapja.

Ami a nagy problémám, hogy rendszeresen szednek össze elhanyagolt gépről SMTP juzert+jelszót és megindul az áldás mindenféle vonalon. Ez ellen perpill a ratelimit szigorítását tudtam megtenni és geoip2 alapú szűrést tervezek. Ez inkább csak védőháló/hatáscsökkentő szerű lesz, mert nincsenek illuzióim, de legalább az egzotikus IP-ket kizárja a darálásból.

Nem ez a megoldás!

Ha megnézed amik bejönnek, azok 95%-a ZIP v. RAR, kell egy script SMTP-hez (pl. exim demime-vel) ami ha van csatolásban zip|rar|.... akkor azt kibontja, ha ezen belül van .js|.vb|..... akkor ezeket a policy-nak megfelelőlen kezeled (eldobod, megjelölöd, etc ...)

Ezzel meg is van oldva minden !

Pont tegnap néztem egy régebbi FW-t, exim-ben nem volt smtp banner delay, és alapvető check-ek (helo, ip reverse), ha csak ezeket bekapcsolod, a spam-ek nagyrésze már connect állapotban lehal.
Jellemzően nem várják meg SMTP bannert, csak behánnyák a levelet, 3 sec SMTP banner késleltetés csodákra képes, HELO-t se szabályosan csinálják, régi dolgok ezek, de ha valahol ez kimarad ...

víruskeresők, és spamd-k ezen most nem segítenek, a fenti script (demime)tegnap került fel nálunk egy csomó helyre, ma már igen érezhető eredménye van

Mar 31 23:34:45 mail exim[demime]: check - /var/spool/exim/scan/1alkEn-0006v1-Iq
Mar 31 23:34:45 mail exim[demime]: zip found - 1alkEn-0006v1-Iq-00000.zip
Mar 31 23:34:45 mail exim[demime]: potentional virus file found ! - Post_Shipment_Label_id00-018896098#.js q.042829426.js

Mi is első körben víruskereső, spamd, szabályok, etc ... oldalról próbáltuk megközelíteni, de itt most ez csak arra jó hogy egy csomó időt elcsesszünk vele.

demime scriptet hiv (mezei sh, pár sor), az megnézi mi van ZIP|RAR|... -ban, és ha gyanús akkor ez alapján mi eldobjuk.

deny demime = zip:rar
message = Attachment has potentially ransomware file inside $found_extension attachment
condition = ${run{/bin/sh -c '/usr/local/sbin/nst-check-demime.sh $message_exim_id'}{0}{1}}

Azokat proxy-n kell tiltani.

Egyébként tud valaki reális forgatókönyvet mondani arra, hogy egy zip-pelt .js file érkezik? (Már a webdev. témán kívül, nyilván.) Szerintem ezek r=1 cégnél 1 valséggel jelentenek valami olyan mocskot, amit el kell dobni a fenébe, de minimum karantén.

Illetve az jutott még eszembe, hogy az ilyen invoice.*.zip és hasonló csatolmányt tartalmazó levelek spam score-jához hozzá kell adni egy akkora score-t, amit semmi se visz le a spam szint alá, ami ugye megy egy hozzáértő által nézett központi spam folder-be. Aztán ha (Magyarországon) netán valamelyik tényleg legitim lenne, akkor azt lehet kézzel továbbítani. Nem szép megoldás, de evvan...

zip -pelt .js max. webdeveloper studiokban foroghat.

hozzank is erkezett ma egy, abban TITKOSITOTT zip-ben volt .js, es szemelyreszoloan a level torzseben, hogy kedves x.y. a csatolmanyodhoz ez a jelaszo: 000

na ezt szurd le.
a titkositott .zip -eket nem szurheted, nalunk pl. banki treasury megerositesek is abban jonnek.
meg elofordul altalanosan mindenhol ez-az titkositott zip -ben.

Sajnos nagyon regota, talan 10+eve is van mar, hogy a zip formatum resze lett a central directory encryption.
De rar, 7zip, stb talan mar alapbol igy mukodik.
Majd megnezem a bank milyet kuld.
De amig osx re nincs ugyse ilyen addig nem nagyon foglalkozunk vele, 15 userbol van ketto windowsos azok is backupolva vannak.

Pedig ez is jó megoldás.
Én (andrej ötlete nyomán)is megcsináltam a clamavba, hogy az archivba nézzen bele és ha valami gyanús kiterjesztés van, akkor dobja a kapcsolatot (exim data szekció). Még belőttem a snaesecurityt a clamavhoz és (nem akarom elkiabálni :) tegnapi naphoz képest amikor kb 200 ilyen levél jött, ma még egy sem csúszott át (hajnal óta 333 fogott meg) (az ilyenek mint smtp banner , helo , reverse dns, blacklistek eddig is megvoltak). Nyilván ha a tömörített fájlba doc, vagy xls van , akkor bukta, de ma nem volt ilyen :), bár azoknak a nevére meg lehetne greppelni .
Kezdetnek már ez is nagyon jó.

( toMpEr | 2016. 04. 01., p – 20:53 )

Ötlet: Honeypot fájlokat csinálni (pl. dontedit.py) és amelyik process/user módosítani akarja azt kilőni

En ebbol kiindulva csinaltam 3db honeypot filet, de lehetne akar tobbet is:
az elso a nevsorrendben elso alkonyvtar elso dokumentuma lett 00_Important.doc nevvel :D
a masodik az random helyen
a harmadik pedig a legvegen, uccso alkonyvtar, ZZ_Important.doc lett.
A fileok ugyan azok, es folyamatosan nezem ossze az md5 checksumot a letaroltal.

szerk:

persze lehet hogy addigra a tobbi !.doc fileomat reg hazavagta, de kiindulasnak nem rosz :D

( gemnon v | 2016. 04. 11., h – 15:38 )

Aki csak a .js-t blokkolja ajánlom figyelmébe a .jse-t :)

Az a baj a .bin kiterjesztéssel, hogy az .xlsx fájlok is tartalmaznak .bin kiterjesztésű dolgokat. Mivel az .xlsx is zip ezért a levelezőszerver jó eséllyel belenéz és már megy is a levesbe az Excel tábla.

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Nálam a .docm (application/vnd.ms-word.document.macroenabled.12) volt az új. Tegnap 13 óra körül kaptam az elsőt, utána még jött (volna) vagy nyolc, de addigra letiltottam őket, a biztonság kedvéért a .xlsm és .pptm kiterjesztésekkel együtt. A tiltott fájlkiterjesztések csak jelszavas archívban jöhetnek.

Érdekes, épp ma nyafogott egy user, hogy nem kapta meg a mailjét, át kellett küldesse gmail-re.
Kiderült, hogy a spamszűrő ezért dobta vissza a levelet, mert doc valójában docx volt. Szerencsére downloader nem volt benne, csak a hülye küldő valahogy a filenév.docx végére kézzel odarakta, hogy .doc

Következő trükk: zip kiterjesztésű - valójában rar-ral tömörített - archívban .wsh fájl. Úgy tűnik, hogy az amavis nem tömöríti ki, mert a .wsh kiterjesztést blokkolnia kellett volna. Megoldás: a zip-re és a rar típusra (T=zip, T=rar a logban) a nem hozzá tartozó kiterjesztésű csatolmányok blokkolása.

Üzenet szövege:

Reply to: office@DOMAIN.HU
Device Name: MX2310U@DOMAIN.HU
Device Model: MX-2310U
Location: Reception

File Format: PDF MMR(G4)
Resolution: 200dpi x 200dpi

Attached file is scanned image in PDF format(RAR archive).
Use Acrobat(R)Reader(R) or Adobe(R)Reader(R) of Adobe Systems Incorporated to view the document.
Adobe(R)Reader(R) can be downloaded from the following URL:
Adobe, the Adobe logo, Acrobat, the Adobe PDF logo, and Reader are registered trademarks or trademarks of Adobe Systems Incorporated in the United States and other countries.

http://www.adobe.com/

( Fisher v | 2016. 04. 13., sze – 20:10 )

Volt egy CTB webinar, ahol összefoglalták az akkor tudható dolgokat. Lesz hasonló? Állati sok változás nem történt, ha jól látom javul a C&C kommunikáció, több kiterjesztést keres és kezdi inkább a cégeket támadni. Estegleg az akkori adás elérhető valahol?

Már van Jigsaw is ami egy idő után törli a fájlokat elvileg (márha egyáltalán elindul mert az elvetemült .NET varázsló :P) 


    internal static class Locker
    {
        private static readonly string EncryptedFileListPath;
        private static readonly HashSet<string> EncryptedFiles;
        private const string EncryptionFileExtension = ".fun";
        private const string EncryptionPassword = "OoIsAwwF23cICQoLDA0ODe==";

*facepalm*