INCIDENT SE JE ZAČEL, PREDNO GA JE SISTEM PRVIČ ZABELEŽIL

Varnostni sistemi imajo radi dogodke. Prijava uporabnika ustvari zapis, sprememba avtentikacijske metode pusti sled, dostop do poštnega predala je mogoče evidentirati, dejavnost prek Microsoft Grapha pa je ob ustrezno omogočenem beleženju mogoče vključiti v širšo časovnico dogodkov. SIEM lahko takšne podatke poveže z informacijami iz drugih virov in iz njih sestavi precej natančno sliko incidenta. Takšna rekonstrukcija ima omejitev, o kateri se govori precej manj: sistem lahko zelo dobro vidi nadaljevanje napada, njegov začetek pa se je morda zgodil nekje, kjer organizacija nima nobene telemetrije.

Microsoft je septembra 2026 opisal napade, pri katerih so uporabniki na osebne telefone prejemali klice ali sporočila domnevne službe IT. Razlaga je bila dovolj verjetna: zaradi nove varnostne politike, težave s prijavo ali spremembe sistema naj bi bilo treba ponovno registrirati passkey oziroma drugo avtentikacijsko metodo. Uporabnika so nato vodili skozi postopek, ki je napadalcu omogočil dostop do njegove identitete.

Če je prvi stik potekal prek zasebnega telefona, ki ni bil vključen v organizacijski nadzor, tega dela zgodbe ni bilo v dnevnikih službenega računalnika. Microsoftovi preiskovalci so pri takšnih incidentih opozorili, da je bil lahko spomin zaposlenega na telefonski klic ali prejeto sporočilo najzgodnejši, v nekaterih primerih pa celo edini dokaz, kako se je kompromitacija dejansko začela. [1]

Forenzična časovnica zato ni nujno začela z IP-naslovom, dogodkom v dnevniku ali datoteko. Včasih se je začela s precej manj tehničnim podatkom: nekdo je nekaj minut prej poklical uporabnika in se predstavil kot informatika.

Napad se je preselil na drug del življenjskega cikla identitete

Večfaktorska avtentikacija in predvsem metode, odpornejše proti phishingu, so pomembno izboljšale zaščito uporabniških računov. NIST phishing odpornost opredeljuje kot lastnost avtentikacijskega protokola, pri katerem napadalec ne more pridobiti uporabne skrivnosti ali rezultata avtentikacije zgolj zato, ker je uporabnik napačno presodil, komu zaupa. WebAuthn je primer protokola, pri katerem je avtentikacija kriptografsko vezana na identiteto preverjevalnika oziroma avtenticirano domeno. Ročno prepisane enkratne kode takšne zaščite nimajo. [2]

Toda zaščita same prijave še ne pomeni, da je enako zaščiten celoten življenjski cikel identitete.

NIST zato poleg same avtentikacije posebej obravnava tudi dogodke, kot so vezava novega avtentikatorja, njegova zamenjava, obnova, preklic in druge spremembe. Prav ti postopki postajajo zanimivi za napadalce, saj lahko dobro zaščiteno prijavo obidejo tako, da poskusijo vplivati na to, katera naprava ali avtentikacijska metoda bo v prihodnje veljala za zaupanja vredno. [2]

Okta je julija 2026 dokumentirala napade, pri katerih cilj ni bil klasičen prestreznik gesla in kode MFA. Napadalec se je lažno predstavljal kot služba IT ter uporabnika vodil skozi postopek registracije novega avtentikacijskega sredstva. V enem izmed opisanih scenarijev je lahko nato v uporabnikov račun registriral passkey pod svojim nadzorom. Pri drugih napadih je med telefonskim pogovorom sprožil legitimni postopek samopostrežne ponastavitve gesla in uporabnika prepričal, da potrdi korake, potrebne za dokončanje postopka. [3]

Takšni primeri ne zmanjšujejo vrednosti phishingu odporne avtentikacije. Pokažejo pa, da se je del napadalne površine premaknil. Sam trenutek prijave je lahko zelo dobro zaščiten, medtem ko registracija nove metode, obnovitev dostopa in administracija identitete ostajajo postopki, v katerih je mogoče zlorabiti zaupanje uporabnika.

Za organizacijo to pomeni, da sprememba avtentikacijske metode ni zgolj administrativni dogodek. Pri privilegiranem ali drugače občutljivem računu ima lahko registracija novega avtentikatorja podobno težo kot sprememba varnostnih pravic.

Legitimna prijavna stran ni vedno dokaz legitimnega namena

Podobno spremembo logike pokaže zloraba postopka device code authentication. Ta OAuth mehanizem je namenjen napravam, na katerih običajna interaktivna prijava ni praktična. Naprava uporabniku prikaže kodo, uporabnik pa jo na drugi napravi vnese na spletni strani ponudnika identitete in tam potrdi zahtevo.

Sam mehanizem je legitimen. Težava nastane, če je napadalec tisti, ki je začel postopek in uporabnika prepričal, naj ga dokonča.

Microsoft je septembra 2026 opisal platformo EvilTokens, pri kateri so napadalci takšne postopke avtomatizirali za obsežnejše kampanje. Uporabnik je lahko prejel kodo in bil napoten na pravo Microsoftovo prijavno stran. Če je kodo vnesel in zahtevo potrdil, je s tem odobril sejo, ki jo je v ozadju sprožil napadalec. Za uspešen napad zato ni bilo nujno postaviti lažne kopije Microsoftove prijavne strani in na njej prestreči uporabniškega gesla. [4]

Ta podrobnost je pomembna tudi zunaj konkretnega napada. Dolgoletni varnostni nasvet, naj uporabnik preveri domeno in se prepriča, da je na pravi spletni strani, ostaja smiseln, vendar sam po sebi ni več dovolj. Prava stran lahko nastopa tudi znotraj zlonamernega postopka, če je uporabnik z manipulacijo prepričan, da potrjuje nekaj drugega od tega, kar se v resnici dogaja.

Microsoft je EvilTokens povezal z več kot 12.000 kompromitiranimi poštnimi predali v več kot 10.000 organizacijah. Po pridobljenem dostopu so napadalci med drugim uporabljali Microsoft Graph za nadaljnje aktivnosti v kompromitiranem okolju. [4] Primer zato kaže še nekaj drugega: socialni inženiring se vse manj zanaša na improvizacijo posameznega napadalca in vse bolj postaja del organizirane infrastrukture.

Okta je julija predstavila tudi platformo Work Panel, namenjeno podpori vishing operacijam. Sistem je združeval podatke o tarčah, upravljanje klicateljev, SIP infrastrukturo, phishing strani in upravljanje aktivnih sej. Del informacij o zaposlenih je bilo mogoče pridobiti iz komercialnih B2B podatkovnih virov, zato je lahko imel klicatelj že pred prvim stikom dovolj podatkov, da je bil pogovor videti precej bolj verodostojen od naključnega telefonskega poskusa. [5]

Uporabnik tako ne sliši nujno neznanca, ki ne pozna ničesar o njegovem okolju. Oseba na drugi strani lahko pozna njegovo ime, funkcijo, organizacijo in druge podatke, ki sami po sebi niso skrivni, vendar skupaj povečajo verjetnost, da bo zgodba o nujni spremembi MFA ali težavi z računom zvenela prepričljivo.

Dnevniki lahko začnejo pripoved šele na sredini

Ko napadalec pridobi dostop do nadzorovanega okolja, začne nastajati bistveno več tehničnih sledi. Vidna je lahko nenavadna uporaba device- code prijave, sprememba avtentikacijskih metod, dostop z nove lokacije, uporaba Microsoft Grapha, pregledovanje datotek, dejavnost v elektronski pošti ali ustvarjanje pravil v poštnem predalu.

Ti podatki so za preiskavo dragoceni, vendar lahko odgovorijo predvsem na vprašanje, kaj se je zgodilo po pridobljenem dostopu. Ne povedo nujno, zakaj je uporabnik nekaj minut prej potrdil zahtevo, ki je napadalcu ta dostop omogočila.

Predstavljajmo si preprost primer. V dnevnikih se prvi nenavadni dogodek pojavi ob 10.17. Zaznana je prijava, ki odstopa od običajnega vzorca uporabnika, pozneje pa še spremembe v njegovem računu. Med razgovorom uporabnik pove, da je približno ob 10.10 na zasebni telefon prejel klic osebe, ki se je predstavila kot član službe IT, poznala njegovo ime in ga opozorila na domnevno težavo z večfaktorsko avtentikacijo.

Sedem minut med klicem in prvim zapisom v informacijskem sistemu ni praznina v incidentu. Gre za del incidenta, ki se je zgodil zunaj dosega organizacijske telemetrije. Odgovor na to težavo seveda ni nadzor zasebnih telefonov zaposlenih. Smiselnejše je, da postopki odzivanja na incidente upoštevajo tudi komunikacijske kanale, ki jih organizacija tehnično ne nadzoruje. Pri sumu kompromitacije identitete je zato pomembno vprašati, ali je uporabnik tik pred dogodkom prejel telefonski klic, SMS, sporočilo v drugi komunikacijski aplikaciji ali nenavadno zahtevo za ponovno registracijo oziroma obnovitev dostopa.

Takšna informacija tehnične forenzike ne nadomešča. Lahko pa pojasni, zakaj se je v dnevnikih zgodilo nekaj, kar je bilo brez tega konteksta videti kot običajno uporabnikovo dejanje.

Nadzor identitete mora zajeti tudi njene spremembe

Praktična posledica je razmeroma preprosta: spremljanje identitete se ne sme končati pri vprašanju, ali je bila prijava uspešna.

Pomembni postajajo tudi dogodki, ki spreminjajo način, kako se uporabnik sploh lahko prijavi. Registracija novega passkeya, dodajanje drugega avtentikatorja, ponastavitev gesla, obnovitev računa in sprememba varnostnih podatkov so dogodki, pri katerih je smiselno preveriti ne le tehnično pravilnost postopka, temveč tudi njegov kontekst.

Microsoft in Okta v svojih priporočilih zato poudarjata nadzor nad spremembami avtentikacijskih metod, uporabo phishingu odpornejše avtentikacije, strožje preverjanje identitete pri podpornih postopkih, omejevanje device-code toka tam, kjer za poslovanje ni potreben, ter spremljanje nenavadnih aktivnosti po pridobljenem dostopu. Pri potrjeni kompromitaciji lahko ukrepi vključujejo tudi preklic aktivnih sej in žetonov ter odstranitev nepooblaščenih avtentikacijskih metod. [1][3] [4] Pomembna ostaja še organizacijska disciplina. Če služba IT uporabnike pogosto kliče in jih po telefonu vodi skozi občutljive spremembe avtentikacije, imajo napadalci na voljo zelo verjeten scenarij. Jasno določeni in uporabnikom poznani postopki zmanjšajo prostor za takšno zlorabo. Posebej občutljive operacije lahko potekajo samo prek vnaprej določenega in preverljivega kanala, pri privilegiranih računih pa je smiselno zahtevati dodatno potrditev.

Začetek incidenta ni nujno tam, kjer ga začne meriti sistem

Sodobna varnostna okolja zagotavljajo količino telemetrije, ki je bila še pred nekaj leti težko predstavljiva. Organizacije lahko spremljajo procese na končnih napravah, prijave, spremembe konfiguracije, aktivnosti v oblaku, uporabo aplikacij in velik del omrežnega dogajanja. Vse to bistveno izboljšuje možnost zaznave in rekonstrukcije incidentov.

Toda noben dnevnik ne more zapisati pogovora, za katerega sploh ne ve, da se je zgodil.

Pri napadih na identiteto je zato pomembna meja med tehničnim in človeškim delom incidenta. Če je prvi stik potekal prek zasebnega telefona, naslednji korak pa prek legitimnega postopka ponudnika identitete, lahko nadzorni sistemi nekaj časa beležijo tehnično pravilna dejanja, ne da bi poznali okoliščine, zaradi katerih so bila izvedena.

Šele združitev obeh plati pokaže celotno časovnico. Prijava, ki je v dnevniku videti kot začetek incidenta, je lahko v resnici že njegovo nadaljevanje.

Zato pri nenavadni prijavi ni vedno dovolj vprašati, s katerega IP- naslova je prišla. Včasih je pomembnejše vprašanje, kdo je uporabnika poklical pet minut prej.

EVIDENCE PROFILE

Dokazni profil članka

Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.

OSREDNJI DOKAZForenzična časovnica se lahko začne pred prvim tehničnim dogodkom; pri socialnem inženiringu je človeški spomin včasih najzgodnejši razpoložljivi dokaz.

RAZISKAVE0

DOKUMENTACIJA5

PREDOBJAVE0

UREDNIŠKI PREIZKUSNE

PREVERJENO2026-10-05

Viri

1. 01ADVISORYMicrosoft
   Microsoft Security Research. Passkey-themed social engineering leads to identity and cloud compromise. 9. september 2026.
2. 02STANDARDNational Institute of Standards and Technology (NIST)
   National Institute of Standards and Technology. NIST SP 800-63B-4 – Digital Identity Guidelines: Authentication and Authenticator Management. Julij 2025.
3. 03ADVISORYOkta
   Okta Threat Intelligence. How to stop attackers from self-serving their way into accounts. 10. julij 2026.
4. 04ADVISORYMicrosoft
   Microsoft Threat Intelligence / Microsoft Defender Experts. Unmasking EvilTokens: Getting to the root of device code phishing. 22. september 2026.
5. 05ADVISORYOkta
   Okta Threat Intelligence. Behind the scenes of a vishing operation. 28. julij 2026.