Alle hendelser kunne vært unngått og det er lett å være etterpåklok. Denne posten handler ikke om å peke, men mer om å opplyse alle sammen for å lære, og deretter revidere egne systemer for å finne sårbarheter som må adresseres, og helst raskt.
Fagartikler med informasjon
Digi postet denne artikkelen 18. desember om hendelsen hos Nettdrift AS:
I denne ble dette beskrevet:
Nettdrift AS og Inventum Øst AS ble tatt av Akira
Hvor mange i Norge som er tatt av Akira siden mars i år er umulig å vite, men flere tjenester er nede nå om dagen grunnet ransomware, og flere har nok vært det de siste månedene uten av det kommer ut i media.
I dag kom denne saken i Digi:
Her står det:
Interfil skriver i dag dette på sine sider, mens nettbutikken fortsatt er nede, 10 dager etter angrepet 10. desember:
Nyhetssaker om Akira
Jeg har de siste dagene googlet og lest meg opp på Akira, og mange har skrevet mye om dem. Forskjellige har opplevd litt forskjellige teknikker, og jeg tar med noen artikler her:
GBHackers On Security
Anta at brukernavn og passord er på avveie.
Anta at brukere klikker på phishing e-poster.
Anta at brukerdatabaser har kommet på avveie.
Anta at brukere har samme brukernavn og passord kombinasjon flere steder.
Bruk MFA. Krev MFA.
Sikre at MFA er på alle tjenester, eksterne og interne, for alle brukere, absolutt alle brukere, inkludert eksterne?
En meget oversiktlig timeline for angrepet, som også viser hvor omfattende og komplekst dette er. Man kan si at hver enkelt teknikk ikke er så avansert, men flere vil kalle slike angrep sofistikerte.
Dette tar med andre ord mange dager. Ser man på Interfil saken står det at angrepet startet 25. november, men ble ikke oppdaget før 10. desember, mest sannsynlig grunnet kryptering. Dette betyr at man har tid til å oppdage, om man forbereder seg. Derfor er det viktig med #AssumeBreach. Mennesker MÅ anta besøk av uvedkommende!
Bleeping Computer har flere artikler om Akira
Darktrace
Dette er en teknisk veldig bra artikkel.
Akira bruker flere taktikker for å komme inn
Ser man på det som er skrevet i artiklene er disse inngangsmetodene nevnt:
- VPN
- RDP
- Cisco ASA/FTD sårbarhet
For de to første snakker vi tilgang med brukernavn og passord, uten krav om MFA.
Hvordan var dette mulig? Dette kan være et resultat av phishing, eller brute force.
For Cisco sårbarhetene snakker man om viktigheten av patching, men også viktigheten av et godt og sikkert design og oppsett som kunne avverget hendelsene.
Når de er inne begynner bevegelser rundt omkring i nettverket, og dette skjer via RDP og SMB.
RDP MÅ ha MFA også internt, fordi man MÅ anta at uvedkommende er på innsiden. Dette er enkelt å implementere, og mest sannsynlig gratis. Det handler om å tenke lagvis sikkerhet.
SMB er et issue, da rettigheter ofte er liberale internt i et domene. Men altfor ofte er rettighetene altfor liberale. Det er administrator rettigheter for altfor mange, og mulighetene er for store når man først er inne. Segmentering er viktig for å redusere potensielt skadeomfang.
Tidslinjen
Tidslinjen til GBHackers On Security må repeteres, for den inneholder mange gode detaljer:
Vi har snakket om den intielle fasen for å komme inn, med misbruk av sårbarheter, samt innlogging via VPN og RDP.
Det er også snakket om Lateral Movement med RDP.
Persistence og Command & Control, med SSHD, opprettelse av kontoer, OpenSSH, TeamViewer og Cloud Flared.
- Her er b.la VG testen relevant ved å hviteliste utgående trafikk fra servere for å redusere mulighetene, angrepsflaten og dermed risikoen. Det handler om lagvis sikkerhet.
Lekkasje av data skjer ved hjelp av verktøy som WinRAR, WinSCP og Filezilla.
- Hvitelisting av prosesser på servere burde hindre dem i fra å kjøre applikasjoner som WinRAR.
- Det samme kan forhindre bruk av verktøy som WinSCP og Filezilla.
- Adressering av VG testen vil også forhindre muligheten for eksport av data ut ved hjelp av WinSCP og Filezilla.
Siste del der krypteringen skjer.
- AnyDesk burde ikke kunnet kjøre på serverne, og adressering av VG testen skulle hindre opprettelse av sesjon utgående.
- Netscan -> segmentering.
- Defender disabling -> Hardening av server, les om CIS Benckmarks.
- Kjøring av skadevaren. Denne har blitt lastet ned på et tidspunkt, og skulle vært stoppet av et solid utgående regelsett i brannmuren med Least Privilege (VG testen), SSL dekryptering og inspeksjon med DNS sikkerhet, URL sikkerhet, sandkasse sikkerhet og mer.
- Med Defender disablet blir beskyttelsen begrenset, men kontroll på administrator rettigheter, og hvitelisting av prosesser med f.eks AppLocker burde bidratt.
Og mer….
I artiklene finner man enda flere tekniske detaljer nede på Windows nivå.
Konklusjon
Disse angrene gjorde skade fordi det var mange sårbarheter. Angrepet har mange faser, og angriperne bruker lang tid. Det er mange muligheter til å forhindre skaden, og det er flere muligheter til å oppdage dem før det er for sent.
Alle MÅ tenke solid lagvis sikkerhet. Disse angrepene gjør skade som et resultat av flere sårbarheter i kjede.
Alle MÅ tenke Assume Breach, for først da vil man heve sikkerheten på innsiden, med bedre tilgangskontroll, overvåking og patching, segmentering, MFA også på innsiden, Least Privilege på innsiden og adressering av VG testen med utgående Least Privilege.
Logging med overvåking er for mange en undervurdert verdi. Ser man på Akira angrepene foregår de over flere dager, og da burde god logging med god overvåking bidra til oppdagelse før katastrofen er et faktum
Når skaden er et faktum er det viktig å ha antatt ransomware på forhånd, og dermed sikret seg en backup som ikke bare overlever kryptering med immutability, eller at den er ekstern, men også at man kan klare å gjenopprette raskt. For å gjenopprette raskt må man for det første ha dataene intakt, men før dette igjen må/bør man ha en avtale med et firma som kan hjelpe til raskt med hendelseshåndtering. For selv om man har dataene, kan man ikke bare gjenopprette blindt, for man må finne ut hva man skal gjenopprette, fra når, for å vite at det er trygt, og det kan ta tid. Og selv når dette er OK burde man ha trent på gjenoppretting for å vite hva man starter opp først, som nummer to osv, for systemer er avhengig av hverandre.
Å ha offline backup er fint på en måte, men om det påvirker gjenopprettingstiden med stort negativt fortegn burde man se på andre løsninger som kan stå i eget nettverk med trygghet om at det overlever, og dermed bidrar til raskere gjenoppretting, med et forberedt automasjonsmalverk.
Kontroller
- Sikre MFA for alle brukere for alle eksterne tjenester. Verifiser tredje parts brukerkontoer!
- Fjern gammelt utstyr, fordi det kan fortsatt misbrukes selv om det ikke er i produksjon
- Sikre at inngående regler i brannmuren er i tråd med Least Privilege. Dette jobber jeg med hver eneste dag, og dette anser jeg som en ekstremt lavthengende frukt som er enkel og rask å adressere.
- Patch, patch, patch. Ikke vent. Se på hendelsen i Danmark i mai. Der ble patch for sårbarhet annonsert 25. april, kundene ble purret om patching 1. mai, og hendelsen var et faktum 11. mai
- Segmenter på innsiden og vær streng på Least Privilege mellom segmentene for bl.a å begrense muligheten til RDP
- Aktiver MFA på RDP og på så mange tjenester som mulig internt, først og fremst for alle administrator kontoer
- Sikre dere en robust endepunkt sikkerhetsløsning som ikke enkelt bare kan slås av. Windows Defender er sårbar grunnet knytningen til OS’et. Det er forskjell på disse produktene på mange ting, og en av forskjellene er muligheten for disabling. Dette har jeg skrevet om.
- Adressér VG testen for å hindre muligheten til kjøring av Command & Control, som igjen reduserer muligheten for å laste ned kode og skadevare, samt vingeklipper muligheten for eksfiltrering av data.
Det er snart jul. Start nå!
Flere av disse anbefalingene kan gjøres veldig raskt, så se hva dere kan få gjort før helga.
God jul!
Leave a Reply