Taggat med: Arkime

Kali Purple från OffSec

Kali Purple

Förutom att Offensive Security numera går under namnet OffSec så har företaget även släppt en ny version av Kali Linux som heter Kali Purple.

Som det nya namnet lite avslöjar så handlar det om en Linux-distribution som är anpassad för Purple-Teaming eller Blue-Teaming, dvs mer defensiv cybersäkerhet än offensiv som Kali Linux är mest känt för.

Och givetvis så är Kali Purple proppad med över 100 st olika verktyg, och för att nämna några:

  • Arkime full packet capture (tidigare Moloch)
  • Cyberchef
  • Elasticsearch SIEM
  • GVM vulnerability scanner
  • TheHive incident response platform
  • Malcolm
  • Suricata IDS
  • Zeek IDS

Även så följer alla andra verktyg som vi är bekanta med från Kali Linux med också.

Menystrukturen följer NIST CSF:

  1. Identify
  2. Protect
  3. Detect
  4. Respond
  5. Recover

Med följer även Kali Autopilot som låter dig bygga olika attackscenarion samt en community Wiki som låter dig läsa på om olika defensiva verktyg och hur du använder dessa.

Skärmdumpar

Kali Autopilot

Kali Autopilot

SOC-in-a-box

Kali Purple Soc in a box

Så upptäcker ni bakdörrar i IT-system

Så upptäcker ni bakdörrar i IT-system

Att upptäcka bakdörrar i IT-system är ingen lätt match och en mycket bra utvecklad bakdörr är mer eller mindre omöjlig att upptäcka. En bra utvecklad bakdörr har en mycket liten och snäv målgrupp och ligger vilande större delen av tiden. Men det finns givetvis olika metoder och sätt att upptäcka bakdörrar, för förr eller senare så kan misstag eller avvikande beteenden analyseras och påvisa en bakdörr.

Denna guide är främst skriven för att upptäcka bakdörrar som redan är in-planterade. Och hur bakdörrarna kommer in är utanför denna guide, men för att nämna några sätt:

  • Implanterade från start i servrar eller mjukvara/hårdvara
  • Via manuella eller automatiska uppdateringar av mjukvara, firmware osv
  • Man in the middle-attack eller MOTS mot nedladdad mjukvara
  • Via hackad server eller klient, bifogade filer i mail, sårbarhet i mjukvara
  • Fysiskt installerad via serverhall eller evil-maid attack
  • Infekterat PyPi, NPM, CPAN, RubyGem, NuGet-paket
  • Insider

Klienter och servrar

En vital funktion för att upptäcka bakdörrar på klienter och servrar är att samla in data, det kan röra sig om processer som startar och avslutas, drivrutiner som installeras/avinstalleras, telemetridata. Det är information där en enskild loggrad eller händelse kanske inte säger så mycket, men om den berikas och sätts i ett större sammanhang kan identifiera ett avvikande beteende.

Använder ni Windows-baserade system så är Sysmon ett givet verktyg att använda. För Linux-system så bör man använda verktyg såsom Sysdig Falco och auditd. Eller mer generiska verktyg såsom osquery.

Jag rekommenderar även att titta närmare på Velociraptor som jag bloggade tidigare om. Givetvis bör även binärer, konfigurationsfiler och dylikt hållas koll på med tripwire-liknande funktionalitet. Jobb som körs vid regelbundna intervall såsom cron, AT (Task Scheduler) osv. Eller vid uppstart av mjukvara, system (autoruns).

Nätverk

Jag har tidigare skrivit om RITA som kan underlätta analysen av nätverkstrafik för att hitta beacons som bakdörrar och implantat använder sig av för att kommunicera. Men en väl skriven bakdörr gör detta väldigt sällan och avviker minimalt från normal nätverkstrafik.

Att använda sig av TLSI (TLS Inspection) kan underlätta analysen av TLS/SSL-krypterad nätverkstrafik men det finns givetvis risker också, som bl.a. NSA varnat för. Rekommenderar att titta på PolarProxy som kan hjälpa till med TLSI.

Verktyg som kan hjälpa dig att analysera nätverkstrafik är exempelvis Zeek, JA3/S, Brim, Suricata, Arkime (fd Moloch) och SecurityOnion.

Passivt bör ni också undersöka om system anropar och kopplar upp sig mot kända C&C-servrar, därav viktigt att underhålla aktuella Threat Intelligence-listor med IP-adresser, domännamn etc.

Mängden av data som flödar ut ur era system kan också ge en fingervisning om exfiltration genomförs. Men detta är inte alltid helt enkelt att upptäcka, vid forensiska undersökningar där jag medverkat har jag sett att antagonister delar upp upp information i flertalet 500MB RAR-arkiv som exfiltreras över en längre tid för att undgå upptäckt.

bakdörr IT-system skadlig kod

Glöm inte heller att DNS kan användas för kommunikation, som bl.a. SolarWinds Orion SUNBURST-bakdörren gjorde. Även kan Twitter och andra sociala medier eller andra välkända tjänster användas för kommunikation med bakdörren. Steganografi kan också nyttjas för att försvåra upptäckt.

På internet eller fjärrsystem

Att aktivt undersöka vilka fjärrsystem på Internet som anropas kan hjälpa till att förstå om bakdörren pratar med en Command and Control-infrastruktur (C&C). Flertalet olika datakällor såsom Shodan kan användas för att förstå vilket eller vilka målsystem som kommunikationen sker mot.

Ett verktyg såsom JARM kan hjälpa till med detta och skapa unika signaturer. Observera att just aktivt undersöka system på internet kan vara en legal gråzon och undersök noga vad ni har möjlighet att göra.

Avslutande ord

Jag rekommenderar att bygga upp ett antal olika scenarion där ni undersöker vilka möjligheter ni har att upptäcka just dessa metoder. För att ge några exempel:

  • Log4j JNDI-sårbarheten utnyttjas på ett system mot Internet. Om en bakdörr sedan installeras på detta system, hur kan ni försvåra installation av bakdörren och hur ni upptäcka denna bakdörr?
  • En mjukvara som automatiskt uppdateras börjar att ”ringa hem” via dess normala kanaler för uppdateringar. Men innehåller nu krypterad data om erat interna nätverk såsom AD-namnet
  • DNS används för exfiltration
  • Switchen ni köpte innehåller en Rasperry Pi med WiFi eller 4G-mobildata för exfiltration av intern nätverkstrafik

Vad väntar ni på? Avsätt tid och resurser redan nu för att utveckla förmågan att upptäcka bakdörrar i IT-system. Och givetvis så bör ni också genomföra åtgärder för att försvåra för att bakdörren hamnar i IT-systemet i första taget, och även dess möjligheter att kommunicera ut på internet (eller på andra sätt ringa hem).

Desto mer bakdörren är integrerad i en befintlig komponent i era IT-system desto svårare är det att upptäcka den.

Tack till Erik Hjelmvik för genomläsning och synpunkter!

Analys av näterverkstrafik med Brim

Brim är ett relativt nytt verktyg som släpptes 2018 som underlättar analys av nätverkstrafik. De tre grundstenarna i Brim är Suricata, Zeek (tidigare Bro) och Wireshark.

Den primära analysen görs i ett grafisk gränssnitt som är utvecklat i ramverket Electron (som bl.a. Slack). Backend är skrivet i programspråket Go och använder ett filformat vid namn ZNG. Givetvis går det också att använda Brim utan det grafiska gränssnittet.

Eftersom designen är Unix-lik så kan du separera samtliga komponenter och arbeta mot en Zeek-instans som ligger på en annan server och bara använda det grafiska gränssnittet i Brim på din arbetsstation.

Att komma igång och importera en PCAP-fil på 1 GB tar bara några sekunder och du kan komma igång och arbeta direkt med datan. Förutom PCAP-filer så kan Brim även arbeta med formaten .pcapng, .zng och Zeek ASCII/JSON.

När du startar Brim för första gången ser det ut enligt nedan skärmdump. Du arbetar med olika spaces, queries samt du har möjlighet att se din historik:

När vi sedan importerat en fil så kan vi ställa manuella frågor via en ZQL-query eller klicka på valfritt fält. Följande skärmdump visar hur det ser ut direkt när vi valt att importera en PCAP:

Och nu är det dags att försöka att ställa några ZQL-frågor för att sedan utföra Threat hunting. Med första frågan kollar vi bara vilka olika streams som finns tillgängliga, och ni som arbetat med Zeek tidigare känner igen dessa:

count() by _path | sort -r

Och då ser det ut enligt följande på den PCAP som jag valt att arbeta med:

Från ovan vy så kan vi också högerklicka och välja ”Pivot to logs” för att se all trafik givet en viss _path. Och i ovan fall så ser vi enbart en snmp-förfrågan. Då kan vi enkelt filtrera ut den förfrågan via höger musknapp eller att skriva följande ZQL:

_path = "snmp"

Och enligt ovan så ser vi även att det förekommer 97 st okrypterade anslutningar där vi har möjlighet att söka efter avvikande user_agents med följande ZQL:

_path="http" | count() by user_agent | sort -r

Vilket då ger oss följande user_agents:

Det är även möjligt att använda cut() på följande sätt exempelvis:

_path=http | count() by status_code,host | status_and_counts=collect(cut(status_code,count)) by host

Och en till trevlig sak är att ZQL förstår sig på CIDR så du kan använda network_of() på följande sätt för att hitta vilka nät som DNS-servrar finns på:

_path=dns | put classnet=network_of(id.resp_h) | cut classnet | count() by classnet | sort -r

En annan fördel med Brim som är värd att trycka på också är att du enkelt kan öppna intressanta streams med Wireshark med hjälp av ett klick. Se röd pil nedan:

Vill man helt utesluta det grafiska gränssnittet och bara använda bakomliggande funktioner så går detta också givetvis bra för att exempelvis importera och arbeta med en PCAP-fil.

Det finns två sätt att importera en PCAP-fil direkt från kommandoskalet. Det ena är via zapi som följer med Brims installation eller ladda hem verktyget brimcap. För att använda de verktyg som följer med så kör man bara:

zapi new testspace
zapi -s testspace postpcap trace_2021-02-27_06:17:24.anon.pcap

Vilket tar 26 sekunder. Vi kan sedan ställa frågor direkt mot vårat nya testspace och den ZNG-fil som skapades på följande sätt:

zq -t "sum(orig_bytes)" trace_2021-02-27_06:17:24.anon.pcap.zng

En pcap på 2G resulterar i en ZNG-fil på 5.5MB i mitt test ovan. Och den som känner till zeek-cut sedan tidigare kan också köra frågor likt detta:

zq -f text "cut ts,id.orig_h,id.orig_p" trace_2021-02-27_06:17:24.anon.pcap.zng

Att istället köra via brimcap så tar detta 34 sekunder och filen blir 5,8MB:

brimcap analyze trace_2021-02-27_06:17:24.anon.pcap > trace_2021-02-27_06:17:24.anon.pcap.zng

Slutsats

Första releasen av Brim släpptes 2018 och sedan dess har det släppts mängder av förbättringar och uppdateringar. Dock har det inte hänt så mycket sedan Februari 2021 då version 0.24.0 släpptes.

Företaget bakom Brim har ca 7 anställda och går under namnet Brim Security och här kan du ladda hem Brim om du själv vill testa:

Jag gillar också tänket bakom Zed, att strukturera upp metadata. Och jag hoppas att fler projekt ska plocka upp det såsom Arkime (tidigare Moloch). Och även möjligheten att köra Zqd som är lyssnaren remote tycker jag är mycket bra.

En annan idé som verkar lovande är kombinationen tshark + Elasticsearch, något som är implementerat i tsharkVM.