Näin MFA murretaan ja miten organisaatio voi suojautua siltä
Adversary-in-the-Middle –hyökkäys on edistynyt tekniikka, jolla hakkeri varastaa käyttäjän kirjautumistiedot niin, että myös MFA voidaan ohittaa. On siis tärkeää luoda monikerroksinen suojaus, kouluttaa käyttäjiä ja käyttää CAP:in suojauominaisuuksia.
Adversary-in-the-Middle -hyökkäys ohittaa myös MFA:n
Monet organisaatiot luottavat monivaiheiseen tunnistautumiseen (MFA) suojatakseen organisaatiotaan ja käyttäjiensä tilejä tietomurroilta. On kuitenkin hyvä tiedostaa, että vaikka MFA lisää merkittävästi turvallisuutta, se ei takaa täydellistä suojaa.
Viime vuosina on yleistynyt hyökkäys, joka kiertää MFA:n – nimeltään Adversary-in-the-Middle (AitM). Tässä kirjoituksessa selitetäänkin, miten kyseinen hyökkäystapa toimii käytännössä, miten sillä voidaan varastaa käyttäjän token ja ohittaa monivaiheinen tunnistautuminen (MFA). Lopuksi tietysti muutama vinkki siihen, mitä organisaatiot voivat tehdä suojautuakseen kyseiseltä uhalta.
Miten Adversary-in-the-Middle (AitM) -hyökkäys toimii?
AitM-hyökkäyksessä käyttäjä johdatellaan kirjautumaan välimiehen hallitsemaan verkkosivuun, joka toimii välittäjänä aidon palvelun, kuten Microsoft 365:n, ja käyttäjän selaimen välillä. Yksi tunnetuimmista tämän hyökkäystavan työkaluista on Evilginx, joka on kaikille ilmaisesti ladattavissa ja kohtalaisen yksinkertainen käyttää.
Vaativinta hyökkääjälle tässä skenaariossa on luoda aidolta vaikuttava kalasteluviesti, joka ohjaa Microsoftin kirjautumisikkunaan.
1. Hyökkäyksen kulku:
1️⃣ Hyökkääjä lähettää uhrille huolellisesti rakennetun kalastelulinkin, joka ohjaa Evilginx-palvelimelle.
2️⃣ Evilginx toimii proksina (välityspalvelimena) välittäen kaiken liikenteen aidon M365-kirjautumissivun ja käyttäjän välillä. Käyttäjä ei huomaa mitään epäilyttävää, sillä kaikki näyttää aidolta. MFA mukaan lukien.
3️⃣ Kun käyttäjä syöttää tunnuksensa ja suorittaa MFA-tunnistautumisen, Evilginx kaappaa sessioevästeet (session cookies/tokenit), jotka kertovat selaimelle, että käyttäjä on jo kirjautunut.
2. Tokenin käyttö:
Varastetun tokenin avulla hyökkääjä voi:
1️⃣ Lisätä tokenin oman selaimensa evästeisiin.
2️⃣ Tämän jälkeen hän voi kirjautua suoraan M365-palveluun, aivan kuin olisi kyseinen käyttäjä – ilman käyttäjätunnusta, salasanaa tai MFA-kyselyä.
3️⃣ MFA on näin jo suoritettu oikean käyttäjän toimesta ja istunto on aktiivinen.
Miten organisaatiot voivat suojautua?
Vaikka kyseessä on teknisesti edistynyt hyökkäys, AitM-hyökkäyksiä ei ole mahdotonta estää. Tässä kolme tärkeää suojaustoimenpidettä, joita jokaisen organisaation tulisi hyödyntää:
1. Tietoturvatietoisuus ja koulutus
Suurin osa AitM-hyökkäyksistä alkaa huijausviestillä tai linkillä. Hyvin koulutettu käyttäjä tunnistaa epäilyttävän URL-osoitteen tai viestin, joka vaikuttaa poikkeavalta.
1️⃣ Käytä simuloituja phishing-harjoituksia.
2️⃣ Korosta, että MFA ei tee tilistä ”täysin turvattua”.
3️⃣ Opeta tunnistamaan aidot URL-osoitteet, kuten login.microsoftonline.com.
Vetonaula tarjoaakin monipuolisesti palveluita käyttäjäkoulutukseen.
2. Conditional Access Policy (CAP) – ja sen rajoitteet
Microsoft 365 Business Premium -lisenssillä saa käyttöönsä Conditional Access -käytännöt, joilla voidaan rajoittaa pääsyä esimerkiksi:
🌍 Vain sijainnin, laitteen tilan tai sovelluksen perusteella.
💻 Esimerkiksi pääsy sallitaan vain, jos laite on Entra ID:n compliant–tilassa eli hallittu ja tietoturvapolitiikat täyttävä.
Miksi tämä ei riitä välttämättä?
Jos hyökkääjä onnistuu varastamaan tokenin käyttäjältä, jonka laite on compliant, ja kopioi kyseisen tokenin omaan laitteeseensa, joka on myös määritelty compliantiksi (tai onnistuu huijaamaan tätä statusta), niin CAP ei estä hyökkääjää pääsemästä sisään. Microsoft ei tarkista uudelleen MFA:ta tokenin elinkaaren aikana – se olettaa, että tokenin omistaja on edelleen sama käyttäjä samalta laitteelta.
3. Token Protection for Conditional Access (Preview)
Token Protection on Microsoftin uusi vastaus juuri tähän ongelmaan. Se tuo tokeniin vahvemman kontekstin, mm:
1️⃣ Token sidotaan tiettyyn laitteeseen ja käyttäjään.
2️⃣ Jos hyökkääjä siirtää tokenin toiseen laitteeseen – token ei toimi.
3️⃣ Käytännössä tämä tekee AitM-hyökkäyksestä hyödyttömän.
Mutta mitä tämä vaatii?
Tämä ominaisuus vaatii käyttäjiltä Microsoft Entra ID P1 (sisältyy Business Premium -lisenssiin) tai P2 -lisenssin. Lisäksi ominaisuus on vielä osittain esikatseluvaiheessa, eli sitä ei ole saatavilla kaikille organisaatioille oletuksena, eikä se tue kaikkia työpöytäsovelluksia tai laitteita.
Yhteenveto
💡 AitM-hyökkäys on erinomainen esimerkki siitä, miksi monikerroksinen suojaus on tärkeää. MFA on hyvä lähtökohta, mutta ei riitä yksin. Hyökkäykset kehittyvät – myös puolustuksen pitää kehittyä.
💡 Mikäli haluat nähdä miten hyökkäys käytännössä toimii, voit hakea esimerkiksi YouTubesta demovideoita hakusanalla: Evilginx Attack Demo: How Hackers Bypass Microsoft MFA.
Toimi näin organisaatiossasi:
✅ Kouluta käyttäjiä jatkuvasti.
✅ Käytä Conditional Access Policyja (CAP) viisaasti – mutta ymmärrä sen rajoitukset.
✅ Suunnittele siirtymistä Token Protection -strategiaan ja varmista, että teillä on tarvittavat lisenssit.