In deze blogpost onderzoeken we de werking van AceCryptor, oorspronkelijk gedocumenteerd door Avast. Deze cryptor bestaat al sinds 2016 en omdat hij gedurende zijn hele bestaan ​​is gebruikt om tientallen malwarefamilies in te pakken, zijn veel technische onderdelen van deze malware al beschreven. Je hebt misschien al gelezen over deze cryptor, ook wel bekend als de DJVU-verduistering, Stage 1 van SmokeLoader, RedLine stealer's stage 1, 2 en 3, eenvoudige en populaire verpakker, enzovoort... Veel (maar niet alle) gepubliceerde blogposts herkennen deze cryptor niet eens als een afzonderlijke malwarefamilie, dus laten we alle punten voor je met elkaar verbinden, waarbij we niet alleen een technische analyse van de varianten bieden, maar ook een overzicht van de malwarefamilies die erdoor kunnen worden aangetroffen en hoe vaak AceCryptor in het wild voorkomt.

Voor auteurs van malware is het beschermen van hun creaties tegen detectie een uitdagende taak. Cryptors vormen de eerste verdedigingslaag voor malware die wordt verspreid. Hoewel bedreigingsactoren hun eigen aangepaste cryptors kunnen maken en onderhouden, kan het voor criminelen van criminelen vaak een tijdrovende of technisch moeilijke taak zijn om hun cryptor in een zogenaamde FUD-status (volledig ondetecteerbaar) te houden. De vraag naar dergelijke bescherming heeft er meerdere gecreëerd cryptor-als-een dienst (CaaS) opties die malware inpakken. Deze cryptors kunnen meerdere anti-VM-, anti-debugging- en anti-analysetechnieken bevatten om de payload te verbergen.

Statistieken en verpakte gezinnen overzicht

Sinds de eerste bekende verschijningen van AceCryptor in 2016 hebben veel malware-auteurs de diensten van deze cryptor gebruikt, zelfs de bekendste crimeware zoals Emotet, toen het nog geen eigen cryptor gebruikte. Tussen 2021 en 2022 heeft ESET meer dan 80,000 unieke voorbeelden van AceCryptor gedetecteerd. Vanwege het grote aantal verschillende malwarefamilies die erin zijn verpakt, gaan we ervan uit dat AceCryptor ergens als een CaaS wordt verkocht. Als we rekening houden met het aantal gedetecteerde unieke bestanden: hoewel we de exacte prijs van deze service niet kennen, gaan we ervan uit dat de voordelen voor de AceCryptor-auteurs niet te verwaarlozen zijn.

Vanwege het grote aantal monsters in de afgelopen jaren, zijn de volgende statistieken alleen gebaseerd op monsters die in 2021 en 2022 zijn gedetecteerd. Zoals te zien is in figuur 1, waren de detectietreffers vrij gelijkmatig verdeeld over deze twee jaar, wat te verwachten is van malware die wordt gebruikt door een groot aantal bedreigingsactoren die hun campagnes niet synchroniseren.

Figuur 1. Aantal AceCryptor-detecties in de jaren 2021 en 2022 (7-daags voortschrijdend gemiddelde)

Na het bekijken van de malware verpakt door AceCryptor, vonden we meer dan 200 ESET-detectienamen. Nu kan één malwarefamilie natuurlijk verschillende detectienamen hebben voor de afzonderlijke varianten, vanwege updates of wijzigingen in de verduistering. MSIL/Spy.RedLine.A en MSIL/Spy.RedLine.B zijn bijvoorbeeld beide detecties voor de RedLine Stealer-malware. . Detectienamen voor sommige andere malware zijn niet per familie, maar per klasse (bijv. ClipBanker of Agent), omdat veel onverpakte malwarevoorbeelden generieke klembordstelers, trojans, enzovoort zijn die niet zo wijdverspreid zijn en/of slechts een klein beetje voorkomen. gewijzigde varianten van andere bekende malware gepubliceerd in verschillende openbare opslagplaatsen. Na het groeperen kunnen we concluderen dat na het uitpakken onder de gevonden malwarefamilies SmokeLoader, RedLine Stealer, RanumBot, Raccoon Stealer, STOP ransomware, Amadey, Fareit, Pitou, Tofsee, Taurus, Phobos, Formbook, Danabot, Warzone en nog veel meer zijn. … Figuur 2 toont een overzicht van de hoeveelheden monsters die behoren tot enkele van de bekende en veel voorkomende malwarefamilies die door AceCryptor zijn ingepakt.

Afbeelding 2. Malwarefamilies verpakt in AceCryptor in 2021 en 2022

Het monitoren van activiteiten van CaaS-providers zoals AceCryptor is nuttig voor het monitoren van malware die hun services gebruikt. Neem als voorbeeld een RedLine Stealer die voor het eerst werd gezien in het eerste kwartaal van 1. Zoals te zien is in figuur 2022, gebruikten RedLine Stealer-distributeurs AceCryptor sinds het begin van het bestaan ​​van RedLine Stealer en doen dat nog steeds. Het betrouwbaar kunnen detecteren van AceCryptor (en andere CaaS) helpt ons dus niet alleen met zichtbaarheid van nieuwe opkomende bedreigingen, maar ook met het monitoren van de activiteiten van bedreigingsactoren.

Afbeelding 3. Incidenten van RedLine Stealer in AceCryptor-samples (gemiddelden over 7 dagen)

victimologie

Zoals te verwachten is op basis van de verscheidenheid aan malware die in AceCryptor is verpakt en de diversiteit aan interesses van verschillende malware-auteurs, wordt AceCryptor overal ter wereld gezien. In 2021 en 2022 heeft ESET-telemetrie meer dan 240,000 detectiehits van deze malware gedetecteerd, wat neerkomt op meer dan 10,000 hits per maand. In figuur 4 ziet u de landen met de meeste detecties in 2021 en 2022.

Afbeelding 4. Heatmap van landen die getroffen zijn door AceCryptor volgens ESET-telemetrie

In 2021 en 2022 hebben ESET-producten malwarevarianten gedetecteerd en geblokkeerd die door AceCryptor zijn verpakt op de computers van meer dan 80,000 klanten. We ontdekten ook meer dan 80,000 unieke voorbeelden van AceCryptor. Nu kon natuurlijk elk monster op meerdere computers worden gedetecteerd of werd één computer meerdere keren beschermd door ESET-software, maar het aantal unieke hashes laat zien hoe actief de auteurs van AceCryptor werken aan de verduistering en detectieontduiking. We zullen dieper ingaan op de technische details van AceCryptor's verduisteringen in de Technische analyse onderdeel van deze blogpost.

Wat hier het vermelden waard is, is dat hoewel het aantal unieke monsters van AceCryptor erg hoog is, het aantal unieke monsters dat erin is verpakt minder dan 7,000 is. Dit toont de mate aan waarin veel malware-auteurs vertrouwen op de diensten van een cryptor en hoe gemakkelijk het voor hen is om voor dit soort diensten te betalen in plaats van hun tijd en middelen te investeren om hun eigen cryptor-oplossing te implementeren.

Distributie

Omdat AceCryptor door meerdere bedreigingsactoren wordt gebruikt, wordt de malware die erin is verpakt ook op meerdere verschillende manieren verspreid. Volgens ESET-telemetrie werden apparaten blootgesteld aan met AceCryptor verpakte malware, voornamelijk via getrojaniseerde installatieprogramma's van illegale software of spam-e-mails met kwaadaardige bijlagen.

Een andere manier waarop iemand kan worden blootgesteld aan met AceCryptor verpakte malware is via andere malware die nieuwe malware heeft gedownload die wordt beschermd door AceCryptor. Een voorbeeld is het Amadey-botnet, waarvan we hebben waargenomen dat het een met AceCryptor verpakte RedLine Stealer downloadde.

We willen graag opmerken dat dit twee kanten op werkt en dat sommige malwarefamilies die door AceCryptor worden beschermd, ook nieuwe, aanvullende malware kunnen downloaden.

Technische analyse

Momenteel gebruikt AceCryptor een meertraps architectuur met drie lagen. Er zijn twee bekende versies van de eerste laag die momenteel in gebruik zijn – een versie die gebruikt THEE (Tiny Encryption Algorithm) om de tweede laag te decoderen en een versie die een lineaire congruentiële generator (LCG) van Microsoft Visual/Quick/C++ om de tweede laag te decoderen. De tweede laag is shellcode die defensieve trucs uitvoert, vervolgens de derde laag ontsleutelt en lanceert. Ten slotte is de derde laag meer shellcode die ook enkele anti-onderzoekstrucs uitvoert, en het is zijn taak om de payload te lanceren. Er zijn twee bekende versies van de derde laag: de ene versie voert procesuitholling uit, terwijl de andere een reflecterende lader gebruikt en zijn eigen afbeelding overschrijft met de PE van de uiteindelijke lading.

Figuur 5. Architectuur van AceCryptor

Laag 1

Ook al zijn er twee versies van Layer 1, ze werken erg op dezelfde manier. Hun belangrijkste taken kunnen als volgt worden samengevat:

1. Laad versleutelde laag 2 in het toegewezen geheugen.
2. Decodeer laag 2.
3. Bel of spring naar Laag 2.

Het belangrijkste onderdeel van deze fase zijn de verduisteringen. Door de jaren heen zijn er nieuwe verduisteringen toegevoegd - tot het punt waarop bijna elk deel van het binaire bestand op de een of andere manier willekeurig is gemaakt en versluierd. Dit zal grote problemen veroorzaken voor iemand die YARA-regels of statische detecties probeert te bedenken.

Passanten

De auteurs maken gebruik van lussen voor meerdere verduisteringen. De eerste en meest voor de hand liggende techniek is het gebruik van lussen met ongewenste code om analyse moeilijker te maken. We zien het gebruik van ongewenste code sinds 2016, toen we de eerste voorbeelden van AceCryptor registreerden. Deze loops zijn gevuld met veel API-aanroepen die niet alleen analisten vertragen die niet weten wat er gebeurt, maar ook de logboeken van sandboxen die API-aanroepen koppelen, overweldigen, waardoor ze onbruikbaar worden. De lussen kunnen veel MOV-instructies en wiskundige bewerkingen bevatten, wederom alleen om analisten in de war te brengen en daardoor de analysetijd te verlengen.

Figuur 6. AceCryptor's verduisteringen met loops en het verbergen van belangrijke delen van code

Het tweede gebruik van lussen is om vertraging bereiken. We hebben vastgesteld dat sommige versies van AceCryptor Layer 2 bijna onmiddellijk starten, maar andere bevatten loops die zo veel tijd vergen dat het de uitvoering zelfs tientallen minuten kan vertragen: het vertragen van de uitvoering van sommige delen van malware is een bekende techniek, maar het gebruik van API-aanroepen zoals Sleep kan al enkele vlaggen opwerpen. Zelfs als dat niet het geval is, houden sommige sandboxen ervan Koekoek Zandbak implementeer slaap-overslaande technieken om de vertraging te voorkomen en ga door naar de interessante delen. Het implementeren van vertragingen via lussen en het uitvoeren van ongewenste code is ook een complicatie tijdens dynamische analyse, omdat de analist moet identificeren welke lussen ongewenste lussen zijn en dus kunnen worden overgeslagen.

Een derde verduisteringstechniek waarbij gebruik wordt gemaakt van loops, bestaat erin belangrijke bewerkingen erin te verbergen. Onder de junk-loops zijn er enkele die wachten op een bepaalde iteratie en juist tijdens die iteratie gebeurt er iets. Gewoonlijk wordt een API geladen met behulp van GetProcAdres, die later wordt gebruikt of een constante, zoals de offset van de gecodeerde gegevens, wordt ontmaskerd. Als die specifieke iteratie van een lus niet gebeurt, crasht de sample later. Dit, in combinatie met ongewenste code, betekent dat om de malware dynamisch te analyseren, eerst moet worden geanalyseerd welke lussen of iteraties van lussen kunnen worden overgeslagen en welke niet. Dit betekent dat de analist tijd kan besteden aan het analyseren van ongewenste code of kan wachten tot alle ongewenste code is uitgevoerd. In figuur 6 ziet u twee lussen waarbij de eerste een bewerking bevat die belangrijk is voor latere uitvoering, en de andere vol staat met ongewenste code. Natuurlijk is dit misschien niet (en het is niet in de meeste voorbeelden) zo gemakkelijk zichtbaar tussen alle lussen, vooral als de lussen met de belangrijke bewerkingen ook ongewenste code bevatten.

Randomisatie - Gij zult niet YARA

Een ander belangrijk onderdeel van de eerste laag is randomisatie. Ongewenste code en de eerder genoemde lussen worden willekeurig verdeeld in elke steekproef, op een zodanige manier dat:

• het aantal iteraties verandert,
• API-oproepen veranderen,
• het aantal API-aanroepen verandert, en
• ongewenste rekenkundige of MOV-instructies veranderen.

Al deze randomisatie kan de identificatie van het decoderingsalgoritme en de sleutels ook behoorlijk bemoeilijken. In figuur 7 en figuur 8 ziet u de originele, niet-versluierde en de versluierde versie van het TEA-algoritme. In de versluierde versie zijn er niet alleen overbodige rekenkundige instructies, maar zijn sommige delen van het algoritme ook omlijnd in subroutines en zijn bekende constanten (som en delta in figuur 7) gemaskeerd, alleen om correcte identificatie van het algoritme onwaarschijnlijk of zeker moeilijker te maken. .

Afbeelding 7. TEA-decoderingsfunctie – niet versluierd

Figuur 8. TEA-decoderingsfunctie – versluierd

Code is niet het enige dat gerandomiseerd is. De versleutelde Layer 2 en zijn decoderingssleutel worden momenteel meestal opgeslagen in de .tekst or .gegevens sectie, maar ze zijn verborgen met behulp van enkele offsets die veranderen tussen de samples. Ook na het succesvol decoderen van Laag 2: in sommige voorbeelden staat de code van Laag 2 aan het begin van de gedecodeerde gegevens, maar er zijn voorbeelden waarbij je aan het begin een blok met willekeurige gegevens krijgt en je de juiste offset moet weten om het begin van de code van laag 2 te vinden.

AceCryptor-auteurs randomiseren ook de volgende kenmerken:

• Het PDB-pad begint altijd met C:, maar de rest van het pad is willekeurig.
• Bronnen met willekeurige namen en inhoud, zoals te zien is in figuur 9. De auteurs van AceCryptor vullen steekproeven met willekeurig gegenereerde bronnen die willekeurig gegenereerde gegevens bevatten. We gaan ervan uit dat dit wordt gedaan om monsters minder verdacht te maken en het lokaliseren van de eigenlijke versleutelde gegevens moeilijker te maken. Bronnen kunnen bevatten:
  • String tabellen
  • Menu's
  • bitmaps
  • Binaire data
• Tekenreeksen die in de code worden gebruikt.
• Iconen – ook al zien iconen die in veel voorbeelden worden gebruikt er hetzelfde uit, ze zijn slechts licht aangepast/gerandomiseerd om uniek te zijn.
• Willekeurige namen van dummy-secties.
• Geheugentoewijzingsfuncties voor Layer 2-gegevens - GlobalAlloc, LokaalAlloc en VirtueelAlloc.
• Gebruik van sommige API's die belangrijk zijn voor de uitvoering van code - ze kunnen statisch worden geïmporteerd of verkregen via GetModuleHandleA en GetProcAdres.

Afbeelding 9. De bronnen van AceCryptor worden willekeurig gegenereerd met willekeurig gegenereerde inhoud om voorbeelden minder verdacht te maken

Figuur 10. AceCryptor's willekeurige strings in bronnen

Vorige versies

In de loop der jaren zijn de auteurs van AceCryptor vaardiger geworden in het ontwikkelen van malware en is de cryptor veranderd en geëvolueerd. Hoewel er veel kleinere wijzigingen, updates en verbeteringen waren, waren enkele van de interessante kenmerken van de oudere versies van Laag 1 de volgende:

• In 2016 gebruikte AceCryptor een versie van Layer 1 met XTEA-coderingsalgoritme.
• In de periode 2017–2018 gebruikte AceCryptor nog een Layer 1-versie, waarbij het gebruikte versleutelingsalgoritme RC4 was.
• In 1 verschenen de eerste (X)TEA- en LCG-versies van Layer 2016. In tegenstelling tot de LCG-versie raakte de XTEA-versie al snel in onbruik en werd vervangen door de TEA-versie.
• In oudere versies was de versleutelde laag 2 in de bronnen verborgen in een BMP-afbeelding. Deze afbeelding is willekeurig gegenereerd met willekeurige breedte en hoogte, en het midden van de afbeelding is uitgesneden en vervangen door gecodeerde gegevens. De gegevens moesten op de juiste offset worden gevonden.

Laag 2

Layer 2 van AceCryptor verscheen in 2019. Tot die tijd lanceerde AceCryptor Layer 3 direct vanuit Layer 1. Deze laag dient als extra encryptie en bescherming van Layer 3 en bestaat, zoals figuur 11 illustreert, uit drie delen:

• positie-onafhankelijke code,
• een aangepaste structuur die we hebben genoemd L2_INFO_STRUCT, met informatie over Laag 3, en
• de gegevens van Laag 3

Figuur 11. AceCryptor's Layer 2-structuur

Als eerste stap gebruikt AceCryptor een algemene techniek om enkele API-functieadressen te verkrijgen. Het lost de GetProcAdres en BibliotheekA laden functies met behulp van de PEB_LDR_DATA om door geladen modules te bladeren en door de hash-waarden van hun exportnamen te vergelijken met hardgecodeerde waarden. Als checksum-functie gebruikt AceCryptor een shl1_toevoegen functie, al geïmplementeerd in hashDb, wat de identificatie van opgeloste API's sneller kan maken.

Figuur 12. shl1_toevoegen hachee geïmplementeerd in Python

Dan krijgt AceCryptor een handvat voor kernel32.dll gebruik BibliotheekA laden en gebruikt dat en GetProcAdres om meer API's op te lossen.

Voor de volgende stappen gebruikt AceCryptor informatie uit zijn aangepaste structuur L2_INFO_STRUCT (weergegeven in figuur 13), die aan het einde van de positie-onafhankelijke code te vinden is, zoals te zien is in figuur 11.

Figuur 13. Overzicht van de L2_INFO_STRUCT van Laag 2

In de volgende stappen decodeert AceCryptor Layer 3, die is versleuteld met LCG van Microsoft Visual/QuickC/C++. Decodering gebeurt op zijn plaats. Als de compressieVlag is ingesteld, wijst AceCryptor geheugen toe met de VirtueelAlloc API en decomprimeert de gedecodeerde gegevens met het LZO_1Z-decompressie-algoritme. Hierna springt de uitvoering naar de gedecodeerde en optioneel gedecomprimeerde Layer 3.

Laag 3 – Proces uitholling

Als eerste stap verkrijgt AceCryptor de adressen van BibliotheekA laden en GetProcAdres API's op dezelfde manier als in ` 2 – doorlopen geladen modules, doorlopen exporteren en gebruiken shl1_toevoegen controlesommen. Vervolgens verkrijgt AceCryptor meerdere API-functieadressen en DLL-handles.

Figuur 14. Structuur van AceCryptor's Layer 3 - procesuitholling

In de volgende stap gebruikt AceCryptor de API GetFileAttributenA en controleert op bestandssysteemattributen van een bestand met de naam appfHQ. Attributen worden vergeleken met a niet-bestaande combinatie van vlaggen 0x637ADF en als ze gelijk zijn, komt het programma in een oneindige lus terecht. Omdat dit wordt gebruikt in de laatste laag, die al goed verborgen is, en omdat dit hier niet de enige truc is, gaan we ervan uit dat dit geen zoveelste verduisteringstechniek is, maar eerder een ongedocumenteerde anti-sandbox/anti-emulatortruc tegen een onbekende maar specifieke sandbox/emulator die deze waarde retourneert.

Als het programma succesvol doorgaat, is er nog een anti-sandbox/anti-emulatorcontrole. Nu gebruikt AceCryptor de API RegistreerKlasseExA om een ​​klas te registreren met de klasnaam saodkfnosa9uin. Vervolgens probeert het een venster te maken met de naam mfoaskdfnoa met de MaakVensterExA API. In de laatste stap van deze controle probeert AceCryptor de API's te gebruiken PostBerichtA en Bericht ophalenA een bericht doorgeven. Omdat deze API's niet zo vaak worden gebruikt, helpt deze controle om sandboxes/emulators te omzeilen die deze API's niet hebben geïmplementeerd of waar de geëmuleerde API's niet correct werken.

Afbeelding 15. Anti-VM/anti-emulatortruc

Nadat deze controles met succes zijn doorstaan, gebruikt AceCryptor de proces uitholling techniek waar het een nieuw exemplaar van het huidige proces maakt (GetCommandLineA, CreateProcesA), brengt de uiteindelijke payload in kaart in het nieuw gecreëerde proces en start het.

Vorige versies

Anti-onderzoek truc gebruikt RegistreerKlasseExA, MaakVensterExA, PostBerichtA, Bericht ophalenA was in eerdere versies (bijv. SHA-1: 01906C1B73ECFFD72F98E729D8EDEDD8A716B7E3) gezien gebruikt op Laag 1 en later (toen het werd getest en de architectuur van de cryptor evolueerde) werd het verplaatst naar Laag 3.

Laag 3 – Reflecterende lader

De eerste staphis laag, vergelijkbaar met Laag 2 en Laag 3 – Proces uitholling, verkrijgt adressen van de GetProcAdres en BibliotheekA laden API-functies. Het verschil is dat de auteurs deze keer om de een of andere reden de shl1_toevoegen checksum-functie, maar ze verkrijgen eerst de GetProcAdres door geladen modules te doorlopen, exports te doorlopen en strings te vergelijken. Dan gebruiken GetProcAdres ze krijgen de BibliotheekA laden functie. Met behulp van die twee API's laadt AceCryptor adressen van wat meer API-functies en een handvat kernel32.dll.

Figuur 16. Structuur van de Layer 3 reflecterende lader

In de code zit een truc (getoond in figuur 17) waarbij AceCryptor code met gegevens mengt. AceCryptor beheert een waarde die na één oproep op het retouradres staat. Deze waarde staat standaard op nul en later schrijft AceCryptor daar een adres van het ingangspunt van de uiteindelijke payload. Als het programma wordt gepatcht en de waarde wordt ingesteld op een andere waarde dan nul, springt het programma naar het adres waarnaar die waarde verwijst en crasht.

Figuur 17. Code mengen met data

In de volgende stap voert AceCryptor een bekende uit anti-VM controle gericht tegen Cuckoo sandbox, IDA Pro+Bochs en Norman SandBox. In figuur 19 is die vlag te zien SEM_NOALIGNMENTFAULBEHALVE met de waarde 0x04 wordt altijd ingesteld door de Cuckoo-sandbox, en daarom wordt de tweede aanroep van Foutmodus instellen in de code van Figuur 18 zal niet dezelfde waarde retourneren als degene die was ingesteld door de vorige aanroep.

Afbeelding 18. Anti-VM-truc

Figuur 19. code van Koekoek Zandbak

In de laatste stappen controleert AceCryptor eerst of de uiteindelijke payload (opnieuw) is gecomprimeerd en als dat het geval is, gebruikt het LZO_1Z-decompressie. Net als Layer 2 gebruikt de Layer 3 reflecterende lader een aangepaste structuur, die we hebben genoemd ENCRYPTED_DATA_INFO_STRUCT (Afbeelding 16), die precies tussen de positie-onafhankelijke code en de uiteindelijke payload kan worden gevonden, met informatie zoals compressievlag, aantal secties van payload, (gede)comprimeerde grootte van payload, adres van ingangspunt, adressen van sommige mappen, afbeelding adres van de verhuistabel, enzovoort. AceCryptor gebruikt deze informatie (in tegenstelling tot Laag 3 – Proces uitholling, die de PE van de uiteindelijke payload parseert) om een ​​reflectieve code-laadtechniek uit te voeren waarbij het zijn eigen afbeelding opnieuw toewijst (kaartsecties, rebase-afbeelding, ...) met de afbeelding van de uiteindelijke payload en de payload lanceert door zijn ingangspunt aan te roepen.

Conclusie

AceCryptor is een langdurige en veel voorkomende cryptor-malware die over de hele wereld wordt verspreid. We verwachten dat het ergens op dark web/underground fora als CaaS wordt verkocht. Services van deze malware zijn gebruikt door tientallen verschillende malwarefamilies en velen van hen vertrouwen op deze cryptor als hun belangrijkste bescherming tegen statische detecties.

Aangezien de malware door veel bedreigingsactoren wordt gebruikt, kan iedereen worden getroffen. Door de diversiteit aan ingepakte malware is het moeilijk in te schatten hoe ernstig de gevolgen zijn voor een gecompromitteerd slachtoffer. AceCryptor kan zijn gedropt door andere malware, die al op de computer van een slachtoffer draait, of als het slachtoffer direct werd getroffen door bijvoorbeeld het openen van een kwaadaardige e-mailbijlage, kan de aanwezige malware extra malware hebben gedownload; het kan dus erg moeilijk zijn om de gecompromitteerde machine schoon te maken.

Hoewel het voorlopig niet mogelijk is AceCryptor toe te schrijven aan een bepaalde dreigingsactor en we verwachten dat AceCryptor op grote schaal zal blijven worden gebruikt, zal nauwkeuriger toezicht helpen bij het voorkomen en ontdekken van nieuwe campagnes van malwarefamilies die met deze cryptor zijn gevuld.

IOCs

Bestanden

Opmerking: de vermelde bestanden zijn een redelijke selectie van voorbeelden door de tijd heen, die verschillende versies van AceCryptor dekken of verschillende malware bevatten.

Benoemde objecten

MITRE ATT&CK-technieken

Deze tafel is gemaakt met behulp van versie 12 van de MITRE ATT&CK bedrijfstechnieken.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoAiStream. Web3 gegevensintelligentie. Kennis versterkt. Toegang hier.
• De toekomst slaan met Adryenn Ashley. Toegang hier.
• Koop en verkoop aandelen in PRE-IPO-bedrijven met PREIPO®. Toegang hier.
• Bron: https://www.welivesecurity.com/2023/05/25/shedding-light-acecryptor-operation/