Защо MFA вече не е достатъчна сама по себе си
Много организации са въвели MFA и с това са затворили една от най-очевидните врати за компрометиране на акаунти. Проблемът е, че съвременните атаки рядко спират до екрана за вход. След като един акаунт бъде потвърден, реалният риск често се премества към сесията, токена, device trust модела и допълнителните облачни права.
Това е причината MFA fatigue, session hijacking и token theft да са толкова важни за администраторите. Те показват, че „валидният login“ не означава „безопасен достъп“. Ако атакуващият вече е вътре чрез легитимна сесия или откраднат токен, класическите проверки за парола и дори стандартната MFA защита могат да не дадат достатъчно ранен сигнал.
Ако искате по-широката рамка защо identity е новият attack surface, вижте и Identity is the new attack surface, както и статията за stolen credentials и phishing през 2026.
Какво представлява MFA fatigue на концептуално ниво
MFA fatigue е модел, при който потребителят е подложен на серия от неочаквани потвърждения или prompts за вход, докато в даден момент приеме заявка по навик, по грешка или от умора. От защитна гледна точка проблемът не е само в самото потвърждение, а в това, че организациите често приемат всяка MFA успешна заявка за „нормална“, без да я поставят в контекст.
Това означава, че администраторите трябва да гледат не само дали MFA е минала, а как е минала: от какво устройство, от коя локация, с каква честота, в какъв час и дали поведението съвпада с обичайния профил на потребителя.
Защо session hijacking и token theft са по-трудни за разпознаване от password theft
Кражбата на парола често оставя по-очевидни следи: failed logins, unusual password resets или вход от нови места. При session hijacking и token theft ситуацията е по-неприятна. Сесията вече е валидирана и атакуващият може да се възползва от доверие, което системата вече е изградила.
Точно затова тези атаки са трудни за засичане с единствено базови логове. Те често изглеждат като нормален достъп, особено ако липсва добра корелация между IdP, endpoint telemetry, облачни logs и поведенчески сигнали.
В практиката това е особено чувствително в Microsoft 365, Google Workspace, SaaS приложения и VPN среди, където една активна сесия може да даде достъп до имейл, файлове, чатове, приложения и допълнителни consent-и.
Какви сигнали трябва да следят администраторите
За да има ранно откриване, е добре да се наблюдават не само входовете, а и моделите на поведение след login. Най-полезните сигнали включват:
- необичайни MFA prompts или внезапно увеличен брой заявки;
- нови сесии от неочаквани устройства или браузъри;
- impossible travel или внезапна промяна на географията;
- device changes, които не съответстват на нормалния потребителски профил;
- consent abuse или подозрителни промени в разрешенията на приложения;
- необичайни правила за forwarding, inbox rules или достъп до чувствителни данни;
- вход в необичайни часове или нетипични заявки към SaaS ресурси;
- сесии с нетипична продължителност или активност след смяна на IP/устройство.
Важно е тези сигнали да не се разглеждат изолирано. Едно събитие може да е легитимно, но комбинацията от няколко индикатора често е по-силен сигнал от която и да е единична алерта.
Какви логове и telemetry да включите в monitoring-а
Добрата identity threat detection стратегия започва с видимост. Без достатъчно telemetry няма как да различите нормален достъп от компрометирана сесия. Минимумът включва:
- логове от Identity Provider-а;
- sign-in events и MFA events;
- audit logs за промени по акаунти, роли и permissions;
- session и token-related събития, когато платформата ги предоставя;
- endpoint telemetry от managed устройства;
- cloud audit logs за ключовите SaaS и IaaS услуги;
- alertи за неочаквани admin actions, consent changes и mailbox modifications.
Ако разполагате със SOC или MSSP, е полезно да изискате корелация между IdP, endpoint и cloud logs. Самостоятелно всеки източник е полезен, но заедно дават много по-ясна картина.
Conditional access, device trust и session controls
Една от най-силните защити срещу post-login атаки е да ограничите не само кой може да влезе, а и от какво доверено устройство и при какви условия. Conditional access помага да се изисква по-висока степен на проверка при риск, ново устройство, необичайна локация или чувствителна операция.
Практически полезни мерки са:
- изискване на MFA при риск или при достъп до критични приложения;
- device trust или compliant device политики за чувствителни ресурси;
- ограничаване на legacy authentication;
- short-lived sessions за админ и high-risk роли;
- re-authentication при критични действия;
- session controls за SaaS приложения, когато са налични;
- блокиране или ограничаване на непознати приложения и risky consent flows.
Тук целта не е да затрудните всички потребители безразборно, а да наложите по-строг контрол там, където рискът е реално по-висок.
Incident response при съмнение за компрометирана сесия
Когато подозирате token theft или session hijacking, реакцията трябва да е бърза и последователна. За разлика от традиционен password incident, тук само промяна на парола често не е достатъчна.
Полезен ред на действие е:
- потвърдете дали има активна подозрителна сесия и кои ресурси е достигнала;
- ревокирайте session tokens и прекратете активните сесии, ако платформата позволява;
- нулирайте или ограничете достъпа до чувствителни приложения и роли;
- проверете за промени в forwarding rules, consent-и, inbox правила и admin privileges;
- прегледайте endpoint-а на потребителя за signs of compromise;
- сменете парола и прегледайте MFA методите, ако има съмнение за takeover;
- документирайте времевата линия и засегнатите системи;
- наблюдавайте за повторно влизане чрез нови токени или свързани акаунти.
Когато става дума за администраторски акаунт или high-value потребител, включете и по-широк review на привилегиите, интеграциите и SaaS достъпа.
Практика за Microsoft 365 и Google Workspace
В Microsoft 365 и Google Workspace често се виждат сходни модели на риск: неочаквани sign-ins, промени по mailbox settings, нови forwarding правила, OAuth consent за непознати приложения или достъп през неуправлявани устройства. Това ги прави особено важни среди за monitoring.
За SMB е добър старт да се прегледат:
- дали има включен audit logging за идентичности и администраторски действия;
- дали MFA е задължителна за всички, особено за привилегировани роли;
- дали legacy протоколи и стари auth методи са забранени;
- дали има alertи за risky sign-in, consent и forwarding;
- дали session policies са достатъчно строги за админ акаунти;
- дали има ясна процедура за проверка и отзоваване на съмнителни сесии.
При SaaS приложенията е важно да не разчитате само на central SSO. Някои приложения имат собствена session логика и собствени risk signals, които също трябва да се проверяват.
Как да обучим потребителите без да ги претоварваме
Потребителите често са първата линия срещу MFA fatigue, но обучението трябва да е практично, а не абстрактно. Вместо да ги заливате с общи предупреждения, дайте им ясни правила:
- не потвърждавай MFA prompt, който не очакваш;
- ако видиш повтарящи се заявки, докладвай веднага;
- при съмнение за компрометиране, сменяй паролата само през официален канал;
- не игнорирай уведомления за ново устройство или нова сесия;
- сигнализирай за подозрителни имейли, consent prompts или prompt spam.
Кратки, повтаряеми сценарии работят по-добре от еднократни презентации. Добре е и IT екипът да има готов шаблон за реакция при потребителски сигнал за странни MFA заявки.
Практичен приоритет за следващите 30 дни
Ако трябва да започнете отнякъде, фокусирайте се върху три неща: видимост, ограничаване на сесиите и реакция. Това означава:
- да включите и проверите наличните sign-in и audit logs;
- да валидирате conditional access и session policies за админ и high-risk роли;
- да създадете ясен playbook за suspicious session response;
- да прегледате MFA методите и да ограничите слабите или неподходящи;
- да изчистите legacy auth и ненужните SaaS consents;
- да обучите потребителите да подават сигнал при странни prompts.
Това няма да премахне всички рискове, но значително ще намали времето до откриване и ще ограничи щетите при компрометирана идентичност.
Заключение
MFA остава задължителна, но през 2026 тя е само една част от по-голямата картина. Реалната защита идва от комбинация между conditional access, device trust, session controls, telemetry, бърза реакция и добра хигиена на идентичностите. Ако администраторите следят само успешния login, те пропускат най-опасната фаза от атаката: използването на вече валидна сесия.
Ако искате да оцените дали вашата среда е достатъчно подготвена срещу MFA fatigue, session hijacking и token theft, помислете за identity monitoring review или incident response readiness assessment. Един кратък консултативен одит често показва бързи подобрения в logging-а, session control-а и реакцията при инциденти.
