Силни индикатори (изисквайте незабавна изолация):

• Inbox rule, която премества или трие писма по ключови думи (IBAN, bank, payment, invoice, фактура, плащане, паричен, превод, заплата) - класически BEC подготвителен ход. В Outlook на потребителя често е невидим, защото е създаден през Graph API.
• Sign-in от държава, в която потребителят няма работа с „Success" и MFA „Satisfied". Лагос, Бенин Сити, Хошимин, Кишинев, Тегусигалпа, Каракас са в топ-5 за български компании през последната година.
• Impossible Travel alert от Microsoft Entra: успешен sign-in от София в 09:14 и от Бразилия в 09:31 - не може да се пренесе физически и това означава, че session token е откраднат.
• Нов OAuth grant за непознато приложение с висок privilege scope (Mail.ReadWrite, Files.ReadWrite.All, offline_access) - нападателят си осигурява достъп, който преживява смяна на парола.
• Mass file download/sync от OneDrive или SharePoint: повече от 200 файла за 10 минути от един потребител обикновено е exfiltration.
• Потребител твърди, че е въвел парола в страница след клик от Teams/имейл, или че е одобрил MFA prompt, който не очаквал.

Внимание с „слабите" индикатори. Един „странен" sign-in от България в 02:14 без друг контекст не е компромет - често е автоматизирано приложение или мобилно устройство, което се синхронизира при отворен капак. Не задействайте пълна процедура на основа на едно събитие в Sign-in Logs. Корелирайте поне две независими сигнали или изчакайте 5 минути за допълнителни данни. Парадоксално, прибързаното заключение разваля доверие в ИТ и води до игнориране на следващите истински alert-и.

Последователност на пълна изолация (отчитайте минутите):

Минута 0-1: Disable акаунта

Entra admin center -> Users -> избирате потребителя -> Block sign-in -> Yes. Това спира всички бъдещи sign-in заявки, докато работите по останалото. Не е достатъчно само по себе си, защото не убива съществуващите сесии.

Update-MgUser -UserId user@domain.bg -AccountEnabled:$false

Минута 1-2: Revoke всички sessions

Това е критичната стъпка, която 70 на сто от ИТ-тата пропускат. Revoke session invalidate-ва refresh token-ите. Access token-ите все още могат да живеят до 60 минути, но без refresh не могат да се подновят.

Revoke-MgUserSignInSession -UserId user@domain.bg

Минута 2-3: Смяна на парола с force change at next login

Генерирайте случайна 24-символна парола, запишете я в паролния си мениджър под „IR-incident-DATE-USER", задайте „User must change password at next sign-in". Потребителят НЕ трябва да я знае на този етап. Това предотвратява потребителят да позволи компрометирана сесия да се преподпише от MFA prompt.

Минута 3-4: Премахнете всички MFA методи и app passwords

Entra -> User -> Authentication methods -> премахвате SMS, Authenticator, alternative phone, app passwords. Нападател, който е добавил собствено authenticator приложение, може да преодолее всичко останало. App passwords заобикалят MFA и са невидими за повечето ИТ-та. Препоръчваме пълно нулиране и пре-регистрация в чисто състояние.

Get-MgUserAuthenticationMethod -UserId user@domain.bg | Remove-MgUserAuthenticationMethod

Минута 4-5: Премахнете OAuth grants и inbox rules

Това е финалната тиха стъпка, която отделя „чист акаунт" от „акаунт, който ще бъде компрометиран отново след 3 дни". OAuth grants дават достъп на трети приложения с собствен токен, който не зависи от паролата на потребителя. Inbox rules продължават да правят BEC подготовка дори след всичко горе.

Get-MgUserOauth2PermissionGrant -UserId user@domain.bg | Remove-MgOauth2PermissionGrant

Get-InboxRule -Mailbox user@domain.bg | Remove-InboxRule -Confirm:$false

60-минутен forensic checklist:

1. Sign-in Logs за последните 30 дни

Entra admin center -> Sign-in Logs -> филтър по User Principal Name. Експортирайте CSV. Търсете: успешни sign-in от непознати държави, ново device ID, нов user agent, MFA „Satisfied by claim in token" (token replay), повторение на същия session ID от различни IP.

2. Unified Audit Log (UAL) за последните 90 дни

Purview compliance portal -> Audit. Филтри: UserIds = жертвата, Activities = New-InboxRule, Set-Mailbox, Set-MailboxAutoReplyConfiguration, Add-MailboxPermission, MailItemsAccessed, FileDownloaded, FileSyncDownloadedFull, Consent to application, Add app role assignment grant. Запазвайте резултатите като evidence (UAL retention по default е 90 дни за E3, 365 дни за E5/Audit Premium).

3. MailItemsAccessed (E5/Audit Premium)

Това е единственото регистрирано събитие, което показва какво точно е прочел нападателят. Ако нямате E5 или Microsoft 365 Audit (Premium) add-on, нямате тези данни и трябва да третирате цялата пощенска кутия като компрометирана за периода. Това е една от четирите причини E5 да си струва за компании 50+ души.

4. OAuth grants и enterprise applications

Entra -> Enterprise applications -> User consent. Запишете всеки grant с дата, scope и publisher. Подозрителни: общи имена като „Office Helper", „Mail Sync", „Calendar Add-in" без verified publisher; grants за Mail.ReadWrite, Files.ReadWrite.All, offline_access; grants, направени през работни часове от username, но от странна IP.

5. Inbox rules и mailbox forwarding

PowerShell: `Get-InboxRule -Mailbox user@domain.bg | Format-List` и `Get-Mailbox user@domain.bg | Select ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward`. Записвайте всяко правило - дори ако сте ги изтрили в Стъпка 2, evidence-ът е необходим за регулатор и за вътрешен post-mortem.

6. OneDrive/SharePoint file access и download

Purview -> Audit с activities FileDownloaded, FileSyncDownloadedFull, FileAccessedExtended за периода на компромет. Сумирайте обем (брой файлове, MB) и анотирайте чувствителните - договори, финансови данни, лични данни на служители или клиенти. Това е основата за GDPR оценка и за нотификация на партньорите.

7. Sent items и outbound BEC

Покажете Sent Items за периода чрез Search-Mailbox (или Compliance Search), не само през Outlook на потребителя - нападателят често трие Sent Items след изпращане. Търсете изпратени имейли до външни домейни, които съдържат IBAN, банкови данни, „преводът се промени", lookalike домейн на ваш доставчик. Това е разликата между „малък инцидент" и активен BEC сценарий с външен пострадал.

Запазете evidence-а правилно. Експортирайте CSV-тата на отделна локация (НЕ в SharePoint или Teams на същата tenant), снимките на конфигурациите запазете като PDF, mailbox export-ите направете чрез eDiscovery hold ако подозирате правен спор. UAL се пази 90 дни по default - след това вече няма как да възстановите данните. При сериозен компромет, активирайте Litigation Hold на mailbox-а в първите 24 часа.

Кой какво кога:

Минута 5-30: вътрешни stakeholder-и

Собственикът на акаунта, неговият мениджър, ИТ ръководителят, CFO ако акаунтът има финансови права, юристът ако има клиентски данни. Кратко съобщение в защитен канал (Signal, лично обаждане, НЕ Teams на същата tenant ако подозирате tenant-wide компромет). Без излишни детайли - „имаме потвърден компромет на акаунт X, започнали сме процедура, ще ви информирам в следващия час".

Минута 30-120: външни критични stakeholder-и

Ако има активен BEC, обадете се незабавно на банката за блокиране на изходящи трансфери от ваши сметки и проверка на скоро направени. Партньори, чиито данни е възможно да са прочетени, обаждате им се лично - не имейл от компрометирания канал. Доставчиците на критични системи, ако подозирате lateral movement.

До 24 часа: ОЕЦ при NIS2/ЗКС задължение

Ако сте съществен или важен субект по новия Закон за киберсигурност (банка, ВиК, болница, общинска администрация, енергетика, ИКТ доставчик, държавна администрация и др.), задължени сте за ранно уведомление до Орган за единна точка за контакт (ОЕЦ) в 24 часа от осъзнаване на инцидента. Това НЕ е пълният доклад - това е „имаме инцидент с потенциално значимо въздействие". Format: чрез Единния портал за инциденти на МЕУ.

До 72 часа: КЗЛД при пробив на лични данни

Чл. 33 GDPR. Ако нападателят е имал достъп до пощенска кутия, която съдържа лични данни (договори със служители, кореспонденция с физически лица, прикачени документи с ЕГН, банкови данни) - имате задължение за уведомление, освен ако не докажете, че пробивът „е малко вероятно да доведе до риск за правата и свободите". Това е тесен изход с висока тежест на доказване. По-сигурно е да направите нотификацията. Format: онлайн система на КЗЛД. Съдържание: описание, категории данни, брой засегнати, мерки. До 72 часа можете да подадете начална нотификация без всички данни и да я допълните по-късно.

До 72 часа: пълен NIS2 доклад до ОЕЦ

Ако сте задължен субект, в 72 часа от осъзнаване подавате подробен доклад: причини, въздействие, мерки. В 1 месец финален доклад с пълен post-mortem.

До 72 часа: уведомление на физически лица

Чл. 34 GDPR. Ако пробивът „вероятно ще доведе до висок риск за правата и свободите" на физически лица (например откраднати ЕГН-та на много хора, банкови данни, медицински записи), задължен сте да ги уведомите без забавяне. Това НЕ е публикация - това е персонална нотификация, освен в няколко изключения. Подгответе шаблон, но не го пращайте, преди да консултирате юрист.

До 5 работни дни: киберзастраховател

Ако имате cyber polica, типичният срок за нотификация е 24-72 часа от осъзнаване, но проверете точните условия. Закъсняла нотификация е основна причина за отказ на claim. Изпратете кратко първоначално уведомление веднага, дори преди да имате всички данни - то фиксира момента и спира спор „вие не сте ни казали навреме".

Класическа грешка: чакане за „да съберем всички факти" преди нотификация

Срокът тече от момента на осъзнаване, не от момента на пълно разбиране. Закъсненията дори с 1-2 дни увеличават глобите в значителна степен и създават проблем при cyber застраховките. По-добре е първоначално уведомление с „все още установяваме обхвата" в навременния срок, отколкото перфектен доклад след 5 дни.

1. Phishing-resistant MFA (FIDO2 hardware key или Passkey)

SMS и Authenticator-push MFA се преодоляват от AiTM (Adversary-in-the-Middle) phishing kit като EvilGinx и от MFA fatigue атаки. FIDO2 хардуерен ключ или платформен passkey са устойчиви на тези атаки, защото подписват challenge-а с домейн-обвързан криптографски ключ. Минимум: всички администратори. Препоръчително: всички финансови и изпълнителни роли. Цена: 80-160 лв. на ключ (YubiKey 5C NFC, Token2), или безплатно при използване на Windows Hello/Apple passkey.

2. Conditional Access с Token Protection и Sign-in Frequency

Token Protection (sign-in token cryptographic binding) спира session token replay - атаката, която стои зад 60 на сто от M365 компроментите през 2025-2026 г. Conditional Access политика: за всички users, всички cloud apps, изисквай compliant device или hybrid Azure AD joined device, sign-in frequency 1-4 часа за privileged роли. Втора политика: блокирай legacy authentication протоколи (POP, IMAP, SMTP AUTH, EWS basic). Трета политика: блокирай sign-in от държави, в които нямате служители или операции (geo-blocking).

3. Restrict user consent to verified publisher apps only

Entra -> Enterprise Apps -> Consent and permissions. Промяна от „Allow user consent for apps" на „Allow user consent for apps from verified publishers" за избрани permissions (read-only, low-impact). Всички високи скоупове (Mail.ReadWrite, Files.ReadWrite.All, offline_access) минават през admin consent workflow. Това спира тиха OAuth атака от непознато приложение в 95 на сто от случаите.

4. Safe Links и Safe Attachments (Defender for Office 365)

Включва policy за Safe Links (URL rewrite + time-of-click detonation), Safe Attachments (detonation в sandbox), Anti-phishing с impersonation protection за висши служители и техни домейни-двойници. Зона на действие: Exchange Online, Teams, SharePoint, OneDrive. Цена: включено в M365 Business Premium и в Defender for Office 365 P1.

5. Unified Audit Log retention за 1 година (минимум 6 месеца)

Default UAL retention е 90 дни на E3 - често недостатъчно за пълен post-mortem на компромет, който е траял 4 месеца преди да бъде забелязан. Microsoft 365 Audit (Premium) дава 1 година за всички audit-вани действия и 10 години add-on. За регулирани сектори (NIS2 essential entities, банки, болници) - задължително 1 година минимум. За BG: цената на upgrade-а е по-малка от очаквана глоба КЗЛД при доказан проблем с retention.

6. Mailbox auditing с MailItemsAccessed и SendAs/SendOnBehalf logging

Enable mailbox auditing на всички mailbox-и (по default е включено за Exchange Online от 2019 г., но проверете чрез Get-Mailbox -ResultSize Unlimited | Select Name, AuditEnabled, AuditLogAgeLimit). MailItemsAccessed изисква E5/Audit Premium, но е единственият начин да определите какво точно е било прочетено. Без него нотификацията към КЗЛД ще трябва да третира цялата пощенска кутия като компрометирана.

7. Alert policies: Impossible Travel, Mass Download, New Forwarding Rule, Suspicious Email Pattern

Purview Compliance -> Alert policies. Активирайте поне: User performed mass download from SharePoint/OneDrive (threshold 100 файла за 10 мин), Creation of forwarding/redirect rule, Impossible travel activity, Suspicious inbox manipulation rules, eDiscovery search started. Конфигурирайте notifications към dedicated email (не личния admin email) и към PagerDuty/Teams канал за нощни алерти.

Ниво 1 (Минимално, 5-7 дни ИТ работа, цена 0-500 лв.)

• Включете MFA за всички, поне Authenticator app. Премахнете SMS методите за привилегировани акаунти
• Активирайте Security Defaults в Entra или поне основна Conditional Access политика срещу legacy authentication
• Включете Unified Audit Log (Search-UnifiedAuditLog) и удължете retention до максимум, който позволява вашият лиценз
• Активирайте поне три Alert Policy: Impossible travel, New forwarding rule, Mass download from SharePoint
• Запазете 5-минутната процедура за изолация в OneNote с готови PowerShell команди

Ниво 2 (Средно, 4-6 седмици проект, цена 4 000-12 000 лв.)

• Upgrade до M365 Business Premium (включва Defender for Office 365 P1, Intune, Entra ID P1)
• Conditional Access политики: require compliant device, block legacy auth, geo-block за рискови държави
• User consent restriction за OAuth grants - admin approval за всички high-privilege scopes
• FIDO2 хардуерни ключове за администратори и финансови роли
• Tabletop exercise: симулирайте компромет за един час с целия ИТ екип и финансов директор
• Документиран IR runbook с командите, контактите и шаблон за нотификация на КЗЛД

Ниво 3 (Зряло, текущ ангажимент, цена 18 000-45 000 лв./год.)

• M365 E5 или Defender for Office 365 P2 (MailItemsAccessed, Attack Simulation, Threat Investigation)
• Token Protection в Conditional Access, Continuous Access Evaluation активирано
• Phishing-resistant MFA (FIDO2 или passkey) за всички, не само администратори
• 24/7 SOC monitoring или IR retainer с под 1-часов response SLA
• Тримесечен phishing simulation, годишно red team тестване, годишен IR drill
• Microsoft 365 Audit (Premium) add-on за 1-годишен UAL retention
• Pre-incident връзка с външен IR доставчик (договор, NDA, telephone tree)

Сменихме паролата и MFA. Защо казвате, че акаунтът още е компрометиран?

Защото session token, refresh token, app passwords и OAuth grants не зависят от паролата. Активна сесия с валиден access token продължава да работи до 60-90 минути след смяна. Refresh token може да живее до 90 дни. App password e напълно отделен механизъм, който игнорира MFA. OAuth grant дава достъп на трето приложение, което носи собствен token. Пълната изолация изисква изричен revoke на всичките тези пътища - стъпка 4 и 5 от 5-минутната процедура.

Имаме M365 Business Basic. Достатъчно ли е за защита и за forensic?

Business Basic дава ограничени възможности - получавате Sign-in Logs и базови alert policy-та, но нямате MailItemsAccessed, Conditional Access (P1) и Defender for Office 365. На практика можете да реагирате на компромет, но не можете да определите какво точно е било прочетено, което създава проблем при нотификация към КЗЛД. За компании 30+ души препоръчваме upgrade до Business Premium - на месец това е сума, по-малка от един час IR работа след инцидент.

Имаме ли задължение да съобщим в КЗЛД, ако нападателят само е прочел поща без exfiltration?

Достъпът до лични данни без exfiltration е „пробив на сигурността" по смисъла на чл. 4(12) GDPR. Задължението за нотификация по чл. 33 възниква, ако пробивът „вероятно ще доведе до риск за правата и свободите на физически лица". Достъпът до пощенска кутия с кореспонденция, договори и потенциално чувствителни данни почти винаги изпълнява този праг. Изключения са редки и тежко аргументируеми. По правило препоръчваме нотификация - тя е безплатна, защитава ви правно и регулаторът оценява навременността.

Можем ли да възстановим mailbox в състояние от преди инцидента, ако нападателят е изтрил писма?

Зависи от licensing. С Microsoft 365 имате 14 дни recover в Deleted Items и 14 дни в Recoverable Items dumpster. С Litigation Hold или Retention Policy писмата се пазят и след „трайно" изтриване от потребителя. Активирайте Litigation Hold в първите 24 часа от инцидента - след това вече не можете да възстановите изтритото в долния етаж на dumpster-а. За критични потребители (CFO, изпълнителен директор, IT admin) препоръчваме постоянен Litigation Hold като превенция.

Какво да направим, ако компрометираният акаунт е на изпълнителен директор или CFO?

Същата 5-минутна процедура, но с допълнителни стъпки: незабавно обаждане до банката за блокиране на нови финансови операции от негов канал, преглед на скоро направени трансфери, нотификация на ключови партньори и клиенти преди те да получат фалшив имейл „от него", оценка на достъп до правни/M&A документи. При CFO компромет очаквайте, че нападателят е минал тук, защото е целял BEC - паралелно с изолацията започвате callback verification на всички pending финансови операции.

Колко често правите tabletop exercise за M365 IR в българските компании?

При IR retainer клиентите ни препоръчваме два tabletop-а годишно: един с пълния ръководен борд (включително CEO, CFO, юрист, PR) и един с операционния ИТ екип. Сценарии: компрометиран CFO акаунт в петък следобед; масов phishing с 14 одобрени MFA prompt-а; ransomware след OAuth grant; нощен alert за impossible travel. Цена: 6 000-12 000 лв. за пълен ден с post-exercise документ. Откриваме средно 3-7 пропуска в IR процеса при всяко упражнение - всеки от тях би бил много по-скъп в реален инцидент.