Lurk: een voorbeeldige Cybercrime Inc.

De rechtszaak van de maker van de banking trojan van Lurk is eindelijk afgelopen. De groep werd een halt toegeroepen als resultaat van een nooit eerder geziene gezamenlijke operatie van een groot aantal autoriteiten en met de hulp van onze deskundigen. De criminelen werden in 2016 gearresteerd, maar het onderzoek en de rechtszaak sleepten zich nog vijf jaar voort. Dit is niet verwonderlijk, aangezien het aantal verdachten en slachtoffers ongekend hoog was. De leden van Lurk moesten met bussen naar de rechtbank worden vervoerd. En de dossiers liepen op tot 4000 delen (één deel = 250 pagina’s). De hoeveelheid werk was kolossaal en tijdrovend, verdachten analyseerden elk proces-verbaal en elke verklaring tot in de kleinste details, maar in 2018 stonden er 27 verdachten in de rechtbank.

Kaspersky houdt de activiteiten van de groep al sinds 2011 in de gaten. Ik hoorde voor het eerst over Lurk toen ik in 2013 bij het bedrijf kwam werken. Ik weet nog dat ik bij mezelf dacht: “Vang ze en je kunt zo met pensioen. Dan kun je je carrière wel als compleet beschouwen.” Vergeleken met de gebruikelijke cybercriminelen van die tijd leken ze zeer geavanceerd, zowel in technisch als organisatorisch opzicht. Dat gezegd hebbende, als ik Lurk vandaag zou tegenkomen, zou ik waarschijnlijk minder onder de indruk zijn en ze gewoon zien als een groep die best practices volgt.

Het vonnis van de rechtbank is een goed excuus om met terugwerkende kracht te bekijken wat er zo bijzonder was aan hun cybercriminele activiteiten.

Infectiemethode

We moeten beginnen met de infectievector. De aanvallers maakten gebruik van een watering-hole-tactiek, waarbij ze een redirect naar een exploit-kit op verschillende zakelijke mediawebsites plaatsten. De methode zelf was niet nieuw, maar in dit geval moest het slachtoffer (altijd een accountant), om geïnfecteerd te raken, de site tijdens zijn lunchpauze bezoeken (en alleen op dat tijdstip). De exploit-kit downloadde een lichaamloze trojan op hun computer, die alleen voor spionage werd gebruikt.

De cybercriminelen onderzochten eerst welke programma’s er op de machine draaiden, of er banksoftware of sporen van onderzoekssoftware aanwezig waren, en in welke subnetten de machine werkte (de aandacht ging vooral uit naar bank- en overheidsnetwerken). Met andere woorden: ze beoordeelden de “interessantheid” van de computer – en wisten precies wie ze wilden infecteren.

De belangrijkste malware werd alleen gedownload als de computer inderdaad interessant bleek. Anders zouden ze alle wachtwoorden stelen waar ze zij de hand op konden leggen, voor het geval dat, en daarna de malware van de machine van het slachtoffer verwijderen.

Communicatie met C&C

Niet minder opmerkelijk was het proces van informatie-uitwisseling tussen de trojan en de command-and-control-server (C&C). De meeste trojans uit die tijd bevatten het hard gecodeerde C&C-adres. De auteurs specificeerden gewoon de domeinnaam, en gaven zichzelf de mogelijkheid om, indien nodig, het IP-adres van de server te veranderen: dat wil zeggen, als ze de controle over het primaire C&C-adres zouden verliezen, konden ze dit eenvoudig vervangen door een back-upadres. Alles bij elkaar was het een tamelijk primitief beveiligingsmechanisme. Lurk was in dit opzicht heel anders: de groep gebruikte een methode die een spionageroman waardig was.

Voor een communicatiesessie berekent Lurk het adres van de C&C-server. De cybercriminelen gingen naar Yahoo en keken naar de aandelenkoers van een bepaald bedrijf (tijdens ons onderzoek was dat McDonald’s). Afhankelijk van de waarde van het aandeel op een bepaald tijdstip, genereerden ze een domeinnaam en verkregen hier toegang toe. Dat wil zeggen, om de trojan te besturen, keken de cybercriminelen naar de aandelenkoers op dat moment en registreerden een domeinnaam op basis van deze cijfers. Met andere woorden: het was onmogelijk om van tevoren te weten welke domeinnaam er zou worden gebruikt voor de C&C-server.

Dit roept een legitieme vraag op: als het algoritme in de trojan was ingebed, wat weerhield een onderzoeker er dan van om zo’n sequentie te genereren, een domeinnaam te registreren vóór de cybercriminelen dat deden, en gewoon te wachten tot de trojan er verbinding mee zou maken? Maar helaas, de makers van Lurk hadden voorzorgsmaatregelen genomen. Ze maakten gebruik van asymmetrische cryptografie. Dat wil zeggen, er werd een sleutelpaar gegenereerd, waarna de bot, die toegang kreeg tot de C&C-server, de openbare sleutel zou gebruiken om na te gaan of deze werkelijk aan de eigenaars toebehoorde (door de digitale handtekening te verifiëren). Dit is onmogelijk te vervalsen zonder de geheime sleutel te kennen. Dus alleen de eigenaar van de geheime sleutel kan verzoeken van bots ontvangen en commando’s geven – een onderzoeker van buitenaf kan de C&C-server niet nabootsen. Andere cybercriminelen gebruikten deze beschermingsmethode toen nog niet, dus als we een privésleutelbescherming op de server zagen, konden we er zeker van zijn dat het een Lurk-aanval was.

Georganiseerde infrastructuur

De opzet van Lurks processen verdient een aparte vermelding. Als andere cybercriminele groepen in die tijd slechts een willekeurig stelletje forumgebruikers waren (de één programmeerde, de ander cashte, een derde was de coördinator), dan was Lurk daarentegen bijna een volwaardig IT-bedrijf. Het is passender om ze te vergelijken met een groot softwarebedrijf dan met een cybercriminele groep. Wat het organisatorische niveau betreft, blijven ze tot op de dag van vandaag een modelvoorbeeld voor vele groepen.

Lurk werd gerund door echte professionals (hoogstwaarschijnlijk met solide ontwikkelingservaring) die een zeer georganiseerde infrastructuur opbouwden met managers en HR-personeel. In tegenstelling tot de meeste bendes, betaalden ze hun werknemers een salaris (in plaats van een percentage van de opbrengsten). Ze hielden zelfs wekelijkse briefings, wat in die tijd volstrekt ongehoord was. Kortom, het was een “voorbeeldig” kwaadaardig bedrijf.

Ze hadden zelfs een duidelijk gestructureerd, op rollen gebaseerd systeem om de toegang tot informatie te beperken. Na hun arrestatie kregen sommige groepsleden de correspondentie van hun bazen te lezen en beseften toen pas dat ze niet eerlijk werden behandeld.

Ze legden al hun activiteiten nauwgezet vast, in veel grotere mate dan tal van IT-bedrijven van vandaag de dag. Dit kwam het onderzoek natuurlijk zeer ten goede. En misschien leidde dat uiteindelijk tot hun ondergang: hoe systematischer je aanpak is, hoe makkelijker je te traceren bent. Hier zijn wat voorbeelden.

Kennisbanken

De Lurk-groep hield een gedetailleerde kennisbank bij, duidelijk onderverdeeld in projecten. Elk project was slechts toegankelijk voor een bepaalde kring personen, d.w.z. dat de deelnemers aan het ene project niet op de hoogte waren van de activiteiten van het andere. De projecten varieerden sterk in omvang, van zeer technisch tot organisatorisch. De technische projecten waren daarnaast ook weer onderverdeeld in niveaus. De ontwikkelaars van trojans hadden bijvoorbeeld alleen toegang tot de kennisbank over verwante onderwerpen: hoe antivirussen te omzeilen, hoe te testen, enzovoort. Maar er waren ook algemene databanken over operationele veiligheid (vergelijkbaar met echte veiligheidsvoorschriften in grote bedrijven). Deze gaven informatie over hoe Lurk-medewerkers hun werkstations moesten instellen om detectie te vermijden en hoe ze hulpmiddelen die anonimiteit zouden garanderen moesten gebruiken.

Toegang tot informatie

Om toegang te krijgen tot de informatiebron van Lurk moesten de cybercriminelen via verschillende VPN’s verbinding maken met een server. Zelfs dan kregen zij alleen toegang tot bot-management. Vervolgens kreeg elke werknemer zijn eigen certificaat en zijn eigen account met verschillende rechten. Met andere woorden, het was als een gewoon bedrijfsnetwerk dat was opgezet voor het werken op afstand. Als het ze niet aan 2FA (tweestapsverificatie) ontbrak, hadden ze in principe als een modelbedrijf kunnen worden beschouwd.

Fysiek bevonden alle servers zich in verschillende datacenters en in verschillende landen. Wanneer u een van hen op virtueel niveau bereikt via een VPN, kent u het echte IP-adres van de server niet. Het was grotendeels de reden waarom de groep zo moeilijk te doorgronden was.

Ontwikkeling

De Lurk groep had goede opslagplaatsen voor de broncode, geautomatiseerde build en multi-step testprocedures, een productie server, een testserver en een ontwikkelserver. Ze waren in wezen een serieus softwareproduct aan het maken: op elk willekeurig moment hadden ze een productie-, test- en ontwikkelaarsversie van de trojan.

De gemiddelde C&C-server van een typische trojan kon toen verzoeken van bots ontvangen, ze in een database loggen en een beheerderspaneel verschaffen om ze te beheren. Dit alles werd effectief geïmplementeerd op één enkele pagina. Lurk implementeerde het beheerderspaneel en de database afzonderlijk, terwijl het mechanisme voor het verzenden van antwoorden voor bots volledig werd verborgen door een intermediaire dienst.

Exploit-kits

Lurk had drie exploit-kits, die elk drie verschillende namen hadden: een interne, verzonnen door de ontwikkelaars; een voor klanten en partners; en een toegewezen door onderzoekers. De auteurs van Lurk gebruikten niet alleen hun eigen ontwikkelingen, maar verkochten ook exploit-kits aan andere cybercriminelen. Bovendien hadden de versies voor “partners” een andere code – duidelijk een poging om ze te vermommen als een andere zeer populaire exploit-kit.

De ondergang van Lurk

Uiteindelijk hebben alle trucs die de cybercriminelen hebben uitgehaald weinig geholpen. De meeste leden van de groep zijn uiteindelijk gearresteerd. Maar dat gebeurde pas nadat er behoorlijke schade was aangericht: tijdens hun lange carrière wisten de aanvallers ongeveer 45 miljoen dollar te stelen. Onze deskundigen bestudeerden hun methoden bijna zes jaar lang (wat overigens waardevolle ervaring opleverde die we blijven gebruiken om cybercriminaliteit te bestrijden).

Voor degenen die geïnteresseerd zijn in de voor het bedrijfsleven relevante conclusies uit deze saga, bevelen wij deze post aan. Een gedetailleerde technische analyse vindt u in onze Securelist-post.