2023-09-12

Guide till säkrare containers

Senast uppdaterad 2023-09-22

Att containers har blivit en del av många organisationers vardag råder det ingen tvivel om. Med hjälp av populära verktyg såsom Docker, Podman eller Kubernetes (K8s) så realiserar dessa en containerbaserad infrastruktur och applikationsdistribution.

Det är av stor vikt att hålla dessa säkra och nedan följer en guide hur du kan minska risken för eventuella cyberattacker.

Minska attackytan

Först och främst gäller det att minska attackytan. Detta för att minska risken, och att uppnå en 100%-ig säkerhet är så klart helt omöjligt. Men hur gör man för att minska attackytan? Jo det består i flertalet saker:

Använd användare med låga behörigheter inne i containern. Kör rootless utanför om möjligt
Använd en container till ett syfte. Dvs inte både webbserver och databas, exponera eller installera ej sshd inne i en container
Exponera minimalt med kataloger, sockets eller annat mellan containers och mot värden (operativsystemet som kör containers) och vice versa
Stäng av sådant som inte behövs, såsom nätverk. Kan stängas av med: –network none
Utgå från minimala containers såsom -slim och distroless
Skydda API:et eller socketen för att kommunicera med din containermjukvara såsom Podman, Docker osv. Dvs podman.socket och /var/run/docker.sock samt TCP-portarna 2376/2375
Håll dockerd, podman etc uppdaterat och även containers
Undvik argument såsom : –privileged och –cap-add då dessa öppnar upp för ”container escape” sårbarheter

Attacker via mjukvarukedjan (supply chain)

Ladda inte hem och använd godtyckliga containers, utan utgå ifrån sådana som är signerade och verifierade. Använd verktyg såsom cosign och docker trust för att verifiera. Det har hänt flertalet gånger att containers innehåller bl.a. crypto-miners.

Exempel på hur docker trust inspect kan användas för att validera alpine:latest

Och för cosign där jag verifierar distroless python3-debian11:

Även om containers är signerade så är det givetvis ingen garant för att den innehåller bakdörrar.

Loggning och spårbarhet

Det är av stor vikt att logga även sådant som händer i containers. Det vanligaste sättet är att skriva loggarna till stdout och sedan fånga upp detta. Viktigt är att centralt samla in loggarna och analysera dessa ytterligare efter avvikande mönster, kända attacker osv.

Även så finns det verktyg såsom Sysdig Falco eller auditd som kan kontrollera beteendet på dockerd eller inviduella containers. Exempel på hur audit.rules kan se ut för docker:

-w /usr/bin/docker -p wa
-w /var/lib/docker -p wa
-w /etc/docker -p wa
-w /lib/systemd/system/docker.service -p wa
-w /lib/systemd/system/docker.socket -p wa
-w /etc/default/docker -p wa
-w /etc/docker/daemon.json -p wa
-w /usr/bin/docker-containerd -p wa
-w /usr/bin/docker-runc -p wa

Glöm inte heller att logga och analysera nätverkstrafik som går in/ut ur respektive container, använd Suricata, Zeek eller Arkime. Försök att skilja på applikationsloggar, operativsystemsloggar, prestandaloggar etc. Även om alla är viktiga så har alla sina unika mönster för att identifiera intrång. Andra saker som kan skilja är hur länge du vill lagra dessa.

Sårbarhetsskanning

Det finns många bra verktyg för att genomföra sårbarhetsskanning av containers. Dels det inbyggda kommandot docker scout (tidigare docker scan som använde Snyk) och dels tredjepartsverktyg såsom trivy och grype.

Jag tänkte göra en snabb jämförelse mellan dessa tre enligt nedan.

Trivy

Jag använder en test-image vid namn hello-python. Sedan kör jag kommandot:

trivy image hello-python

Då identifierar den tre sårbarheter i python-paket och 47 st i alpine 3.11.5:

Grype

För att skanna av en container med grype kör jag kommandot:

grype hello-python

Och då hittar den enligt nedan. Totalt blir det 118 kända sårbarheter som identifieras, vilket är flest antal av de tre verktyg jag testar. Men dock räknar jag antalet CVE:er och GHSA:s individuellt så blir det 81 st.

Docker Scout

Kör jag med senaste versionen av docker scout, som tyvärr måste laddas hem separat då nyaste versionen ej ingår i Docker Desktop så hittar den 67 sårbarheter i 12 paket.

Även Docker Scout identifierar tre sårbarheter i python-paket (pypi). Kommandot jag använder är:

./docker-scout cves hello-python

Övrigt

Kan även rekommendera att titta på lösningar såsom Kata och Gvisor som tillför ett extra lager med säkerhet i Er container-miljö.

Vissa IT-forensiska utmaningar kan också uppstå i en container-baserad miljö. Se därför till att öva på olika scenarion där en container eller dess host-operativsystem drabbats av intrång, eller möjlighet att söka efter IOC:er (Indicators of Compromise).

Fick tips om att UFW ej fungerar tillsammans med Docker. Även en rekommendation om att skapa upp SBOM:s för alla dina containers, som jag bloggat tidigare om.

Se även över om ni kan upprätta ett eget container-index och således få en bättre överblick över vilka containers om används inom organisationen.

_{Bild skapad med Midjourney}

2023-09-11

Intervju med HackerOnes VD Mårten Mickos

Under mina många år i branschen är det få personer som har gett ett sådan gott intryck som Mårten Mickos. Mårten är från Finland, pratar flytande svenska och bor numera i San Francisco där han är VD för HackerOne.

Jag tog ett snack med Mårten och vad HackerOne pysslar med och hans jobb som VD där:

Vilka är de största fördelarna med att ha ett bugbounty-program för en organisation?

Det finns inget annat sätt att hitta de svåraste sårbarheterna. Testverktyg, code scanners och till och med intern personal följer order och hittar bara det de satts att söka. Men buggjägare är obundna och har närapå oändlig kreativitet. De hittar de kritiska buggarna – de som kriminella annars skulle exploatera. Till och med de organisationer som kan anställa hur mycket datasäkerhets- och test-personal som helst – Google, Amazon, USAs försvarsdepartement – kör sådana program. Förr var det ganska mycket jobb att drive ett bugbounty-program men i dag är det lätt tack vare företag som HackerOne. Man kan starta smått och utvidga an efter.

På vilket sätt kan företag såsom HackerOne hjälpa organisationer med dess cybersäkerhet?

HackerOne hjälper dem som utvecklar och driftsätter mjukvara. Nästan alla företag har i dag sin egen webbapplikation och kanske mobilapp. Mjukvaran uppdateras hela tiden, och till sin struktur är alla applikationer i dag byggda på kod som levererats av någon annan. Så hur man än gör så har systemen hål och sårbarheter, som man själv eller tredje part förorsakat. På något sätt måste man utsätta dessa applikationer för kontinuerligt testande så att hålen kan lappas. Annars lämnar man dörren öppen för dataintrång av kriminella eller främmande makt, vilket vore ansvarslöst. HackerOne kan sköta detta testande från början till slut för kunder stora som små. Till vår hjälp har vi världens bästa säkerhetsexperter som anmält sig som frivilliga på vår plattform. Dessa så kallade etiska hackare tävlar med varandra om vem som är bäst och får betalt enligt vad de hittar. En sann global meritokrati som producerar världens bästa datasäkerhet.

Vad är det som utmärker en person som är bra på att hitta brister och sårbarheter? (buggjägare)

Nyfikenhet. Det är så enkelt. Visst krävs det kreativitet, logiskt tänkande, datakunskap och goda sittmuskler också. Men det är nyfikenheten som driver dem. Samma som man ser med barn som skruvar i sär sina leksaker (och annat!) för att förstå hur de funkar.

Är ett bugbounty-program något för alla organisationer?

Bara för dem som vill undvika dataintrång.

Bäst passar bugbounty för organisationer som utvecklar och driftsätter mjukvara för sina kunder. Vanligen är det fråga om webbapplikationer, mobilappar och gränssnitt (API). Men vi har också kunder av många andra typer, t.ex. IoT-leverantörer. Riktigt små organisationer saknar ofta kapacitet att ta hand om datasäkerhet, så våra kunder har ofta tiotals utvecklare eller mer. Det är fråga om högteknologiföretag (som PayPal, Zoom och Slack), banker (som Goldman Sachs, CapitalOne), industriföretag (t.ex. General Motors, Caterpillar, Toyota), konsumentföretag (t.ex. Starbucks, Hyatt Hotels m.m.) och den offentliga sektorn (t.ex. försvarsdepartementen i USA, Storbritannien och Singapore).

Vilka är de vanligaste misstagen företag gör när de implementerar ett bugbounty-program?

Vi tar hand om det mesta för våra kunder så i dagens läge är det inte så många misstag som kan ske. Viktigast är kanske att kunden har en intern beslutsamhet att åtgärda sårbarheterna. Det är möjligt att vi hittar ganska många. Då måste kodarna vara beredda på att ta itu med buggarna. Först kanske de lite knotar, men fort inser de värdet av riktigt avancerade buggrapporter. För en utvecklare blir det en möjlighet att skärpa sina egna kunskaper samtidigt som applikationen blir säkrare.

Vad ser du för framtid inom området? Har ni några nya intressanta funktioner eller tjänster på gång?

Det här är ett område som blir bara större. Nu ser vi att USAs statsförvaltning börjar kräva sårbarhetsprogram av alla som levererar något till myndigheterna. Banker och försäkringsbolag kommer till oss allt oftare. Själva bygger vi ut tjänsterna. Vi kan nu gå in på insidan och revidera källkod också. På så sätt hittas sårbarheterna tidigare och smidigare. Vi bygger också ut vår förmåga att hitta svagheter i AI-applikationer. Det är en helt egen värld med ”prompt injection”, ”training data poisoning” och andra faror. Det finns många leverantörer i denna bransch. HackerOne är klart störst och vi har det bredaste utbudet.

Vad är det du gillar mest med ditt jobb som VD På HackerOne?

Det är nog att se de oerhört duktiga experterna som vi har i vårt nätverk. Några av de absolut bästa är bara 17 år gamla. Många har känt sig åsidosatta i samhället. Ingen har verkat behöva dem. Men när de får jaga buggar på HackerOnes kundprogram märker de att deras arbete behövs (och belönas). De sträcker på ryggen och blir stolta. De växer upp och mognar till ansvarskännande globala medborgare. Utan dem skulle vår digitala värld vara på väg i en ganska så otrevlig riktning. Men här har vi lösningen. Och det finns massvis med sådana etiska hackare. Vi har två miljoner i vårt nätverk. På sätt och vis är de som digitala scouter. De över upp sig i nyttiga aktiviteter och gör en god gärning varje dag. De är redo.

Tack Mårten! Och för den som vill jaga efter säkerhetsbuggar och eventuellt tjäna lite pengar kan registrera sig gratis på HackerOne.com.

2023-09-04

DNStapir – Robust DNS

Jag tog ett snack under sommaren Olle E Johansson som är en av initiativtagarna bakom projektet DNSTapir. Olle berättar mer om projektet:

Fokus vad gäller DNS har varit mycket på hur man kan skydda sina frågor från insyn och hur vi kan lita på svaren. Vi såg att det finns mycket information i loggarna från DNS resolvers, dom som förmedlar svar, som är värd att analysera. Det görs idag, men i många fall av utländska aktörer som förser oss med gratis resolvertjänster. Vi vill se till att loggarna anonymiseras och att vi kan analysera data och se vad som händer, inte minst ur cybersäkerhetssynpunkt.

Med stöd av Sunet/Vetenskapsrådet bildade vi projektet Robust DNS som nu fått projektmedel av Post- och Telestyrelsen. Organisation: Vi är nu i en uppstartsfas av ett utvecklingsprojekt och ett Open Source-projekt. All utveckling kommer att ske öppet i vårt projekt ”DNStapir” på Github. Dagens gäng är initiativtagarna – däribland Lars Johan Liman på Netnod, Johan Stenstam på Internetstiftelsen, Jakob Schlyter på Kirei och Mikael Kullberg på Cat Herd. Leif Johansson på Sunet satte oss i samma rum och har fått igång projektet.

Vi har också resurser från Sunet i projektet och kommer att utvidga vårt nätverk och bygga en långsiktig organisation. Jag har en sammahållande funktion i det hela. Partners bakom projektet är idag PTS, Sunet/Vetenskapsrådet, Netnod och Internetstiftelsen. Vi kommer att söka samarbete med fler organisationer, både i näringslivet och i offentlig sektor. Framtidsplaner: Vi jobbar nu med steg 1: Utveckling av arkitektur och programvara.

Samtidigt planerar vi för kommande steg som innebär att bygga för drift och ge oss en stabil grund för vidare utveckling. Idéerna sprudlar och vi har många roliga diskussioner i arbetsgruppen. Målet är att vi ska bygga en plattform som olika operatörer – såväl privata som i offentlig sektor – har förtroende för. För att lyckas krävs ett samarbete, inte minst med Sveriges internetoperatörer. Vad gäller DNS generellt så är jag nog inte rätt person att svara, men har ju expertisen i projektet. Det pågår ju mycket arbete i IETF för att öka privacy i DNS och stärka infrastrukturen. Ett problem jag ser är ju att DNSSec inte har acceptans i alla kretsar och i viss mån motarbetas.

Personligen är jag ju intresserad av att förankra klient- och server-certifikat i DNS, vilket förutsätter DNSsec. Jag är med i arbetsgruppen DANCE som jobbar med klient-cert. Den lösningen handlar mer om TLS och applikationer än själva DNS, men förutsätter DNSsec.

Kontaktuppgifter: Om man har frågor får man gärna kontakta mig direkt. Som sagt, vi bygger upp en organisation inklusive web sajt och kommer att synas mer under hösten. Projektet DNStapir finns redan på GitHub och där kommer det löpande komma mer kod och ges möjlighet att medverka.

Följ även projektet på hemsidan dnstapir.se

2023-08-30

BloodHound CE ”Six Degrees of Domain Admin”

Säkerhetsverktyget Bloodhound finns nu ute i en ny utgåva vid namn BloodHound Community Edition (CE). BloodHound skapades 2016 av Rohan Vazarkar, Will Schroeder och Andy Robbins. Den har laddats ner närmare 500 000 gånger och har över 12 000 användare i BloodHound Community Slack. BloodHound har rekommenderats av US Cybersecurity, Infrastructure Security Agency (CISA) och av Microsoft för att hjälpa till att säkra Microsoft Active Directory och Azure AD.

BloodHound CE är den nya och fria, öppna versionen av BloodHound och som alltid kommer alltid att vara gratis under en Apache 2.0-licens. Den delar nu kodbas och dokumentation med BloodHound Enterprise (BHE), vilket innebär konsekventa och högkvalitativa uppdateringar. Från bl.a. SpecterOps som står bakom utvecklingen till stor del.

Nya funktioner och förbättringar

Ny arkitektur: BloodHound CE har en arkitektur med flera front-end och back-end komponenter, inklusive Postgres och Neo4J databaser, ett nytt REST API och en helt ny frontend-webbapplikation
Förenklad implementering: Alla komponenter presenteras nu i en helt containeriserad modell, vilket gör det enklare att köra BloodHound CE (se nedan)
Nytt GUI: Det nya gränssnittet är helt ombyggt och använder design och komponenter från BloodHound Enterprise, med diverse förbättringar
Säkerhet och autentisering: Nya funktioner inkluderar Cypher-inmatning, cachade frågeresultat och möjligheten att hantera användare och autentisering

Introduktion av BloodHound API

BloodHound API är en autentiserad REST API som accepterar och returnerar JSON-formaterad data. Det öppnar spännande möjligheter för att fråga BloodHound och få tillförlitlig, välformaterad data som kan användas som indata för andra verktyg.

Vad är nästa steg?

Denna första release av BloodHound CE är ett tidigt tillgänglighetsbygge. Applikationen är fullt funktionell och stabil, men det finns några kända buggar som arbetas med. Feedback är mycket välkommen, och du kan gå med i BloodHound Slack eller rapportera problem på BloodHound GitHub-repo.

Denna release markerar en helt ny era för BloodHound CE, med en helt ombyggd applikation som delar en gemensam kodbas med BHE. Detta innebär snabbare och enklare uppdateringar och community-bidrag i framtiden.

Ladda hem och testa nya BloodHound CE

Teamet tillhandahåller en docker-compose YAML-fil som enkelt kan laddas hem och startas. Ungefär något liknande bör fungera väl:

$ mkdir bloodhound-ce && cd bloodhound-ce
$ wget https://raw.githubusercontent.com/SpecterOps/BloodHound/main/examples/docker-compose/docker-compose.yml
$ docker compose up

Sen väntar du ett stund och läser texten som visas på skärmen när du kör docker compose up, där står lite intressant information som är viktig att ta del av. Bl.a. så står lösenordet till webbgränssnittet som du kan behöva. Exempelvis:

Du loggar sedan in mot localhost:8080 med din webbläsare och användarnamnet admin med lösenordet som visades upp.

Om du inte har en demo-miljö eller liknande och vill testa lite så finns det ett github-repo med test-data som du kan importera till Bloodhound (kolla även BadBlood):

github.com/mike-nolan-councilman/Bloodhound_Data

Viktigt att poängtera är att det inte finns något enkelt sätt i GUI:t att ladda upp JSON/ZIP-filer, som det fanns i tidigare versioner av Bloodhound. Det sättet jag gjorde var att använda python-programmet bloodhound import från Fox IT, installeras genom följande kommando:

pip install bloodhound_import

Sedan kan man köra:

for a in *.json; do bloodhound-import -p 7687 -dp bloodhoundcommunityedition -du neo4j $a; done

Observera att detta kräver att du exponerar port 7687 från Neo4j-containern. Det gör du enklast genom att modifiera docker-compose.yml. Viktigt att poängtera att lösenordet ovan som är bloodhoundcommunityedition bör ändras.

Nu bör demo-datat vara importerat och du kan använda API:et eller webb GUI:t. För mer information om REST API:et se apiclient.py samt följande supportsida hur du skapar upp API-nycklar.

Hur du enklast identifierar brister och tar över ett Windows AD är utanför denna guide.

2023-08-25

Evilginx version 3.2 ute nu

Nu finns det en ny version av phishing-ramverket Evilginx. Evilginx är utvecklat av Kuba Gretzky och var det första ramverket som var öppet och hade möjlighet att kringgå multifaktorsautentisering genom att utföra man-i-mitten-attacker (MITM). Jag kan även rekommendera denna artikel då jag testar ett annat liknande verktyg.

Nyheter i version 3.2

Den första och största nyheten har och göra med hur redirect_url fungerar. När väl en sessionstoken har spelats in vid en phishing-sida så har det tidigare varit svårt att göra ompekningar när sidorna har varit SPA:er (Single Page Applications). Men genom att injicera ett javascript i webbsidan som MITM:as så går det nu att göra en redirect enklare.

När en ny phishing-kampanj skickas ut via E-post så brukar de första som besöker phishing-sidorna vara automatiserade scanners som automatiskt försöker lista ut om länken i ett E-post är en phishing-sida. Genom att nu använda följande konfigurations-direktiv så är det möjligt att pausa phishing-sidan temporärt och således försvåra för dessas automatiserade scanningar och säkerhetsprodukter:

lures pause <id> <time_duration>

Det går nu att finjustera proxy-anropen som går via Evilginx och returnera egna fel-koder eller svar på HTTP-förfrågningar. Exempelvis:

intercept:
  - {domain: 'www.linkedin.com', path: '^\/report_error$', http_status: 200, body: '{"error":0}'', mime: "application/json"}
  - {domain: 'app.linkedin.com', path: '^\/api\/v1\/log\/.*', http_status: 404}

Det finns många andra nyheter och buggfixar i Evilginx, se följande inlägg för alla nyheter.

Skydd mot MITM/proxy phishing-attacker

Kuba som utvecklar Evilginx höll ett föredrag på konferensen x33fcon om hur man kan skydda sig mot denna typ av phishing-attacker där angriparen gör MITM/proxy-attacker för att stjäla sessions-cookies.

Föreläsningen hittar du inbäddad här:

2023-06-13

Fortinet SSL-VPN sårbarheter

Flertalet sårbarheter har identifierats i FortiOS som är operativsystemet som bl.a används för Fortinet SSL-VPN och FortiProxy. Flera av dessa sårbarheter utnyttjas även aktivt på internet och är således viktiga att åtgärda snarast.

Volt Typhoon Campaign är namnet på en pågående operation där antagonister utnyttjar sårbarheten CVE-2022-40684 som ej listas nedan, och som CVE:n antyder så är det en äldre sårbarhet från 2022. Microsoft har även en bra write-up gällande Volt Typhoon här.

Det är inte första gången som allvarliga sårbarheter uppdagats i Fortinets produkter, var inte så länge sedan som jag bloggade om denna sårbarhet.

Lista med nya sårbarheter i FortiOS:

Incident ID	NVD CVE	Product	Severity	Description
FG-IR-23-097	CVE-2023-27997	FortiOS	9.2 (Critical)	Heap buffer overflow in SSL-VPN pre-authentication
FG-IR-23-111	CVE-2023-29180	FortiOS	7.3 (High)	Null pointer de-reference in SSLVPNd
FG-IR-22-475	CVE-2023-22640	FortiOS	7.1 (High)	FortiOS – Out-of-bound-write in SSLVPNd
FG-IR-23-119	CVE-2023-29181	FortiOS	8.3 (High)	Format String Bug in Fclicense daemon
FG-IR-23-125	CVE-2023-29179	FortiOS	6.4 (Medium)	Null pointer de-reference in SSLVPNd proxy endpoint
FG-IR-22-479	CVE-2023-22641	FortiOS	4.1 (Medium)	Open redirect in SSLVPNd

Rekommenderad åtgärd från Fortiguard är att uppgradera till senaste FortiOS samt genomföra härdning av sina enheter, se till att inte använda enheter som är End-of-life.

2023-05-28

Barracuda varnar för ny zero-day

Företaget Barracuda går ut och varnar för en sårbarhet som aktivt utnyttjas. Sårbarheten återfinnes i dess produkt Email Security Gateway (ESG).

Sårbarheten har CVE-2023-2868 klassificeras som en Remote Code Injection-sårbarhet som finns i versionerna 5.1.3.001 till 9.2.0.006.

Företaget har 200000 kunder globalt men det är oklart i dagsläget hur många av dessa kunder som har sårbara enheter exponerade mot internet. Amerikanska CISA har lagt till sårbarheten till sin katalog med sårbarheter som aktivt utnyttjas ”Known Exploited Vulnerabilities Catalog”.

Sårbarheten har och göra med hur .tar-filer hanteras med perls qx-funktion.

Mer information finns på Barracudas status-sida.

2023-05-10

Ny lokal sårbarhet i Linux Netfilter

Netfilter är generellt den del i Linux-kerneln som handhar brandväggsfunktionalitet. Sårbarheten är av typen heap out of bounds write och medger att lokala användare kan eskalera sina behörigheter till root (administratör). Sårbarheten har fått CVE-2023-32233 reserverat och identifierades av Patryk Sondej samt Piotr Krysiuk

Denna sårbarhet är framförallt extra allvarlig för att den går att använda för så kallade ”container escape” attacker där det går att bryta sig ur en container-baserad miljö. Sårbarheten gäller samtliga nuvarande Linux-kernelversioner inklusive version 6.3.1. Oklart i dagsläget huruvida Android är sårbart för denna säkerhetsbrist.

Sårbarhet för att utnyttja denna kod har av misstag publicerats via en E-postlista. Observera också att även om kernelmodulen nf_tables som är sårbar, ej är laddad så tillåter många Linux-distros att automatiskt ladda in kernel-moduler som en vanlig användare.

2023-03-19

Många brister blir det

Det har uppdagats en hel del intressanta brister på senare tid så jag tänkte försöka skriva en kortare sammanställning på vad som kan vara bra att hålla koll på:

CVE-2023-23415 – Vilket är en sårbarhet i Windows som gör att en lyssnare på en RAW-socket kan troligtvis utföra RCE via ett ICMP-paket. Exempelvis på mjukvara som nyttjar RAW-sockets i Windows är Wireshark. Mer info här.

CVE-2023-24033 – Sårbarheter i Samsungs Exynos basbandsmodem. Möjliggör att en angripare kan få fotfäste i flertalet Google Pixel-telefoner såsom Pixel 6 och 7 samt flertalet Samsungmodeller. Voice-over-LTE (VoLTE) eller WiFi-samtal kan slås av för att mitigera sårbarheterna temporärt. Project Zero hos Google har skrivit här.

CVE-2023-21036 (acropalypse) – När crop-funktionen används i Android så tas inte den croppade delen bort. Det går att återskapa delar eller delen av bilden som har beskurits bort. Men observera att flertalet tjänster såsom Signal gör en konvertering av filen innan, således försvinner metadata. Intressant root-cause.

CVE-2023-23397 – Elevation-of-privilege i Outlook, utnyttjas aktivt just nu. Attacken upptäckes av CERT-UA, läs mer här. ”This attack vector, which leads to NTLM harvesting,”

2023-03-15

Kali Purple från OffSec

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:

Identify
Protect
Detect
Respond
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

SOC-in-a-box