Bronnen bevestigen WastedLocker-ransomware en vraag om losgeld bij Garmin

Alhoewel Garmin het nog niet heeft bevestigd, stapelt het bewijs zich op dat het bedrijf is getroffen door een ransomware-aanval, waarbij de hackers om losgeld hebben gevraagd. De it-afdeling binnen Garmin zou tevergeefs hebben geprobeerd om het netwerk af te sluiten.

Garmin zelf spreekt vooralsnog van een storing, maar bronnen bevestigen aan BleepingComputer dat er sprake is van een ransomware-aanval, zoals eerder al werd vermoed. Daarbij werd ook bewijs geleverd dat het gaat om de WastedLocker-ransomware.

Volgens de bronnen die BleepingComputer heeft gesproken ontdekte de it-afdeling van Garmin de aanval toen zij op donderdagochtend hun computer aanzetten, waarna werd geprobeerd om zoveel mogelijk systemen uit te zetten om te voorkomen dat die werden besmet. Ook computers van werknemers werden uitgezet, al slaagde de it-afdeling hier niet volledig in, waardoor de ransomware toch het netwerk van Garmin in zijn greep kreeg.

Het uitzetten van systemen heeft ervoor gezorgd dat bepaalde diensten, zoals Garmin Connect niet meer functioneren, iets dat gebruikers op donderdag merkten. Garmin gaf toen al te kennen dat het gaat om een storing, iets dat het nu nog altijd volhoudt; het bedrijf heeft nog altijd niet bevestigd dat het kampt met een ransomware-aanval.

Volgens BleepingComputer willen de hackers, die hun aanval naar verluidt in Taiwan begonnen, een bedrag van 10 miljoen dollar ontvangen om de vergrendelde bestanden weer te ontsleutelen. Wie er achter de hack zit, is nog onduidelijk.

Reacties (226)

[mosesk]

Als de hackers net zoals in Maastricht al geruime tijd binnen waren, kunnen ze ook de updates van de Garmin Connect-app, op Android, IOS en Windows geïnfecteerd hebben, waardoor er mogelijk miljoenen devices besmet zijn. Of zie ik dat (hopelijk) verkeerd?

[Oon]

Ligt er geheel aan hoe ver/diep ze zitten en hoe Garmin dit proces laat verlopen. Als ze een extern build-systeem gebruiken dat bestanden verifieert zonder uitvoerrechten dan is dat risico al een stuk kleiner, zo niet dan zou dat inderdaad kunnen.

[akooijman]

Breng ze maar niet op ideeën.

[telenut]

Alle ransomware die ik tot nu toe tegen kwam deed encryptie van bestanden (via een Windows PC).
Hoe komt het dat een dienst daar dan zo veel last van heeft? Vermoedelijk werkt alles toch met servers en databases... Of zijn er nu ook al encryptie virussen die een database infecteren? En vooral... hoe kunnen die dat ongemerkt doen dan...

Ik vrees dat de slechte publiciteit hen meer zal kosten dan de eis...

[teacup]

Uiteindelijk zijn die databases ook gewoon bestanden, database, index en cache bestanden. De job die de extenties aan de bestanden toevoegt zal het een worst wezen wat het doel van een bestand is. Wel zijn die databases voortdurend in gebruik zodat zo'n bestand niet zomaar is aan te passen. Om dit te counteren eigenen die jobs zich dan ook behoorlijk absolute rechten toe om veel te kunnen.

Mogelijk dat een ander besturingssysteem dan Windows voor de server omgeving (Linux i.p.v. Windows server) nog een verschil kan maken. Echter op het moment dat deze servers open staan naar windows systemen dan bouw je daarmee al weer een kwetsbaarheid in.

Wel of niet betalen is mogelijk het dilemma waar Garmin zich nu voor gesteld ziet, nu we enkele dagen verder zijn en inmiddels wel duidelijk zal zijn geworden welke opties voor het bedrijf resteren.

[Reactie gewijzigd door teacup op 23 juli 2024 05:09]

[mphilipp]

Uiteindelijk zijn die databases ook gewoon bestanden, database, index en cache bestanden

Ja, heel simpel gezegd wel, maar als je met een echte database werkt, wil ik je nog datafiles zien veranderen. Ik (als Oracle specialist) wil je wel een actieve database zien encrypten. Dat lukt je niet met een of ander programma op Windows. Je zult echt de userid van de Oracle user (owner van de bestanden) moeten zijn om iets te kunnen doen.
Misschien dat het met een of andere Mickey Mouse database lukt, maar ik vind het maar een vreemd scenario. Je gaat dan haast denken dat Garmin alles op een simpele database heeft staan en dat ze op die server ook gewoon werken zodat allerlei malware die jij doorkrijgt meteen op die server staat.

Mij is sowieso nooit duidelijk geworden hoe dat werkt met die ransomware. Op mijn laptop kan ik het mij voorstellen. Maar propageert die malware zich automatisch over je netwerk, zoekt database servers op en encrypt die dingen via de user van de eerste besmette pc? Dat zie ik echt niet zomaar gebeuren. Je moet toch aardig wat hordes nemen op die manier. Bij een beetje robuuste infrastructuur zouden de database servers nooit exposed moeten zijn naar internet en alle applicatie servers sowieso goed afgeschermd moeten zijn. Zoiets kun je alleen hacken als je al een poosje toegang hebt tot de systemen en handmatig van alles uitzoekt zodat je ook handmatig de malware installeert. Het kan naar mijn idee nooit een simple pakketje zijn dat via een mailtje klik-klak-klaar en de boel staat op slot.
Maar zelfs als dat zo is gegaan, spreekt het niet voor Garmin en hun security. Dat iemand inbreekt is één ding, maar dat ie zeg maar een paar dagen ongemerkt kan rondkijken en zo van alles te weten komt om vervolgens malware te installeren vind ik zeer opmerkelijk. Dan heb je geen effectief security beleid.

[supersnathan94]

Je brengt het nu alsof Oracle DB de heilige graal is mbt data security, maar ook daar zijn al jaren geleden exploits gevonden om privelege escalation naar SYS user voor elkaar te krijgen:

http://obtruse.syfrtext.c...e-escalation-via.html?m=1

Maar propageert die malware zich automatisch over je netwerk, zoekt database servers op en encrypt die dingen via de user van de eerste besmette pc? Dat zie ik echt niet zomaar gebeuren. Je moet toch aardig wat hordes nemen op die manier. Bij een beetje robuuste infrastructuur zouden de database servers nooit exposed moeten zijn naar internet en alle applicatie servers sowieso goed afgeschermd moeten zijn.

En daar zit dus het probleem. Dit is exact waarop die malware is gebouwd. Iedereen heeft uiteraard meerdere lagen in z’n infra zitten (les 1 van security). Probleem is alleen dat er altijd wel ergens een attackvector gevonden kan worden. Al is het maar het systeem van de DBA-er met remote access over VPN. Of een systeem met UCP bundle, SSH access naar server in datacentrum of, zoals bij BlueEternal, een legacy protocol wat een foutje bevat.

Zoiets kun je alleen hacken als je al een poosje toegang hebt tot de systemen en handmatig van alles uitzoekt zodat je ook handmatig de malware installeert.

Nee dus. Dit is vrij geavanceerd spul wat super amateuristisch overkomt door het TXT bestandje, maar onderwater tientallen zo niet honderden explouts kan gebruiken om allerlei mogelijke systemen te infecteren. Dit zijn vaak zeer gevaarlijke zerodays die ontwikkelt zijn door veiligheidsdiensten bijvoorbeeld (EternalBlue is hoogstwaarschijnlijk door de NSA ontwikkelt).


Het is echt niet zomaar een beetje geneuzel in de ruimte. Dit zijn zeer geavanceerde aanvallen die je eigenlijk in de categorie cyberwarfare kunt plaatsen. Je kunt hier zeer kritieke infra mee platleggen.

[mphilipp]

Je brengt het nu alsof Oracle DB de heilige graal is mbt data security

Nee hoor. Maar het is het enige dat ik ken Ik kan geen uitspraken doen over MS SQL, want dat ken ik niet goed genoeg. Er zal denk ik in alles wel ergens een lek zitten dat te exploiteren is.

Maar ik probeer er ook juist achter te komen (voor mijzelf) hoe dat spul werkt. Er wordt altijd maar zo makkelijk geroepen dat er op een attachment is geklikt in een mail en dat toen de hele boel op slot zat. En aangezien ik mij dat alleen kan voorstellen op een single user systeem of klein/simpel netwerk, wil ik erachter komen hoe het zit. Bij zoiets als de vermeende hack op Garmin kan ik mij niet voorstellen dat je dat met één simpel scriptje af kan doen. De infra is bij verschillende bedrijven zodanig anders dat je echt een heel ingewikkeld pakket moet hebben om dat automatisch te doen. Je hebt te maken met zoveel verschillende OSen, versies daarvan en beveiligingsmaatregelen en weetikwat. Het scenario dat er via een clickbait ding de eerste hack is gepleegd waardoor de hackers toegang kregen tot 'een' systeem en van daaruit verder konden werken lijkt mij waarschijnlijker.
Ik weet dat die malware enorm geavanceerd is en dat er in het geval van zo'n clickbait geval er een heel mechanisme achter zit (een soort malwarehouse) die een pakketje op maat produceert voor het systeem waarop de arme klikker zit. Maar daarna zal er toch echt een mens aan de gang moeten op een systeem om zijn weg te vinden naar een 'bruikbare' database. Ik weet dat er zat manieren zijn om daar te komen, maar een automaat is ook maar een automaat. Ze zullen best wel scantools e.d. gebruiken, maar een mens moet beoordelen of het een bruikbare tak is. Er zijn databases waarbij jij van mij best DBA rechten mag hebben, maar daar leg jij mijn tent niet mee plat. En er zijn nogal wat databases, vooral bij een tent als Garmin. Duizenden servers, evenzoveel databases en er zijn er maar een paar belangrijk voor deze hack. Dus de combi mens/machine zal de beste zijn naar mijn idee.

[supersnathan94]

Nee hoor. Maar het is het enige dat ik ken Ik kan geen uitspraken doen over MS SQL, want dat ken ik niet goed genoeg. Er zal denk ik in alles wel ergens een lek zitten dat te exploiteren is.

Nou vooruit dan maar. keur hem voor deze keer goed

Er wordt altijd maar zo makkelijk geroepen dat er op een attachment is geklikt in een mail en dat toen de hele boel op slot zat.

Helaas wel ja. "Niet op mailbijlages klikke. foei" is het bijbehorende advies, maar als beheerder weet je nog steeds niet hoe je je hier dan tegen beveiligd dat klikken op het linkje niet gelijk betekent pats boem klaar.

De infra is bij verschillende bedrijven zodanig anders dat je echt een heel ingewikkeld pakket moet hebben om dat automatisch te doen. Je hebt te maken met zoveel verschillende OSen, versies daarvan en beveiligingsmaatregelen en weetikwat.

Jup. En soms is het zo simpel als gewoon de gok wagen en hopen dat je op de goede versie zit en soms is het een kwestie van targetten van je audience:

Petya's payload infects the computer's master boot record (MBR), overwrites the Windows bootloader, and triggers a restart. Upon startup, the payload encrypts the Master File Table of the NTFS file system, and then displays the ransom message demanding a payment made in Bitcoin.[6][25][26] Meanwhile, the computer's screen displays text purportedly output by chkdsk, Windows' file system scanner, suggesting that the hard drive's sectors are being repaired.[1]

The original payload required the user to grant it administrative privileges; one variant of Petya was bundled with a second payload, Mischa, which activated if Petya failed to install. Mischa is a more conventional ransomware payload that encrypts user documents, as well as executable files, and does not require administrative privileges to execute.[6] The earlier versions of Petya disguised their payload as a PDF file, attached to an e-mail.

Soms wordt er zelfs social engineering gebruikt om de user zover te krijgen dat hij de privileges toekent.
Aan de andere kant is het soms een keuze van hogerop om updates uit te stellen om redenen:

Wired believed that "based on the extent of damage Petya has caused so far, though, it appears that many companies have put off patching, despite the clear and potentially devastating threat of a similar ransomware spread."[46] Some enterprises may consider it too disruptive to install updates on certain systems, either due to possible downtime or compatibility concerns, which can be problematic in some environments

dat je dat met één simpel scriptje af kan doen

Nee dat is het dus niet idd. Het gaat er echt om comlexe software die soms eerst zelf nog een payload binnenhaalt aan de hand van een lijst aanwezige software bijvoorbeeld.

Het probleem is vaak dat er dus van 1 of meerdere zerodays gebruik gemaakt wordt en dat maakt het lastig. Hier heb je nog niet de kans voor gehad om tegen te patchen (want die is er nog niet) en de combinatie van meerdere van dat soort dingen is nogal funest. Een combi zerodays waarvan de 1 remote code execution is en de ander privilege escalation. Nou dan kan je inpakken. Het enige wat je dan kan doen is de boel gewoon niet aan een netwerk hangen wat direct met internet praat en dat volledig airgappen en onderling hoogstens via 1 poort HTTPS only kunnen doen. maarja dan is performance mogelijk weer een ding. Is allemaal lastig.

[teacup]

Wat je schrijft over het alleen toegang hebben tot de database van Oracle als zijnde een System user (ook op OS niveau) herken ik inderdaad. Ik heb geen Oracle kennis, maar ben wel bekend met PDM/PLM software die Oracle als database gebruikt. Ben je geen system user, dan kom je niet bij die bestanden.

Dat deze gijzelsoftware zo invasief kan zijn kan volgens mij alleen maar als ze dit soort access conventies opzij kan schuiven. Hoe? Dat weet ik ook niet. Maar toch zou het mij niet verbazen als een Oracle system account (voor de gijzelsoftware dan) niet veel anders is dan al die andere accounts die de gijzelsoftware zomaar kan bypassen. Het enige dat ik kan verzinnen is als die software op een lager niveau in het OS ingrijpt, waarom het access rights bouwsel nog niet van invloed is. Ik wil daarom nog niet direct een oordeel geven over de kwaliteit van de installatie bij Garmin.

Misschien dat een derde met wat meer kennis hierover iets kan zeggen over hoe gijzelsoftware access conventies op OS niveau kan passeren?

[Reactie gewijzigd door teacup op 23 juli 2024 05:09]

[mphilipp]

Geen enkele malware kan 'zomaar' access conventies opzij schuiven. Dat zou op een ernstig lek in het OS duiden. Wat je bedoelt is denk ik privilege elevation (volgens mij heet dat zo), wat erop neerkomt dat je op een of andere manier root user of equivalent wordt. Dat kan als een beheerder zo dom is om met een privileged account op een exposed systeem te werken. Als je dán een stukje malware op je bord krijgt, kan ie met jouw account heel ver in het systeem komen.
Ik zit nu niet meer op productie systemen, maar ik heb een paar jaar geleden bij een grote webshop in NL gewerkt waar ik ook toegang had tot productie. Iedereen kon op zijn laptop met een os naar keuze werken. Dus er waren mensen met Windows, MacOS en Linux. Maar als je Windows of MacOS had, kon je nooit direct via dat OS connecten naar een productie database server. Dat moest altijd via een terminal sessie, en dan nog moest je een security key opgeven die een bepaalde tijd geldig was.
En in dat bedrijf was een actieve security crew actief, die echt wel met IDS en whatnot de boel in de gaten hielden. Want wat ik zelf al aangeeft, en een aantal hieronder ook al opmerken, moeten die hackerds al een poosje in dat systeem zitten. Maar dat is niet best. Als je zo lang ongemerkt kunt rondneuzen, is dat niet ok. Ik vermoed dat Garmin de security van Connect niet zo serieus nam omdat het geen systeem is waar je geld mee kunt verdienen om te hacken. Maar dan hadden ze niet op ransomware gerekend. Dom, heel dom.

Ik hoop alleen dat ze het snel oplossen, want de horloges raken vol als ze hun spullen niet kwijt kunnen...

[teacup]

Wat je bedoelt is denk ik privilege elevation

Daar zal het op neer komen inderdaad. Eigenlijk ben je dan de access rights naar je voordeel aan het ombuigen. Misschien nog een variant: privilege combination. Door verschiende rollen in dezelfde account te combineren wordt de account te zwaar en kan te veel doen. In accounts moet wat dat betreft ook met een soort scheiding van machten worden rekening gehouden.

[Sandwalker]

Zelfs als je back-end gewoon operationeel is, maar je hele Windows infrastructuur dienst weigert, dan is het niet zo gek om zaken uit te zetten. Liever en dagje teveel spullen uit hebben staan dan erachter komen dat er allerlei encrypted waarden in velden staan. Eerst maar eens horen wat er gebeurd is.

[OruBLMsFrl]

Zulke malware is regelmatig van aanvallers die al weken in het netwerk zitten ook. In ieder geval bij universiteit Maastricht kwam dat naar voren. Als ze dan al aan het keyloggen en sniffen zijn geweest al die tijd is er maar heel weinig dat ze niet kunnen vrees ik.

Daarbij is enkel een database niet voldoende voor je klanten. Ligt heel je Active Directory inlogsysteem, (interne/forwarder) email, fileservers en alle werkstations plat, hoe kun je dan nog controles op je betalingen en operatie uitvoeren, klantenservice leveren, enzovoorts? Grootschalig gebrek aan secondaire processen kan zo alsnog je bedrijf stilleggen voor de nodige werkdagen vrees ik, afhankelijk van de opzet/type IT en bedrijfsvoering, misschien zelfs richting werkweken?

[Reactie gewijzigd door OruBLMsFrl op 23 juli 2024 05:09]

[Skywalker27]

Deze criminelen zitten al maanden in het systeem en maken vaak gebruik van privilege escalation om het spulletje op scherp te zetten vaak zijn ze ook al in het bezit van een golden ticket. En dan wens ik Garmin veel succes eigenlijk vooral sterkte want dan zijn de backups ook encrypted.

[Webaccess]

even een hele simpele werkwijze.
- Malware komt binnen op gebruikers PC
- Via fileshares ook bij andere gebruikers
- Vervolgens bij een beheerder
- Malware komt vervolgens bij Domain Controller en leest Service accounts uit
- Malware komt op je database server
Je kan de rest zelf verzinnen maar als maar voldoende systemen zijn geïnfecteerd kom je steeds wel iets verder en uiteindelijk ook op de core infrastructuur.

[mphilipp]

Ik denk niet dat ie dat zomaar automatisch doet. Volgens mij moeten er altijd mensen aan te pas komen. En jij veronderstelt een complete Windows infra. Ik heb bij genoeg bedrijven gezeten waar ze in de front end met Windows werkten en Unix/Oracle in de back end, maar bij geen van allen zaten de Oracle accounts in de AD zodat je vanaf die Windows servers zomaar bij Oracle kan. Dat is nergens voor nodig. Het kan allemaal wel, maar je bent a)erg kwetsbaar en b)is er 0,0 voordeel. Oracle heeft zijn eigen access laag, en je gaat niet in je centrale AD een Oracle superuser stoppen. En je moet sowieso zo min mogelijk met unnamed service accounts werken, want dan kun je nooit goed achterhalen wie wat gedaan heeft. Is erg lastig, maar zeker voor de Oracle superusers (sys/system) wil je dat helemaal niet. Maak dan in Oracle beperkte beheerders aan. Gelukkig kan dat tegenwoordig allemaal, maar ik weet niet (denk niet) dat veel toko's het zo dichtgetimmerd hebben. Meestal kunnen de DBA's alles. Maar je kunt dat (precies om die reden) behoorlijk beperken, zodat je wel je beheerwerk kunt doen, maar die de database encrypten of wegkiepen oid.

[Baserk]

Het zou me niet verbazen als de aanvallers al meer dan een week binnen waren en het netwerk lateraal verkenden en verder binnendrongen.
Misschien alleen tbv uiteindelijke ransomware.
Of dit ter afleiding van interesse in intellectueel eigendom.
Of zoals hieronder genoemd, interesse in de Garmin NFC codes voor betalingen.

[Bensimpel]

Ik denk zelfs al maanden, en de zomervakantie periode is net zoals tijdens kerst/nieuwjaar een perfecte moment om toe te slaan.

[Echnon]

En dan nog als het lukt, een lopende Oracle DB encrypten en weer decrypten, veel success om daar nog wat werkends uit te krijgen. Dan moet die malware Oracle in backup modus weten te zetten ofzo

[Verwijderd]

Ja, heel simpel gezegd wel, maar als je met een echte database werkt, wil ik je nog datafiles zien veranderen. Ik (als Oracle specialist) wil je wel een actieve database zien encrypten. Dat lukt je niet met een of ander programma op Windows. Je zult echt de userid van de Oracle user (owner van de bestanden) moeten zijn om iets te kunnen doen.

Dat is toch helemaal niet nodig? Er zijn meerdere manieren om op een database in te loggen en de inhoud te encrypten, via servers die acties mogen uitvoeren binnen de database. Het uitvoeren van dbms_crypto of encryptbykey bijvoorbeeld.

[mphilipp]

Klopt. Er zijn altijd vele wegen die naar Rome leiden. Toen ik jaren geleden met Rman bezig was, zag ik een heel leuke commando:

In Oracle Database 10gR1 Oracle introduced the RMAN command DROP DATABSE. This one simple statement has the ability to completely remove a database including all RMAN backups with the optional INCLUDING BACKUPS clause.

What could possibly go wrong?

Uiteraard kom je er niet zo heel simpel in, en ook dbms_crypto heeft wel iets meer voeten in aarde dan alleen het ene commando intikken. Maar je moet ervan uitgaan dat hackers die de boel willen plat leggen wel eea weten.

Inmiddels lijkt Garmin weer langzaam overeind te krabbelen. Helaas krijgen we waarschijnlijk nooit te horen hoe het allemaal precies zat. Dat is deels om anderen niet wijzer te maken, en het is ook gewoon veel te genant natuurlijk. In security kringen zal men wel eea weten, maar wij zullen het nooit echt weten hoe of wat. Aan de ene kant jammer, want ik wil graag weten hoe zoiets in zijn werk gaat, vooral omdat er in de media vaak zo simpel over geschreven wordt. Maar het is niet eenvoudig. Jammer ook dat die hackers hun kennis niet voor een goede zaak toepassen, want het zijn geen prutsers volgens mij. Je moet toch echt behoorlijk wat kennis hebben om dit uit te voeren.

[Dillex]

Het kan naar mijn idee nooit een simple pakketje zijn dat via een mailtje klik-klak-klaar en de boel staat op slot.

Zo begint het helaas wel. Ik stuur jou een mail met een malafide bijlage (office document met malafide macros) en ik zorg d.m.v. social engineering dat jij deze bijlage opent of op een malafide link klikt. Met behulp van obfuscation zorg ik ervoor dat dit bestand / linkje gewoon geopend wordt (goede EDR zou hier iets tegen kunnen doen)

Vervolgens open je voor mij een beacon op jouw laptop/workstation. Ik heb nu dezelfde rechten als jij en dan kan het feest gaan beginnen. Ik kan het netwerk verkennen / scannen, jouw rechten gebruiken om door het netwerk te navigeren, naar een beheer server springen, passwords dumpen en vervolgens een domain admin account pakken om het netwerk te gaan ownen.
Ik disable de anti-virus, pak de SCCM server (of andere distributer) prak daar de ransomware in en doe eventuele nazorg om te controleren dat deze goed land en ook eventuele back-up oplossing pakt.

Dat is allemaal mogelijk met alleen een phishing e-mail. Met een gelaagde beveiliging kun je het allemaal veel lastiger maken, maar er zijn ook talloze wegen naar Rome. Echter, andere wegen maken vaak wel meer lawaai en daarom is het dus essentieel om een SOC in te richten met analysten die ook daadwerkelijk ernaar kijken (Universiteit Maastricht .....)

[Reactie gewijzigd door Dillex op 23 juli 2024 05:09]

[mphilipp]

Dat is allemaal mogelijk met alleen een phishing e-mail.

Ja, dat station waren we al gepasseerd in de discussie. Dat kan dus alleen bij hele domme bedrijven. Als je mijn logon hebt, kun je best veel, maar niet bij een beheerserver. Daar heb je weer andere credentials voor nodig en moet je weer via een aparte server heen. Vreselijk onhandig, maar voor de hackerd een extra horde.

Maar goed, dan ga ik weer de hele discussie van voren af aan doen, en daar heb ik geen zin in. Theoretisch heb je gelijk en in grote lijnen is dat wat er gebeurt. Maar zo simel als het klinkt is het niet. Tenzij je een bedrijf treft dat alles via één server doet en met één logon overal toegang toe geeft.

[Dillex]

De enige extra horde die je hier in feite mee creëert is dat het nu noodzakelijk wordt om iets meer geduld te hebben als hacker zijnde. Het aanzetten van een keylogger en afwachten totdat jij springt met jouw beheer account naar een beheerserver is dan voldoende. Dat is dus echt niet alleen bij hele "domme bedrijven" mogelijk.

Phishing is ook voor APT's de manier om binnen te komen. Lees anders maar even de casus Maastricht terug waar TA505 ook middels phishing is binnen gekomen.

Overigens zag ik in je post dat je op zoek was naar tekst en uitleg hoe ziets werkte en dat heb ik bij niemand nog teruggelezen dus vandaar geef ik je een basale kill-chain. Mocht je verder geen zin discussie hebben dat is wat mij betreft prima.

Mocht je je vervelen zoek eens voor de gein op wat Armitage / Cobalt Strike allemaal kunnen doen.

[ari3]

Nouja, voor het encrypten van databasebestanden heb je misschien een systeem-account nodig, maar op zichzelf is een database-user met schrijfrechten al voldoende. Zo'n account kun je gewoon vinden in de config van de applicaties die koppelen met de database.

UPDATE tabel SET data=ENCRYPT(data)

[Reactie gewijzigd door ari3 op 23 juli 2024 05:09]

[akooijman]

Als de tools (applicaties, websites, whatever) die de database gebruiken gecorrumpeerd zijn heb je niet zo veel aan de database, beschadigd of niet.
Bovendien willen ze heel erg zeker zijn dat alles 'schoon' is voor ze wie of wat dan ook weer toegang geven.

[84hannes]

Ik vrees dat de slechte publiciteit hen meer zal kosten dan de eis...

Het gaat mij niet om de hoogte van de eis, maar dat je, door het betalen van losgeld, de gijzelingsindustrie lucratief maakt. Ik heb wel eens gehoord van bedrijven die expliciet communiceren dat ze geen losgeld voor hun medewerkers betalen, juist om hun medewerkers te beschermen tegen gijzeling. Dat zouden bedrijven van mij ook voor hun data mogen doen.

[Zynth]

Het zou wettelijk verboden moeten zijn om losgeld te betalen in dit soort gevallen.
Alleen dan verdwijnt het lucratieve karakter, en help je "de markt" hiervoor om zeep.

Tsja, dat kost je wel een paar bedrijven totdat de hackers doorhebben dat ze echt niks meer krijgen, maar dat is dan de prijs...

[pauldebra]

Zo'n wettelijk verbod gaat weinig oplossen. De crux van de zaak is dat het mogelijk is om anoniem losgeld te betalen. Wat dus nodig is is een wereldwijd verbod op anoniem bruikbare betaalmiddelen zoals cryptomunten. Voordat er cryptomunten bestonden konden bijna-anonieme betalingen alleen met cash geld. Maar cash is niet echt anoniem: elk bankbiljet heeft een uniek serienummer. Het is technisch mogelijk (en veel eenvoudiger dan crypto) om bij elke transactie waarbij iemand cash geld opneemt de serienummers aan de klant te linken. Het cash geld dat vervolgens van hand tot hand gaat is niet genoeg om ooit aan een anoniem losgeld van miljoenen te komen. Dat moet wel door een bank of overheidsinstelling worden aangeleverd, en wanneer maar goed gegarandeerd wordt dat dit NOOIT kan of mag gebeuren zonder al die serienummers te registreren worden anonieme grote cash-betalingen onmogelijk.
Tot nu toe bestaat wereldwijd gewoon de onwil om alle financiële transacties te kunnen linken aan personen. Daar zit het probleem. Wanneer criminelen gewoon nooit meer anoniem geld kunnen ontvangen wordt losgeld erg oninteressant voor hen.

[Chielemans]

Wat een eng beeld schets je hier.. ik moet er niet aan denken dat anderen weten wat ik met mijn geld doe... Daar heeft niemand iets mee te maken.

[pauldebra]

Zolang je kleine bedragen cash tussen mensen uitwisselt is er niets aan de hand. En als je in een winkel met cash betaalt dan zouden de briefjes die door het apparaat gaan dat kijkt of het geen vals geld is meteen aan een database kunnen vragen of het geld is dat geregistreerd aan criminelen is gegeven. Blijkt het geld geregistreerd te zijn dan heb je een klein probleem (er moet onderzocht worden hoe je eraan komt, maar het is niet erg want het is weinig) en zoniet wordt het "afgemeld" en kan door de winkelier als wisselgeld ook weer aan de volgende klant worden meegegeven of later bij de bank worden gestort.
Het crimineel geld wordt getraceerd, de rest wordt gewoon ongemoeid gelaten.
Als je al te veel nadruk legt op het garanderen van privacy dan wordt het opsporen van criminelen onmogelijk. Het is altijd zoeken naar een balans tussen privacy garanderen en privacy niet door criminelen laten misbruiken om met crimineel geld weg te komen. De cryptomunten waren duidelijk een brug te ver richting privacy, en zo'n ransom gevallen zijn een mooie illustratie hiervan. We moeten een stapje terug zetten in onze obsessie voor privacy om het vangen van boeven nog mogelijk te maken.

[Orangeno]

Leuk te lezen dat je cash ziet als het financiële middel dat te traceren kan zijn.

DNB denkt hier anders over, die zien wel een toekomst voor 'cryptos' echter noemen zij het programmeerbaar geld.

Daarentegen heeft de FATF vorig jaar een ruling uitgebracht aangaande 'cryptos' en de anonimiteit daarvan. Doorgaans nemen landen en daarmee betaal- wisseldiensten deze rulings over.

Daarnaast is dit jaar de AMLD5 in de EU van kracht gegaan. Sommige landen, waaronder Nederland, hebben strengere eisen neergelegd dan hierin voorgeschreven.

TL;DR cryptos kunnen bijna niet meer worden omgezet naar cash zonder dat het te linken is aan een persoon.

[pauldebra]

Cash is nu nog niet te traceren omdat de unieke serienummers niet in een database gekoppeld worden aan wie via een bank of andere "instelling" een hoeveelheid cash ontvangt. In misdaadseries waar om een betaling in cash wordt gevraagd wordt naar "ongemarkeerde biljetten" gevraagd, met "willekeurige serienummers". Maar ook willekeurige serienummers kunnen allemaal netjes in een database gelogd worden. Het ontbreekt nog aan de infrastructuur om dit te doen. DNB zou dit een keer moeten onder handen nemen...

[K-aroq]

De bedragen die jij uitgeeft zullen waarschijnlijk nooit getraceerd gaan worden. Daar is domweg de capaciteit niet voor beschikbaar om dat bij iedereen te gaan doen. Maar als er opeens bepaalde onverklaarbare geldstromen zijn dan moet dat wel onderzocht worden. Grote kans dat om criminele zaken of losgeldzakken (wat eigenlijk ook criminele zaken zijn) gaat.

Maar als je totaal niet wilt dat er onderzoek wordt gedaan naar geldstromen dan zullen we tot in lengte van dagen te maken hebben met losgeldzaken.

Of heb jij een beter idee om het op te lossen?

[MrDayOff]

ik moet er niet aan denken dat anderen weten wat ik met mijn geld doe...

Die gedachte gaat wel erg ver, men kijkt toch niet naar jou als persoon als dat geld gecheckt wordt. Het is een systeem dat het geld checked wat bij de kassa wordt aangeleverd. Stel dat er in een klein gebied heel veel geregistreerde biljetten worden ingeleverd kan het zijn dat de camera beelden worden opgevraagd. Mocht jij dat iedere keer geweest zijn zal men jouw gaan onderzoeken inderdaad, maar als het telkens een ander is lopen ze op een dood spoor. Mogelijk dat men dan wil achterhalen wat de relatie is tussen al die personen (zelfde sportschool oid), maar dat is door ds privacy wet helemaal dicht getimmerd. Dus ja, criminelen pakken wordt dan erg lastig.

Zo'n onderzoeker zal het een worst zijn dat jij bij de AH boodschappen hebt gedaan of bij de Jumbo, maarja, men wil persé privacy alles op alles. Want anders kan iemand weten dat je vanavond bloemkool eet. Dus zijn dat soort onderzoeken vrij lastig te achterhalen.

Natuurlijk moet dat soort info niet openbaar zijn, maar laten we nou wel wezen dat professionele speciale eenheden die een eed afgelegd hebben vertrouwelijk met data omgaan. En alleen als doel hebben om criminelen te pakken (en niet om een burger te volgen die een reep chocolade gekocht heeft).

[Verwijderd]

En toch zit het al in je bank. Rabobank serveert ineens apps in mobiel bankieren app die suggesteert waar je je geld aan uitgeeft in een leuke tabel / boom / spreadsheet look a like. Verbaast me helemaal niets als de bank die gegevens ook elders (verkoopt) gebruikt.

[Zynth]

Nu probeer je niet de rootcause van het probleem op te lossen, maar slechts een van de zaken die het mogelijk maken.
Net zoals alle voertuigen verbieden, zodat er geen drugs meer vervoerd kan worden...

De vraag is; waarom investeert een hacker zo lomp veel tijd en geld in een hack (dit soort hacks/locker-algo's zijn geen kleintjes); omdat hij er wat voor terug krijgt.
Zorg dus dat dat niet gebeurt, dan houdt het op.

Als Garmin nu die 10 miljoen gaat overmaken, blijft deze hackgroep en vele anderen dekomende 10 jaar gegarandeerd doorgaan op zoek naar een nieuwe jackpot. Zelfs al verdienen ze het eerste jaar helemaal niets.

Losgeld betalen moet verboden worden; je maakt daarmee alle bedrijven/overheden tot potentieel en lucratief volgend slachtoffer

[Reactie gewijzigd door Zynth op 23 juli 2024 05:09]

[pauldebra]

De root cause van het probleem is dat er met criminaliteit anoniem geld kan worden "verdiend".
Je moet om drugstrafiek tegen te gaan niet alle voertuigen verbieden maar de mogelijkheden wegnemen om met voertuigen ontraceerbaar te rijden/reizen. Hierdoor blijft het voor iedereen met goede bedoelingen mogelijk om gewoon met voertuigen te rijden, maar "ongemerkt" ergens naartoe kan met alle voertuigen onmogelijk worden gemaakt.
De hele moeilijkheid is om van alles het legitieme gebruik mogelijk te houden zonder grote ongemakkenn en tegelijk het criminele gebruik direct traceerbaar en daarmee voor criminelen onaantrekkelijk te maken.

Losgeld betalen hoeft niet verboden te worden, maar door anoniem losgeld betalen onmogelijk te maken neem je de oorzaak weg: er gaat geen losgeld meer gevraagd worden voor iets omdat de ontvanger gegarandeerd gepakt wordt.

[Zynth]

Onhaalbaar. Terwijl het verbieden van betalen van losgeld eenvoudig haalbaar is.
Dus ik begrijp je verhaal niet goed.

[Dillex]

Hoe kom je erbij dat het verbod op het betalen van losgeld eenvoudig haalbaar is? Als je wilt dat dit verbod daadwerkelijk effect heeft zal het tenminste door de gehele EU moeten worden geimplementeerd en worden gehandhaafd, eigenlijk liever ook door de andere grootmachten. Dat noem ik nou niet bepaald eenvoudig.

Daarnaast, wat denk je dat er gebeurt als een ziekenhuis wordt getroffen door ransomware of een bank?
Deze instanties zullen hoe dan ook willen betalen als hun back-up oplossing ook getroffen lijkt en/of niet op orde is. Deze instanties willen hoe dan ook hun data niet verliezen en het is naief om te denken dat het bij deze instanties helemaal waterdicht is ingericht.

[pauldebra]

Het verbieden van betalen van losgeld treft in eerste instantie het slachtoffer van "ontvoering" en pas in tweede instantie de criminelen. Zie je het al gebeuren: er wordt een kind ontvoerd. De politie gaat vanaf dan met man en macht bewaken dat er vooral door de ouders geen losgeld wordt geregeld. Eerste prioriteit dus het voorkomen dat er losgeld wordt betaald. In tweede instantie ook maar proberen dat kind te vinden en de ontvoerders, maar als dat mislukt, jammer dan. Kind dood, maar de ontvoerders hebben tenminste geen losgeld gekregen... Ik zie dit nog zo niet gebeuren. Sorry hoor.
Natuurlijk gaat het bij ransomware niet rechtstreeks om een mensenleven, maar afhankelijk van welke data er is buitgemaakt kan het via die data uiteindelijk toch om mensenlevens gaan.
Ik zou als wetgever veeleer inzetten op het traceerbaar maken van een betaald losgeld en minder op het voorkomen dat er betaald kan worden. Maar ja, iedereen heeft zo zijn eigen prioriteiten... Als politieke partijen hierin nu eens een duidelijke keuze zouden maken dan hebben de kiezers bij de volgende verkiezingen tenminste weer iets om voor te kiezen.

[Bensimpel]

Er blijft altijd een manier op zwart geld wit te wassen. Daar helpen corrupte overheden dan wel aan mee.

[GoBieN-Be]

Voordat dat de cryptomunten populair waren voor dit soort criminele activiteiten waren het zo'n soort vouchers die gekocht konden worden in pompstations en die anoniem konden gebruikt worden.

[pauldebra]

Ik zie iemand al aankomen bij een pompstation: "Doe mij maar voor 10 miljoen aan vouchers..."
En daarna komt er een tweede: "Ik heb hier een voucher voor 10 miljoen. Die wil ik graag even ontvangen..."
Gaat denk ik toch niet werken...

[GoBieN-Be]

Is het enkel een probleem als het over miljoenen gaat dan?
Vroeger was het rond de 300€ voor een gewone gebruiker. Maar dat is niet erg dan?

[pauldebra]

Natuurlijk is ook 300€ erg. Maar ik droom nog dat elke gewone gebruiker bij een ransomware gewoon de hele PC kan herinstalleren en een van z'n vele recente backups kan terugzetten zonder veel data te verliezen.
Dat is toch heel anders voor bedrijven met continu draaiende informatiesystemen waarop handel gedreven wordt. De database met de transacties van een paar uur of (oei, oei) een paar dagen oud... meteen een groot financieel verlies en ook reputatieschade.

[MrDayOff]

Het zal wellicht via de cryptomunt Monero gaan, die is niet te traceren. Dat hele privacywet gebeuren maakt het criminelen steeds makkelijker om ongezien grote bedragen weg te sluisen.

[M2M]

De aanname die je nu maakt is dat hackers stoppen met proberen als er niet meer betaald wordt. Hoe zeker ben je van je zaak?

[84hannes]

Het ontwikkelen van dit soort software en het uitvoeren van dit soort hacks is niet gratis. Als ze die investering niet terug verdienen stoppen ze vanzelf.

Of we gaan tegen ze pokeren en winnen om ze bankroet te krijgen

offtopic:
Ik hoop nog steeds dat ik Casino Royale niet goed begrepen heb.

[turbojet80s]

Dan ga jij ervan uit dat de hacker enkel de bestanden versleuteld en hoopt geld te krijgen, maar als de hacker toch al binnen is kan hij net zo makkelijk de data stelen en verkopen op de illegale markt.

[84hannes]

Klopt. Maar zelfs als de gijzelingsactie slechts een bijverdienste is, hij kost geld. Dus als het niets oplevert moeten ze al bijzonder hatelijk zijn om zuiver te encrypten voor het pesten. Gewoon verwijderen is makkelijker, kost aanzienlijk minder en levert even weinig op.

[FreezeXJ]

Uiteraard, maar zo lang de kans op betaling aanwezig is, en de uitbetaling best groot is (10 miljoen is een flink bedrag, de hack zelf zal ze wellicht een ton gekost hebben?) dan blijft die verleiding bestaan.

[84hannes]

Precies, van die kans op betaling moet je dus af.

[bussie66]

Niet met een wettelijk verbod. Zou einde kunnen betekenen van een (zeer groot) bedrijf met alle maatschappelijke gevolgen (o.a. veel werknemers werkeloos).

Dan maar geld betalen, is minder erge impact.

Of leg jij degenen die werkloos worden even je mening uit....

[84hannes]

Leg jij diegenen die gedood worden bij een gijzeling eens uit waarom betalen een slecht idee is. Het steekwoord is: preventie.

Misschien zou een flinke boete beter zijn maar dat komt op hetzelfde neer: je kunt er weinig aan doen als een bedrijf de wet overtreed, anders dan alsnog een boete opstellen of de verantwoordelijken in de gevangenis gooien.

[Sandwalker]

Laat ze nou eerst die Pipo’s opsporen die dit eenheid idee leek. Kunnen ze daarna een tijdje gaan zitten. Aangezien het bedrijf wereldwijd opereert kan Garmin een goede jurisdictie uitzoeken. Garmin enkelband om en over twintig jaar hebben we Olympische sporters van ze gemaakt.

[akooijman]

Het begon allemaal met particulieren die een paar honderd euro moesten betalen om hun vakantiefoto's te redden. Objectief bezien is er weinig verloren als je vakantiefoto's weg zijn, toch zijn er veel mensen die betaald hebben.

Voor een bedrijf kan het zoekraken van gegevens het einde betekenen. De vraag is dan: eigen schuld dikke bult, of gaan we bedrijven redden in dit soort situaties?
Als Garmin zomaar verdwijnt kost dat de samenleving veel geld. Als de universiteit van Maastricht moet sluiten (voor een half jaar of langer) kost dat niet alleen de universiteit veel geld.

[J_van_Ekris]

Een server is in dat opzicht ook maar een Windows PC met wat extra diensten. Als je een kwetsbaarheid hebt waarmee je op de server op het juiste niveau binnenkomt, dan kun je vaak dezelfde trucs uithalen als op een desktop. Dus een virus/worm kan op een puur Windows domein een vrij grote klap maken, zeker als men niet segmenteert.

Bedenk ook dat dit waarschijnlijk geen toevalstreffer is. Dit is waarschijnlijk voorbereid en gericht aangevallen. Hackers hebben waarschijnlijk gericht medewerkers proberen te besmetten, en van daaruit hun positie versterkt totdat ze wisten dat ze Garmin echt klem zouden zetten. En toen is de ransomware losgelaten.

[Reactie gewijzigd door J_van_Ekris op 23 juli 2024 05:09]

[Coffee2Code]

Veruit de meeste servers op het internet draaien op Linux.

[J_van_Ekris]

Als ik naar https://w3techs.com/techn...rison/os-linux,os-windows kijk, is minstens 29,9% Windows (tegen 29,8 % Linux en 40% onbekend). Niet fantastisch groot, maar wel bijna 1/3 van alle webservers. Ik tref in praktijk behoorlijk wat "all microsoft" domeinen aan, al is het maar omdat beheerders eenvoudiger getrained kunnen worden om ergens op te klikken dan een commandprompt te begrijpen.

[Coffee2Code]

Damn, dat was vroeger wel heul anders.

[Furious5]

Daarom koop ik zoveel mogelijk producten die standalone zijn.. Leuk zo'n fitnesswatch maar tja, nu heb je er weinig aan....

[J_van_Ekris]

Op zich functioneren de Garmin producten nu ook standalone. Je kunt nog steeds sporten en je prestaties meten. Voor enkele sporten (krachttraining) kun je ook ter plekke gegevens corrigeren. Ik kan ook nog steeds zien hoeveel uur ik deze week gesport heb, etc..

Je kunt alleen niet de boel synchroniseren en automatisch naar Strave/Endomondo overpompen, wat handmatig gewoon omslachtig is. Ook is het wel praktisch om automatisch via WiFi te syncen: gevoelsmatig worden gegevens automatisch overgenomen, wat gewoon de analyse eenvoudiger maakt: als het geregistreerd is door mijn horloge, dan staat het on-line.

Maar bepaalde info is niet te achterhalen zonder hulp van Garmin. Dan doel ik met name op zaken als hersteltijden na een specifieke training, slaapritmes, etc.. Ik kan de training wel terugvinden, maar de lichamelijke reactie en hersteltijd (tijd totdat mijn bodybattery weer op 100% zit) niet. En dat is wel een belangrijk gegeven als ik binnenkort weer naar mijn oude ritme van 5 keer per week trainen terugga (slecht slapen en oplopende hersteltijd zijn indicaties van overtraind raken) en ik mogelijk ook wat last heb van Corona-effecten. Dit zijn dingen die wel voor mensen die vaker per week trainen van belang zijn en eigenlijk niet goed inzichtelijk te krijgen zijn zonder desktop component (vereist te complexe interactie).

[computerjunky]

tja niet dus. Ik gebruik mijn garmin edge voor het loggen van ritten en vergelijken met voorgaande data en segmenten dat hele zaakje werkt nu gewoon niet.
En strava is een drama voor segmenten en als ik mijn logs daarnaartoe upload krijg ik heel andere data als via garmin connect dus daar kan ik ook niet vanuit gaan.

Ik had dit liever met een lokaal programma gehad en downloadable data. Maarja het is de wereld waarin we leven. zelfs google home heeft internet nodig net als veel smart home apparaten. ik hoop dat ze ooit allemaal het licht zien en dit allemaal gelimiteerd kan worden tot puur lokaal maar ik ben bang van niet met de huidige move naar betaal diensten voor alles wat los en vast zit.

[K-aroq]

Met een standalone PC doe je niet zoveel meer.

[jhijman]

En nu maar hopen dat ze een backup kunnen terugzetten waar de randsomeware niet in zat

[MijnKijk]

Persoonlijk vind ik gegevensverlies 1 ding, maar wat dacht je van de potentiële gevolgen die het heeft als bijvoorbeeld locatiegegevens op straat komen te liggen?...

Dat gecombineerd met e-mail adressen en weet ik niet wat nog meer (gewicht, trainingsschema’s, slaap/waak ritme, etc) kan een zeer interessante dataset zijn voor kwaadwillenden.

Het is voor de gebruikers van Garmin te hopen dat deze adequaat beveiligd zijn, maar ik heb zo m’n vraagtekens.

De tijd zal het leren, maar het kwijtraken van het aantal stappen dat je gezet hebt of je PR op de x kilometer is imho het minst erg, ook vanuit het Garmin perspectief.

[J_van_Ekris]

Om niet te vergeten, de gegevens van Garmin Pay. Ze zeggen op hun website (zie https://explore.garmin.com/nl-NL/garmin-pay/):

Daarom biedt Garmin Pay u de veiligheid van horlogespecifieke pasnummers en transactiecodes bij elke aankoop die u doet. Uw pasnummer wordt niet op uw toestel opgeslagen, maar op onze servers of wordt aan de verkoper doorgegeven wanneer u betaalt.

Deze rekeningnummers worden op dit moment klakkeloos door banken geaccepteerd. Ik heb zo moeiteloos 250 euro contactloos afgerekend. Ik weet niet of men ook een backup maakt van de NFC tokens (zou dom zijn, maar heb gekker meegemaakt om klanten weer snel op weg te kunnen helpen). Maar die pasnummers zijn zeker interessant.

[groene henk]

Goede post! Had ik niet even bij nagedacht.
Uit voorzorg maar een nieuwe creditcard aangevraagd.

[J_van_Ekris]

Ja, na wat wikken en wegen heb ik de pas van de wearable bij mijn bank geblokkeerd (zie https://www.abnamro.nl/nl...en/wearables/beheren.html) door hem als vermist te markeren. ABN heeft geen contactloos betalen voor Android meer, dus voor de weekboodschappen ben ik nogal gehecht aan contactloos betalen boven de 100 euro zonder PIN via mijn horloge. Volgens de website kan ik die op elk gewenst moment weer activeren (kan wel even duren). Ik blokkeer hem wel totdat ik weer boodschappen ga doen, deblokeer hem een paar uurtjes voor vertrek en meld hem na de boodschappen ook weer als vermist. Perfect is anders, maar hiermee kan ik wel het risico beheersen totdat Garmin zijn zaakjes weer op orde heeft.

[Reactie gewijzigd door J_van_Ekris op 23 juli 2024 05:09]

[KoffieAnanas]

Of overstappen naar de Rabobank, die heeft nog wel contactloos betalen voor Android. Ik ben zelf ook overgestapt om die reden van de ABNAMRO naar de Rabobank. Bevalt goed.

[madmaus]

Ik heb toen gratis een abn wearable gekozen.
Een sticker die je in je hoesje kan plakken. Werkt prima tot nu toe (nfc moet wel uit).
Ik baalde er enorm. Van maar ik heb geen zin om alles over te zetten en al mijn incassos om te zetten.

[84hannes]

Nu quote je heel specifiek. Ik mis

Privacy and Security
Garmin takes the security of your payment information seriously. That’s why Garmin Pay protects you by using watch-specific card numbers and transaction codes every time you make a purchase.

Als ik dit goed begrijp genereren ze een virtuele credit card en gebruiken die voor betalingen. Ik weet niet of die kaart ook geblokkeerd wordt als je je fysieke kaart blokkeert.

edit:
Nog even nagedacht

Je hebt waarschijnlijk gelijk, de virtuele kaart staat op je horloge maar de fysieke kaart wordt ‘beheert’ door Garmin.

[Reactie gewijzigd door 84hannes op 23 juli 2024 05:09]

[J_van_Ekris]

De ABN Amro maakt een soort virtuele creditcard aan met zijn eigen nummers. Dat is wat Garmin overneemt. Maar als ik ermee betaal gaat het wel gelijk van mijn rekening af. Dus wie wat weet en wat je daarmee kan heb niet terug kunnen vinden, dat zullen ze wel geheim houden. Ik weet ook niet of bijvoorbeeld met dat creditcardnummer ook normaal betaald kan worden, en of de NFC tokens ook centraal opgeslagen worden (backup als horloge vervangen wordt?). Garmin en Fitbit zijn ongemerkt steeds meer payment provider gaan spelen. De horloges moeten aan de EMV standaarden voldoen (zie https://www.emvco.com/app...20-07-26&px_search=garmin) maar of de beveiliging van hun centrale oplossing daarmee ook naar voldoende niveau hebben gebracht wil ik niet op vertrouwen.

[Reactie gewijzigd door J_van_Ekris op 23 juli 2024 05:09]

[OldSchoolPhoto]

Sterker nog, op basis van dat nummer genereert Garmin weer een nieuw kaart nummer. Dus tussen je rekeningnummer en wat er in je horloge staat zitten twee nummers(!), nummers die alleen. In het Garmin ECO-systeem werken. In een andere omgeving heb je er dus niets aan. Garmin Pay is gewoon blijven werken, lijkt dus los te staan van de rest van hun infra.

[J_van_Ekris]

Sterker nog, op basis van dat nummer genereert Garmin weer een nieuw kaart nummer. Dus tussen je rekeningnummer en wat er in je horloge staat zitten twee nummers(!), nummers die alleen. In het Garmin ECO-systeem werken. In een andere omgeving heb je er dus niets aan.

Goed punt! Je doelt op "Tokenization": de credit card gegevens worden voor de payment terminal vervangen door random strings. Wat je beschrijft klopt (zie https://squareup.com/us/e...okenization-actually-mean en https://cardconnect.com/l...security/tokenization-101). Ik dacht dat ze dat alleen tussen kaart en winkelier toepasten, maar als ik zoek op tokinization en Garmin pay kom ik op een pagina die beschrijft dat ze zelf ook alleen de tokens hebben, en geen echte CC-nummers (zie https://support.garmin.com/en-US/?faq=S3mWL2xXY44A5V1RNxuqz6).

Garmin Pay is gewoon blijven werken, lijkt dus los te staan van de rest van hun infra.

Kan zijn omdat ze het Garmin Pay uitbesteden bij FitPay (https://thepaypers.com/pa...-payment-feature--776950# en https://www.emerce.nl/nie...ay-nu-officieel-nederland).

Lijkt erop dat we op dat punt opgelucht adem kunnen halen.

[Reactie gewijzigd door J_van_Ekris op 23 juli 2024 05:09]

[azogtoth]

Om niet te vergeten Garmin InReach, een dienst waarmee je nood berichten via satellieten kunt versturen.

[DiedX]

Ik zou er vanuit gaan dat die gegevens op straat liggen. Garmin is dusdanig groot dat dit niet een dubbelklik van Mien van de administratie op een verkeerd bestand is, maar een goed voorbereide aanval.

Met die aanval ga ík er vanuit dat alle data ook "gebackupped" is door de hackers in kwestie.

Ik hoop allen dat ze 10 mio hebben. De backup lijkt niet op tape te staan

[84hannes]

Met die aanval ga ík er vanuit dat alle data ook "gebackupped" is door de hackers in kwestie.

Dat zou heel veel datatransport zijn en daardoor potentieel opvallen en geld kosten voor de gijzelnemer (data-opslag). Het idee van crypto/ransomware is dat je de gegevens versleuteld bij de klant, het enige dat de gijzelnemer heeft is de sleutel voor ontsleutelt het.

[DiedX]

Ik zou als aanvaller niet geinteresseerd zijn in alle hartslaginformatie van een persoon hoor. In dat geval kan ik veel minder data exfiltreren.

[J_van_Ekris]

Kan zijn dat ze al weken binnen zijn en op hun gemak in kleine porties informatie hebben geexfilteerd. En inderdaad, ik heb niet de indruk dat ze uit zijn op mijn persoonlijke record downhill skieen, hoe cool ik dat zelf ook vindt. GPS data is wellicht wel weer interessant, maar die staat alleen aan tijdens bepaalde sporten. Maar het kan wel patronen verklappen (wanneer iemand vaak weg is, etc.), welke sporten doet iemand graag, etc. Kan interessant zijn voor spammers en fishing.

Aan de andere kant: sommige informatie is flink in waarde gedaald nu de hack openbaar is. Met name mogelijke buitgemaakte creditcard-info (webshop, Garmin Pay) verminderd van waarde nu mensen weten dat er bij Garmin mogelijk een datalek is: mensen gaan hun creditcards extra controleren en wellicht zelfs blokkeren. Dus dat type info hebben ze wellicht niet buit weten te maken, of ze beseffen (nog) niet wat ze dan in handen hebben, als ze inderdaad de moeite hebben genomen om data te exfilteren.

[Hakker]

Ik denk dat het je tegen zal gaan vallen hoeveel mensen hun passen zullen blokkeren. Mens zijn naief en lui van nature. Het is altijd van het overkomt mij niet dus hoef ik toch niks te doen.

Daarnaast Garmin heeft het nog steeds over een storing en geen datalek dus het geeft mensen nog niet eens aanstalte om iets te doen.

[paralyz3]

Je zou inderdaad hopen dat zo'n grote partij als Garmin dat goed ingericht heeft inderdaad, dat er slechts enkele dagen aan data verloren gaan.

[sn33ky]

Een bedrijf met zoveel bedrijfskritische data, dat zelfs een beperkte impact heeft op de maatschappij (vliegtuigen), moet een backup oplossing hebben dat maar maximaal 24u aan gegevens verliest.
Paar dagen data (alleen in het weekend back-uppen) is niet meer acceptabel voor een bedrijf met deze impact op de wereld.

Dit is dus cruciale bedrijfsdata die zelfs een impact heeft op de maatschappij, en daar hebben ze hopelijk niet op bespaard.
Wegens de tijd dat ze nu al nodig hebben om het terug draaiende te krijgen vrees ik er voor dat ze geen degelijk backup/recovery systeem hebben opgezet.
Die ene IT-er die er werkt zal nu wel denken: Ik had jullie nog gewaarschuwd als je er investeert in IT beveiliging & backup. Speculatie natuurlijk, maar waarschijnlijk.

Edit: Impact maatschappij > "beperkte" impact maatschappij

[Reactie gewijzigd door sn33ky op 23 juli 2024 05:09]

[Maurits van Baerle]

Backup is nog relatief makkelijk, recovery zal (zeker in zo’n groot bedrijf) nog best lastig zijn.

Dat zal nog worden bemoeilijkt als je de malware zelf misschien nog niet gegarandeerd overal verwijderd hebt. Stel dat die nog ergens in een hoekje van je netwerk aanwezig is en je net gerecoverde systemen een paar uur later weer gewoon encrypt.

[JBVisual]

het lullige is dat veel van deze randsomware tegewoordig langere tijd de sleutel beschikbaar houd.
Alle bestanden worden langere tijd toegankelijk gehouden alsof er niks aan de hand is.

Alleen zal er op een bepaald moment een omschakeling komen, probeer nog maar eens een backup terug te zetten als alles tot een paar maanden terug al van encryptie voorzien is.

[asing]

Je zit in de goede richting te denken maar het klopt niet wat je zegt. De werkwijze zal gelijk zijn aan die van de universiteit Maastricht. Ze dringen binnen op een bepaalde manier. Daarna proberen ze vanaf hun "point of entry" verder te komen en door het netwerk heen te gaan. Dus via vulnerabilties verder het netwerk op.

Als ze dat gedaan hebben en ze zitten in zo veel mogelijk systemen, dan laten ze hun payload los en ben je het haasje. Bij de UM waren ze bijvoorbeeld al in oktober binnen terwijl alles met de kerst pas actief werd.

De enige vraag is nu hoe lang ze al bij Garmin binnen waren en of ze bijvoorbeeld ook de backup te pakken hebben gekregen.

[Geekomatic]

Het duurt verdacht lang, dus is vraag me af of ze wel een backup *schema* hadden,
bv elke dag + elke week + elke maand.
Zo niet, dan wordt het betalen...
(En als alle backups versleuteld zijn ook natuurlijk)

[Reactie gewijzigd door Geekomatic op 23 juli 2024 05:09]

[akooijman]

Ook als de backup in orde is moet je eerst je systemen waterdicht hebben voor je kunt terugrollen.
Het is best denkbaar dat er al een gaatje in de backup van vorige maand zat...
En hoe bruikbaar is een backup van een maand oud? Die is alleen zinvol als je bruikbare journals van je databases hebt. Een maand informatie over betalingen en dergelijke kwijt zijn is niet eenvoudig te herstellen.

[asing]

Zorgvuldigheid is de sleutel hier.

Ik weet wel dat ze na de ontdekking een aantal servers echt uit hebben gezet. Zo wilde ik basecamp downloaden maar dat ging dus niet. Dat heeft tot gisteren geduurd, toen was de server waarop de download stond weer in de lucht en bereikbaar.

Universiteit Maastricht was een paar maanden bezig voor ze weer operationeel waren. Dit soort dingen verhelp je niet even in een weekend.

[Aeternum]

Met alle respect, ransomware is een typisch lange adem spel. Wacht lang genoeg en je hebt de backups ook geïnfecteerd. En gezien de omvang en de duur kan je er vanuit gaan dat dat hier ook meespeelt. Je hoeft maar 1 verkeerde usb stick op een zwakke plek in je netwerk te krijgen (en die zijn er altijd) en het gaat mis.
-edit-
En sowieso wanneer ze systemen herstellen, moet er 100% garantie zijn dat de infectie niet opnieuw de kop opsteekt.

Ik vraag me sowieso af, of je met een uefi bios infectie dit soort hacks kan plaatsen?

[Reactie gewijzigd door Aeternum op 23 juli 2024 05:09]

[IStealYourGun]

Ik vermoed het wel, maar vermoedelijk ligt hun backup infrastructuur er gewoon ook uit en moeten ze dus beginnen met die te herstellen. Bovendien is de kans groot dat ze gebruik moeten maken van de off-site backup en die is doorgaans een stuk trager. Het is niet abnormaal dat dit een operatie is die enkele weken in beslag kan nemen.

[Cergorach]

Dan zal ik hetzelfde zeggen als de vorige keren dat het werd aangehaald. Encryptie van de file betekend dat de hele file is aangepast, in 24 uur zou dat betekenen dat enorme hoeveelheden data zijn aangepast en dat zou een enorme impact op de backup moeten hebben. Daar zou iemand al maanden geleden achter moeten zijn gekomen.

[akooijman]

Tenzij ze de backup op een andere manier corrumperen. Ik neem aan dat moderne backups versleuteld zijn? Je wilt tenslotte niet dat je off-site backup in verkeerde handen kan vallen. Als de sleutel gewijzigd en/of gekaapt is door de hackers heb je een interessante uitdaging.

[Cergorach]

Offsite backup heeft meestal ook offsite key. Anders heb je er nog niets aan als de primaire site niet beschikbaar is. Nu is hier natuurlijk aan te sleutelen, maar imho heb je dan zoveel toegang tot een bedrijf dat er makkelijker geld te verdienen is, zoals directe toegang tot betaling en fiattering.

[Aeternum]

Klopt, een backup systeem behoort te pullen en niet passief te ontvangen. Op die manier kan je denk ik voorkomen dat er executie van troep op je backupsysteem plaats vindt.

[Het.Draakje]

Een database dump is groot en wordt (bij de organisatie waar ik destijds werkte) inderdaad iedere dag geheel opnieuw aangemaakt. (En daarna stuur je hem door naar je backup-medium). Met een database van 100 gb (IIRC) had ik dagelijks (inclusief dump voor batch / na batch en incremental dumps) iets van 300 gb naar backup-medium. De rest van de server stelde vrijwel niets voor.

Het lijkt me ook niet slim voor malware om in één keer de hele server te encrypten. Stel dat je 30 dagen historie heb, dan encrypt je de eerste dag alles van dag -30. De volgende dag alles tot -27 enz. Dan is de kans op detectie het kleinst want jouw backup tijden lopen nauwelijks op.

Verder zou een organisatie iedere dag een full-backup strategie kunnen hebben, dan maakt het niets uit of het bestand gewijzigd is of niet; hij gaat gewoon de backup in. En dan maakt het niets uit in doorlooptijd.

Stellen dat het een enorme impact op de backup moet hebben is iets te kort door de bocht.

[Reactie gewijzigd door Het.Draakje op 23 juli 2024 05:09]

[Blokker_1999]

Ik zie niet direct in hoe dit een grote impact heeft op de maatschapij. Het is niet alsof vliegtuigen ineens niet meer kunnen vliegen. Daar zijn het net autonome systemen die om veiligheidsredenen net niet verbonden zijn met het internet.

En gesofisticeerde ransomware kan weken of maanden rustig liggen nietsdoen behalve backups infecteren. Als dat gebeurd wordt het net weer zeer moeilijk om snel even een backup terug te zetten. In tegenstelling tot het falen van de hardware is het bij ransomware altijd de vraag: kan ik mijn backups nog wel vertrouwen? En hoe moet ik die recovery doen om ervoor te zorgen dat die backups niet opnieuw onmiddelijk geïnfecteerd zijn?

[MijnKijk]

De FAA eist dat je GPS gegevens up to date zijn. Met het uitvallen van deze dienst voor Garmin devices, mag je dus niet meer vliegen met Garmin devices.

Daar zal een Boing of Airbus wellicht geen hinder van ondervinden, maar veel van het kleinere spul wel. Ze kunnen technisch dus wel vliegen, maar ze mogen het niet

[KRASH]

De FAA eist helemaal niet dat je GPS gegevens up to date zijn. De FAA eist dat je up to date kaartinformatie aan boord hebt. Of dat nou een papieren kaart is, een Garmin device of een app op je telefoon / tablet. Wijzigingen in kaartinformatie zijn ook niet van de een op de andere dag actief, dat word meestal ruim een maand van te voren aangekondigd met daarbij een effective date.

Ik open net even m'n Garmin Pilot app en die gaat vrolijk updaten, dus het lijkt erop dat ze daar geen last hebben van de ransomware.

[MijnKijk]

In de snelheid wat onzorgvuldig verwoord, maar de strekking lijkt me helder.

Verder, zie de link in het bericht van @KeiFront: https://status.flygarmin.com/

Wellicht hebben ze een oplossing gevonden voor die updates gezien de noodzaak, de status:

Our services are operational and we are monitoring them at this point.

Wellicht even checken of de data (nog steeds) van een Garmin server komt, of dat ze ergens een samenwerking hebben kunnen realiseren. Zou gezien de belangen goed zijn als concurrenten op zo’n moment even samenwerken.

Edit: linkje toegevoegd.

[Reactie gewijzigd door MijnKijk op 23 juli 2024 05:09]

[Birdstrike]

De FlyGarmin site was ook één van de eerste sites die weer online was. Net als inReach.

[dasiro]

de vraag is maar wat daar juist vereist is en ik weet niet of garmin connect ook voor de aviation devices gebruikt wordt; het lijkt me dat die volledig onafhankelijk opereren van dit consumer-platform.

[MijnKijk]

Alles ligt eruit, ook aviation. Er zijn meerdere berichten over te vinden, waaronder hier: https://www.bleepingcompu...locker-ransomware-attack/

While Garmin didn't mention it in their outage alert, multiple flyGarmin services used by aircraft pilots are also down, including the flyGarmin website and mobile app, Connext Services (weather, CMC, and position reports) and Garmin Pilot Apps (Flight plan filing unless connected to FltPlan, account syncing, and database concierge).

[Sandwalker]

Alles lag eruit. Connext werkt grotendeels weer. Idem voor flyGarmin. Ze geven allen voor sommige zaken nog een degraded performance ivm database rebuild.
Dat klinkt in ieder geval hoopvol.

Our services are operational and we are monitoring them at this point.

Garmin Pilot Apps: Operational
FlyGarmin: Operational
Connext Services: Operational
FltPlan.com: Operational

[Reactie gewijzigd door Sandwalker op 23 juli 2024 05:09]

[dasiro]

dat verandert de zaak natuurlijk, had ik je nog een spotlight kunnen geven, dan had je hem gekregen

[Verwijderd]

Zonder GPS mag je wel vliegen hoor! Je mag alleen het betreffende apparaat niet gebruiken. Daarnaast komt GPS natuurlijk niet van Garmin he? Mijn Garmin aero apparatuur werkt gewoon nog. Je kan alleen niet updaten en geen andere online services gebruiken. Maar ik vlieg vaak maanden zonder enige connectie te maken, niet veel aan de hand dus.

[MijnKijk]

I know, haha. Zie dit bericht van mij.

Was wat onzorgvuldig verwoord

[Blokker_1999]

Daar zijn wegen rond. Om te beginnen vervalt de huidige database niet dagelijks. Diie blijft een bepaalde termiojn geldig. En zelfs als deze vervallen is en je deze niet kunt bijwerken zijn er andere procedures om na te gaan of de data die je hebt nog geldig is of dat jij je bewust bent van die punten in je vliegplan die niet correct zijn op je GPS en je een plan hebt om daar omheen te werken.

[Saven]

Lekker weer VFR met de kaart op je schoot gaan dan

[Reactie gewijzigd door Saven op 23 juli 2024 05:09]

[Sandwalker]

Gelukkig is het helder vandaag. Dat wordt dus laag blijven.

[The Zep Man]

In tegenstelling tot het falen van de hardware is het bij ransomware altijd de vraag: kan ik mijn backups nog wel vertrouwen?

Wat een reden is dat je regelmatig in een organisatie je backups en de herstelprocedures moet (laten) testen.

Een ongeteste backup of een backup zonder herstelprocedure is geen backup.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 05:09]

[inversions]

Wat hij hier bedoeld is dat als de ransomware in de backup zit en je deze dus terug zet je er dus niets mee opschiet. De ransomware is dan ook weer terug.

Je kan als organisatie nog zoveel testen op herstelprocedures maar als de backup besmet is schiet je er niets mee op.

[Maurits van Baerle]

Je krijgt dan nog een lastige spagaat dat je dan wel een backup van weken of maanden geleden (waar de ransomware dus nog niet in zat) terug kunt zetten maar dat je dan ook met weken of maanden oude data moet gaan werken. Alles wat in de tussentijd toegevoegd is ben je dan kwijt.

[SuperDre]

Ja, duhh, maar die ransomware kan er dus best al wel weken of soms al maanden in zitten voordat het aktief wordrt dan is het ook pas echt doeltreffend.

[The Zep Man]

Wat hij hier bedoeld is dat als de ransomware in de backup zit en je deze dus terug zet je er dus niets mee opschiet.

Je 'zet niets terug' als je een backup enkel test. Je herstelt het op een ander systeem en probeert daar de data uit te lezen (bijvoorbeeld door bekende hashes en inhoud van bestanden te vergelijken). De herstelprocedures probeer je in een representatieve omgeving, maar dat staat los van de productieomgeving en los van de tests waarin data los wordt getest.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 05:09]

[SuperDre]

Maarja, en dan? De tests zijn succesvol, maar de ransomware zit er wel in... Enige wat je dan kunt proberen is om de backup terug te zetten op een systeem met een oude datum en hopen dat je dan de ransomware kunt schonen voordat het zichzelf daadwerkelijk activeert.

[IJzerlijm]

De enige echt goeie test zou hetzelfde effect moeten kunnen hebben als wat er nu gebeurd is: dagen outage en kolossale schade voor het bedrijf. En dat risico wil niemand nemen dus als er getest wordt zal dat aangekondigd zijn en er allerlei voorzorgen genomen die het effect van de test ondergraven.

Helemaal niets testen is zeker verwijtbaar als dat blijkt zo te zijn maar dit kan ook gebeuren als je je zaakjes schijnbaar goed op orde hebt.

[Het.Draakje]

Niet bepaald. Ik had gewoon iedere 6 maanden een uitwijk test (wettelijk verplicht in de branch). Testgegevens verzamelen in productie (inhoud van bepaalde datasets uitprinten). Test (database) server restoren met productie backup. Productie database down, juiste config laden (productie front-end laten wijzen naar test omgeving) reboot en testen of het inderdaad klopt.

Server down en productie config laden. Reboot. Vervolgens de database backup van de test-server weer restore in de test omgeving.

Downtijd was beperkt tot de reboot-tijden van de database servers. Maar verder geen impact. Uiteraard was je wel je zondag kwijt (maar dat zat voornamelijk in het vergelijken van de gegevens).

[IJzerlijm]

Dat is een goeie test die je in een hoop scenario's zal helpen maar het is geen cryptolocker attack die van een admin account komt met volledige rechten op alles voor een worst case scenario.

[Het.Draakje]

Een admin account met volledige rechten op alles?

Volgens mij moet men toch echt eens gaan denken aan een admin account per server en per applicatie. MS_Office_Install_User (schrijf rechten) MS_Office_Gebruik_Group (leesrechten) op MS_Office.

Ik zie geen enkele reden waarom een OS_Beheerder (Windows of Unix) een database software pakket moet kunnen installeren, laat staan waarom hij de database moet kunnen benaderen.

Het account waarmee de backup's gemaakt worden hoeft alleen leesrechten te hebben op de servers, niet in kunnen loggen op de servers en alleen de backup naar zich te pullen. Als een applicatie op een bepaalde tijdstip een backup wilt hebben dan doen je het met je applicatie-user naar een lokale directory en dat wordt t.z.t. opgepikt door de backup-daemon.

[Verwijderd]

Een ongeteste backup of een backup zonder herstelprocedure is geen backup.

Als er een slapende ransomware besmetting is hoeft dat helemaal niets te zeggen.

[akooijman]

Een ongeteste backup of een backup zonder herstelprocedure is geen backup.

Ik heb ooit geruime tijd backup gemaakt naar een defecte schijf. De controle op het succes van de backup was 'niet perfect'. Was geen leuke ontdekking toen de primaire schijf ook de geest gaf.

[Calypso]

Vergis je niet in de impact en de taktieken die dit soort ransomware aanvallen hebben. Zomaar een backup van 24 uur ervoor terugzetten geeft je geen garantie dat het probleem opgelost is.

Als je al het huidige netwerk vrij zou kunnen krijgen van de ransomware, dan nog heb je een grote kans dat de ransomware al eerder aanwezig was en pas sinds donderdag actief geworden is - dit soort aanvallen zijn niet simpelweg "kom binnen en encrypt" maar "kom binnen, blijf zitten, zorg voor verspreiding en wordt na een tijdje massaal actief". Dat zul je dus goed moeten uitzoeken.

[mkools24]

Maar je zou wel een backup kunnen terugzetten van net voor de encryptie begon, zodra je weet welk proces de encryptie aftrapt en vervolgens dat proces eerst blokkeren.

[Sluuut]

Als je (zoals ik zou verwachten als een bedrijf zoals Garmin) 500+ servers, 5000+ workstations en ook nog duizenden mobile devices hebt, dan zet je niet even een backup terug dan alles wat er is. Sterker nog, mogelijk is de backup oplossing ook buiten spel gezet en kunnen ze daar helemaal niet bij.

Stel je idee zou werken en je zou erachter komen welk proces de encryptie begint, dan kun je dat blokkeren, maar dan ben je nog niet bij de rootcause. Ik kan me voorstellen dat de hackers minimaal een aantal backdoors hebben ingebouwd en een aantal verschillende invalshoeken gebruiken. Je wilt geen single point of failure want dan is het makkelijk op te lossen en krijg je geen 10mil.

Lijkt me logisch om als eerste stap je gehele infra van internet fysiek te disconnecteren, alles uit te zetten, en daarna te onderzoeken of je bij je backup oplossing kunt (en of die infected is), en dan beginnen met de infra structurele dingen 1-voor-1 op te gaan zetten. Bv eerst 1 DC en dan onderzoeken of die al infected was op het moment dat de backup was gemaakt.

In ieder geval veel sterkte gewenst voor Garmin..

[mkools24]

Paar dagen zou ik al van balen, ik houd m'n sportstatistieken redelijk bij en ik train elke dag. Ik vind het nu al lastig dat het plat ligt. Zo zie je maar weer hoe fragiel clouddiensten zijn.

[teacup]

Ik hoop dat Garmin ook tot die conclusie zal komen en haar software in de nabije toekomst minder afhankelijk zal maken van de cloud services, ook als dit tot beslissingen leidt die niet per se in het belang van haar ecosysteem zijn.

[Rataplan_]

De pest is dat een beetje slimme ransomware al maanden in je systemen kan zitten, en gelijk gaat encrypten na een restore. Je zou wel eens héél ver terug moeten voor je een niet geïnfecteerd systeem kunt restoren.
Honden zijn het.

[mschol]

als ze hun netwerk al niet kunnen afsluiten.. vrees ik het ergste

[Blokker_1999]

Een virus kan heel snel om zich heengrijpen terwijl een netwerk volledig uitzetten toch echt tijd kost.

[teacup]

Als ik nog terugdenk aan dat drama bij de Universiteit van Maastricht en hoe lang dat duurde ben ik bang dat dit ook nog wel wat langer kan gaan duren.

Laat ik eerlijk zijn dat ik geen beeld heb hoe vlot een goed voorbereidde organisatie zich kan herstellen van een ransomaanval. Maar inmiddels meer dan twee etmalen voor een hersteloperatie lijkt mij lang worden. De waarschijnlijkheid dat dit vlot opgelost raakt wordt wat dat betreft nu ieder uur kleiner.

[Reactie gewijzigd door teacup op 23 juli 2024 05:09]

[slijkie]

Ik zeg betaal die 10M direct, wees niet zo dom. Elk uur dat het langer offline is kost je miljoenen. Klanten gaan geen Garmin meer nemen zo.

Klinkt heel stom, je wil criminelen niet hun zin geven, maar beperk de schade. Gooi er desnoods nog 5 miljoen aan prive onderzoek geld er aan uit daarna om ze op te sporen.

[radicalEMT]

Dat zou je denken, maar de Amerikaanse wetgeving staat het niet toe eenvoudigweg het losgeld te betalen.

[Postman]

Plus dat de gebruikte ransomware erg lijkt op die van een Russische groepering en er sancties zijn vanuit de VS richting Rusland dat het verbied om deze betaling te doen. Zie ook https://www.bleepingcompu...locker-ransomware-attack/ waarin ze bevestigen dat de seed van Evil Corp/Dridex afkomstig is.

[teacup]

Dit wist ik niet. Heb je hierover wat broninformatie? Trachtte hierover net zelfwat broninformatie te vinden. De staat New York bereidde eind 2019 wetgeving voor om betaling van ransomware losgeld door overheidsinstellingen te verbieden. Voor de bron was dit nieuws. Het artikel is niet gedateerd. Maar uit de context leid ik af dat het begin 2020 moet zijn geschreven. Het artikel refereert trouwens op zijn beurt aan een artikel van zdnet uit januari 2020 die deze wet wel degelijk een noviteit noemt. Door de nieuwswaarde begin 2020 leid ik af dat dit nog niet in de gehele VS het geval is.

Een andere bron, FBI, meldt ook niet dat het verboden is te betalen. Als het een VS brede regel zou zijn, zou ik daar er wel een opmerking over verwachten.

[Reactie gewijzigd door teacup op 23 juli 2024 05:09]

[Postman]

Probleem van betalen is dat je jezelf open zet voor nieuwe aanvallen (die betalen toch wel). Ook weet je niet zeker dat er niet nog een extra virus actief is of backdoor geopend is door de groep die je momenteel afperst. Na een maand is opeens alles opnieuw ge-encrypt en moet je 50 miljoen betalen. Ik snap dus heel goed dat ze niet zomaar tot betaling overgaan.

[SunnieNL]

Betalen van ransomware is geen garantie dat je systemen decrypt worden of dat je weer kan werken.
Soms krijg je de sleutel niet, soms werkt het decrypten niet.

[MijnKijk]

Amerikaanse wetgeving staat dat (mogelijk) in de weg. Dus best een delicate kwestie.

Dubbel

[Reactie gewijzigd door MijnKijk op 23 juli 2024 05:09]

[jaaoie17]

En wat als ze een poosje later weer binnen dringen en weer 10M vragen?

edit: Postman zei het al een beetje.

[Reactie gewijzigd door jaaoie17 op 23 juli 2024 05:09]

[Jelster]

Ja en zo gaat dat cirkeltje dus eindeloos rond. Plus je zal in de kaartenbak van gemakkelijk doelwit komen. Niet betalen dus. En volgende keer je backups en beveiliging wel goed op orde hebben.

[Satkan]

Ik ben niet zeker wat ze van plan waren met "het netwerk af te sluiten". Een ransomware kan al weken op je netwerk staan. Hierdoor sluipt die ook lekker mee in de back-ups van de laatste weken en kan je dus steeds hetzelfde voorhebben.

Een bedrijf zoals Garmin zal heus wel tapes gebruiken voor cold storage, maar die terugzetten kost ook veel tijd. Meestal zijn de back-ups op de servers ook encrypted en die op NAS ook infected.

Meestal een kwestie van te kijken welke back-up zeker en vast niet geïnfecteerd is, waar de meeste data verloren gaat en waar niet. En dat duurt lang.

Ik vraag mij af of bepaalde firma's in dit soort back-ups op zoek gaat naar een signature en die dan gebruikt om andere back-ups met schoon te maken, zodat je toch de nieuwste back-up kan gebruiken.

[DeCo]

Zou dan een strategie kunnen zijn door de backups in een gesloten omgeving terug te zetten en vervolgens enkel de ruwe data eruit te halen, die je terug zet in een nieuwe en schone omgeving? Ruwe data kan geen ransomware bevatten, volgens mij. Wel afbeeldingen, maar dat vind ik geen ruwe data.
Dit kost veel tijd en geld.. ze zullen ook andere wegen onderzoeken uiteraard.

[Maurits van Baerle]

Ik weet niet of dat hier zo is, ransomware is een beetje van na mijn tijd, maar het sluiten van een netwerk zou natuurlijk wel zin kunnen hebben als er sprake is van communicatie tussen malware en command & control server.

[t link]

Daarvoor hoef je niet het netwerk af te sluiten, gewoon de verbinding naar buiten doorknippen. Meestal zijn deze ransomewares slim genoeg om gewoon door te gaan zonder c&c server. de encryptie keys kan je toch van tevoren al terugsturen.

[Satkan]

Ik zou er mijzelf terug wat in moeten verdiepen, maar meestal komt het binnen via één of andere bijlage, chrome extension exploit, zelf er op gezet enzovoort. Daarna geeft die exploit een payload wat dan de encryptiesoftware is. Dat draait dan als een achtergrond process.

Welke data het is maakt niet echt uit, elk programma, elke file kan je uiteindelijk omvormen om een payload te geven. Via afbeeldingen enzovoort is echter makkelijker omdat dan het doelwit zichzelf infecteerd. Je hoeft dan namelijk niet binnen te breken via een exploit of andere vormen van social engineering.

De payload verwijderd zichzelf na het netwerk te infecteren, tijdens de ontplooing gaat deze op zoek naar elk volume waar er toegang is, al dan niet met exploit om admin privileges te verkrijgen. In die zin denk ik dat als je ruwe data over gaat laden, en de payload is nog niet geactiveerd, dat deze dan nog steeds in die ruwe data zal zitten.

Met wat geluk is er iemand hier die wat meer info kan geven over hoe je back-ups clean kunt krijgen. Ik hoor het graag.

[Caayn]

Het probleem zit hem ook in het opzetten van een schone omgeving. Dergelijke omgevingen zijn vaak enorm complex en hoe garandeer je dat in een schone omgeving enkel je eigen code draait? Je eigen code moet immers ook uit een back-up komen. Een corrupt script of een code inject vanuit een build straat zit er zo in of nog erger is de firmware aangetast en moet je hardware gaan vervangen.

[Reactie gewijzigd door Caayn op 23 juli 2024 05:09]

[aard1984]

Hebben die hackers ook privé gegevens hebben buitgemaakt? Kan me het zomaar voorstellen...

Misschien wat off-topic. Ik maak gebruik van een sporthorloge van Garmin, ziet er allemaal gelikt uit, en ben er hartstikke blij mee. Maar waarom moet mijn data altijd geupload worden naar de garmin-cloud? Waarom krijg ik als consument niet de mogelijkheid om mijn data op te slaan waar ik het zelf wil? Ik heb het liever in eigen beheer, en als ik het dan kwijt raak is het mijn eigen schuld. Ik ben in ieder geval niet afhankelijk van een externe partij.

[Webgnome]

Die optie heb je in beperkte mate wel. JE kunt met met je datakabeltje lekker alle trainingen van je Garmin halen en vervolgens deze bestanden in een compatibele software laden en je dingen doen.

Dat dat niet handig is dat is een ander verhaal.

[riotrick]

Inderdaad, en het is vrij simpel te doen. Sure het is wat omslachtiger dan de normale werking. Maar als tijdelijke optie kun je zo nog steeds bij je opgenomen data.

[KeiFront]

Laatste officiële respons van Garmin zelf: https://twitter.com/Garmin/status/1287100566959792128

We want to extend our sincerest apology for the inconvenience the outage has caused for our customers. We hope this FAQ answers some of the questions you have: http://garmin.com/outage

Enkel voor flygarmin zijn er nette updates te vinden https://status.flygarmin.com/, status van connect is nog altijd down https://connect.garmin.com/status/.

De crisiscommunicatie strategie van Garmin tijdens dit event is wel zeer slecht. Tijdig proactief communiceren naar je klanten en partners is de moeilijkste, maar beste oplossing. Nu komt de meeste informatie van derde partijen je wilt liefst hebben dat klanten rechtstreeks correcte informatie van jouw (Garmin) krijgen.

[Reactie gewijzigd door KeiFront op 23 juli 2024 05:09]

[J_van_Ekris]

Als je naar https://connect.garmin.com gaat, dan verwijzen ze door naar https://www.garmin.com/nl-NL/outage/

Daar staat al iets meer, onder andere een FAQ.

[Reactie gewijzigd door J_van_Ekris op 23 juli 2024 05:09]

[Coffee2Code]

En FAQ die nagenoeg niets zegt...

[J_van_Ekris]

Soms zijn de dingen die ze niet zeggen interessanter dan die ze wel zeggen: ze zeggen bijvoorbeeld niet hard dat de op de server opgelsagen gegevens zeker terug komen.

[Coffee2Code]

Exact, of dat historische gegevens zijn gestolen, ze hebben het alleen over de huidige ongesynchroniseerde gegevens in de FAQ.

[FireBladeX]

Mn fenix 6 is vorige week geleverd en ivm vakantie nog niet kunnen instellen. Nu zit ik wel degelijk te overwegen om het retour te sturen en even komende maanden afwachten wat voor schade dit allemaal gaat hebben. Als ik nog 2 weken moet wachten om mijn product in gebruik te nemen, terwijl het wel is geleverd. Als het dan DOA is, kan ik mij niet herroepen op de 14 dagen recht en moet het aangeboden worden ter reperatie. En aangezien de klantenservice niet bereikbaar is voor onbepaalde tijd...

[J_van_Ekris]

Heb je hem bij Garmin rechtstreeks besteld of via een webshop? Kans is groot dat ze bij Garmin nu niet eens weten wie wat wanneer besteld heeft en wat de betalingsgegevens zijn. Dus nu iets retour naar Garmin sturen zonder overleg met een helpdesk kan wel eens niet optimaal afgehandeld worden.

Een DOA kun je nu wel vaststellen. Gewoon horloge aanzetten. Veel kun je ook op je horloge instellen na eerste boot. Dus je kunt hem gewoon gebruiken en tot 200 uur activiteiten registreren (daarna overschrijft hij de 1e). Alleen kaarten laden etc wordt moeilijk.

[Reactie gewijzigd door J_van_Ekris op 23 juli 2024 05:09]

[teacup]

Dit was mijn reactie in eerste instantie ook. Een punt kan wel zijn dat niet is vast te stellen of het horloge (Bluetooth) goed communiceert met de app op de telefoon, omdat hiervoor de verbinding met online services voorwaardelijk is. Basis functionaliteiten zijn zonder de app initialisatie ook wel te checken.

De ellende nu een DOA te melden is alleen groter dan het risico dat de Bluetooth functionaliteit niet zou werken. Garmin begrijpt ook wel dat dit een overmacht situatie is, waarop je jezelf als klant op moet kunnen beroepen.

[Reactie gewijzigd door teacup op 23 juli 2024 05:09]

[xjs678qr]

Aan het einde van m'n fietstocht gisteren gaf mijn Edge dat de upload voltooid was. Misschien is het enkel de front-end die onbeschikbaar is?

[J_van_Ekris]

Mijn horloge en weegschaal willen beide niet syncen. Hoop dat men de boel langzaam aan aan het herstellen/herbouwen is.