Kringgå multifaktorautentisering
Vi har tidigare på bloggen skrivit om hur multifaktorsautentisering (MFA) kan kringgås (https://simovits.com/kringga-2fa-lika-latt-som-123/). I det länkade inlägget visade Peter på hur det är möjligt att med verktyget Modlishka kapa sessioner till webbapplikationer som använder sig av MFA. Detta genom att lura användare att gå in på en sida med en snarlikt namn som den egentliga sidan och skicka all kommunikation genom Modlishkas proxy. I veckans inlägg ska vi diskutera ett en annan metod för att kringgå MFA – MFA-spamming.
Genomgående i denna bloggpost kommer notifieringar och notiser användas synonymt.
Multifaktorautentisering och metoder
Innan vi går in på vad MFA-spamming är ska vi inleda med ett grundläggande stycke om vad MFA är och vilka metoder som vanligtvis används.
MFA är ett andra steg i ledet vid autentisering av användare och ger ett ytterligare skydd för att stärka en användares identitet. Vid användning av MFA används ytterligare en faktor i kombination med ett lösenord och används oftast med exempelvis SMS, OTP i app, push-notiser och samtal. Det ger en starkare försäkran om att användare är den som denne utger sig att vara.
MFA är ett utmärkt skydd som förhindrar en stor del av alla phishingangrepp och det är även tydligt när man tittar på trender inom cybersäkerhet. Jämförs det senaste tre årsrapporter som IBM har gett ut [D2], är det tydligt att med det bredare införandet av MFA söker sig angripare till andra metoder för initial åtkomst. Phishing ligger fortfarande bland topp tre för initial attackvektor men har tappat position för andra attackvektorer såsom stulna autentiseringsuppgifter och utnyttjande av kända sårbarheter. Phishing står för ca 33 % av alla initiala attackvektorer enligt [D2] och 2020 var samma siffra 41 %. MFA har troligen i kombination med en större uppmärksamhet på problemet med phishing bidragit till denna minskning. MFA ska trots det inte ses som en silverkula mot phishingattacker och kontokapning utan ett komplement till ett kontinuerligt säkerhetsarbete.
MFA-spamming
En angreppsmetod som blivit allt vanligare efter LAPSUS$ attack mot Okta är MFA-spamming. Metoden har funnits ett tag men efter LAPSUS$ attack uppenbarades svagheter i vissa MFA-metoder, bland annat samtal och push-notiser, men särskilt det sistnämnda. När LAPSUS$ väl hade korrekta autentiseringsuppgifter till en användare, spammade de användaren till dess att användaren godkände inloggningen. I Figur 1 och 2 ses ett utdrag ur LAPSUS$ officiella Telegram-kanal.
Figur 1. Bild från LAPSUS$ officiella Telegram-kanal.
Figur 2. Bild från LAPSUS$ officiella Telegram-kanal.
Metoden som beskrivs i bilderna ovan är effektiv då, åtminstone jag, hade troligen klickat bort notisen eller svarat på samtalet mitt i natten. Som tidigare nämnt så är metoden inte ny utan har använts ett tag, Mandiant skrev en bloggpost om förfarandet som användes av ryska APT:er i december 2021 [D1].
MFA-spamming med push-notiser
Metoden innebär att angripare försöker logga in på en användares konto upprepade gånger och att det då skickas ut flertalet notifieringar till användaren där denna ombedes att godkänna inloggningen med sin telefon. Efter tillräckligt många notifieringar blir användaren irriterad och godkänner angriparens inloggning på dennes konto/enhet.
Attacken är enkel i den meningen att det endast krävs att angriparen manuellt eller automatiskt försöker logga in på en användares konto/enhet och genom detta spamma användaren med push-notiser. Det kräver dock att angriparen har kännedom om användarens lösenord vilket skulle kunna erhållas genom brute-force, passwords-spray eller leta i lösenordsdumpar.
Attacken är särskilt effektiv eftersom den inriktas mot den mänskliga delen av MFA. Användare är generellt inte medveten om att det är en attack och förstår således inte att de ger en angripare åtkomst till deras konto. Användare kan tro att det rör sig om en bugg eftersom det kommer så stora mängder notiser. En användare kan vara distraherade eller vill bara att dessa notiser ska sluta komma så till slut så godkänner de bara notiserna. Figur 3 visar ett exempel på en push-notis som kommer till en användare och hur lätt det är att bara acceptera notisen.
Upptäcka MFA-spamming och åtgärder för att stoppa det
I de kommande avsnitten kommer flera åtgärder för att upptäcka MFA-spamming i Microsoft 365 att demonstreras samt åtgärder som kan vidtas för att stoppa liknande attacker. Flera av åtgärderna förutsätter att en organisation har specifika Microsoft-licenser som tillåter de utpekade åtgärderna.
Upptäcka MFA-spamming
Vi kommer visa flera metoder för att upptäcka MFA-spamming.
1. Manuellt i Azure
Gå in på Azure-portalen (URL) och klicka dig vidare till Monitoring och sedan Sign-in Logs. På denna sida finns information om varje användares inloggningar och från vilken enhet och IP-adress. Filtrera inloggning på Status efter Failure för att erhålla en lista över misslyckade MFA-inloggningar.
Härifrån är det möjligt att manuellt gå in och undersöka varje enskild inloggning. Det som bör undersökas är ifall inloggningen:
- Skett från en organisationsägd enhet som är enrollad. Enheten har då ett enhets-ID och det är mer troligt att inloggningen då är legitim om inte en angripare har komprometterat enheten.
- Skett från de IP-adresser användaren vanligtvis brukar logga in från, och
- Om lösenordet är korrekt men MFA misslyckas eller avvisas upprepade gånger.
Det finns såklart undantag till det ovanstående som exempelvis att användaren har problem med sina enheter, användare har inte en organisationsägd enhet som är enrollad i Azure och/eller användare arbetar på distans och/eller på flera platser. För att till fullo veta vad som försiggått bör man kontakta användaren eller dennes chef.
Det går även att i Azure Sentinel eller Advanced Hunting använda sig av sökfrågor för att upptäcka dessa attacker. De nedanstående sökfrågan hämtar alla poster med status att MFA har avvisats.
SigninLogs
| where ResultType == 500121
| where Status has "MFA Denied; user declined the authentication"
Från denna är det möjligt att skapa larm som notifierar när sådant händer. Det finns en uppsjö med sökfrågor som kan användas, bland annat [3,4,5].
Mitigerande åtgärder
Det finns flera åtgärder för att mitigera denna typ av attack. Vi kommer nedan att punkta upp några av dessa så att M365 administratörer kan använda den metod som passar organisationen bäst.
Generella åtgärder
- Utbilda användare: Det absolut effektivaste metoden att stoppa inverkan av phishing är att utbilda användare. Genom att utföra awareness-kampanjer och utbildningar för alla medarbetare som ämnar till att öka uppmärksamheten för phishing ger ett stort avtryck i organisationen och bidrar till en högre rapporteringsgrad av phishingmail.
Specifika Microsoft-åtgärder
- Aktivera Impossible travel detektion: Microsofts inbyggda Impossible travel larm genererar stora mängder larm och vill man undvika hantera flera (100st+) Impossible travel varje dag bör man skriva ett eget i Sentinel eller Advanced Hunting. Det finns flera exempel på larm som exempelvis dessa [6,7]. Den senare referensen använder sig av flera förbättrande åtgärder till Microsofts larm som jämför senaste sju dagars aktivitet för användaren, berikning av loggar med Treat Intel och inkluderar/exkluderar vissa användare, applikationer och/eller IP-adresser för att ta bort false positives.
- Aktivera Azure AD Identity Protection: Azure AD Identity Protection skyddar användare genom att basera skyddet och risken på Microsoft Threat Intel. Funktionen kan exempelvis upptäcka:
- Onormal resa (Atypical travel)
- Obekanta inloggningsegenskaper
- Password spray
- Läckta autentiseringsuppgifter
- M.m
Microsoft beskriver hur risker och larm genereras på [8].
- Avaktivera push-notiser och telefonsamtal som verifieringsåtgärd: Avaktivera push-notiser och telefonsamtal som tillåten MFA och tillåt endast sådant som tvingar användaren att mata in en kod för autentisering. Det medför att MFA-spamming inte blir en tillräckligt enkel attack om dessa avaktiveras. Detta kan göras genom att gå in på Azure AD -> Alla användare -> MFA per användare och klicka på tjänsteinställningar på den resulterande sidan. Därefter klicka bort alternativ för ”Samtal till telefon” och Meddelande via mobilapp. Se bilder nedan:
Säkerställ att den i er organisation som skall göra detta har rätt behörigheter, i bilden ovan är allt gråmarkerat då jag inte har korrekt behörigheter att ändra denna inställning.
Sammanfattning
Som vi har beskrivit i denna blogg är MFA-spamming ett bekymmer som bör tas hänsyn till vid prioritering av säkerhetsåtgärder inom en organisation. Tillåts telefonsamtal och/eller push-notiser kan en angripare kompromettera konton/enheter och vi har visat hur det går att upptäcka och skydda sig mot sådana attacker. Utöver det som beskrivits i bloggen finns ytterligare åtgärder som kan vidtas för att skydda sig mot denna typ av attacker och dessa är bara en Google-sökning bort.
Referenser
[1] – https://www.mandiant.com/resources/russian-targeting-gov-business
[2] – https://www.ibm.com/security/data-breach/threat-intelligence/
[6] – https://learnsentinel.blog/2021/07/16/cloud-app-security-azure-ad-identity-protection-help/
[7] – https://medium.com/@adriangrigorof/the-impossible-travel-alert-friend-or-foe-1c49768d5d4c