BEC измама · Реален случай · Финанси

BEC имейл измама за 1.2 млн. лв.: как 11 имейла за 6 дни източиха сметката на българска производствена компания

Анонимизиран реален случай от 2026 г.: 90-човешка производствена компания в Пловдив прехвърля 1.187 млн. лв. на нападател, който 19 дни преди това е компрометирал имейл сървъра на италианския им доставчик. Банката не спира трансфера. Застраховката покрива 320 хил. лв. Не е сложна атака. Четири евтини контрола щяха да я спрат напълно. Подробната хронология, точният механизъм на компромет, четирите контрола и процедурата за верификация на нови банкови сметки в десет стъпки.

Най-важното накратко

• BEC (Business Email Compromise) е най-скъпият тип киберизмама в България през последните 24 месеца. Среден размер на успешна атака за SMB: 180-1 200 хил. лв. Възстановяване на парите: под 15 на сто. Времето между компромет и кражба често е 14-30 дни
• В 83 на сто от случаите, които сме разследвали, нападателят не е компрометирал ВАШЕТО Microsoft 365, а пощата на ВАШ ДОСТАВЧИК. Седи в неговия имейл, гледа фактури, имитира тона му, и когато види голяма сума, изпраща "нова банкова сметка"
• Българските банки нямат правно задължение да задържат превод заради подозрение за измама, освен ако сте подали изричен сигнал. AML филтрите им хващат под 8 на сто от BEC трансферите, защото получателите са законни европейски сметки на муле компании
• Четирите контрола, които спират 95 на сто от BEC атаките, струват общо под 6 000 лв./година: callback verification на нови банкови сметки чрез независим телефонен номер, MFA на всички акаунти включително на доставчиците ви, DMARC enforcement на изходящата ви поща, и dual approval за всички плащания над определен праг
• Възстановяване на парите след BEC е възможно само в първите 24-72 часа. След 7 дни вероятността е под 3 на сто. Първото обаждане е към банката, второто към ГД БОП, третото към IBAN на получаващата банка чрез SWIFT recall
• Киберзастраховката рядко покрива BEC напълно. Стандартните полици в България изключват "social engineering loss" или го лимитират до 15-30 на сто от полицата. Преди да подпишете полица, проверете изрично за "social engineering coverage" или "fraudulent funds transfer coverage"

АКО СТЕ ИЗПРАТИЛИ ПЛАЩАНЕ И ПОДОЗИРАТЕ BEC ИЗМАМА:

1. Обадете се на вашата банка ВЕДНАГА (не имейл). Поискайте recall на превода. Записвайте часа на обаждането.

2. Подайте сигнал в ГД БОП на cybercrime@mvr.bg и на телефон 02 982 2222 - входящ номер ще ви трябва за банката.

3. Свържете се с професионален incident response екип. Atlant Security: +359 884 050 042. Първите 24 часа определят дали парите ще се възстановят.

Разглеждаме случая ден по ден, защото в 12 от 14 BEC инцидента, които сме разследвали в България през последните 18 месеца, нападателят е чакал между 11 и 34 дни преди да удари. В тези 11-34 дни той е чел имейли, разбирал е процесите, идентифицирал е големите фактури, и е изчаквал точния момент - обикновено малко преди важна доставка или важна публична поръчка, когато финансовият директор е под натиск и проверките са по-малко стриктни.

1.1. Ден -19: компроматът, който никой не видя

19 дни преди измамата, италианският инженер инсталира crackeд видео игра от торент сайт на личния си лаптоп вечерта. В крекетния файл е RedLine InfoStealer - един от най-разпространените credential stealers на пазара, наличен под наем за 100-200 USD/месец. RedLine изтегля от Chrome browser-а на лаптопа: запазени пароли, активни cookies (включително auth tokens за Microsoft 365), история на посетени сайтове, и автоматично попълнени формуляри. Пакетът се изпраща на C2 сървър в Русия. След 4 часа credentials за corporate@italian-vendor.com са продадени в подземен форум за 35 USD.

Защо MFA не помогна. Италианската компания има задължителен MFA на всички акаунти. Но MFA защитава момента на login, не момента на session. Чрез откраднатия cookie с активна session, нападателят се "представя" на Microsoft 365 като вече logged-in потребител и заобикаля изцяло MFA проверката. Това е стандартна техника, известна като "session hijacking" или "AiTM (Adversary in the Middle)". Защитата срещу нея: Conditional Access policies с device compliance, session timeout под 24 часа, FIDO2 hardware ключове вместо TOTP, и Continuous Access Evaluation.

Първият пропуснат сигнал. В Microsoft 365 sign-in логовете на италианската фирма имаше login от IP адрес в Холандия в 02:34 местно време - 6 часа след открадването. Анормална географска позиция, анормален час, анормално устройство. Никой не гледа sign-in логовете в реално време. Италианската фирма няма SIEM. Имаше Defender for Cloud Apps, но не и beaconing alert configured.

1.2. Дни -18 до -1: 18 дни в имейла

През следващите 18 дни нападателят прави това, което се нарича "BEC reconnaissance" - чете имейли тихо, без да изпраща нищо ново. Първото му действие е да създаде Outlook inbox rule, която автоматично изтрива входящи писма от определени домейни (в случая - от българската компания) и ги препраща към архивна папка. Така когато италианският инженер преглежда пощата си, не вижда отговорите от българския клиент, и нападателят има време да отговаря от негово име.

Какво направи нападателят през 18-те дни:

• Изчете 14 дни назад кореспонденция с българската компания (около 240 имейла)
• Идентифицира 4 други големи клиенти на италианската фирма (на различни езици) и започва паралелна подготовка срещу всеки
• Изтегли 10 PDF фактури за последните 6 месеца - научи структурата, IBAN сметката, типичните суми, реквизитите на италианската фирма
• Регистрира IBAN на муле компания в холандска банка (Bunq, която предлага бизнес сметки за 24 часа с минимална проверка на адрес и ID документ)
• Регистрира lookalike домейн italian-vendor-srl.com (оригиналът е italianvendor.com) като backup, в случай че италианската фирма открие компромета и блокира оригиналната поща
• Анализира стила на писане на италианския инженер (кратки изречения, използване на конкретни технически термини, типични emoji в края), направи 3-4 пробни чернови за изпращане

През тези 18 дни нападателят НЕ е изпращал нищо ново. Това е критично важно: BEC reconnaissance е "пасивна фаза". Стандартните защити срещу фишинг (DKIM/SPF/DMARC, anti-spam, attachment scanning) не правят нищо срещу пасивен компромет, който само чете. Откриването изисква поведенчески анализ на login активността, не на изходящи имейли.

1.3. Ден 0: ударът в петък следобед в 16:42

Нападателят изпрати имейла в петък в 16:42 местно италианско време (17:42 българско). Това не е случайност. BEC атаките се изпращат най-често в петък следобед, защото:

• Получателят е уморен от седмицата и проверките са по-малко стриктни
• Има два дни уикенд, преди някой да открие нещо нередно
• Финансовите системи и банковите call центрове работят в намален състав
• Между петък 17:00 и понеделник 09:00 има 64 часа прозорец за извеждане на парите

Имейлът беше структуриран професионално. Темата гласеше "Re: Invoice INV-2026-03847 - bank account update". Имитираше предишен thread с реална фактура (нападателят имаше всички предишни thread-ове). Текстът:

Сигналите бяха слаби, но видими: фразата "as discussed last month" не съответстваше на нито един реален разговор; промяна на банка от UniCredit (стара италианска банка) към Bunq (новонеобслужваща холандска банка за дигитални предприемачи) е необичайна за корпоративна фирма; и името на бенефициента "Italian Vendor SRL" беше леко различно от обичайното "Italian Vendor Srl" (главна "S" в "SRL"). Никой не забеляза.

1.4. Ден 1: одобрението в 09:47

Финансовата директорка отвори имейла в понеделник в 08:23. Прочете го два пъти. Изпрати кратък отговор: "Hi Marco, noted. We will process the transfer on Tuesday morning as per our normal schedule. Can you confirm the IBAN is correct?" Този имейл стигна до компрометирания акаунт. Нападателят (вече с автоматично filtering на отговорите от българската компания) отговори в рамките на 14 минути: "Yes, confirmed. The new IBAN is final. Please proceed as scheduled."

Във вторник в 08:00 финансовият асистент въведе плащането в банковия портал на банката (с 1 187 084.20 лв., конвертирани в 607 428 EUR). В 09:47 финансовата директорка влезе в портала, прегледа транзакцията, и натисна "Approve". Между въвеждането и одобрението не беше направена нито една външна проверка на новата IBAN - нито callback към известен телефонен номер на италианския доставчик, нито проверка дали Bunq е реална обслужваща банка на компанията, нито вътрешна допълнителна проверка с втори одобряващ. Това е грешката, която е струвала 1.187 млн. лв.

В 09:52 банковата система генерира SWIFT превода. В 12:18 парите бяха в холандската банка. До 17:00 парите бяха разделени на три транзакции и преместени в две други европейски банки. До утрешния ден всичко беше конвертирано в USDT (Tether) през регулирана криптоборса в Естония.

Това е техническата секция. За финансови директори, които не са технически - вижте Раздел 4 и Раздел 5. Тук обясняваме точния механизъм, защото в 9 от 14 разследвани от нас BEC случая, началната точка е същата: InfoStealer на личен лаптоп, който не е под фирмено управление.

2.1. Какво е InfoStealer и защо е толкова разпространен

InfoStealer е тип malware с една цел: да извлече credentials и сесии от заразен компютър и да ги изпрати на нападателя. За разлика от ransomware, InfoStealer-ите се опитват да останат скрити. Обикновено работят 2-15 минути след зараза, изпращат един пакет с данни, и след това се самоунищожават или остават неактивни.

Най-разпространени InfoStealer семейства в 2024-2026 г.:

• RedLine - на пазара от 2020 г., над 9 милиона заразени устройства глобално. Цена под наем: 150-200 USD/месец
• Raccoon Stealer v2 - след падането на v1 през 2022 г., v2 доминира пазара. Цена: 200 USD/месец
• Vidar - известен за извличане на 2FA tokens и crypto wallets
• Lumma Stealer - най-новият голям играч, специализиран в Chrome session cookies
• StealC - руски произход, с фокус на корпоративни credentials и SSO sessions

Векторите на разпространение: crackeд софтуер от торент сайтове (преобладаващ), фалшиви Adobe/AutoCAD downloads, malicious browser extensions, фалшиви "captcha" клавиши на компрометирани сайтове, фалшиви reCAPTCHA prompts (стара техника, която още работи в 8 на сто от случаите), и YouTube описания с "free software" линкове.

2.2. Защо личните лаптопи са initial access vector

В нашия случай италианският инженер беше синхронизирал работната си Microsoft 365 поща на личния си Chrome browser, за да чете email-и от вкъщи. Това е стандартна практика в малки и средни европейски фирми, които нямат BYOD политика или MDM (mobile device management) контроли. Личният лаптоп няма EDR, няма centralized antivirus, няма URL filtering, и Chrome пази passwords и cookies в encrypted local store, който InfoStealer декриптира с няколко реда код.

Стандартни решения за този проблем (всички с разумен бюджет):

• Microsoft Intune compliance policies - изискване Conditional Access да блокира login от неподдържани/некомплейънт устройства (8 USD/потребител/месец)
• FIDO2 hardware tokens (YubiKey, Token2) - физически защитен втори фактор, който не може да бъде откраднат от cookie (45-80 USD/потребител, веднъж завинаги)
• Browser isolation - служебните имейли се отварят в изолиран браузър контейнер (Microsoft Defender Application Guard, Cloudflare Browser Isolation, 3-8 USD/потребител/месец)
• Token Protection в Conditional Access - връзва session token-а към устройството, така че откраднат cookie не работи на друго устройство (включен в Microsoft Entra ID P2)
• Defender for Cloud Apps OAuth filtering - откриване на login от нови, нестандартни локации с автоматично revoke на session

Общата цена за 50-човешка компания: 2 800-4 500 USD/година плюс еднократно 2 500-4 000 USD за FIDO2 ключове. Сравнено с 1.187 млн. лв. загуба, инвестицията се изплаща около 200 пъти за един предотвратен инцидент.

2.3. Признаци за компромет на доставчик, които можете да видите ОТ ВЪН

Българската компания не можеше да види, че италианския доставчик беше компрометиран. Или можеше? Има 5 видими сигнала, които често придружават компромет на доставчик:

• Промяна на стила на писане - по-кратки имейли, по-малко конкретика, по-общи фрази. Често се пренебрегва защото "Marco днес е зает".
• Изпращане в нестандартни часове - имейли от обичайно работещ човек в 02:00 или 04:00 без обяснение. Може да бъде червен флаг за login от далечен timezone.
• Reply-To header е различен от From - технически сигнал, който повечето имейл клиенти не показват по подразбиране. Включете "show full headers" опцията в Outlook или Gmail.
• Слабо позната или нова обслужваща банка - смяна на UniCredit/Deutsche Bank за Bunq/Revolut/Wise. Не е автоматично червен флаг, но е сигнал за вторична верификация.
• Урочни фрази на спешност - "please process today", "we are under deadline pressure", "our auditor needs confirmation". BEC атаките винаги добавят елемент на спешност, за да блокират рационалното мислене.

Това е въпросът, който всеки финансов директор задава: "Защо банката не видя, че сметката е нова, че бенефициентът се различава, че сумата е голяма?" Отговорът е смесица от правна реалност, технически ограничения, и икономика на банкирането.

3.1. Правната рамка: банката изпълнява нареждания, не оценява решения

Според Закона за платежните услуги и платежните системи и Регламент (ЕС) 2015/847, банката има задължение да изпълни валидно представено платежно нареждане, освен ако има конкретно правно основание за отказ. Конкретните правни основания за блокиране на превод:

• Бенефициент в санкционен списък (ЕС, ООН, OFAC, БНБ)
• Подозрение за пране на пари съгласно ЗМИП и BSP/CTF директивата (изключително висок праг на сигурност за блокиране)
• Изричен сигнал от клиента или от ГД БОП за измама
• Несъответствие в KYC данните, които биха блокирали ВЪВЕЖДАНЕ на бенефициент
• Превишение на лимит, който клиентът сам е настроил в портала

"Подозрение за BEC измама" не е сред тези основания. Дори ако служител в банката лично смята, че сметката изглежда подозрителна, той няма правно основание да задържи превод, който клиентът изрично е одобрил.

3.2. AML филтрите: какво всъщност търсят

Българските и европейските банки използват AML (Anti-Money Laundering) транзакционни филтри, които сканират всеки превод. Те търсят паттерни на пране на пари: множество малки преводи (structuring), преводи към известни high-risk юрисдикции, преводи към новорегистрирани фирми, преводи от/към лица в санкционни списъци. AML филтрите НЕ са оптимизирани за BEC, защото в BEC получателят е законна компания с легитимна банкова сметка, а изпращачът е законна компания, която доброволно изпраща пари.

В нашия случай: получаващата компания "Italian Vendor SRL" беше регистрирана в Холандия като дъщерна на холдинг в Малта 7 месеца преди измамата. Имаше валиден KYC при Bunq. Сметката имаше няколко десетки трансакции за последните 3 месеца. От гледна точка на AML алгоритъма, това беше нормална компания. Идентификацията че е муле за престъпни схеми изисква разузнавателна информация, а не транзакционен анализ.

3.3. Confirmation of Payee: новата защита, която още не работи в България

Confirmation of Payee (CoP) е новопредложена европейска регулация (PSD3 проект, влиза в сила между 2026 и 2028 г. в различни държави), която изисква банката на изпращача да провери дали името на бенефициента в нареждането съответства на регистрираното име на IBAN сметката. Ако има разминаване, банката трябва да предупреди изпращача преди да изпрати парите.

CoP е активен в Обединеното кралство от 2020 г. (под Open Banking Implementation Entity) и е намалил APP (Authorised Push Payment) измамите с 60 на сто. В Холандия е активен от 2023 г. В Германия и Франция е в процес на въвеждане през 2026 г. В България има първоначални пилоти при ОББ и Първа Инвестиционна Банка през второто тримесечие на 2026 г., но пълно внедряване не се очаква преди 2028 г.

В нашия случай: дори ако CoP беше активен, нападателят регистрира бенефициента като "Italian Vendor SRL" вместо "Italian Vendor Srl" (леко различен правопис). Това би е fuzzy match и зависи от прага на банковата система. Британските CoP реализации обикновено маркират такова разминаване като "near miss" с предупреждение, не като пълно блокиране. Българската финансова директорка вероятно би натиснала "потвърждавам" въпреки предупреждението, защото в имейла стилът беше познат.

3.4. SWIFT Recall: 24-72 часовата процедура за връщане на парите

След като парите са изпратени, единственият механизъм за връщането им е SWIFT Recall (MT199 message за recall request). Това е молба от изпращащата банка към получаващата банка с искане парите да не бъдат предоставени на получателя, защото има подозрение за измама. Решението е на получаващата банка. Тя няма правно задължение да върне парите без съдебно решение или без съгласие на получателя.

Реална статистика от BEC случаи, които сме разследвали:

• SWIFT recall в първите 4 часа: 45-55 на сто шанс за частично възстановяване (ако сметката още не е изпразнена)
• SWIFT recall в първите 24 часа: 18-25 на сто шанс
• SWIFT recall в първите 72 часа: 5-12 на сто шанс
• След 7 дни: практически нулева вероятност, защото парите вече са разклонени или конвертирани в крипто

В нашия случай: SWIFT recall беше изпратен в 16:34 - 6 часа и 47 минути след оригиналния превод. Холандската банка получи recall в 16:51, freeze-на остатъка по сметката (87 хил. лв.), и в 17:30 изпрати потвърждение за връщане. Останалите 1 100 хил. лв. вече бяха в две други банки.

След като сме разследвали 14 BEC случая в България, можем да кажем с увереност: 95 на сто от тях биха били спрени с четири евтини контрола. В нашия случай, ако българската компания имаше нито един от четирите, измамата щеше да премине. Ако имаше дори един от тях, щеше да бъде спряна. Подреждаме ги по ROI:

4.1. Контрол 1: Callback verification (0 лв., 95 на сто ROI)

Това е най-важният контрол. Той не струва нищо. Той изисква процесна дисциплина и фирмена политика. Правилото е просто и абсолютно: преди да изпратите плащане на нова банкова сметка или след промяна на стара сметка, обадете се на доставчика на телефонен номер, който НЕ е взет от имейла, който получите промяната. Използвайте номер от: предишен договор, фирмения сайт, визитна картичка, предишно нареждане за плащане, или ваш CRM/ERP.

Защо номерът от имейла не работи. Нападателят често контролира имейл сметката, така че може да промени и подписа, и contact details, и дори да отговори от името на получателя ако обадите на "техния" телефон. Веднъж имахме случай където нападателят беше регистрирал виртуален телефонен номер със SIP gateway и beats звучеше на български като продавачът, защото беше използвал AI voice clone.

Процедурата: финансовият асистент въвежда плащането, но не натиска "Approve". Финансовият директор или CFO проверява новата IBAN, и преди да одобри, прави callback. Разговорът: "Здравейте, обаждам се да потвърдя, че сте сменили банковата си сметка. Получихме имейл от Marco за нова сметка в Bunq. Можете ли да потвърдите?" Ако другата страна не знае нищо за тази промяна, спрете трансфера ВЕДНАГА.

4.2. Контрол 2: Dual approval за плащания над праг (0-200 лв./година)

Българските банки (УниКредит Булбанк, Първа Инвестиционна, ОББ, ДСК, Райфайзенбанк, Пощенска Банка) поддържат dual approval в бизнес портала. Включва се с няколко клика в настройките и не струва нищо допълнително. Прагът се настройва от вас - типични стойности за SMB: 20 000 лв. за един превод, 100 000 лв. за единия одобряващ.

Реална имплементация:

• Под 20 000 лв.: едно одобрение (CFO или финансов директор)
• 20 000-100 000 лв.: две одобрения (CFO + управител)
• Над 100 000 лв.: две одобрения + email потвърждение от управителя в отделно time прозорец (минимум 30 мин закъснение)
• Над 500 000 лв.: callback verification ВЪПРОСНА в политиката, независимо дали сметката е стара или нова

В нашия случай: ако имаше dual approval с праг 100 000 лв., управителят щеше да види нареждането за 1.187 млн. лв. към непозната холандска банка, щеше да попита защо, и щеше да настоява за callback verification. Цяла измама щеше да се срине за 3 минути.

4.3. Контрол 3: MFA с FIDO2 + Conditional Access (1 500-3 500 лв./година)

Този контрол защитава ВАШИЯ имейл от компромет. Той не може директно да защити ВАС от компрометиран ДОСТАВЧИК (за това вижте Раздел 5), но е критичен, защото в 30 на сто от случаите BEC се играе в "обратната посока" - нападателят компрометира ВАС и измамва ВАШИ клиенти, които ви плащат. Това е по-болезнено защото ВАШАТА репутация страда.

Компонентите:

• FIDO2 hardware ключове (YubiKey 5 NFC, Token2 Release) за всички privileged и финансови роли. 75 USD/ключ еднократно, 2 ключа на потребител (резервен).
• Microsoft Entra ID P1 или P2 лиценз за Conditional Access policies (включен в M365 Business Premium или E3/E5)
• Conditional Access политики: блокиране на login от нестандартни държави, изискване на device compliance за привилегировани акаунти, session timeout под 24 часа, Token Protection (binds session to device)
• Defender for Cloud Apps с alerting за impossible travel, anomalous login patterns, OAuth grant misuse

За 50-човешка компания: Token Protection + FIDO2 ключове = около 8 000 лв. еднократно + 1 800 лв./година licensing. Това спира 90 на сто от credential theft attacks независимо дали потребителите ви ще кликнат на фишинг или не.

4.4. Контрол 4: DMARC enforcement + lookalike domain monitoring (0-1 800 лв./година)

SPF, DKIM и DMARC са три DNS-базирани стандарта за защита на изходящата ви поща. Когато са правилно конфигурирани и DMARC policy е "reject", други имейл сървъри отхвърлят имейли, които се представят като изпратени от вашия домейн, но не са. Това спира нападатели да изпращат "от името на вашия CFO" към ваши клиенти или партньори.

Имплементация (включително monitoring):

• SPF record - списък на разрешените изпращащи IP-та (нула цена, DNS промяна)
• DKIM signing - криптографски подпис на всеки изходящ имейл (нула цена, M365/Google Workspace настройка)
• DMARC policy=reject + rua/ruf reports (нула цена за DNS, 0-100 EUR/месец за monitoring tool като Postmark DMARC Digest, dmarcian, EasyDMARC)
• Lookalike domain monitoring - sermons за регистрация на домейни, които приличат на вашия (yourcompany-bg.com, your-company.com, yourcompany.eu). Услуги: DomainTools (5 USD/month), RiskIQ, или безплатен dnstwist скрипт + crontab

DMARC enforcement не спира директно BEC атаки, при които нападателят е КОМПРОМЕТИРАЛ оригиналния имейл (както в нашия случай). Но спира 40-60 на сто от паралелните "look-alike domain" атаки, в които нападателят регистрира yourcompany-bg.com и изпраща от там. Тези атаки са по-чести от истинския компромет.

Това е процедурата, която препоръчваме на всеки клиент след BEC инцидент. Тя е документирана като фирмена политика, подписана от управителя, и е задължителна за всеки финансов служител. Лепнете я на стената до бюрото на финансовия директор. Никой не може да я преодолее без писмено разрешение от управителя.

Стъпка 1: Прочетете full email headers

В Outlook: File > Properties > Internet headers. В Gmail: Show original. Проверете дали Return-Path, From и Reply-To са еднакви и са от очаквания домейн. Проверете SPF, DKIM, DMARC статуси (Authentication-Results header). Един от трите failure-а е автоматичен червен флаг.

Стъпка 2: Сравнете с предишни имейли

Отворете 3-5 предишни имейла от същия подател. Сравнете подписа (точно до пиксел), стила на писане, времето на изпращане, използваните фрази. Леки различия са нормални. Системни различия (нов език, нов имейл клиент, странен формат) са червен флаг.

Стъпка 3: Намерете независим телефонен номер

НЕ от имейл подписа. Източници: предишен договор, фирмен сайт на доставчика (проверете дали URL съответства на домейна, който ви праща имейли), визитка, предишно подписано нареждане, CRM/ERP. Ако нямате нито един от тези източници, обадете се на главния телефон на компанията (от Google search) и поискайте свръзка със конкретния контакт.

Стъпка 4: Направете callback от поверителен номер

Не от вашия офисен номер. От мобилен. Целта: ако някой се представя по неприятен начин, нямате установена връзка с него от служебния си номер. Питайте: "Здравейте, обаждам се за потвърждение на промяна на банковата ви сметка. Получихме имейл от [име] за нова сметка в [банка]. Можете ли да потвърдите?" Слушайте внимателно за изненада, колебание, или преориентиране.

Стъпка 5: Проверете IBAN с банков ETIC tool

IBAN валидаторите (online безплатни) ви казват само дали структурата на IBAN е валидна за дадена държава. Те НЕ казват чий е акаунтът. Но проверете: дали IBAN-ът е за държавата, в която доставчикът е регистриран (italian-vendor с холандски IBAN е сигнал), дали банката е известна (Bunq, Revolut, Wise са легитимни, но за корпоративни плащания са нестандартни), дали кодът на банката съответства на реалната банка.

Стъпка 6: Видео разговор за потвърждение на стойност >100 000 лв.

За плащания над 100 000 лв., организирайте кратък 5-минутен видео разговор (Teams/Zoom/Google Meet) с финансовия отговорник на доставчика. Целта не е проверка на самоличност - целта е реакция на лицето. AI voice clones още не са идеално и в живо видео могат да се видят. Питайте за нещо извън сценария: "Как мина ремонтът на склада ви?" или "Маркус все още ли работи при вас?"

Стъпка 7: Тест с малка сума преди голяма

Първият превод към нова IBAN е малка сума (5-10 на сто от планираното) с прикачена бележка "test transfer". Изчакайте потвърждение от доставчика, че сумата е получена, преди да изпратите остатъка. Този подход добавя 24-48 часа към плащането, но при BEC измама вие губите само 5-10 на сто. Доставчиците разбират и приемат тази процедура.

Стъпка 8: 24-часово изчакване преди голяма сума

Между тестовия превод и пълния превод изчакайте поне 24 часа. Това дава време за: получаване на потвърждение, неочакван контакт от истинския доставчик ("Защо ни пращате тестови превод?"), и evaluation на нови признаци. В нашия случай: 24-часовото изчакване щеше да позволи на италианския доставчик да открие компромета (нападателят беше блокирал имейлите само от българската компания, не всички).

Стъпка 9: Dual approval в банковия портал

Плащането се въвежда от един служител и се одобрява от втори. За плащания над 100 000 лв. - три одобрения (въвеждащ, одобряващ 1, одобряващ 2). Поне един одобряващ задължително прави независима callback verification и подписва checklist, че процедурата е спазена. Дигиталното одобрение запазва timestamp и user ID за одиторска диря.

Стъпка 10: Архив на цялата документация

Запазете в споделена папка: оригинален имейл с full headers, screenshot на отговорите при callback, screenshot на IBAN validator-а, видео разговор записи (ако са направени), checklist на verification-а с подписи. Срок на retention: минимум 7 години (изискване на ЗСЧ за финансови документи). Целта: при бъдеща измама имате одиторска диря; при злоупотреба от служител имате запис.

Първите 4 часа определят дали ще възстановите 5 на сто или 50 на сто от парите. Следните 24 часа определят дали ще възстановите 10 на сто допълнително. След 7 дни вероятността за възстановяване е под 3 на сто. Процедурата:

Час 0-1: Спрете опитът за оправяне сами

Не пишете на нападателя. Не отговаряйте на имейла. Не публикувайте в социалните мрежи. Не пишете на доставчика преди да потвърдите чрез независим канал, че той не е нападателят. В случая в Пловдив, финансовият директор изпрати ядосан имейл към "Marco" в 11:00 - това задвижи нападателя да блокира всички бъдещи комуникации и да изпрази сметката по-бързо.

Първото действие: обадете се на банката си. Не имейл. Поискайте recall. Запишете часа на разговора, името на служителя, и входящия номер на сигнала. Това ще ви трябва за всички следващи стъпки.

Час 1-4: Подайте сигнал в ГД БОП и активирайте партньорите

Сигналът в ГД БОП се подава на cybercrime@mvr.bg и на телефон 02 982 2222. Описанието трябва да бъде кратко: "BEC измама с превод на [сума] към [IBAN] в [банка]. Превод е инициирани в [час], одобрен в [час], изпратен в [час]. SWIFT recall е поискан в [час] при [българска банка]." Изискайте входящ номер на сигнала - той е нужен за SWIFT recall, за киберзастраховката и за следваща правна работа.

Час 4-12: Активирайте IR екип и юрист

Призовете професионален incident response екип за: расследване на компромет (ако е компрометирана ВАШАТА мрежа, не само на доставчика), оценка на щетите (възможна изтичка на лични данни на служители или клиенти - КЗЛД нотификация в 72 ч), и подготовка на нотификации (киберзастраховка в 24-48 ч, ОЕЦ при ЗКС, БНБ при DORA). Юристът готви: формална жалба към ГД БОП и към прокуратура, заявление за SWIFT recall (форма-стандарт на банката), и комуникация с регулатори.

Ден 1-7: Преследване на парите

Парите рядко стоят в първата сметка. В нашия случай, парите бяха разделени на три транзакции в 4 часа след пристигане. Преследването следва SWIFT нишката: българска банка пише на холандска, холандска на немска, немска на чешка. Всяка стъпка отнема 24-72 часа. Крайната спирка обикновено е криптоборса в юрисдикция с слабо AML (Кипър, Естония до 2024 г., някои офшорни). След конвертация в крипто, проследяване изисква блокчейн форензика и сътрудничество на борсата - често постижимо, но рядко води до възстановяване.

Защитете финансите си преди следващата фактура

BEC одит и внедряване на четирите контрола за 14 дни

Atlant Security помага на български SMB и mid-market компании да внедрят пълната BEC защита: процедурата за верификация в 10 стъпки, dual approval в банковите портали, FIDO2 keys, Conditional Access policies, DMARC enforcement и security awareness training за финансовите екипи. Първа консултация безплатна, fixed-price пакет за 14-дневно внедряване.

Научете повече за нашия одит на ИТ сигурността · Свържете се с нас