Laitekoodikalastelu avaa M365-tilin hyökkääjälle – Riittääkö MFA enää?
Tämä on nykypäivää: Käyttäjä klikkaa dokumenttilinkkiä, kirjautuu Microsoftin oikealle sivulle ja hoitaa monivaiheisen tunnistautumisen niin kuin kuuluu. Jälkikäteen huomataan, että tilillä on tapahtunut outoja toimintoja. Ensimmäinen ajatus on “Tämän pakko olla joku murto”, mutta todennäköisesti mitään ei ole murrettu. Mistä siis on kyse? Riittääkö MFA enää suojaamaan tiliä ja kirjautumista?
Laitekoodikalastelusta (Device Code Phishing) on tullut erittäin tehokas tapa murtautua Microsoft 365 -ympäristöön. Tämä on selvästi huomattu kevään 2026 kyberhyökkäyksissä, ja Kyberturvallisuuskeskus on raportoinut tapauksista myös Suomessa.
Laitekoodikalastelussa ei ole kyse perinteisestä tunnusten kalastelusta, vaan itse kirjautumisprosessin hyväksikäytöstä. Se liittyy laajempaan ilmiöön, jossa hyökkääjät hyödyntävät identiteettipohjaisia kirjautumismekanismeja ja OAuth‑avaimia saadakseen pääsyn ilman salasanojen varastamista.
Miten hyökkäys toimii käytännössä?
Laitekoodikalastelussa käyttäjä ohjataan Microsoftin oikealle kirjautumissivulle ja hänelle annetaan laitekoodi, joka näyttää täysin normaalilta. Tämän jälkeen käyttäjä
- syöttää koodin,
- kirjautuu sisään ja
- hyväksyy MFA:n.
Kaikki menee siis näennäisesti oikein, mutta samalla hyökkääjän hallitsema laite saa pääsyn käyttäjän M365-tiliin. Jälkikäteen huomataan outoja sääntöjä postilaatikossa, epäilyttävää tiedostojen käyttöä tai kummallisia toimintoja tilillä.
Hyökkäys onnistuu, koska se käyttää hyväkseen Microsoftin omaa laitekoodikirjautumista, ja saa sen avulla käyttöönsä OAuth‑tunnukset ilman tarvetta kalastella salasanoja. Aiemmin ongelma syntyi siitä, mitä käyttäjä syötti, mutta nyt lumipallo lähtee liikkeelle siitä, mitä käyttäjä hyväksyy. Se tekee laitekoodikalastelusta hyvin vahingollista ja vaikeasti tunnistettavaa.
Miksi MFA ei pysäytä hyökkäystä?
MFA ei laita stoppia hyökkäykselle, koska hyökkäys ei riko mitään sääntöjä. Hyökkäyksessä hyödynnetään luottamusta ja rutiinia, ja kaikki näyttää teknisesti oikealta, vaikka kokonaisuus on väärä.
- Sivusto on oikea, sillä kirjautuminen tapahtuu Microsoftin omassa login flow’ssa.
- Monivaiheinen tunnistus toimii ja MFA hyväksytään käyttäjän toimesta.
- Sessio näyttää täysin normaalilta ja lokit näyttävät onnistuneen kirjautumisen.
Järjestelmä ei näe hyökkäystä, koska teknisesti sellaista ei tapahdu. Koska hyökkääjä saa käyttöönsä istuntoavaimen, jolla se pääsee palveluihin ilman uusia MFA-haasteita, ei mitään merkkejä epänormaalista toiminnasta ole havaittavissa. Tämän vuoksi pelkkä “kiristetään kirjautumista ja seurataan lokia” ei aina pysäytä tilannetta ajoissa. Hälytys syntyy usein vasta jälkikäteen, kun vahinko on jo tapahtunut.
Missä kohdassa hyökkäys tulisi pysäyttää?
Hyökkäys ei pysähdy endpointilla eikä MFA:lla, vaan kontrolloimalla, mistä kirjautuminen tapahtuu ja mistä liikenne tulee.
Ratkaiseva hetki ei ole kirjautumisessa, vaan se tapahtuu ennen sitä. Jos käyttäjä pääsee suoraan hyökkääjän rakentamaan näkymään, hyväksyntä tapahtuu helposti huomaamatta. Ongelmaa ei kannata hoitaa vain jälkikäteen selvittämällä, sillä se on raskasta, ja erityisesti PK‑ympäristöissä se helposti jää “tehdään kun ehditään” -tasolle. Kestävämpi malli on suojata arkea etukäteen. Hyökkäys voidaan pysäyttää kolmen toiminnon yhdistelmällä eli Kolmen Kohdan -metodilla:
1. Web-liikenteen kontrolli – estä hyökkäyksen alku
Monessa hyökkäyksessä käyttäjä ohjataan esikatselun, erilaisten ohjausten tai “jatka tästä” -näkymien läpi. Tämä on vaihe, jolloin käyttäjä usein viedään väärään kontekstiin.
Älä anna epäilyttävän sisällön aueta suoraan käyttäjän selaimeen. Epäilyttävä web‑sisältö voidaan avata hallitusti, niin ettei käyttäjä ole suoraan sisällä hyökkääjän rakentamassa näkymässä. Kun linkki avataan eristetyn selausympäristön kautta
- käyttäjä ei ole suoraan yhteydessä haitalliseen sivuun,
- sivu esitetään eristettynä näkymänä ja
- toiminta, kuten copy-paste tai tunnusten syöttäminen, voidaan estää eristetyssä selaimessa.
Käyttäjä näkee sivun, mutta ei ole suoraan vuorovaikutuksessa sen kanssa.
Lue lisää web-liikenteen kontrollista
2. Tee ehdollisesta pääsystä oikeasti tehokas
”Jos et kontrolloi mistä liikenne tulee, et voi kontrolloida kuka sitä käyttää”.
Sido pilvipalveluihin pääsy hallittuun verkkopolkuun. Kun etäkäyttäjille rakennetaan oma tunnistettava verkkopolku, josta pilvipalveluihin mennään, ei pelkkä käyttäjän tekemä hyväksyntä välttämättä riitä hyökkääjälle. Jos hyökkääjä yrittää käyttää pääsyä omasta verkostaan käsin, se voidaan estää, koska yhteys ei tule odotetusta luotetusta kontekstista.
Tämä on toteutettavissa niin, että web‑liikenne sisään kulkee Secure Web Gatewayn kautta ja ulos lähdetään organisaatiolle varatuista staattisista IP‑osoitteista. Näin etäkäyttäjälle syntyy “oma toimisto‑IP”, joka voidaan lisätä luotettuihin verkkoihin identiteettipolitiikoissa.
- Oma käyttäjä → liikenne kulkee hallitun reitin kautta → sallitaan
- Hyökkääjä → eri IP → estetään
Kun pääsy sidotaan luotettuun verkkoon, hyökkääjä ei pysty käyttämään tiliä, vaikka hän saisi kirjautumisprosessin käyntiin.
3. Rajoita ehdollinen pääsy vain sinne, missä sitä oikeasti tarvitaan
Jos organisaatiossa ei ole aitoa tarvetta tietyille vaihtoehtoisille kirjautumistavoille, niiden rajaaminen vähentää suoraan hyökkäyspintaa. Tämä kannattaa tehdä hallitusti, eli ensin selvitetään mikä oikeasti käyttää kyseistä kirjautumista, ja sen jälkeen suljetaan turha ovi.
Kun käyttäjäliikenne kulkee hallitun pisteen kautta
- näet, mihin dataa siirtyy,
- voit rajoittaa latauksia ja SaaS-palvelujen käyttöä (esim. ChatGPT vs CoPilot) sekä
- tunnistat poikkeavan käytön.
Näin suojaus ei jää vain kirjautumiseen, vaan se jatkuu koko session ajan.
Riittääkö MFA? – Laitekoodikalastelu ja suojautuminen tiivistettynä
Laitekoodikalastelu tuo ilmi hyvin tärkeän asian: pelkkä MFA ei enää riitä suojaamaan käyttäjiä. Aiemmin ajateltiin, että kun kirjautuminen on suojattu, riski on hallinnassa. Nykyään hyökkäys voi tapahtua, vaikka
- käyttäjä tekee kaiken oikein ja
- kirjautuminen on validi.
Siksi suojautuminen laitekoodikalastelulta tulee alkaa jo ennen kirjautumista. Hyökkäyksen torjuntaan ei riitä yksi kontrolli, vaan toimiva suojaus rakentuu Kolme Kohdan -metodilla:
Hallittu liikenne: Estä käyttäjän ohjaaminen hyökkäykseen. Katkaise epäilyttävä web‑polku ennen käyttäjän päätöstä
Hallittu kirjautuminen: Varmista, että kirjautuminen tapahtuu hallitusta ympäristöstä. Tarvittaessa myös “oma toimisto‑IP” etäkäyttäjille.
Jatkuva näkyvyys: Kontrolloi, mitä kirjautumisen jälkeen tapahtuu ja rajaa pois turhat kirjautumistavat.
Kun nämä kolme asiaa ovat kunnossa, hyökkäys menettää tehonsa.
Tunnistaisitko huomaamattoman hyökkäyksen?
Jos käyttäjä tekisi M365-ympäristössä kaiken oikein ja silti altistuisi hyökkäykselle, tunnistaisitko sen? Entä riittääkö MFA yksinään M365-tilin suojaamiseen? TNNet auttaa selvittämään, missä kohtaa riski laitekoodikalastelulle syntyy ja kuinka se katkaistaan ennen kirjautumista. Kokonaisvaltaiselta IT-kumppanilta löytyy keinot toteuttaa kaikki suojaukseen tarvittavat kolme tietoturvatoimintoa.
Haluatko lisää tietoa M365-tilin suojaamisesta? Tutustu TNNetin tietoturvaratkaisuihin.
Suojataan M365-ympäristö laitekoodikalastelulta
Laitekoodikalastelu on ovelaa toimintaa, mutta meiltä löytyy keinot suojata M365-ympäristö ja käyttäjä jo ennakkoon Kolmen kohdan -metodilla.
Kysy tietoturvaratkaisuistamme:
Lue seuraavaksi nämä:
Usein kysyttyä – Laitekoodikalastelu
1. Kehen laitekoodikalastelu voi kohdistua?
Laitekoodikalastelu voi kohdistua mihin vain organisaatioon, joka käyttää Microsoft 365-ympäristöä. Kohteena voivat olla sekä suuret yritykset että pk-yritykset.
2. Suojaako MFA tältä hyökkäykseltä?
Ei. Käyttäjä itse hyväksyy kirjautumisen, joten MFA menee läpi normaalisti eikä siksi teknisesti näytä normaalista poikkeavalta toiminnalta tai hyökkäykseltä.
3. Miten tiedän, onko tiliäni käytetty väärin?
Merkkejä voivat olla esimerkiksi uudet kirjautumissessiot, poikkeavat sijainnit tai sovellukset, joille on annettu käyttöoikeuksia.
4. Voiko laitekoodikirjautumisen estää?
Kyllä. Se voidaan rajoittaa tai estää Conditional Access -politiikoilla, ja Microsoft suosittelee sen estämistä, jos sitä ei tarvita. Lisätietoa Microsoftilta.