Някой може да наблюдава банкирането ви, без да знаете

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

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

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

Следата, която промени проверката

В мрежовите настройки на Windows открихме ръчно зададен посредник, наричан proxy. Неговата задача по принцип е да приема интернет заявките на компютъра и да ги препраща нататък. Такива настройки могат да имат напълно легитимна употреба в корпоративна мрежа.

Тук адресът беше 127.0.0.1:9090. Това означава, че трафикът не отива директно към интернет, а първо към програма на същия компютър. Потребителят не знаеше за нея и организацията не използваше подобно решение.

Проследяването ни отведе до неподписан изпълним файл, отделен Python компонент и малък скрипт, поставен в папката за автоматично стартиране. При всяко включване на Windows той пускаше програмата без видим прозорец.

Какво всъщност правеше скритата програма

В откритите файлове имаше код за mitmproxy. Това е легитимен инструмент, използван от разработчици и специалисти по сигурност за анализ на интернет комуникации. Инструментът сам по себе си не е вирус. Проблемът е, че тук беше инсталиран тайно, стартираше автоматично и изпълняваше допълнителен код с очевидно злонамерено поведение.

Проверката показа, че програмата:

• включва отново proxy настройката, ако бъде изключена;
• приема интернет трафика преди той да напусне компютъра;
• може да чете и променя съдържанието на уеб страници;
• добавя собствен JavaScript код в получени страници;
• комуникира с външни сървъри и може да изтегля нов код;
• разпознава конкретни адреси, използвани от банкови и 3‑D Secure системи.

Това не означава, че банковите системи са били пробити. Компрометиран е компютърът на клиента — точката, от която той отваря истинските банкови страници.

Среща ли се същата схема и в други държави?

Да. Конкретните файлове и адреси от този случай не открихме в публичните доклади на големите международни лаборатории. Затова на този етап не можем коректно да го свържем с определена известна malware фамилия.

Самият начин на действие обаче не е нов. През годините различни банкови троянци са използвали почти същата комбинация от локално пренасочване, подменено доверие и промяна на страниците, които потребителят вижда:

• Retefe е разпространяван чрез фишинг и е атакувал потребители в Швейцария, Швеция и Япония. Анализът на Palo Alto Networks описва инсталиране на нов root сертификат и промяна на proxy настройките, така че трафикът към избрани банки да минава през нападателя.
• TrickBot използва локален proxy, генерира собствен сертификат и променя проверките на сертификатната верига, за да наблюдава защитени връзки в основните браузъри.
• Gataka създава proxy на заразения компютър и използва web injects — допълнителен код, който променя истински банкови страници. ESET описва дори подмяна на показвания баланс, за да бъдат скрити измамни преводи.
• ATMZombie използва т.нар. proxy changer срещу банкови клиенти в Израел и пренасочва връзките им през инфраструктура на нападателя.

Това поставя нашия случай в познат международен клас банкови атаки, но с важна местна особеност: кодът съдържа адреси за български банкови и 3‑D Secure услуги.

Един от откритите външни адреси — 3dsecbg0[.]com — не се среща в публичните анализи, които проверихме. Публичната регистрационна информация показва, че домейнът е създаден на 21.05.2025 г., все още е активен и регистрационните данни сочат България/София. Това е индикатор за разследване, но не е достатъчно доказателство за самоличността на извършителя.

Важно е и терминологичното уточнение: тук не е задължително да има нова софтуерна уязвимост или „zero-day exploit“. По-точно е да говорим за зловредна верига на атака, която злоупотребява с легитимни възможности на Windows, proxy софтуер и системата за доверени сертификати.

Международните паралели са описани подробно в анализите за Retefe, TrickBot, Gataka и ATMZombie.

Защо символът за защитена връзка не е достатъчен

Повечето потребители познават индикатора за защитена връзка като „катинар“, въпреки че съвременните браузъри невинаги го изобразяват точно по този начин. Той показва, че връзката със сайта е криптирана, но не доказва, че самият компютър е чист.

Криптираната връзка защитава данните при пренасянето им по мрежата. Тя не може да гарантира, че съдържанието не се обработва от скрита програма още преди да напусне компютъра. Затова истинският адрес, нормално изглеждащата страница и липсата на предупреждение не изключват локално прихващане.

За да не показва браузърът предупреждения, атаката е добавила собствен доверен сертификат в Windows. Сертификатът е документ, чрез който компютърът решава на кого може да има доверие. Когато злонамерена програма добави свой сертификат сред доверените, тя може да създава убедителни междинни сертификати за сайтовете, които потребителят посещава.

Така вместо една защитена връзка от браузъра до банката се получават две връзки: от браузъра до скритата програма и от нея до истинския банков сайт. Между двете съдържанието е видимо за програмата. Официалната документация на mitmproxy обяснява точно тази роля на доверения CA сертификат.

Защо са наблюдавани 3‑D Secure адреси

В кода открихме списък с адреси, използвани при допълнителни банкови и картови потвърждения. Това показва, че програмата не е следяла произволен трафик, а е имала специален интерес към финансови операции.

Важно разграничение: 3‑D Secure е механизъм за потвърждаване на определени картови плащания. SMS кодът, кодът от Google Authenticator и банковият токен са начини за удостоверяване. Това не са едно и също нещо и различните банки ги прилагат с различно ниво на защита.

Когато междинният слой контролира браузърната сесия, той може да препрати в реално време потребителското име, паролата и поисканата допълнителна проверка към истинската банка. Потребителят въвежда получения SMS или еднократен код, а нападателят го използва веднага или получава вече удостоверената сесия. Microsoft описва точно този модел при adversary‑in‑the‑middle атаки: потребителят завършва MFA проверката, но нападателят открадва валидната сесийна бисквитка.

Затова самият факт, че има SMS, шестцифрен код или приложение за кодове, не е достатъчна гаранция. CISA подрежда SMS като най-слабата разпространена MFA възможност и посочва, че кодовете от authenticator приложения също могат да бъдат откраднати чрез фишинг. Те все пак са по-добри от липсата на допълнителна защита, но не са устойчиви на атака с посредник.

И банковият токен не е автоматично слаб или автоматично сигурен. Решаващо е какво точно потвърждава. Обикновен код за вход може да бъде препратен. Значително по-силен е механизъм, който показва на независимо устройство конкретната сума и получателя и създава подпис, валиден само за тази операция.

Европейските правила за силно удостоверяване изискват при дистанционно плащане потвърждението да бъде динамично свързано с конкретната сума и конкретния получател. Ако някой от двата параметъра бъде променен, кодът трябва да стане невалиден. Това е съществената защита — не просто наличието на още един шестцифрен код.

Операцията спря при електронния подпис

В този конкретен случай банковата операция не беше завършена, защото последната стъпка изискваше отделно действие с електронния подпис. Подписването отказа и именно този проблем доведе до техническата проверка.

Важно е да разграничим двете неща: не междинната 3‑D Secure проверка, а електронният подпис се оказа последната бариера в тази операция.

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

Какво да проверите, когато избирате банка

Не избирайте само по броя кодове и по думата „токен“. Попитайте как е защитено окончателното нареждане:

• виждате ли на независимо устройство точната сума и името или IBAN на получателя;
• валидно ли е потвърждението само за тази конкретна операция;
• става ли кодът невалиден при промяна на сумата или получателя;
• има ли отделно подписване за нов получател и за по-рискови преводи;
• можете ли да зададете ниски дневни лимити и незабавни известия;
• предлага ли банката механизъм, устойчив на фишинг или отделно хардуерно/квалифицирано подписване.

Правилният въпрос не е „Има ли SMS или токен?“, а „Какво точно подписвам и мога ли независимо да проверя сумата и получателя?“

Какво можем да твърдим със сигурност

При публично описание на инцидент е важно да не превръщаме риска в недоказан факт.

• Установено е: скрито автоматично стартиране, локално пренасочване на трафика, доверен сертификат и код за наблюдение и промяна на уеб съдържание.
• Установено е: специално разпознаване на адреси, свързани с банково и 3‑D Secure удостоверяване.
• Установено е: комуникация с външна инфраструктура и възможност за изтегляне на допълнителен код.
• Установено е: операцията не е завършила на етапа с електронния подпис.
• Не е доказано: че самата банка е била пробита или че конкретна сума вече е била открадната.

Рискът обаче е реален. Позицията между потребителя и истинския сайт позволява наблюдение, подмяна и кражба на данни или активни сесии. MITRE ATT&CK описва този тип поведение като adversary-in-the-middle — нападател или злонамерен компонент, поставен по средата на комуникацията.

Как остана незабелязано повече от месец

Откритият сертификат и файловете показват, че механизмът е бил поставен през юни. Проблемът беше намерен значително по-късно, когато електронният подпис започна да отказва.

Антивирусният продукт не беше подал предупреждение. Това не означава, че антивирусните решения са излишни. Означава, че едно зелено състояние не е доказателство, че машината е чиста.

При подобен инцидент се проверява цялото поведение на системата: стартиращи програми, proxy и DNS настройки, доверени сертификати, неподписани процеси, мрежови връзки и файлове, появили се в потребителския профил.

Как ограничихме инцидента

1. Изолирахме компютъра от мрежата.
2. Запазихме необходимите следи за анализ и спряхме свързаните процеси.
3. Изключихме непознатата proxy настройка.
4. Премахнахме скритото автоматично стартиране.
5. Поставихме подозрителните файлове под карантина.
6. Премахнахме добавения доверен сертификат.
7. Проверихме за други начини за автоматично стартиране и външен достъп.

След такъв случай е необходима и проверка на банковите операции и използваните акаунти. Паролите се сменят от чисто устройство, активните сесии се прекъсват, а при съмнение банката се уведомява незабавно.

Проверете дали и вашият компютър не е наблюдаван

Следните признаци не доказват сами по себе си атака, но заслужават проверка:

• в Windows е включен ръчен proxy, който не разпознавате;
• в доверените root сертификати има неизвестен издател;
• при стартиране се зареждат непознати скриптове или програми;
• изпълними файлове без цифров подпис работят от AppData или друга потребителска папка;
• банкови, държавни или подписващи услуги започват да се държат необичайно;
• proxy настройката се включва отново след ръчно изключване.

Не изтривайте на случаен принцип сертификати и системни файлове. Ако видите необяснима proxy настройка или непознат доверен сертификат, прекъснете чувствителните операции, изолирайте устройството и потърсете компетентна проверка.

Най-важният извод

„Не ми работи електронният подпис“ невинаги е проблем с подписа. „Не мога да вляза в банкирането“ невинаги е проблем с банката. Понякога това са първите видими признаци, че компютърът между потребителя и услугата вече не е надежден.

Ако използвате служебни компютри за банкиране, счетоводство и електронно подписване, не разчитайте само на антивирусно сканиране. Проверявайте и поведението на системата — преди дребният симптом да се превърне във финансова загуба.

Свържете се с нас, ако имате необясними проблеми с банкиране, електронен подпис или защитени онлайн услуги и искате независима техническа проверка.