Sinds januari 2025 volgen onderzoekers twee nieuwe backdoors in aanvallen tegen overheidsorganisaties in Centraal-Azië: OctLurk en SilkLurk. De slachtoffers bevinden zich onder meer in Afghanistan, Kirgizië, Tadzjikistan, Oezbekistan, Kazachstan en zelfs in Syrië. De getroffen organisaties werken in uiteenlopende sectoren, van zorg en onderzoek tot ministeries, logistiek, wetshandhaving, en publieke onderwijsinstellingen.
Wat deze campagnes extra zorgwekkend maakt, is de manier waarop de malware is opgebouwd: elke loader wordt aangepast aan het doelwit en gebruikt informatie uit de besmette machine om payloads te ontsleutelen. Daarnaast is zowel de code als de communicatie zwaar geobfusceerd, waardoor analyse lastig is en verdedigers extra moeite moeten doen om indicatoren betrouwbaar te herkennen.
Waarom OctLurk en SilkLurk opvallen
De achterliggende tooling bestaat niet uit één simpele backdoor die “alles doet”. In plaats daarvan is er een keten van componenten: een loader die zichzelf en de volgende payloads voorbereid, gevolgd door een backdoor die op commando’s reageert. Bovendien kunnen de backdoors extra plug-ins downloaden en injecteren, waarmee de aanvallers nieuwe acties toevoegen zonder een volledig nieuw implant te verspreiden.
De onderzoekers noemen onder meer mogelijkheden zoals het draaien van command shells, interactie met het bestandsysteem, het genereren van muis- en toetsaanslagen, netwerkverkenning, het stelen van inloggegevens en het verzamelen van e-mail. Ook keylogging en het ontvreemden van wachtwoorden uit browsers komen in beeld. Daardoor lijkt het vooral te gaan om langdurige toegang met veelzijdige post-exploit mogelijkheden.
Verder blijkt uit de analyse dat dezelfde dreigingsacteur actief is met zowel SilkLurk als OctLurk. Sommige slachtoffers met SilkLurk bleken óók OctLurk te bevatten. Op basis daarvan schatten de onderzoekers de kans “middelmatig” in dat beide varianten door dezelfde actor zijn ontwikkeld en dat die actor Chinees-sprekend is. Een definitieve toeschrijving aan een bekende groep kon op publicatieniveau niet worden gedaan.
OctLurk: van geplande taak tot payloadinjectie
Bij OctLurk start de aanval met het verkrijgen van uitvoerrechten via admin-credentials. Vervolgens maakt de aanvaller op externe systemen een geplande taak aan met de naam GoogleUpDate. Die taak wordt eenmalig uitgevoerd kort nadat ze is aangemaakt, onder het System-account. De taak wijst naar een batchscript dat zich in de gebruikersmappen bevindt en waarna de loader begint.
Voor de feitelijke uitvoering zet OctLurk een servicestructuur op. Het script maakt een service aan die een DLL laadt (met een specifiek DLL-naamspatroon in de bronanalyse). Deze DLL exporteert functies waarmee de loader een volgende fase opstart en de kerncode activeert.
Het payloadmechanisme is daarbij duidelijk gericht op omzeiling. De loader verzamelt hard-coded bytes die eerst met een dubbele XOR worden ontcijferd en daarna met zlib worden gedecomprimeerd. De sleutelcomponenten bestaan uit ten minste twee delen: een eerste sleutel die in de loader is vastgelegd en een tweede sleutel die wordt afgeleid uit het serienummer van de C:-schijf van het slachtoffer. Dat maakt de payloadspecifiek voor elk apparaat en bemoeilijkt hergebruik door defenders.
Daarna wordt de backdoor DLL reflectively geïnjecteerd in het geheugen en wordt het entry-point geactiveerd. Van daaruit kan de malware functies aanroepen via gedecryptde methoden, waarbij zowel namen als ordinals hard-coded en opnieuw geobfusceerd zijn.
OctLurk backdoor: informatie verzamelen en commando’s uitvoeren
De OctLurk-backdoor maakt een versleutelde verbinding op met een C2-adres en poort 443. Voor het opzetten van de sessie verzamelt de malware verschillende gegevens: OS-informatie, computer- en gebruikersnaam, hostname-to-IP-vertaling, lokale tijd en IP-adresdetails. Vervolgens comprimeert en versleutelt de backdoor deze data met een hard-coded XOR-sleutel en een tweede sleutel op basis van willekeurige bytes (lengte in de onderzochte samples hard-coded).
De malware gebruikt een eigen pakketopbouw, waarbij eerst een header wordt verstuurd en daarna de echte datalading. Op antwoord van de C2 ontvangt de backdoor een pakket dat opnieuw via dubbel XOR en zlib wordt verwerkt. De resulterende inhoud kan zowel commando-instructies als plug-in-achtige code bevatten.
In de post-compromise fase kan OctLurk verschillende plug-ins activeren die uiteenlopende taken ondersteunen. In de bronanalyse wordt expliciet genoemd dat een command-shell plug-in wordt gebruikt om verdere acties uit te voeren, zoals uitgebreid slachtoffer-fingerprinting en het exporteren van relevante event logs.
Post-exploit: cred theft, keylogging en browserwachtwoorden
Na initiële toegang richt de actor zich op het uitbreiden van zicht en controle. Er wordt onder meer een geplande taak opnieuw ingezet om uitgebreide informatie te verzamelen over hardware, software en netwerkconfiguraties. De resultaten worden opgeslagen in meerdere bestanden in de %TEMP%-omgeving.
Daarnaast exporteren de aanvallers succesvolle aanmeldgebeurtenissen voor interactieve remote logons en zoeken ze naar logons van specifieke gebruikers. Voor credential harvesting wordt een portable variant van het bekende secretsdump-materiaal ingezet (Impacket-achtig), waarmee wachtwoord-hashes van domeincontrollers worden opgehaald. Meteen daarna wordt ook gekeken naar alle leden van de “Domain Controllers”-groep om vervolgdelen van de omgeving te kunnen targeten.
Ook keylogging maakt onderdeel uit van het gereedschap. In de analyse wordt een keylogger gedropt en uitgevoerd via een pad onder openbare mappen. De malware schrijft vervolgens toetsaanslagen en clipboarddata weg naar twee bestanden, waarbij de verzamelde data eerst wordt geëncodeerd door per byte een vaste waarde af te trekken.
Tot slot komt het stelen van browserwachtwoorden aan bod. De bron beschrijft een “Browser Password Decryptor” die wachtwoorden uit Chrome en Firefox-datafiles kan extraheren. Het mechanisme draait onder andere om het gebruik van master key-gegevens (zoals Local State bij Chrome) en de opslag van geëncrypteerde loginrecords.
Rol van LurkProxy: verkeer relayeren via proxy-modus
Naast de OctLurk-backdoor zetten de aanvallers een extra utility in die de onderzoekers LurkProxy noemen. Hoewel LurkProxy qua architectuur sterk op OctLurk lijkt, is het in de analyse nadrukkelijk geen “backdoor” op zichzelf: het primaire doel is het proxy’en van netwerkverkeer.
De onderzoekers zagen dat de actor een service aanmaakt die een DLL laadt en vervolgens connectiviteit test naar een domein dat als C2-koppelpunt fungeert. Na bevestiging van bereikbaarheid wordt het proxycomponent actief en legt het een TLS-verbinding aan met de C2-server. De communicatie gebruikt een eigen pakketprotocol met compressie en dubbel XOR-achtige versleuteling.
Opvallend is dat de proxy in twee modi kan draaien, waarbij de gebruikte modus vastligt in de implant. In de onderzochte variant wordt vooral SOCKS5 gebruikt: de proxy geeft aan de C2 door dat er een verbinding is gemaakt, waarna de C2 een verbinding naar het doel opent zodat bidirectionele communicatie via de aanvaller loopt.
SilkLurk: sideloading met legitieme executables
Waar OctLurk start met geplande taken en services die een loader DLL aansturen, bouwt SilkLurk meer richting “sideloading” via legitieme programma’s. De actor creëert een servicestructuur die normale binaries start (zoals tools gerelateerd aan NVIDIA en Realtek), waarbij vervolgens malicious loader DLLs worden meegeladen.
De SilkLurk loader verifieert eerst dat hij draait in de juiste context (namelijk binnen de legitieme executable die hem laadt). Daarna verplaatst hij een payloadbestand naar een pad dat in de sample hard-coded is. Om persistence te realiseren wordt een nieuwe service aangemaakt die de legitieme module binary opnieuw start, zodat de schadelijke DLL steeds opnieuw wordt ingeladen.
De decryptie is ook hier apparaat- en doelgebonden: de loader maakt een 32-bit hash op basis van de computernaam en gebruikt die hash in een eigen algoritme om zowel de payloadpaden als payloadbytes te ontsleutelen. Daarmee wordt de malware specifiek gemaakt voor het betreffende systeem.
Wat dit betekent voor verdediging
Voor organisaties is de kernboodschap dat OctLurk en SilkLurk niet alleen “een backdoor” zijn, maar een complete set technieken voor persistence, payloaddecompressie, taakuitvoering en netwerkrelaying. Door de combinatie van geobfusceerde loaders, machine-specifieke sleutels en plug-ins die extra functionaliteit toevoegen, kunnen aanvallen zich aanpassen terwijl ze actief blijven.
Daarom helpt het om niet alleen naar één component te kijken. Richt je op het herkennen van de keten: geplande taken en services die DLL’s laden, onverklaarbare netwerkverbindingen richting de genoemde C2-structuren, en afwijkend gedrag rond credential harvesting, keylogging en het uitlezen van browserdatabases.
Conclusie
De campagne rondom OctLurk en SilkLurk laat zien hoe geavanceerde achterdeuren in Centraal-Azië werden ingezet tegen uiteenlopende overheidsomgevingen. Met aangepaste loaders, zware obfuscatie, plug-in uitbreiding en aanvullende proxy-functionaliteit via LurkProxy proberen aanvallers toegang te behouden en laterale beweging te ondersteunen.
Door de technische details uit de onderzoeksanalyse te vertalen naar detectie- en responsmaatregelen kunnen defenders sneller verbanden leggen tussen initial access, persistence en post-exploit activiteiten—en daarmee de kans op langdurige compromise verkleinen.
Bron: https://securelist.com/octlurk-silklurk-backdoors-central-asia/120840/
