Taggat med: SecurityOnion

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!

Identifiera beacons (bakdörrstrafik) med RITA

Identifiera beacons (bakdörrstrafik) med RITA

Det amerikanska cybersäkerhetsföretaget Active Countermeasures har en intressant open-source produkt som heter RITA. RITA står för Real Intelligence Threat Analytics är ett verktyg för dig som vill genomföra Cyber Threat Hunting.

RITA läser in data från Zeek (fd Bro) och kan genomföra följande:

  • Beacon-detektion – Sök efter tecken på beaconing-beteende in och ut ur ditt nätverk.
  • DNS-tunnelavkänning – Sök efter tecken på DNS-baserade bakdörrskanaler
  • Kontroll mot svartlisor – Sök mot ett antal olika svartlistor/blocklists

Jag intresserar mig dock mest för beacon-detektion då detta finns inbyggt i flertalet kommersiella produkter såsom Cisco Encrypted Traffic Analytics  men få open-source produkter kan söka efter denna typ av nätverkstrafik.

Beacons används av bakdörrs-ramverk (C2 frameworks) såsom Cobalt Strike, Metasploit, Empire, SharpC2 och PoshC2 för att nämna några.

RITA är utvecklat i programspråket Go och kan installeras i SecurityOnion, Ubuntu 16.04, Ubuntu 18.04 eller CentOS 7 om du vill köra med det medföljande scriptet install.sh. Du kan även installera RITA på egen hand eller köra RITA under Docker.

Stöd gärna mitt bloggande via Patreon >

De beroenden som RITA har är förutom Zeek är också databasen MongoDB. Jag installerar RITA utan Zeek och MongoDB och editerar sedan konfigg-filen /etc/rita/config.yaml så att den pekar mot min fristående mongodb.

Observera att du ej kan köra RITA med det paket som följer med Ubuntu 16.04 eftersom det är 2.6.10. RITA behöver mongodb-version som är mellan 3.2.0 och 3.7.0.

Jag fick det att fungera genom att installera mongodb version 3.6.18.

Analysera PCAP efter bakdörrar

Nu när RITA är installerat så måste jag först köra zeek på de pcap-filer jag har sparat ner. Bäst fungerar det om du har en pcap-fil för varje dag, detta kan vara problematiskt om du har många filer men går att lösa med verktyg såsom mergecap.

Första steget är att läsa in ett dygns pcap-fil med zeek och skriva ut loggfilerna. Detta exempel gäller dagen 2020-06-05 och pcap-filen var på 33GB:

$ cd /data/pcap
$ mkdir -p zeek/2020-06-05
$ cd zeek/2020-06-05
$ zeek -Cr ../../trace_2020-06-05.pcap local

Ovan kommando tar cirka 15 minuter på min Raspberry Pi och sedan att importera detta via RITA mot mongodb tar ca 3 minuter:

Nu när vi har importerat mappen 2020-06-05 mot RITA-databasen vid namn 2020-06-05 så kan vi titta på analysen när det gäller beacons på följande sätt:

Observera att ovan bild är censurerad av mig. Men när jag tittar på source/dst-IP så ser jag att två översta går till 8.8.8.8 respektive 8.8.4.4 vilket är Googles DNS och troligtvis false-positive. Det som är intressant här är första kolumnen vid namn score och en score på 0.9 och över är mycket intressant. Kör jag metasploit och meterpreter så hamnar score på 0.987.

Och tittar vi på beacon-trafik från Cobalt Strike så ligger standard på sleeptime 30000 millisekunder och 20% jitter. Vilket motsvarar följande kommando från agressor-klienten:

Vill du läsa mer om den underliggande algoritmen så hittar du koden här:

Och en analys av RITA på Cobalt Strike som legat och kommunicerat en hel dag så blir analysen enligt följande:

RITA beacon Cobalt Strike

Rad 17 som är rödmarkerad är den trafik som tillhör Cobalt Strike, och får enbart en score på 0.829 samt hamnar på 16:de plats på topplistan. Resten är enbart falska positiva, dvs videostreaming, DNS-uppslag osv. Så kontentan är att det inte är helt trivialt att detektera Cobalt Strikes standardkonfigurering.

Gillade du detta blogginlägg? Hjälp mig att blogga mer genom att stödja mig via Patreon >