'Grote ransomwarebende BianLian versleutelt geen data meer, steelt alleen nog'

Amerikaanse en Australische autoriteiten waarschuwen dat meerdere grote ransomwarebendes, waaronder het beruchte BianLian, in hun aanvallen niet meer aan versleuteling doen. Deze bendes stelen alleen nog data voor afpersing. Experts zien die verschuiving al een tijd plaatsvinden.

De Australische Signals Directorate heeft een advisory over de BianLian-ransomwarebende bijgewerkt. In die advisory schrijft de instantie, samen met andere Australische cybersecurityorganisaties en met de Amerikaanse politiedienst FBI dat zij nieuwe activiteiten van BianLian heeft waargenomen, onder andere tegen kritieke infrastructuur in de Verenigde Staten. De groep lijkt via het remote desktop protocol binnen te dringen bij bedrijven en data via FTP te exfiltreren.

Opvallend aan de rapportage is dat BianLian volgens de instanties helemaal geen zogenaamd dubbel afpersingsmodel meer gebruikt. Ransomwarebendes zijn de laatste jaren bijna volledig overgestapt op dat dubbele model, waarbij ze data niet enkel meer versleutelen, maar ook dreigen die openbaar te maken. Dat vergroot de kansen dat slachtoffers betalen. BianLian is daar nu van afgestapt: de groep zou sinds vorig jaar al hebben geëxperimenteerd met alleen nog het stelen van data en sinds begin dit jaar daar helemaal op zijn overgestapt.

Dat is een verschuiving binnen ransomware die experts al een tijdje zien. Tweakers sprak begin dit jaar met experts die dat voorzichtig zien gebeuren. Maar begin dit jaar leek het dubbele afpersingsmodel nog gemeengoed te zijn. Slechts een handjevol bendes was overgestapt op enkel nog datadiefstal in plaats van diefstal én versleuteling. Nu lijkt die verschuiving ook de grote bendes te bereiken: BianLian is een van de grotere en beruchtere ransomwarebendes die er zijn. Dat BianLian daar eerder mee experimenteerde, was overigens al wel langer bekend, maar niet dat de bende daar definitief op was overgestapt.

De Australische en Amerikaanse instanties noemen geen expliciete reden waarom de bende op het enkelvoudige afpersingsmodel is overgestapt. In het algemeen hebben experts daar wel verklaringen voor. Zo is versleuteling en dan met name succesvolle ontsleuteling technisch ingewikkeld. Ook zijn bedrijven steeds vaker voorbereid op versleuteling, doordat ze betere beveiliging en werkende back-ups hebben.

Reacties (106)

[HKLM_]

De groep lijkt via het remote desktop protocol binnen te dringen bij bedrijven en data via ftp te exfiltreren.

Echt bizar hoeveel beunhazen er nog in de IT werken en RDP en FTP gewoon open hebben en niet beveiligd hebben. Wat mij betreft vraag je er dan ook wel een beetje om hoor.

[AlphaRomeo]

Ik gok dat het om outbound (s)ftp gaat. Dat is meestal niet geblokkeerd. Inbound RDP zou uiteraard wel geblokkeerd moeten zijn.

[Ricco02]

Of je gooit 2FA op de RDP als je het nodig hebt. Probleem ook opgelost.

[Reactie gewijzigd door Ricco02 op 22 november 2024 08:17]

[Kees]

Nee, je zet RDP niet open naar het internet. Als je het nodig hebt dan gaat dat via een vpn-oplossing (liefst geen fortinet, ivanti of palo alto meer tegenwoordig )

[Marcelvdsteen]

Of je maakt daarnaast ook gebruik van een whitelisting systeem. Bij onze klanten hebben wij geologisch locaties in de firewall gezet zodat bijv vpn alleen nl de eu open staat. Is de klant buiten de eu dan zetten we dat land voor die tijd even open. Dit alles met ook mfa en eventueel alternatieve poorten.

Ja je hebt dan wel af en toe eens een klant die boos belt dat het niet werkt in thailand of hong kong, maar als je de reden uitlegt dan snappen de meeste het wel.

[SunnieNL]

dat lijstje kun je nog wel wat groter maken met cisco, citrix, microsoft en vele anderen.

[Ricco02]

Alhoewel de oplossingen die jij opnoemt uiteraard beter zijn. Is 2FA een prima oplossing en voorkom je dit soort dingen mee.

[skelleniels]

Tja zelfs VPN is niet ideaal. Al die homeworkers willen dan VPN op hun thuispc die ook voor privewerkzaamheden gebruikt worden. Die mogelijks gecompromitteerde pc zit dan los in het bedrijfsnetwerk. Beetje IT'er zorgt er dan wel voor dat enkel maar de nodige resources toegankelijk zijn via VPN, maar ik kom eerder tegen dat die VPN dan toegang heeft tot iedere pc in het netwerk.
Beter is dan RDP via RDGateway en daarbovenop nog eens 2FA en password lockout policy. Voeg dan nog eens geolocations op firewallniveau toe zodat deze enkel maar toegankelijk is vanuit de nodige landen en je hebt het al goed afgeschermd.

[Reactie gewijzigd door skelleniels op 22 november 2024 16:18]

[Kees]

Ik wilde eigenlijk niet een hele specifieke oplossing benoemen en ging daarom maar even voor de generieke term 'vpn', maar eigenlijk wil je een 'zero-trust' oplossing. Met een VPN maak je een client toch vaak onderdeel van het netwerk, inclusief toegang tot alle andere clients.

Even afgezien van de hype, met een 'zero-trust' oplossing kan zo'n client dan alleen bij services waar je hem toegang toe geeft en niet meteen bij het hele bedrijfsnetwerk inclusief alle computers die daaraan hangen. Stel zo'n client is dan besmet met een samba-worm, dan is het een stuk lastiger om andere apparaten te besmetten in het bedrijfsnetwerk als hij alleen maar toegang heeft tot zijn eigen RDP.

[skelleniels]

Ook met een VPN kan je toegang tot alle resources/services ontzeggen en enkel toegang geven tot hetgeen benodigd is via Firewall policies. Maar overal waar ik kom zie ik VPN/RDP combinatie die veilig wordt geacht, maar intussen heeft VPN toegang tot het volledige netwerk

[Kees]

Het is veiliger dan de RDP open aan het internet te hangen, dat dan weer wel

En de 'zero trust' software is natuurlijk meestal dat: een vpn met strenge firewall policies die de beheerder eenvoudig kan beheren. Al dan niet met ssl-terminatie/inspectie zodat je ook toegang tot specifieke domeinnamen kan regelen (bijvoorbeeld wel 'dashboard.bedrijf.nl' maar niet 'salarisadministratie.bedrijf.nl' dat via dezelfde proxy gaat).

[Reactie gewijzigd door Kees op 22 november 2024 16:33]

[paradoXical]

Ik connect via SSH en tunnel een RDP verbinding, werkt ook perfect

[BytePhantomX]

Ben toch benieuwd hoe jij dit praktisch zou doen. Is niet echt een standaard instelling in Windows of Active Directory.

Beter zou zijn om RDP niet internet facing te maken en er een VPN voor te zetten (met MFA).

[Reactie gewijzigd door BytePhantomX op 22 november 2024 08:48]

[Sebazzz]

Je kan met Duo two-factor security zetten op RDP.

[BytePhantomX]

Mijn vermoeden is dat bedrijven die RDP openzetten naar het internet, niet de bedrijven zijn die extra producten gaan aanschaffen als DUO en daar kosten voor willen maken. Kom DUO in de praktijk ook eigenlijk nooit tegen.

[vtsalf]

Bij ons zijn alle Windows servers met DUO uitgerust. Werkt erg goed moet ik zeggen. Licensering is op basis van gebruikers, niet servers. Dus als je met (stel) 3 man 500 servers beheert, betaal je maar voor 3 licenties.

Wij hebben geen RDP naar buiten open staan, maar wel elke Windows server met MFA ingesteld dus als extra layer of security.

[Reactie gewijzigd door vtsalf op 22 november 2024 09:29]

[willieverhoef]

Denk dat "bedrijven" de rdp openzetten dit vaak doen via gateway en azure ad.
Denk dat een admin die even een server openzet dit gewoon doet door een poortje open te gooien.

[batjes]

Je kan natuurlijk ook el cheapo gewoon via Intune/Entra afdwingen dat je voor elke handeling via SSO een MFA verplicht.

Dan kunnen ze wat makkelijker op het systeem inloggen, maar wil je bij data of op apps inloggen, krijg je een MFA request.

[Reactie gewijzigd door batjes op 23 november 2024 12:36]

[Skinnyice]

Haal die haakjes maar weg en maak MFA vetgedrukt. Hoevaak bedrijven niet hun firewall VPN gebruiken zonder MFA in te schakelen is stuitend. Ook geen enkele controls erop, iedere gebruiker mag de VPN gebruiken.

Updates, MFA, netwerksegmentatie en toegang tot servers alleen beschikbaar maken voor beheerders. Nu een hoop bedrijven overgaan naar M365 is de noodzaak voor een VPN ook al aan het dalen, tenzij je nog hybrid hebt uiteraard.

[KeesAlderlieste]

Bijvoorbeeld door ESET Secure Authentication te gebruiken.
https://www.eset.com/nl/z...multifactorauthenticatie/

[Lagonas]

Hoe wij dit doen is wellicht niet echt rechtstreeks aan het internet hangen, maar als wij in het uitzonderlijke geval iemand RDP access moeten geven dan kan dit enkel via Citrix waar dan weer MFA aan hangt.

[SunnieNL]

Er zijn zoveel problemen geweest met RDP waarbij je niet eens hoefde in te loggen, dat 2FA het probleem niet gaat oplossen. Ook uitgaande external RDP moet je blokkeren tenzij naar bekende hosts.

[lenwar]

Of je gooit 2FA op de RDP als je het nodig hebt. Probleem ook opgelost.

Totdat er een bug zit in de RDP-server, waardoor die tweede factor niet goed gecontroleerd wordt. Ofwel gewoon blokkeren, achter een VPN (of zo) en dan met MFA inloggen. Laagjes is het devies

[ASS-Ware]

Of je gooit 2FA op de RDP als je het nodig hebt. Probleem ook opgelost.

Heel verstandig met een slecht versleuteld protocol.

[Blokker_1999]

Outbound (S)FTP en SSH zijn tegenwoordig in vele bedrijven geblokkeerd net omdat het zo eenvoudig is om data weg te krijgen via die protocollen. Niet alleen voor bendes zoals dit, maar ook voor werknemers die niet willen voldoen aan het beleid van het bedrijf.

[BytePhantomX]

Ik ken er niet veel, en zeker niet op het niveau van MKB bedrijven. Grote enterprises misschien.

[lenwar]

Het ligt er ook aan wat voor apparatuur de MKB'er zich heel laten aansmeren. Er zijn best een boel firewalls/(transparante) proxies die dit standaard doen. (alles dicht, behalve wat je expliciet open zet)

[djmuggs]

Ik gebruik al sinds het bestaan van HTTPS de poort 443 voor inbound en outbound proxies voor VPN, (S)FTP enzo.
Tenzij een organisatie een firewall heeft die ook op de content die er over de poort gaat controleert of dat ook echt is wat men mag verwachten van HTTPS verkeer.

Dus al het andere dicht zetten betekend niet meteen dat het veiliger is.

RAT detectie zou een hoop oplossen denk ik, zowel intern als extern.

[bleep1912]

Het probleem is alleen dat die vele bedrijven niet SSH en SFTP blokkeren, maar poort 22/21 en dat is natuurlijk kinderlijk eenvoudig te omzeilen. Enige wat hier zou helpen is DPI.

[bzzzt]

Outbound (S)FTP en SSH zijn tegenwoordig in vele bedrijven geblokkeerd net omdat het zo eenvoudig is om data weg te krijgen via die protocollen.

Het enige wat daarmee bereikt wordt is dat malware data wegsluist via HTTPS of andere protocollen die wel open staan. Oftewel: 100% schijnveiligheid. Ondertussen wordt het gebruiken van degelijke op SSH gebaseerde oplossingen enorm gehinderd wat het bedrijf potentieel geld kost.
Hoewel een bedrijf natuurlijk eisen mag stellen zijn dit soort dingen wel mede oorzaak dat werknemers problemen hebben met het beleid.

[Alfa1970]

s(ftp) zou zowel in-, als outbound geblokkeerd moeten zijn.
Het zijn archaïsche protocollen die slechts zeer beperkte toepassingen hebben, die feitelijk allemaal intern en geïsoleerd zouden moeten zijn.
Het is hetzelfde met mensen die udp/tcp poort 53 open laten staan voor alles en iedereen in plaats van het te beperken tot uitsluitend of je eigen dns server of die van je isp. En als het om je eigen dns server gaat, moet je je afvragen of er enig voordeel aan is dat iedereen jouw dns server kan benaderen, of dat je die beter achter de vpn muur kan plaatsen. (Er zijn natuurlijk wel plenty valide redenen om een DNS publiek te hebben, maar in de meeste gevallen die ik tegen kom in de praktijk is dat volledig onnodig.)

[Reactie gewijzigd door Alfa1970 op 22 november 2024 09:18]

[bzzzt]

Het is hetzelfde met mensen die udp/tcp poort 53 open laten staan voor alles en iedereen in plaats van het te beperken tot uitsluitend of je eigen dns server of die van je isp.

En omdat bepaalde browsers er op staan hun eigen DNS te leveren omdat ze de lokale dienst niet vertrouwen hebben we nu dus DNS over HTTPS...

[lenwar]

omdat ze de lokale dienst niet vertrouwen

Het gaat verder dan de lokale 'dienst' niet vertrouwen. Niet-versleuteld verkeer kan heel makkelijk gespoofd worden door malware op het werkstation, switches, routers, enz. Je kunt de dienst dus wel vertrouwen, maar je kunt er niet op vertrouwen dat je überhaupt bij die dienst aan bent gekomen.

Door het verkeer vanaf de browser tot aan de DNS-server te versleutelen (en ondertekenen) is de hele keten beveiligd. (van client tot server). Dit is precies de reden dat het per definitie een goed idee is, om overal en nergens DoH/DoT/DoQ/Do? (kies je vergif). te gebruiken waar mogelijk. Ook intern. En als de client-software het zelf kan regelen zonder tussenkomst van het besturingssysteem, is dat dus alleen maar beter. Het enige lastige is, is dat je al die software ook nog moet configureren en beheren om de juiste DoH-servers te gebruiken. Nou is dit met browsers prima te doen, maar menig ander stukken software vraagt het nog steeds aan het besturingssysteem.

[bzzzt]

En als de client-software het zelf kan regelen zonder tussenkomst van het besturingssysteem, is dat dus alleen maar beter.

"Beter" is natuurlijk subjectief. Misschien wel meer 'resilient' tegen configuratiewijzigingen. Maar een browser of andere client die draait met rechten van de ingelogde gebruiker is meer vatbaar voor aanvallen dan een OS wat de nodige drempels opwerpt tegen eventueel misbruik.

[lenwar]

Die moest ik even laten inzinken, want je hebt hier op het eerste oog wel een goed punt.

Mijn visie:
De browser doet uiteindelijk altijd een 'DNS-verzoek' (even versimpeld gezegd). Of hij dat naar het besturingssysteem of een intern proces stuurt, is even om het even. Het feit dat hij het verzoek stuurt is het gegeven.

Stel dat er een fout in de browser zit (verkeerde addon/bug/enz, weet ik er allemaal stuk kan gaan. Ik weet niet hoe een browser van binnen werkt, maar we maken de aanname dat het verkeerd gaat,) dan gaat het sowieso scheef als dat niet gedetecteerd wordt door de browser. Want dan komt het sowieso niet goed uit bij de juiste bestemming. Want die bug kan tenslotte zowel het interne proces als het besturingssysteem omzeilen.

Het is in mijn beleving gewoon een schakel minder. De enige kwetsbare locatie is dan de browser zelf. Als je het door het besturingssysteem laat doen, dan kan de fout in zowel de browser als in/op het besturingssysteem zitten.

Zie jij dit anders?

[bzzzt]

Je hebt gelijk dat het niet uitmaakt als je browser gecompromitteerd is. Maar door alle functionaliteit in een enkele applicatie te concentreren wordt het wel lastiger om resources te delen met andere zaken op het OS en heb je meer code nodig dus meer kans op bugs.
Daarnaast mag je verwachten dat OS functionaliteit op de juiste manier is beschermd tegen lekken, boosaardige invoer etc. Door dit allemaal in de browser te doen maak je het aanvalsoppervlak groter en moet je naast je OS leverancier ook je browser leverancier vertrouwen.

[closefuture]

Het is hetzelfde met mensen die udp/tcp poort 53 open laten staan voor alles en iedereen in plaats van het te beperken tot uitsluitend of je eigen dns server of die van je isp.

Proberen af te dwingen dat mensen jouw DNS server gebruiken is alang een verloren zaak met de introductie van DOH (DNS over HTTP). DOH word ondersteund in Chrome, Firefox, Android, etc. Lees: Alles wat er toe doet.

[Alfa1970]

Het maakt niet hoe je de verbinding met de DNS server opzet.
Of dat nu traditioneel DNS op TCP/UDP 53 is, of DOH over 443 of DOT over 853, _iedereen_ kan een verbinding opzetten met die DNS server en informatie opvragen.
Dat het verkeer wordt versleutelt tussen twee eindpunten betekend niet dat iets wezenlijks verandert aan die DNS server en de gegevens die het prijsgeeft.

[closefuture]

Ik heb het over outbound DNS traffic. Deze zin impliceert namelijk dat je het over outbound DNS traffic hebt:

Het is hetzelfde met mensen die udp/tcp poort 53 open laten staan voor alles en iedereen in plaats van het te beperken tot uitsluitend of je eigen dns server of die van je isp.

Deze hele zin maakt eigenlijk enkel maar sense voor outbound traffic. Als het om inbound traffic gaat zou je ISP niet eens toegang tot je DNS hoeven. Ik zou geen scenario kunnen bedenken waarbij je ISP toegang tot je DNS nodig heeft als dat niet is om je DNS data te publiceren.

[Alfa1970]

De DNS van je ISP heeft toegang nodig als je wilt dat jouw web server bekend is op het internet.
Je bekijkt het verhaal vanuit het oogpunt van een normale gebruiker zonder DNS server.
En dat is prima.
Zelfs in dat oogpunt gaat het verhaal op.
Uitgaand DNS verkeer dient beperkt te worden tot de DNS van je ISP.
Theoretisch gezien kan je bij DNS over HTTPS niet meer zien of het DNS verkeer is of web verkeer.
Dus je kan het niet meer controleren. Op zich is dat een slechte ontwikkeling als veiligheid je prioriteit is. Voor privacy helpt het je verder niks. Het eerste request van een web browser voor een HTTPS site gaat in plain text.

[Reactie gewijzigd door Alfa1970 op 24 november 2024 08:08]

[closefuture]

De DNS van je ISP heeft toegang nodig als je wilt dat jouw web server bekend is op het internet.

De DNS van je ISP heeft geen toegang nodig tot jouw DNS server als je een webpagina host. Bijna niemand zal zijn/haar DNS publiek beschikbaar maken. Als je voor je eigen domein een DNS server zelf wilt runnen dan moet je inderdaad je DNS server publiek beschikbaar maken en dan glue records instellen bij de DNS server van je upstream provider, maar dat doet echt niemand. Iedereen gebruikt simpelweg een externe DNS server zoals TransIP, Hetzner, etc.

[Alfa1970]

Idd dat is het hele technische verhaal compleet.
Ik heb mijn eigen DNS servers, maar zoals je zegt kun je ook prima een externe DNS provider gebruiken.

[florisjan]

Is rdp zo kwetsbaar dan?

[Botmeister]

nieuws: Microsoft waarschuwt voor spearphishingcampagne via rdp-bestand

[Sissors]

Wie zegt dat het niet beveiligd is? Maar als ze de juiste credentials hebben gestolen kunnen ze daar omheen werken natuurlijk.

[HKLM_]

Zoek voor de grap maar eens op bijvoorbeeld Shodan naar systemen welke direct op 3389 te benaderen zijn voor de hele wereld.

[useruser]

Zoiets als poort 3306 is helemaal schrikbarend

[al__in__gebruik]

diegene die zegt dat ze via RDP binnen geraken en via FTP data stelen

[The Zep Man]

Wie zegt dat het niet beveiligd is?

Als een noemenswaardig bedrijf zet je nooit een protocol als RDP direct open richting het internet. Hetzelfde met bijvoorbeeld SSH. Het vergroot je aanvalsoppervlak door nog te vinden kwetsbaarheden in implementaties van deze protocollen. Updates beschermen je niet tegen een 0-day.

Het is beter om externe ontsluiting te beperken via VPN. Ja, in VPN-software kunnen ook kwetsbaarheden zitten. Er zijn echter VPN-implementaties die qua code een stuk kleiner, minder complex en meer gericht zijn op ontsluiting op het internet (en daar ook naar worden getoetst). Implementaties van RDP en SSH zijn een stuk complexer en daarmee gevoeliger (het eerste is veelal onderdeel van het besturingssysteem, het tweede doet zoveel meer dan enkel een beveiligde verbinding opzetten).

Verder zijn zaken zoals (platform)authenticatie beter centraal te regelen d.m.v. VPN.

[Reactie gewijzigd door The Zep Man op 22 november 2024 09:14]

[kimborntobewild]

Echt bizar hoeveel beunhazen er nog in de IT werken en RDP en FTP gewoon open hebben en niet beveiligd hebben.

Beveiliging is complexer / veelomvattender dan jij denkt.
Als bedrijven zouden wachten met het opbouwen van hun bedrijf (incl. de aanwezigheid op het internet / remote working) totdat ze 99,9999% zeker weten dat hun netwerk 99,9999% veilig is, maar nog wel gebruiksvriendelijk is, zouden we nu niet 2 miljard websites hebben. Misschien maar 2.000.

Wat mij betreft vraag je er dan ook wel een beetje om hoor.

Dat is onjuist.

[HKLM_]

Beveiliging is complexer / veelomvattender dan jij denkt.

Hier doe je toch een verkeerde aanname

Bedrijven hoeven niet te wachten, security by design is het start punt. Er is echt nul reden om RDP open te zetten.

[Reactie gewijzigd door HKLM_ op 22 november 2024 09:17]

[Pinkys Brain]

Het gebruiksvriendelijke aspect van IT is gewoonte.

Als de standaard voor elk groot bedrijf was "VPN als eerste linie met bedrijfs laptop/mobiel" dan is alles daar op ingericht, van opleidingen tot software, tot hardware en kunnen kleine bedrijven daar zo in mee. Dat had 30 jaar terug al zo moeten zijn.

Als fabrieken hun Lock Out Tag Out zouden regelen zoals IT beveiliging doet, zouden overal betonscharen hangen met een bordje "doe maar wat".

[Morress]

Als je thuis de deur open laat staan ben je inderdaad een pannenkoek,maar soms vergeet je het
Echter, betekent het niet dat iemand zomaar naar binnen mag lopen.

[svenk91]

Je bent dan idd een pannenkoek, en het zijn enkel en alleen de inbrekers die crimineel bezig zijn en er iets niets verzachtends aan die open deur. Maar je verzekering kan er wel wat van vinden, die eisen toch wel skg 2 of skg 3 sloten die ook echt op slot waren voor ze gaan uitkeren bij inbraak.

Je zou denken dat bij bedrijven die digitaal met bijv. persoonsgegevens werken (oftewel, elk bedrijf zo’n beetje, al is het alleen maar van de eigen werknemers) toch wel iets van een audit verplicht zou zijn. Dat kan zelfs met zelf-certificatie voor zzp’ers/eenmanszaken als ze een totaal oplossing gebruiken voor klantdata die al gecertificeerd is.

Je boekhouding door een accountant laten nakijken is gemeengoed, voor midden en groot bedrijf nu ook je klimaat en milieu impact, maar je (digitale) beveiliging helaas nog niet.

[The Zep Man]

Je bent dan idd een pannenkoek, en het zijn enkel en alleen de inbrekers die crimineel bezig zijn en er iets niets verzachtends aan die open deur.

Het zijn dan geen inbrekers, maar insluipers. Je kan immers niet spreken van inbraak.

[Gallo_Claudio]

En wat denk je van alle firewalls waarvan de management interfaces opstenstaan naar het internet? Je zou bijna een blacklist van dit soort mensen willen gaan bijhouden...

[HKLM_]

Ja firewalls, backup-systemen etc allemaal wagenwijd open. Is lekker makkelijk voor thuiswerken he

[Gallo_Claudio]

Hackers werken blijkbaar ook thuis

[Bongoarnhem]

Je moet eens weten voor hoeveel kleinere bedrijfjes IT bijzaak is. Ik kwam ergens te werken waar ze met zeer vertrouwelijke data werkte.

Je kon dit benaderen via de “netwerkschijf”.
Dit bleek een Synology nas te zijn die al jaren geen updates had gehad en iedereen gebruikte admin als toegangscredentials.

Bij dit soort bedrijfjes is It een lastige “kostenpost”.

[BCC]

It is een ondersteunende dienst voor de business.

[bzzzt]

Tsja, als je een bedrijfsbus aanschaft is dat ook 'ondersteunend'. Toch moet die APK hebben en de chauffeur een rijbewijs...

[BCC]

Lease

[Aeternum]

Nee is het niet, het zijn kosten die in de kostprijs van het product/dienst dat ze leveren thuis horen. Het is wel lastig omdat het geen core business is dus moeten ze iemand voor x tijd in de maand inhuren of uit besteden.

[Reactie gewijzigd door Aeternum op 22 november 2024 08:39]

[Triblade_8472]

Met ftp gaat het om exfiltratie als ik dit zo lees.

En dat komt doordat men Firewall ing van "binnen naar buiten' moeilijk en lastig vindt. Daar staat veel te vaak alles gewoon open.

Overigens vindt ik het super stoer van KPN dat ze een tijdje geleden hun modems hebben geüpdatet met óók het dichtzetten van "binnen naar buiten" in de firewall!
(Alleen de communicatie hierover liet flink te wensen over waardoor vele zaken, zoals Chinese zonnepanelen geen ata meer konden versturen)

Let wel, je moet allen tijde eigenlijk ook applicatie-detectie toepassen. Als de slechterikken een ftp server op poort 443 hebben draait schiet het nog steeds niet op natuurlijk.

[pOZOR jED]

FTP... anno 2024
En RDP, dan hang je dus windows computers 1:! aan het internet? beunhaas is nog zacht uitgedrukt

Maar ondanks dat, is het binnendringen van iemands pc natuurlijk nooit goed te praten, zelfs als het een enorme prutser is.

[BytePhantomX]

FTP is echt nog heel erg gemeengoed bij veel organisaties. Recent nog een casus waarbij de overheid vraagt om data en je die verplicht moet aanleveren op straffe van een boete. Kan via een API, maar dat moet gebouwd worden en is niet op tijd af, dan is de andere optie: aanleveren via (s)ftp.

Zie dit nog zoveel voor datauitwisseling, lastig om afscheid van te nemen.

Zoals ook al eerder gezegd, dit is uitgaande FTP. Genoeg organisatie die uitgaand verkeer blokkeren, maar deze lage poort nummers (21 & 22) vaak niet. Zeker ook omdat SFTP een overlap heeft met SSH.

[pOZOR jED]

FTP, FTPS en SFTP zijn wezenlijke verschillen.
FTP is unencrypted over het net, anno 2024 absoluut not done! als het FTPS is, kan, maar geen voorkeur.

SFTP is een compleet ander protocol, wat encrypted is en op basis van SSH keys zeer veilig kan zijn, dat is dus echt een ander verhaal.

[the_stickie]

FTPS is versleuteld en beveiligd met PKI/certificaten - net zo veilig als https...

[Skinnyice]

FTP wordt inderdaad nog best veel gebruikt, maar tools als Rclone zijn ook zeer populair bij dit soort groepen. Die gaat gewoon over 443, dus dan zul je extra ogen op je netwerk moeten hebben die grote hoeveelheden data naar buiten ziet gaan.

[kamerplant]

Ja mee eens. Maar ik ben ook kritisch op Microsoft die deze onveilige software nog steeds levert, en daarmee faciliteert.

[Triblade_8472]

Hoezo onveilige software? Lijkt mij logisch dat ze een ingang meeleveren anders dan het console toch? En rdp staat standaard uit ook!

Wat ik wél bizar vindt is dat mensen dit toegankelijk maken vanaf het internet, maar daar kan Microsoft toch weinig aan doen?

[kamerplant]

Men zou bijvoorbeeld inloggen met je Microsoft account met 2FA kunnen verplichten, om maar wat te noemen.

[HKLM_]

Hoe zie je dat voorje op een on-prem omgeving? Als je VM’s in Azure draaien bijvoorbeeld gebruik je Azure Bastion oid en laat je het ook wel uit je hoofd om RDP open te zetten in je NSG… maar schijnbaar denken veel beheerders daar anders over

[ASS-Ware]

Ja mee eens. Maar ik ben ook kritisch op Microsoft die deze onveilige software nog steeds levert, en daarmee faciliteert.

Voor intern gebruik of extern via RDGW is er niets mis mee.

[jvdmeer]

Mogelijk heb je het nieuws laatste maanden niet gevolgd, maar het gaat hier om het opbouwen van een RDP-verbinding met een machine van de aanvaller. Dus de eindgebruiker neemt de machine van de aanvaller over.
Hierbij wordt dan het klembord en de lokale schijven gedeeld, waardoor de aanvaller via de verbinding daarbij kan.
Dit hoeft dus ook niet over poort 3389 te gaan, maar kan over elke poort gaan.
Al deze opties (lokale resources en poort) worden in een .rdp-bestandje aangegeven.
Wat er hier dus vooral fout gaat, is dat eindgebruikers .rdp-bestanden per mail kunnen ontvangen en openen.

[pOZOR jED]

Ik volg het nieuws over dit soort zaken (rdp) niet zo nee, voor mij niet super relevant.
RDP is voor mij een ver van mijn bed show.

[vanaalten]

Beetje mee eens, maar het is ook ‘victim blaming’. Als je beveiliging niet op orde is, heeft nog steeds niemand het recht je data te stelen.

[The Zep Man]

Beetje mee eens, maar het is ook ‘victim blaming’.

Een misvatting is dat een slachtoffer niet ook een dader kan zijn. Dat zie je bijvoorbeeld in huiselijk geweld, waar slachtoffers van (vroeger) geweld vaak daders worden. Niemand heeft het recht om jou iets aan te doen, maar je hebt de plicht om een ander niets aan te doen.

Hetzelfde met informatiebeveiliging. Niemand heeft het recht om jou iets aan te doen, maar je hebt de plicht om gegevens van anderen zorgvuldig te beveiligen. Dus ja, je moet je informatiebeveiliging op orde hebben. Al doe je het niet voor jezelf, dan doe je het voor de gegevens van anderen die je verwerkt. Elk beetje bedrijf verwerkt persoonsgegevens van anderen (zoals eigen werknemers, waar de werkgever ook verplichtingen aan heeft).

[Reactie gewijzigd door The Zep Man op 22 november 2024 09:01]

[vanaalten]

Ja, als een bedrijf jouw gegevens niet goed beveiligd, dan mag jij terecht boos zijn op die ondernemer. En wat mij betreft mag een ondernemer juridisch keihard aangepakt worden voor lakse beveiliging. Maar wel op een juridische manier. Het bestraffen van slechte beveiliging door een ransomware-bende is niet correct.

Daarnaast: dit artikel gaat niet specifiek over persoonsgegevens - het gaat over data algemeen, die van bedrijven gestolen wordt. Dat kan dus ook niet-persoonsgegevens zijn, bedrijfsdata. En dan kom ik toch op 'victim blaming': dat een bedrijf z'n eigen data niet goed beschermd geeft niemand het recht de data te stelen.

[The Zep Man]

Daarnaast: dit artikel gaat niet specifiek over persoonsgegevens - het gaat over data algemeen, die van bedrijven gestolen wordt.

Een banaan is fruit. Fruit hoeft geen banaan te zijn.

Data als overkoepelende term hoeft geen eigendom te zijn van een bedrijf zelf, en kan persoonsgegevens bevatten. Gekeken naar de MO van aanvalsgroepen (zoals het leegzuigen van adresboeken) kan snel gesproken worden van het stelen van persoonsgegevens.

Verder heb je als ondernemer ook verantwoording over hoe je omgaat met je eigen organisatie, en kan je bij laakbaar gedrag ook persoonlijk aansprakelijk gesteld worden.

[Reactie gewijzigd door The Zep Man op 22 november 2024 09:39]

[vanaalten]

Ik ben het op zich wel eens met dat de ondernemer een verantwoordelijkheid heeft, aangepakt mag worden.

Maar, mijn eerste reactie kwam op deze uitspraak: "Wat mij betreft vraag je er dan ook wel een beetje om hoor.". En dat vind ik te ver gaan. Je kan niet een misdrijf (stelen van bedrijfsdata) goedpraten met "je vroeg er om".

Dat komt overeen met een verkrachting goedpraten omdat iemand aantrekkelijk gekleed is - gewoon niet goed te praten, je hebt van iemand af te blijven. Of de diefstal van een fiets goedpraten als 'ie niet op slot staat - niet goed te praten, je hebt van andermans spullen af te blijven.

Is het verstandig om aantrekkelijk gekleed alleen door een donker park te wandelen? Nee, en in een ideale wereld moet dat gewoon kunnen. Is het verstandig een fiets niet op slot bij het station achter te laten? Nee, en in een ideale wereld zou het geen probleem zijn. Maar beide onverstandige acties vragen niet om een misdrijf.

Net zo goed als dat een ondernemer die naief, onverstandig met bedrijfsdata omgaat (wat, wat mij betreft, hard aangepakt mag worden!) niet om datadiefstal vraagt. Met victim blaming legitimeer je (deels) de misdadiger.

[The Zep Man]

Maar, mijn eerste reactie kwam op deze uitspraak: "Wat mij betreft vraag je er dan ook wel een beetje om hoor.". En dat vind ik te ver gaan. Je kan niet een misdrijf (stelen van bedrijfsdata) goedpraten met "je vroeg er om".

"Je vroeg erom" wordt in dit geval niet gebruikt om het misdrijf goed te praten, maar om de ondernemer te wijzen op laakbaar gedrag. Zet een bord neer in je tuin met "ik ben rijk, niet thuis, de deur zit niet op slot en het alarm staat uit", en degene die daarop acteert is nog steeds fout bezig. Toch heb je ook een stuk eigen verantwoording in het goed beveiligen van je zaken.

Juist door te schermen met victim blaming waar het niet gepast is wordt de verantwoording van de ondernemer ondergesneeuwd.

Dat komt overeen met een verkrachting goedpraten omdat iemand aantrekkelijk gekleed is - gewoon niet goed te praten, je hebt van iemand af te blijven. Of de diefstal van een fiets goedpraten als 'ie niet op slot staat - niet goed te praten, je hebt van andermans spullen af te blijven.

Je vergelijkingen gaan niet op. Er is niets mis met aantrekkelijk gekleed zijn of je fiets niet op slot zetten. Qua wet- en regelgeving doe je niets fout in die situaties. Er is wel iets mis met je informatiebeveiliging niet op orde hebben. Ook zonder dat ze gehackt zijn worden organisaties in sectoren met toezicht op slechte digitale hygiene afgerekend. Dat is terecht, en zou breder moeten zijn dan enkel die sectoren. Wel of niet gehackt zijn maakt je niet meer of minder laakbaar als je je zaken niet op orde hebt. Het enige dat een hack doet is het gedrag en de gevolgen ervan openbaar maken.

[Reactie gewijzigd door The Zep Man op 22 november 2024 18:26]

[L-project]

Maar wanneer is het voldoende beveiligt? Als er een slot op zit? Wanneer de data alleen air-gapped beschikbaar is en elke aanvraag uitgeprint doorgegeven wordt om dan weer ingescand opgestuurd te worden?

We weten hier bijvoorbeeld niet eens wat er gebeurt is. Mogelijk een menselijke fout, of domme beveiliging. Of gewoon een briljante inbraak samen met social engineering waar niets praktisch tegen te doen is.

Ook beveiliging heeft een grens waarbij het 'goed genoeg' is en er ook gewerkt moet kunnen worden. En dan is de betreffende ondernemer wat mij betreft niet fout (maar wel aansprakelijk).

[The Zep Man]

Maar wanneer is het voldoende beveiligt? niet fout (maar wel aansprakelijk).

Wanneer je risicoanalyses maakt, alle relevante industriebrede aanbevelingen hebt geïmplementeerd, geen onveilige uitzonderingen hebt, je de beveiliging onafhankelijk laat testen, en deze cyclus blijft herhalen.

[Reactie gewijzigd door The Zep Man op 23 november 2024 01:13]

[Alfa1970]

Sowieso de primaire regel zou moeten zijn dat uitsluitend en alleen datgene online beschikbaar is dat absoluut niet anders dan online uitgewisseld kan worden.
Voor de rest zou data _nooit_ beschikbaar moeten zijn via het internet.
Als het makkelijk is om te delen, dan is het makkelijk om te stelen.

Hoe kan het bestaan dat er (bedrijfs-.) "geheimen" beschikbaar zijn via het internet?
Je moet je als ondernemer afvragen of zoiets überhaupt op een computer zou moeten staan, laat staan dat die computer benaderbaar is via het Internet. En, zelfs met een air-gap is het niet onmogelijk om aan de gegevens te komen als het op een computer staat.

[nst6ldr]

Ja, als een bedrijf jouw gegevens niet goed beveiligd, dan mag jij terecht boos zijn op die ondernemer. En wat mij betreft mag een ondernemer juridisch keihard aangepakt worden voor lakse beveiliging. Maar wel op een juridische manier. Het bestraffen van slechte beveiliging door een ransomware-bende is niet correct.

Een ransomware bende steelt niet om te straffen maar omdat het gelegenheid ziet te verdienen op laconiek ondernemen. Niemand stelt dat ze 'mogen' stelen, maar dat het gebeurd is een gegeven en door daar niet op voor te bereiden is toch echt een gebrek van de ondernemer. Zo'n aanval is niet uniek.

Daarnaast: dit artikel gaat niet specifiek over persoonsgegevens - het gaat over data algemeen, die van bedrijven gestolen wordt. Dat kan dus ook niet-persoonsgegevens zijn, bedrijfsdata. En dan kom ik toch op 'victim blaming': dat een bedrijf z'n eigen data niet goed beschermd geeft niemand het recht de data te stelen.

Bedrijfsdata is nog steeds een belang van de ondernemer zelf. Hij nam bewust het risico.

[magician2000]

Dat is wel erg simplistisch en denigrerend gesteld. Je kunt dan net zo goed stellen dat de soft- en hardwaremakers maar eens beter hun best moeten doen om de boel te beveiligen en geen fouten meer in hun spullen te hebben. Of dat de hele IT (nog steeds) veel complexer is dan noodzakelijk.

Waarom staan RDP en FTP standaard niet gewoon uit en/of zijn ze zwaar beveiligd? Ook dat kun je je afvragen.

[moeilijkenaam]

Als ik mag filosoferen, kan ik mij voorbeelden dat het niet verleutelen ervoor zorgt dat er geen pauze in werkzaamheden bij het slachtoffer is, misschien geen bekendmaking daardoor geforceerd wordt, waardoor bedrijven sneller stilletjes het bedrag voor de afpersing betalen zonder reputatieschade?

[TijsZonderH]

Ik heb vooralsnog nooit gehoord dat dat een reden zou zijn, maar detectie speelt wel mee. Nu zie je al dat bendes heel lang in systemen blijven zitten om alles klaar te zetten voor een aanval om dan op één moment toe te slaan. Mijn vermoeden is dat detectie tegenwoordig ook wel sneller is dan een paar jaar geleden en dat dat mee kan spelen.

[BytePhantomX]

Als ik kijk naar de advisory, is de modus operandi nog steeds hetzelfde en zou je dit met detectie vrij goed moeten kunnen zien.

Wat je wel ziet is dat veel meer bedrijven hun backup op order hebben. En dus na een aanval makkelijk terug kunnen komen. En geen idee wat voor psychologische keuzes er dan misschien spelen bij bedrijven. Als je al zo genaaid ben door ransomware maar wel terug hebt kunnen komen, dan ben je misschien minder genegen om te betalen voor het datalek. Terwijl een datalek heel klein gehouden kan worden, betalen en je bent er vanaf. Niemand hoeft er ooit iets van te weten.

[TijsZonderH]

Vergeet ook niet dat het voor veel bedrijven ook een financiële afweging is, zelfs als je back-ups hebt. Als je kijkt naar de tijd en kosten voor het terugzetten van back-ups, kan dat soms duurder uitvallen dan betalen.

En verzekeringen spelen hier vaak ook een rol in. Als die (deels) het losgeld uitkeren, denk je ook al sneller aan betalen. Dat helpt ook bij die kosten-batenafweging.

[BCC]

Bij Randsome ware zal het bedrijf oook veel geld uit moeten geven aan een derde partij om alles weer recht te zetten - dat geld kunnen ze nu betalen aan de bende.

[oef!]

Het rechtzetten van de it is een heel stuk goedkoper dan het betalen van ransom. Daarna maak je alsnog kosten om je infra geanalyseerd en gepatched te krijgen.

Ransom gaat je tussen de 50k en miljoenen kosten, hoe meer omzet, hoe meer ransom. Heropbouw van je it en security consultancy kost je waarschijnlijk tienduizenden.

[BleghBlarg]

Als je denkt aan het voordeel voor bendes lijkt me dat vooral dat de schietschijf op hun rug vooral wat kleiner wordt. Als je grote partijen helemaal plat legt is er veel economische reden(en veel media aandacht ja) om die bende snel onderuit te halen. Alleen afpersing om anders je data te verkopen zal inderdaad ook stiller afgehandeld worden kan ik me voorstellen.

[FairPCsPlease]

Maar als bendes de data alleen maar stelen, waar 'verdienen' ze dan aan ('verdienen' is een verkeerd woord, ze verdienen het absoluut niet, maar ik weet even niet hoe ik het anders moet zeggen). Hoe zetten die bendes de gestolen data dan om in geld, als ze geen losgeld eisen?

[TijsZonderH]

Afpersing. "Betaal ons of we maken deze bestanden openbaar"

[Arnoud Engelfriet]

En verkopen aan geïnteresseerde concurrenten en/of overheden?

[TijsZonderH]

Ik ken eigenlijk geen voorbeelden waarbij dat gebeurt, maar misschien onder de radar wel. Publiceren op het darkweb lijkt wel de normale modus operandi.

[biomechanical]

Heb weleens met een "expert" gepraat over de beveiliging van zijn zoons bedrijfje (welke hij dus "regelde").
Hij had namelijk een goede oplossing gevonden om een netwerk probleem op te lossen en wilde dit aan mij vertellen.
Hij had gewoon de hele ip range in dmz gezet.
En nadat ik hem uitlegde wat dmz deed, geloofde hij mij niet.
Nog geen week zag ik hem weer en daar stond hij, met tranen in zijn ogen, te vertellen hoe zijn zoon's bedrijf gehacked was en dat zijn zoon alles kwijt was geraakt (zijn zoon had een klein bedrijfje thuis en dus waren ook alle computers die niets met zijn bedrijfje gehacked en dus ook zijn persoonlijke rekening alsmede die van zijn vrouw en kinderen waren geplunderd).
En het ergste was dat hij niet nog steeds niet snapte wat hij fout gedaan had.

Sommige mensen!

[dwizzy]

Mooi voor mijn dreigingsmodel, hoef ik dus niet meer backups te maken!

[Ray_]

Doe eens niet zo.
'Nooit' is een bewering die je niet hard kunt maken. Je kunt de kans wel aanzienlijk verkleinen door geen RDP lijntjes zomaar uit je bedrijfsnetwerk te hangen. Ik denk dat dit meestal de gevallen zijn waarbij de buurjongen 'die wel handig is met computers' een netwerkje in elkaar mocht zetten.

[jvdmeer]

De RDP-lijntjes hangen niet naar buiten. De aanvaller heeft juist allerlei RDP-lijntjes naar buiten hangen en verleidt de slachtoffers om hun eigen computers over te nemen. Als de slachtoffers dat doen, dan worden de lokale resources zoals schijven en klembord gedeeld met de aanvaller.
En om het moeilijk te maken, gebruikt de aanvaller natuurlijk niet poort 3389 daarvoor, maar gewoon een reguliere poort als 443.

[BytePhantomX]

Ja, dat is een hack methode waar onlangs voor gewaarschuwd is, bij mijn weten overigens niet als modus operandie van ransomware aanvallers, maar van een statelijke actor.

Verder vermoed ik dat je de advisory niet gelezen hebt, daar gaat het echt over inkomende RDP verbindingen: https://www.cyber.gov.au/...bianlian-ransomware-group

[BytePhantomX]

Nee zeker niet, maar je kunt wel leren van dit soort voorbeelden. Er zijn genoeg openbare voorbeelden van hoe ransomwar aanvallers te werk gaan. Zoals deze, maar ook adviezen van de CISA of een website als deze: https://thedfirreport.com/

Als je naar al die adviezen kijkt zie je veel zaken terugkomen:
- internet facing assets die kwetsbaar zijn (firewall, rdp etc)
- gebruik van tools als rclone, netwerk scanners en websites als mega.io
- gebruik van psexec
- het scannen naar domain admins, toevoegen van domain admins

Daar kun je wel van leren en je eigen infrastructuur op aanpassen en op detecteren. Met dit risico verwacht je wel dat bedrijf zichzelf informeren en maatregelen nemen om de kans te verkleinen. Het is naar mijn idee allemaal geen rocket science meer.