Onderzoekers vinden M1-compatibele malware op bijna 30.000 Macs

Onderzoekers hebben op bijna 30.000 Macs met de nieuwe M1-chipset een malware-variant aangetroffen die compatibel is met die architectuur. Het is niet de eerste voor M1 op maat gemaakte malware in het wild, maar opvallend is dat hij nog geen payload heeft.

De onderzoekers stellen tegenover Ars Technica dat de malware contact houdt met command & control-servers die bij Amazon en Akamai gehost zijn, waardoor ze moeilijk te blokkeren zijn. Wat precies het startsignaal voor de malware is, is ook niet bekend. Wie nu de binaries van de malware zelf uitvoert, wordt alleen begroet met de berichten 'Hello World!' en 'You did it!'. Opvallend is verder dat de malware een zelfvernietigingsmechanisme heeft, zodat het geen overtollige sporen achterlaat na het inzetten van de payload.

Wat al wel duidelijk is, is dat de malware aardig besmettelijk is. De onderzoekers van Red Canary stellen dat dat onder andere komt doordat er ook compatibiliteit is voor x86_x64-processors, waar oudere Macs op draaien. Ars Technica noemt de bijna 30.000 ontdekte infecties 'indrukwekkend'. De besmettingen zijn voornamelijk geconcentreerd in West-Europa. MalwareBytes tekent ook aan dat de werkelijke hoeveelheid besmettingen waarschijnlijk veel hoger is, aangezien ze ze niet allemaal hebben op weten te sporen.

De onderzoekers speculeren dat de malware zich wellicht verspreidt via malafide zoekresultaten en zich voordoet als een legitieme app. Dat denken ze omdat de malware na succesvolle installatie de url opvraagt waar de installer oorspronkelijk vandaan komt.

De researchers, die van Red Canary en MalwareBytes afkomen, stellen dat de informatie met de infosec-gemeenschap gedeeld moet worden, ondanks dat de malware momenteel nog niets doet. De malware, die ze Silver Sparrow noemen, zou in de toekomst een zeer schadelijke payload kunnen krijgen. In het rapport staat ook hoe Mac-gebruikers kunnen onderzoeken of de malware op hun systeem aanwezig is.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (124)

For those who want to check if their Mac has been infected, Red Canary provides indicators of compromise at the end of its report.

Bron: https://arstechnica.com/i...as-security-pros-stumped/

Artikel met de indicators: https://redcanary.com/blog/clipping-silver-sparrows-wings/

Bij mijn werk kom ik zeer vaak mac gebruikers tegen die denken dat een mac van nature veilig is en daarom geen enkele maatregel nemen tegen mogelijke besmettingen.
De laatste besmetting die ik tegenkwam in ons gastennetwerk was op een mac.

Ik denk dat ondanks een minder marktaandeel van Apple, dat ze wel vaker problemen gaan veroorzaken.

Ik merk dat bij Windows gebruikers er vrijwel altijd antivirus maatregelen zijn genomen. Vrijwel alle providers, in Nederland in iede geval, hebben zelfs een gratis versie voor hun klanten. Ook voor Apple computers.

Is niet nodig op een Mac. Ik gebruik het al 6 jaar nu en heb nog nooit een virusscanner of wat dan ook nodig gehad.
Zolang je geen vreemde bestanden opent en uitvoert is er niets aan de hand.

Misschien ben je heel verstandig als je op internet bent, maar de hoeveelheid Clop-besmettingen op Macs die ik in de afgelopen 1,5 jaar bij klanten heb moeten helpen verwijderen, is triest. En de meesten zeiden ook "maar ik heb toch een Mac? Dan kan dat toch niet?" Wel dus.

Is niet nodig op een Mac. Ik gebruik het al 6 jaar nu en heb nog nooit een virusscanner of wat dan ook nodig gehad.
Zolang je geen vreemde bestanden opent en uitvoert is er niets aan de hand.

Lekker naief. Ook op Apple systemen zijn er exploits voor remote code execution zonder dat bewuste interactie van de gebruiker vereist is hoor. Zero-days in Safari en andere Mac software genoeg.

[Reactie gewijzigd door R4gnax op 22 februari 2021 21:20]

Maar dat geldt net zo goed voor een Windows-computer. Een driveby-aanval via een legitiem advertentienetwerk is dan nog steeds even reëel als gevaar.

Een Mac is van nature ook veilig. "Antivirus" en meer zit standaard ingebouwd in macOS, een 3rd party "virusscanner" heeft geen enkel nut en geeft alleen maar ellende.

Apple Platform Security

App security overview

Als je ook naar andere partijen kijkt wordt daar anders over gedacht.
En ik heb zelf van een macbook pro via malwarebytes foute software moeten verwijderen. Die was zo vervelend dat de provider de verbinding had afgesloten.
Dus niet nodig is echt niet waar.

https://www.tomsguide.com/best-picks/best-mac-antivirus

[Reactie gewijzigd door HoleinOne op 21 februari 2021 23:34]

Lees dan het volgende artikel eens door om te voorkomen dat je nog eens malware installeert i.p.v. 3rd party 'antivirus' software te installeren die de ingebouwde macOS beveiligingsmechanisme omzeilt...

Effective defenses against malware and other threats
https://discussions.apple.com/docs/DOC-8841

[Reactie gewijzigd door cavemees op 24 februari 2021 20:47]

Ik doe het beheer van een bedrijfsverzamelpand met een semi openbaar gastennetwerk. Daar was een van de mac 'gebruikers', iemand die echt alleen maar een argeloze gebruiker is, besmet.
Verder is het gastennetwerk compleet los van andere gebruikers en totaal niet kritisch. Dus het was verder geen probleem.

Ik geloof dat er voorlopig niet eens goede en vooral compatibel antivirussoftware voor de m1 is

De laatste keer dat ik keek waren ze bij eset zelfs niet eens begonnen aan een bigsur versie

Hoe kan je zien dat je deze malware al hebt? Wil graag voorkomen dan mijn Macs deelnemen aan dit netwerk.

Check of je een of meerdere van de volgende bestanden hebt, dat lijkt een goede indicatie:

~/Library/Launchagents/verx.plist
~/Library/Launchagents/init_verx.plist
/tmp/version.json
/tmp/version.plist
/tmp/verx
~/Library/Application\\ Support/verx_updater
/tmp/agent.sh

Als je het volgende bestand "~/Library/._insu" hebt dan ben je (mogelijk) slachtoffer geweest maar heb je het niet meer.

(bron)

Edit: Het lijkt er op dat je enkel door het aanmaken van de file "~/Library/._insu" (bijv met "touch ~/Library/._insu" in de terminal) de malware zichzelf kan laten verwijderen.

[Reactie gewijzigd door JapyDooge op 21 februari 2021 12:59]

Dank, zeer handig.

Alleen vind ik (als blijkbaar leek) "~/library" niet duidelijk. Betekent dat "HardDiskNaam/library", "hd/users/GebruikersNaam/library" of beide?

[Reactie gewijzigd door Rutger Muller op 21 februari 2021 13:37]

De tweede inderdaad; ~ (tilde) verwijst altijd naar je home directory.

Meestal, maar niet helemaal, zoek maar eens op Tilde Expansion, bijvoorbeeld hier

Daar wordt tilde in combinatie met andere karakters gebruikt, bv. ~+. ~ an sich is altijd de home directory van de huidige gebruiker toch?

De laatste, de tilde ~ verwijst naar je gebruikersmap. Dus als je cd ~/Library/ intoetst kom je eigenlijk in /Users/gebruiker/Library.

Ik ben geen Mac gebruiker en wist dit niet. Wel grappig dat het op BSD bouwende Darwin niet de BSD (en linux, maar dat is in deze minder relevant) standaard /home gebruikt, maar afgeleid is van de de AT&T/ SyS V 'standaard' /usr, /user, /users.

Het is gewoon een UNIX ding, op alle UNIX gebaseerde systemen (MacOS, BSD, Linux etc.) kom je de tilde --> home directory reference wel tegen

Het is gewoon een UNIX ding, op alle UNIX gebaseerde systemen (MacOS, BSD, Linux etc.) kom je de tilde --> home directory reference wel tegen

Je begrijpt me verkeerd, die tilde ben ik zeer bekend mee

Jaren geleden maakte ik de overstap van een BSD variant naar System V variant en moest toen wennen dat de ~ een shortcut was voor /urs in plaats van de /home die ik gewend was op BSD. Een aantal jaren later stapte ik over op Linux en opeens was ~ weer een shortcut naar de gebruikersdirectory onder /home.

Darwin is een BSD variant op een Mach kernel, voor vandaag had ik dan ook verwacht dat de ~ op een Mac naar een directory onder /home zou verwijzen.

Alle Linux varianten zover ik weet gebruiken gewoon de ~ als home folder.
Dat andere Unix varianten dit aanpaste naar iets anders, is het weggaan van de standaard.
Maar goed, GNU is over het algemeen de variant die veel Linux OS's gebruiken.
BSD en dus Darwin vallen daar ook onder.

~ is used to represent the current users home folder in a path independent of the actual location in the filesystem it's nothing more than a reference. Maar ~ is zelf dus geen directory!

The actual location in the filesystem is usually different for every user (but not necesarily!) and also different by operating systems.

BSD unix has traditionally used the location /home/<username>

SysV unixes have used directories with a variation of user in the name like /usr/<username> or /users/<username>

Every Linux I ever used followed the BSD standard of /home<username>

Macs (Darwin) is the odd one out in that it is a BSD based system with the location in the filesystem following Sys V precedents.

All these systems use the ~ reference to refer to the current users personal directory.

So on the same Linux system for you
~/tmp/ would be /home/power2all/tmp/
And for me /home/omegasupreme/tmp/

And just because we can, on old Unix systems for the root user ~ was often / aka the root of the file system, while on more modern systems it refers to /root/. Both of which are not in the location where normal user directories are.

You can see why a reference like ~ is handy to have around

Jep maar heeft Mac OS geen geweven kernel net als Windows en hebben Linux en Unix dit normaal niet?

Geweven kernel? Wat is dat?

MacOS is een aangepaste versie van BSD met de Mach-kernel.

[ed.]Kleine correctie:
Een doorge-evolueerde Machkernel, namelijk XNU.

[ed2.]
Maar goed, de kernel heeft weinig te maken met hoe je door het bestandssysteem navigeert. Dat is volgens mij onderdeel van POSIX standaarden.

[Reactie gewijzigd door Keypunchie op 21 februari 2021 15:15]

Geweven kernel betekend gewoon Hybride. macOS gebruikt een hybride kernel van Mach3 en XNU.

Geweven kernel betekend gewoon Hybride

Wie heeft nu in hemelsnaam dat woord "geweven" bedacht? Voegt niet echt veel toe.

Blijkbaar rob1242 :-)

Vlak voor hij de mocro kernel uitvond!

Nee. XNU IS de kernel. Dit is een samenraapsel van BSD versie 4.x (en met FreeBSD code) en OSFMK. In het begin was het wel Mach, versie 2.5. Dit is aangepast later naar OSFMK

Bij Linux: kernel --> xserver --> De (windowmanager) De De draait losstaand van Xserver enz. Over het algemeen (als ik het goed heb) Je draait dingen ook vaak nog eens in userland.

Bij Unix zelfde als bij Linux. Alleen is Xserver van oorsprong X met later Xserver erbij volgens mij.

Bij Mac: mach/Darwin verweven met nexstep/X. Crasht 1 van de 2 dan gaat alles eraan. Windows heeft net zo'n constructie. Het heeft zijn voordelen maar ook nadelen.

Sorry ik kan dit nogal slecht uitleggen en heb de bel wel horen luiden maar weet volgens mij niet waar de klepel hangt. Kan iemand dit beter uitleggen en ook wat de gevolgen zijn op het gebied van security (ik dacht dat bij geweven het OS direct door een virus de Kernel kan aanvallen?) Maar geweven wel makkelijker en sneller te maken is en sneller werkt?

Bedoel je een microkernel?

Nee hybride. Mac osx is hybride geweven. Mach is op zichzelf een Mocro en Linux is modulair (monolitisch toch? ) Of zie ik dat verkeerd?

Mach is een Mocro

XNU is een hybride kernel ja. Linux is niet helemaal monolitisch meer, trouwens.

Was macOS maar opgebouwd rond een BSD kernel, dan kon je ook drivers voor macOS gebruiken op BSD. Helaas kan dat niet

Als ik het goed begrijp is het eigenlijk alleen het macOS userland dat oorspronkelijk van BSD komt. De hardware abstractie laag (I/O Kit en sinds macOS 11 DriverKit) lijkt in de verste verte niet op BSD dus op een kernel niveau valt er weinig uit te wisselen tussen macOS en BSD.

Volgens mij moet je in Mac OS sowieso eerst al een vinkje aanzetten om de Library directory te zien in Finder. Ik denk dat de gebruikers die daar bekend mee zijn en met die directories hun weg ook redelijk weten in de terminal emulator, en dus ook weten dat ~ (zonder toevoegingen) een verwijzing is naar je homedirectory.

[Reactie gewijzigd door mjz2cool op 22 februari 2021 07:31]

Staat een firewall op een Mac ook outbound wagenwijdt open zoals op Windows? Neem aan dat veel van deze botnets niks kunnen beginnen als je dit gewoon netjes locked zoals het hoort.

Tenzij deze malware geprogrammeerd is en privileges heeft om firewall rules zomaar aan te passen.

Mensen moeten eens wat meer security focussed zijn ipv. het OS alles maar laten regelen en er blindelings op vertrouwen.

Zo moeilijk is het toch niet om alleen programmas die je zelf aanwijst door de firewall heen te loodsen? In windows kan je gewoon mooie context menutjes maken hiervoor bv. :-)

[Reactie gewijzigd door Marctraider op 21 februari 2021 16:18]

Op basis waarvan concludeer je dat Mac gebruikers minder onderlegd zijn dan Windows gebruikers?

Rondom Macs heerst denk ik nog steeds het denkbeeld dat het gemaakt is voor de eenvoudige gebruiker die wil dat de computer en programma's het meteen doen zonder zelf nog allerlei instellingen te moeten doorvoeren en dat het daarbij veilig is, want, op Apple "immers geen virussen zoals op een Windows systeem". Iets wat onderhand natuurlijk allang achterhaald is maar goed..

"En dan zijn er nog Mac users, die zijn nog minder onderlegd. Beetje onrealistisch wat je hier stelt."

Maar goed dat je verder niets meer getypt had, want door deze opmerking was ik meteen afgehaakt met lezen. Wat een vooringenomen onzin, erg jammer. Jouw eerste zin ben ik het overigens wél mee eens.

Inderdaad, met een Windows machine ben je natuurlijk veel beter af als het aankomt op virussen.

Aangezien dit(geen Windows kopen/draaien) een standaard reactie is als er malware voor Windows opduikt, moet je dit denk ik vooral met een knipoog lezen(de drie laatste smilies zijn een niet zo stille hint). In beide gevallen is het een dooddoener, maar ik kan er in dit geval de humor zeker van inzien.

Als je een "honeypot" wilt opzetten, is Windows prima geschikt
(Één van de redenen waarom privé geen Windows gebruik)

[Reactie gewijzigd door MarcAngel0 op 22 februari 2021 08:21]

Lees eens, @bedanktjoh geeft aan dat hij wil weten of zijns macs het hebben.
Dan is het al te laat met jouw advies te komen.

Erg weinig info. Hieruit haal ik dat de MacOS-versie voor deze systemen een gat heeft dat direct op de hardware exploitable is. Hoe kan anders de architectuur een rol spelen?

Volgens mij maakt de architectuur niet veel uit, het is gewoon opvallend dat het gecompileerd is voor ARM omdat dit pas de tweede ontdekte malware variant is waar dat is vastgesteld. Op zich maakt het verder niet zo heel veel uit, compileren voor de M1 is gewoon een extra vinkje in xCode aanzetten en je code wordt voor zowel X86-64 en ARM gecompileerd.

De reden dat de malware developers waarschijnlijk bewust hebben gekozen om ook voor de M1 te compileren is dat het de succeskans verhoogt. Zeker als je wat obscuurdere dingen doet (zoals vaak het geval met malware) dan bestaat het risico dat de conversieslag die Rosetta2 met zich meebrengt onbedoeld van alles blokkeert of verstoort.

Het gaat om voor de M1 "op maat gemaakte" malware. Lijkt me niet dat ze alleen maar compiler-parameters bedoelen. Hoe dat compatible met x86 zou kunnen zijn snap ik dan ook niet. Of hebben we weer een malware/virus-bedrijf dat interessant loopt te doen met niks? Een malware voor MacOS zou kunnen maar dat is waarschijnlijk ook niet zo want dat zou waardevoller nieuws zijn dan dit. Een 0-day exploit die daadwerkelijk gebruikt is maar zonder kwaadwillende intentie...

[Reactie gewijzigd door blorf op 21 februari 2021 13:49]

De malware kent twee verschillende binaries, eentje voor x86-64 en eentje voor ARM. De xCode compiler kan gewoon twee verschillende binaries afleveren op basis van dezelfde code.

De onderliggende code is hier overigens op minieme punten iets verschillend per architectuur in in ieder geval hun succesmeldingen en de naam van het distributiebestand verschilt ook één letter.

Normaal gesproken stop je beide binaries in één bestand zodat een gebruiker niet hoeft te kiezen welke hij moet downloaden, bij het opstarten pakt het OS de meest geschikte binary voor het platform.

Ik vermoed dat ze hier voor afzonderlijke binaries hebben gekozen om de distributie zo klein mogelijk te houden. De URL waarvan de malware is gedownload wordt ook teruggestuurd naar de Command & Control server, vermoedelijk om er analytics op los te laten en de meest effectieve distributiekanalen te ontdekken. Misschien dat ze daarom ook een onderscheid hebben gemaakt tussen de twee architecturen.

[Reactie gewijzigd door Maurits van Baerle op 21 februari 2021 15:02]

Dat bedoel ik. Je kan op een systeem met een redelijke compiler je "hello world" omzetten naar binaries die specifieke hardware targeten, dus x8632/64, ARM, IA64, PowerPC, noem maar op. Maar dan heb je het over een programma dat niet op maat gemaakt is voor een bepaalde architectuur. Dat is bij een API-gebaseerd besturingssysteem op zich al onwaarschijnlijk. Ik ben geen MacOS-gebruiker maar ik vermoed dat je niet zomaar instructies direct op je hardware kan uitvoeren...

macOS heeft support voor "fat binaries". Dat wil zeggen dat ze gecompileerde programma's voor een of meerdere platformen in een enkel bestand zetten. Het OS kijkt in dit bestand en kiest dan de beste binary voor het systeem.

Ter voorbeeld:

• Malware.app (voor de gebruiker een "applicatie", maar in het echt een directory structuur) bevat 'Malware' (een exe-bestand zoals Windows dat kent).
• 'Malware' bestaat uit ELF headers, gecompileerde instructies voor Intel, en gecompileerde instructies voor ARM
• Het OS opent 'Malware' en ziet dat daar gecompileerde instructies voor ARM in staan, en voert deze uit.

ELF is een Unix/Linux/... bestandsformaat waarin staat hoe een executable is opgebouwd.

[Reactie gewijzigd door RuudAnders op 22 februari 2021 13:38]

Wat zegt het commando 'file' over het bestand? Dat is de executable vorm. Geen idee hoe dat op een dergelijk M1 systeem wordt genoemd.
Daarna kan er nog van alles aan conversies gedaan worden. Een executable die een programma in meerdere formaten bevat is alleen maar executable als die met de fysieke architectuur strookt.

Ik heb geen toegang meer tot een macOS systeem, maar file zegt iets als 'Universal Binary' met daarbij een opsomming van de architecturen die erin zitten.

Een executable is niets meer dan een bestand met daarin verschillende stukken informatie. De meest voorkomende stukken informatie zijn: object code, linker instructies, data, debug symbols. Dat is voor ieder OS hetzelfde, alleen gebruiken ze niet allemaal ELF. Bij een fat binary staat er sommige stukken informatie gewoon meerdere keren in. Het OS kiest dan een combinatie dat het snapt.

Zie ook: ELF, "Universal Binary".

Dat werkt alleen als je OS de software-layer heeft om dat te converteren. De executable code is niet hardware-compatible of direct laadbaar als het bestand niet initieel verstaanbaar is voor de native hardware. Oftewel elk 64-bit x86 OS kan alleen maar 64-bit x86 executable code lineair in RAM laden. Analyseren en vertellen wat het allemaal bevat of selectief een deel ervan laden is iets anders.

[Reactie gewijzigd door blorf op 23 februari 2021 10:55]

Dat het malware voor de m1 is, is wat dat betreft niet relevant. Alle software draait nu eenmaal beter als het native is voor de betreffende architectuur.

Erg weinig info. Hieruit haal ik dat de MacOS-versie voor deze systemen een gat heeft dat direct op de hardware exploitable is. Hoe kan anders de architectuur een rol spelen?

Volgens mij is het helemaal niet architectuur specifiek.

Het is meer een indicatie dat malware ontwikkelaars niet stil zitten en intussen ook voor M1 compileren.

Wat @Maurits van Baerle al zegt, het maakt weinig uit, kost nihil meer moeite om een voor M1 ‘native’ versie mee te geven.

Eerlijk gezegd is het bijzondere vooral de voor macOS hoge verspreidingsgraad, maar een titel met M1 er in wordt ongetwijfelt vaker aangeklikt..

De onderzoekers stellen
dat de malware contact houdt met command & control-servers die bij Amazon en Akamai gehost zijn, waardoor ze moeilijk te blokkeren zijn.

Waarom wordt het hierdoor moeilijker? Is het niet een kwestie van uitzoeken welke servers hier een rol in spelen en die door Amazon en Akamai te laten uitschakelen?

Ik denk dat ze bedoelen dat het blokkeren moeilijker is op apparaat niveau. De servers opsporen en uitschakelen zal niet het probleem zijn, maar als jij op jou apparaat of netwerk de communicatie wilt blokkeren maar deze server dat zal wat moeilijker zijn. Als het goed is het wel al vaker voorgekomen dat er een Adres geblokkeerd wordt en daarmee een heel aantal andere wel legitieme websites niet meer toegankelijk zijn.

Het format van de uitgaande data controleren op opvallende kenmerken of anders heel amazon blokkeren?
Er moet gewoon een TCP/IP transmissie naar een Amazon-server plaatsvinden. In het meest onwaarschijnlijke geval wordt de verbinding naar de desbetreffende server voorbij het Amazon-domein mogelijk gemaakt en gecaoufleerd door een hack zodat Amazon zelf op onderzoek uit moet om te kijken om welk systeem het gaat.

Amazon AWS als geheel blokkeren is niet te doen. Er draaien ontzettend veel websites op AWS waardoor je er als internetgebruiker feitelijk niet doorheen kan.

Alles met dezelfde bestemming als het "contact" naar die Amazon servers. Als het daaraan ligt is dat sowieso geen slecht idee. Wie wil er gebruik maken van een server die botnet-centrum is?

Maar het virus moet toch weten wat de nieuwe C&C server is, dat gaat toch vrij lastig indien zowel Amazon en Akamai beiden platgooien?

Dat is de active IP. Wie zegt dat de malware niet honderden IP’s heeft waarvan er 1 gebruikt wordt als de ene een time-out geeft?

Hoeft niet lastig te zijn om te achterhalen indien je de malware op een speciale machine gooit. Gewoon kijken welke IP-adressen het apparaat poogt te contacteren.

Dit moet je bij de bron aanpakken inderdaad, en je zou toch verwachten dat Amazon hier ook niet blij mee is cq meewerkt dit aan te pakken?

dat de malware contact houdt met command & control-servers die bij Amazon en Akamai gehost zijn, waardoor ze moeilijk te blokkeren zijn.

… vind ik daarom de vraag oproepen: Waarom kan dit niet aangepakt worden via Amazon en Akamai?

Ja lijkt me ook, zal toch ergens in de voorwaarden staan dat je die diensten niet voor cyber-criminaliteit etc mag gebruiken.Obv IP adres kunnen ze zo traceren welke omgeving het ist. Hoppa hele omgeving offline wegens schending gebuiksovereenkomst, klaar.

Omdat je dan je netwerk verkeer niet op ip address nivo kan blokkeren

Omdat je heel amazon en of akamai moet blokkeren, en dan heel veel andere (wenselijke) spulledingetjes niet meer zouden werken. Hierdoor is het vaak geen optie.

Ik vraag me dan af, is het verstandig dit te delen? Als de makers dit lezen, hebben ze dan niet ineens de druk om de payload te pushen?

Nuja, wat is het alternatief? Als je zwijgt kan het ook schade doen natuurlijk.

Net als met CVE's? Onder de pet houden voor niet-onderzoekers en pas naar buiten brengen als er al een fix is. Dit soort dingen zijn echt niet nieuw. Vraag me af of dat nu ook gebeurt is en de berichtgeving wat krom is of dat dit gewoon heel onverantwoordelijk is.

Ze weten zelf ook de aantallen via de Command and Control server.

Gaat niet om aantallen maar om dat nu bekend is dat er inactieve malware rond zwerft en er actief onderzoek gedaan wordt. Niet voor niets dat de ook een self-destruct gemaakt hebben.

Als iedereen zijn computer na 20:00 uitzet voorkomen we verdere verspreiding.

Offtopic: Haha ik moest lachen, mooie ref

Kijk! En dit mis ik nou heel erg op tweakers. Net dat ene beetje humor, mijn dag is weer goed

Daarom moet de +1 grappig ook weer terug... Nu krijgt iets grappigs vaak alsnog een 0 of -1.
En dus plaatsen de meeste mensen dan maar niks grappigs meer.

Hoezo? Met het nulletje is iets gewoon zichtbaar.

Bij mij is alles zichtbaar, anders krijgt een bericht met -1 geen kans op een eerlijk oordeel.

lol, gebeurt niet vaak dat ik hardop moet lachen door een comment op tweakers

Als iedereen zijn computer na 20:00 uitzet voorkomen we verdere verspreiding.

Patrick Wardle heeft er vorige week al e.e.a. over geschreven. Zijn tools zijn trouwens echt een aanrader ook. https://objective-see.com/blog/blog_0x62.html

Tis een grap, maar het klopt wel, als hij uit staat kan die niet verder verspreiden

En denk aan de 1,5 meter UTP kabel...
WiFi gebruik alleen met luchtreiniger voorzien van hepa filer 💪

En 1,5m tussen iedere computer om infecties te voorkomen.

Kijk ff op malwaredashboard.rijksoverheid.nl

Volgende malware heet dan ook Corona om(op internet) verwarring te zaaien!

Ik begrijp ook niet waarom de grote os'en niet standaard een lijst bijhouden met al het uitgaande tcp verkeer per uitvoerder en de inhoud ervan zonder versleuteling (opt in). Tenzij de malware eigen encryptielib en tcp-drivers bevat is alles zichtbaar voor het OS. Gebruik dat dan ook.
Een soort mitm maar dan gewoon lokaal ingebouwd. Maar nee hoor want dan gaat Netflix en vrienden weer klagen.

[Reactie gewijzigd door Mushroomician op 23 februari 2021 14:13]

zoals "netstat -a -b -f -v" doet? of wat mist er dan nog?

Dat werkt voor jij en ik maar een gui met historische logging en waarschuwingbeheer zou toch wel een stap vooruit zijn sinds de jaren 80. Standaard in het os als onderdeel van beveiliging

[Reactie gewijzigd door Mushroomician op 23 februari 2021 13:52]

Nouja, is dat realistisch? zeker meegewogen dat je het hebt over het loggen van inhoud zonder versleuteling; ga maar eens na hoe veel data we (onbewust) verstoken, waar kan je dat kwijt en als je zulke datahoeveelheden maar laat rolling-loggen per 24 of 48u naar een ssd, wat lever je dan in op de levensduur?

Wel makkelijk met je eens dat het hoog tijd zou worden als windhoos vrij inzichtelijk totaalverbruiken kan laten zien, maar met extra wensen als onversleutelde logging wordt het m.i. vrij snel onreëel

[Reactie gewijzigd door Annihlator op 23 februari 2021 14:03]

Opt in uiteraard. Nu moet je door een hoelahoop om een beetje de in en uitgaande verbinding van je eigen device te beheren.
Admin moet ten alle tijde "soeverein" blijven. Als douane optreden met een externe MITM is gewoon nergens voor nodig. Bovendien moeten sommige apps met Ssl-pinning (waaronder malware) opnieuw worden gecompileerd om eigen certificaten te vertrouwen omdat de malware de cert-store van het os negeert.
Dat is malicieus en simpel opgelost met de gegevens die al aanwezig zijn in het geheugen in runtime.

Maar nu even wat vragen van een 'gewone' (M1) Macbook gebruiker:
- Hoe kom je eraan / hoe kan je voorkomen dat je besmet raakt
- Hoe ontdek je het?
- Hoe kom je er vanaf?

[Reactie gewijzigd door pimsaint op 21 februari 2021 13:14]

Hoe je er aan komt is mij ook nog onduidelijk, maar het artikel suggereert dat deze malware enkel voor de M1 is. Dat is niet zo. De malware is er zowel voor x64_86 als arm (M1).

Staat toch gewoon in het artikel genoemd

De onderzoekers van Red Canary stellen dat de infection rate relatief hoog is mede dankzij het feit dat er ook compatibiliteit is voor x86_x64-processors, waar oudere Macs op draaien.

Het gebruik van 'M1 compatibiliteit' is ook een beetje clickbait in mijn ogen. "Gewone' x64 binaries werken sowieso al op M1 Macs, en het in XCode compileren als Universal Binary is een kwestie van een vinkje aanzetten. Het is niet zo dat de makers ongelooflijk veel werk hebben moeten steken in die M1 compatibiliteit, en het voegt ook niet eens iets unieks toe in dit geval.

Waarschijnlijk treedt infectie op via advertenties, dus zoals altijd activeer je adblocker.

hoe ontdek je het/hoe kom je er vanaf : onderstaand is hoe de malware zichzelf deinstalleert, en de files die verwijdert worden (alle files na het unix commando 'rm'), geven dus aan welke files aanwezig zijn als de malware actief is op je systeem :

if [ -f ~/Library/._insu ]
then
rm ~/Library/Launchagents/verx.plist
rm ~/Library/Launchagents/init_verx.plist
rm /tmp/version.json
rm /tmp/version.plist
rm /tmp/verx
rm -r ~/Library/Application\\ Support/verx_updater
rm /tmp/agent.sh
launchctl remove init_verx

[Reactie gewijzigd door Anoniem: 474132 op 21 februari 2021 14:00]

Je bent een "fi" vergeten.

Shit . Deze malware staat op een Mac van een vriend van me.

Weet iemand hoe je deze malware kunt verwijderen?

Even lezen?
JapyDooge in 'nieuws: Onderzoekers vinden M1-compatibele malware op bijna 30....

[Reactie gewijzigd door Deleon78 op 21 februari 2021 13:23]