Vrijwel iedere inzet van het Eye Security Incident Response-team levert nieuwe leermomenten op. Deze momenten delen we om cybersecurity- en IT-professionals te informeren. Kennis over de tactieken, technieken en procedures (TTP's) van een aanvaller kan immers ook nuttig zijn voor andere incident responders. Die kennis over de modus operandi biedt een aanzienlijk voordeel als je een aanval succesvol kunt toeschrijven aan een partij.
Tijdens een recent incident dat we hebben toegeschreven aan de 8Base-ransomwaregroep, hebben we diverse nieuwe en interessante TTP's gezien, die we hieronder met je delen.
Over het ransomware-onderzoek
Het team van Eye Security werd door een organisatie ingeschakeld nadat zij ontdekten dat ze het slachtoffer waren geworden van een ransomware-aanval. In deze blog refereren we naar deze organisatie als 'het doelwit'. We werkten samen met het management en het IT-team van het doelwit om het incident snel te onderzoeken en te verhelpen. Dat leverde een succesvolle uitkomst op, waarbij we hun infrastructuur snel wisten te herstellen zonder dat we het losgeld moesten betalen.
Om de vertrouwelijkheid en anonimiteit van de klant te behouden, kunnen we niet overal in detail treden. Maar dit belet ons niet om de onderstaande informatie te delen om interessante inzichten te bieden.
Ontdekking van de aanval
Het doelwit ontdekte een losgeldbrief die achtergelaten was op een van de getroffen hosts. Dat leidde direct tot onze eerste verrassende ontdekking: de brief was gelinkt aan een ongebruikte en offline .onion-website. Waarschijnlijk kwam dit doordat er een verouderde versie van een encryptor gebruikt werd. Het gevolg was dat het doelwit geen mogelijkheden had om in contact te komen met de aanvaller, zelfs als zij het losgeld hadden willen betalen.
Dit leek een fout te zijn, waardoor wij vermoedden dat de 8Base-ransomwaregroep niet verantwoordelijk was voor de aanval, ook al claimde de aanvaller wel tot deze groep te behoren. We hielden alle opties open, aangezien het bij incident response een significant voordeel biedt als je je tegenstander en zijn TTP's begrijpt. Later werd de datalekwebsite van de 8Base-groep geüpdatet en bevatte deze ook informatie die gestolen was van het doelwit. Daardoor konden we bevestigen dat we wel met 8Base te maken hadden.
Tijdens het onderzoek ontdekten we dat de aanval zo gepland was dat deze tijdens het weekend zou plaatsvinden – het moment dat het doelwit het meest kwetsbaar is. De tijdlijn en acties worden hieronder besproken.
Eerste aanvalsdag
- Initiële toegang wordt getraceerd naar de SSL VPN van het doelwit. De aanvaller gebruikte een service-account met hoge privileges. We hebben geen onsuccesvolle loginpogingen gezien. De inloggegevens waren dus al in het bezit van de aanvaller. . Aangezien dit een service-account was, konden de inloggegevens niet tijdens een eerdere phishing-aanval gestolen zijn. We vermoeden dat ze gestolen zijn via een initial access broker. De logs tonen geen verdere gerelateerde informatie, dus we gaan ervan uit dat ze enige tijd geleden zijn buitgemaakt.
2. De aanvaller bewoog lateraal naar een andere host in het netwerk, direct nadat ze de SSL VPN-verbinding hadden opgezet. Dit werd gedetecteerd door de Endpoint Detection and Response (EDR) van deze host. De daaruit resulterende waarschuwing werd echter niet opgemerkt. De aanvaller dumpte vervolgens de registry hives en vervolgde zijn ontdekkingsproces. Na een paar uur stopte de activiteit op de VPN.
Tweede aanvalsdag
- De aanvaller keerde aan het begin van de avond terug. Firewall-logs tonen dat het volledige /24-subnet gescand werd op zestien verschillende TCP-poorten (TCP-poorten: 22, 80, 135, 139, 443, 445, 1556, 3389, 4119, 4343, 5800, 5900, 8000, 8080, 9392, 9443 en UDP-poorten: 137, 161, 5353). Ten minste één van deze poorten wordt gebruikt door back-upoplossingen als Veeam (zoals TCP/9392). Zoals verwacht zochten de aanvallers actief naar back-ups om deze te saboteren – een standaard voorbereiding op een ransomware-aanval.
2. De aanvaller kreeg daarna toegang tot de domain controller. Het is onduidelijk hoe ze de inloggegevens in handen hebben gekregen. We vermoeden dat dit mogelijk via de registry hive-dump op de eerste dag is verlopen, aangezien er geen meldingen waren gerelateerd aan misbruik van inloggegevens – zoals een LSASS-dump – op de hosts in het aanvalspad. Als de aanvaller de inloggegevens al in bezit had voordat de aanval begon, hadden ze deze waarschijnlijk gebruikt voor de initiële toegang. 8Base staat niet bekend om zijn subtiele aanpak, maar geeft de voorkeur aan snelheid. Als ze de inloggegevens gebruikt hadden, was het proces zeker sneller verlopen.
3. De voortgang ging nog sneller nadat een tweede aanvaller aan de slag ging. We ontdekten een tweede IP-adres op de SSL VPN en wisten daardoor dat er nu twee aanvallers betrokken waren, die allebei Windows virtual machines (VM's) gebruikten.
4. We zagen hoe de aanvallers fileshares benaderden. Alle activiteiten verliepen op dit moment via de SSL VPN. De aanvallers probeerden geen malware in te zetten om een host op locatie te compromitteren of om een bastion host naar eigen hand te zetten voor meer heimelijkheid. Ze realiseerden zich waarschijnlijk dat ze de SSL VPN konden blijven gebruiken, dus zagen geen reden om de aanval gecompliceerder te maken.
5. De aanvallers maakten vervolgens diverse 'fouten' toen ze via RDP verbinding maakten met de Windows-hosts van het doelwit. We zagen hoe een nieuwe Windows-hostnaam toegang kreeg tot de VPN, die we konden koppelen aan de groep voor toekomstige referenties. Vervolgens probeerden ze in te loggen op de hosts van het doelwit als UserName en kali. Dit zijn de standaard inloggegevens voor de tools die zij gebruikten om toegang te krijgen tot de hosts van het doelwit. Dat ze deze niet vervingen door de correcte, gestolen inloggegevens demonstreert hun ietwat agressieve aanpak en voorkeur voor snelheid.
Derde aanvalsdag
- De aanvallers keerden midden in de nacht/vroeg in de ochtend een laatste keer terug, waarbij ze nog altijd de SSL VPN gebruikten als toegangspunt voor het netwerk van het doelwit. In deze laatste fase compromitteerden ze een Windows-host en downloadden ze hun tools daarnaartoe. We ontdekten Netscan, hun encryptor (genaamd Fast.exe) en AnyDesk, een remote monitoring and management (RMM)-tool. Ook deze stap genereerde EDR-alerts. Als er gemonitord was, had dit ertoe geleid dat de aanvallers ontdekt werden. Maar inmiddels waren de aanvallers er vrij zeker van dat hun activiteiten niet gemonitord werden. Ze gingen dus door met hun acties, waarbij ze een significant aantal waarschuwingen genereerden via de EDR van het doelwit.
2. Vervolgens startten de aanvallers een FTP-sessie, direct via het internet, vanaf een gecompromitteerde host naar hun Windows VM. Dit gebruikten ze om tientallen gigabytes aan data te stelen. Dit werd allemaal gemonitord en gelogd door de firewall van het doelwit – nog een signaal van een lopende aanval.
3. De laatste stap was het versleutelen van de data van het doelwit in zijn VMware-omgeving. Verrassend genoeg gebruikten de aanvallers daarbij geen encryptor die direct op een ESXi-hypervisor draait, maar besloten ze om de schijven op een gecompromitteerde Windows VM in het netwerk van het doelwit te mounten en ze vanaf daar te versleutelen. Dit is een nieuwe TTP en een die we nog niet gezien hebben in de OSINT-bronnen die we gebruiken. Dit heeft langer geduurd dan wanneer ze een encryptor hadden gebruikt die direct op de hypervisor geïnstalleerd was. Maar zoals we gezien hebben, waren de aanvallers nu zeker van hun succes. Zelfs als ze gedetecteerd werden en niet alle data van het doelwit wisten te versleutelen, konden ze het doelwit afpersen door te dreigen alle gestolen data te lekken.
Het herstelproces
Nadat de encryptor gedraaid werd, konden de VMware ESXi-machines niet langer opgestart worden. Een aantal van deze machines werd onbruikbaar en moest opnieuw geïnstalleerd worden.
Toen we een ESXi ontdekten met de ransomware-binary die nog steeds draaide op een virtuele gastmachine, is een incident responder van Eye Security bij het kantoor van het doelwit langsgegaan om dit te onderzoeken. We zagen hoe nieuwe bestanden op de schijf van de ESXi versleuteld werden zodra ze werden aangemaakt. We hebben logs en forensische artefacten verzameld in de hoop de gebruikte encryptiesleutels te vinden. Daarna besloten we om de ESXi-machines volledig opnieuw te installeren. (Zie '8Base-ransomware - Sleutel- en bestandherstel' voor meer informatie.)
Een deel van de modus operandi van 8Base is om actief lokale back-ups te zoeken en te vernietigen. Gelukkig had het doelwit onveranderlijke back-ups op een andere locatie, waarmee we de gehele infrastructuur konden herstellen.
Ieder hersteld systeem werd in een beperkte netwerkomgeving online gebracht, zodat onze incident responders onze EDR-agent naar voorkeur konden installeren. Dit zorgde ervoor dat we de herstelde systemen direct konden controleren op verdacht gedrag, zoals achterdeurtjes, en ze konden blijven monitoren en digitaal forensisch bewijs konden verzamelen.
Dit is een standaard onderdeel van de incident response-dienstverlening van Eye Security. We voegen de endpoints van klanten automatisch een maand lang toe aan onze MDR-dienst. Deze aanpak zorgt voor een snelle, maar veilige restauratie van de omgeving. Dreigingen worden snel opgepikt en geneutraliseerd, waardoor het klanten veel minder tijd kost om terug te keren naar de gebruikelijke activiteiten.
Eye Security's unieke incident recovery-aanpak stelde ons in staat om de omgeving van de klant binnen twaalf dagen volledig te herstellen, met minimale impact op de zakelijke activiteiten. Tijdens dat proces werden eventuele risico's volledig gemitigeerd door de managed detection and response-dienst van Eye Security.
Conclusie
8Base is op dit moment een van de meest productieve ransomwaregroepen en zoals je kunt zien zijn hun methodes soms weinig subtiel. Dit resulteert in meer schade dan alleen versleutelde bestanden, wat blijkt uit de vernietigde ESXi-hosts. Je zou verwachten dat als slachtoffers inzien hoe groot de hersteloperatie is, zelfs nadat er betaald is om de data te ontsleutelen, dat ze wel twee keer nadenken voor ze betalen.
Er was nog één laatste stuk van dit verhaal dat zich afspeelde. Eye Security en de teams van het doelwit hebben tijdens dit proces geen contact opgenomen met 8Base. Zelfs als het doelwit het losgeld had willen betalen, was dit niet mogelijk geweest omdat de .onion-website in de losgeldbrief niet bereikbaar was. Het doelwit heeft een aantal e-mails en een telefoontje ontvangen gerelateerd aan de aanval. De beller claimde namens 8Base te handelen en wilde onderhandelen over het losgeld. Maar ze waren veel te laat, zelfs als het doelwit interesse had gehad.
Deze ransomwarezaak was niet geavanceerd of baanbrekend. 8Base kon zonder problemen toegang krijgen tot het netwerk van het doelwit en daar misbruik van maken.
Ze werden op geen enkel moment tegengewerkt, ook al genereerde de aanwezige EDR-oplossing bruikbare waarschuwingen. Als er na een van die vroege waarschuwingen wel menselijk ingrijpen had plaatsgevonden, zou de aanvallende partij het veel moeilijker hebben gehad en was het hele incident waarschijnlijk te voorkomen geweest.
Hoe je bedreigingen voor kunt zijn
Er waren verschillende momenten tijdens deze aanval waar een activiteit een waarschuwing produceerde die onderzocht had moeten worden. De timing van de aanval speelde echter een grote rol in het succes ervan.
Dit is niet ongebruikelijk. Aanvallers realiseren zich dat veel organisaties geen budget of middelen hebben om hun EDR 24/7 te monitoren. Daarom schakelen veel organisaties MDR-aanbieders in. De meerderheid zou al tijdens het eerste stadium van de aanval hebben ingegrepen, toen de laterale beweging werd gedetecteerd op de server waarvan data werd gestolen.
Als het doelwit een Eye Security MDR-klant was geweest, zou de aanval dit stadium waarschijnlijk niet eens hebben bereikt. Een fundamenteel onderdeel van ons onboarding-proces is om een aantal scans van het aanvalsoppervlak van een klant uit te voeren om hun security posture te beoordelen.
We brengen deze als door mensen geleide inzichten naar voren. In dit geval zouden we de onnodig uitgebreide privileges van het service-account hebben opgemerkt. Zonder deze privileges was de aanval al over geweest voor deze begon.
Maak je je zorgen over het beschermen van jouw netwerk tegen ransomware? Nieuwsgierig hoe Eye Security kan helpen? Maak nu een afspraak:
