Индийският екип за реагиране при компютърни инциденти (CERT-In) разкри, че подпомаган от изкуствен интелект (ИИ) автор на заплахата, проследяван под името Crafty Falcon, атакува организации в секторите на банкирането, финансовите услуги и застраховането (BFSI) в страната.

Описвайки заплахата като активна и продължаваща, дейността включва използването на публично достъпни инструменти за офанзивна сигурност, задвижвани от ИИ, като ARTEX, PentAGI, Cairn и CyberStrikeAI.

„Тези инструменти изпълняват пълни вериги от атаки автономно с машинна скорост, генерират и усъвършенстват голям брой персонализирани скриптове за атаки в бърза последователност и адаптират своя зловреден код въз основа на отговорите на целта“, заявиха от CERT-In. „Поддържащата атакуваща инфраструктура ротира IP адресите в рамките на часове до дни.“

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

Информацията следва предупреждение от октомври 2026 г., издадено от CERT-In, което алармира за множество кампании за кибератаки, насочени към небанкови финансови компании (NBFC), платформи за дигитално кредитиране, финтех дружества, доставчици на платежни услуги и оператори на портфейли за криптовалута.

Забелязано е, че киберпрестъпниците експлоатират достъпни през интернет приложения, незащитени приложни програмни интерфейси (API) и привилегировани крайни точки, за да откраднат API идентификационни данни за платежни агрегатори/шлюзове и банки партньори, след което извикват API за превод на средства директно от собствената одобрена инфраструктура на засегнатите организации.

Някои от другите забележими вектори за първоначален достъп са изброени по-долу –

  • Използване на откраднати дълготрайни статични, твърдо кодирани API токени
  • Компрометиране на веригата за доставки на хранилища с изходен код чрез фалшифицирани подавания (commits)
  • Експлоатиране на идентификационни данни в чист текст в конфигурационни файлове, изходен код или бази данни
  • Достъп до приложения и отдалечени услуги, при които липсва многофакторна автентикация (MFA)

Този подход, добавиха от CERT-In, заобикаля контролите на ниво приложение, като създаване на заеми, опознай своя клиент (KYC), санкции, проверка на бенефициента, достатъчност на баланса и лимити за отделна трансакция.

Бързо изпълняваните измамни трансакции са предназначени да прехвърлят средства към контролирани от атакуващите сметки на „финансови мулета“ в множество банки. В допълнение, атаките включват предприемане на стъпки от страна на операторите за изтриване на регистрационни файлове (логове) и манипулиране на инструментите за сигурност на крайните точки в опит да се усложнят усилията за откриване и реагиране при инциденти.

CERT-In също така предупреди, че атакуващите се насочват към облачната инфраструктура, за да изпълняват команди и да разполагат зловреден код, както и към публично достъпни непроизводствени среди, за да получат споделени идентификационни данни, токени или мрежови пътища, които след това използват за прехвърляне към производствените системи.

Други забележими действия след експлоатацията, предприети от противника, са следните –

  • Обратно инженерство на кодовите бази на приложенията за разработване на персонализирани експлойти
  • Иницииране на неоторизирани API повиквания с помощта на модифицирани пакети на приложения, подкопавайки контролите, които „предполагат, че само легитимното клиентско приложение ще извиква съответните API“
  • Изпълнение на тестови трансакции с микростойност (като например 1 индийска рупия) за валидиране на неоторизирани парични потоци преди извършване на преводи на големи стойности
  • Злоупотреба с API за разплащане с търговци на платежни агрегатори за преместване на средства
  • Експлоатиране на наскоро разкрити уязвимости, включително вериги от експлойти за качване на файлове и десериализация, водещи до уеб шелове в PHP и Node.js приложения
  • Създаване на голям брой персонализирани скриптове в движение и итеративното им подобряване в бърза последователност – модел, съответстващ на разработка, подпомагана от ИИ

Развитието идва в момент, когато CERT-In публикува Насоки за одит на сигурността на изкуствения интелект, определящи специфични изисквания за гарантиране на „управлението, сигурността, поверителността, справедливостта, прозрачността, устойчивостта и възможността за одит на ИИ системите“.

Рамката призовава за тестване на документираните идентичности на ИИ агентите, оторизираните цели, одобреното използване на инструменти, границите на правата за достъп и спазването на принципа на най-малката привилегия (PoLP). Тя също така налага ИИ агентите да изискват човешко одобрение за действия със сериозни последствия, като същевременно гарантира, че високорисковите ИИ системи включват аварийно прекъсване, отмяна на идентификационни данни и контроли за предотвратяване на автоматични рестартирания.

„Ефективното подсигуряване изисква организационна отчетност, техническо тестване, управление на данни и модели, непрекъснат мониторинг, човешки надзор, реагиране при инциденти и гаранции от трети страни“, заявиха от агенцията. „Съответно рамката предоставя одитируеми изисквания, пропорционални на естеството, мащаба, автономността и потенциалното въздействие на всяка ИИ система.“

Копирана версия на ARTEX раздава root шел достъп

Злоупотребата с инструменти за тестване за проникване с отворен код като ARTEX при реални пробиви накара неговия разработчик да премахне хранилището от GitHub. Но множество копия се появиха в притежаваната от Microsoft платформа за хостинг на код, за да запълнят празнината –

  • github[.]com/trhhubsd/ARTEXX
  • github[.]com/mhtsec/ARTEX („mianhuatang11/artex“ в Docker Hub)
  • github[.]com/RuoJi6/ARTEX

Първите две хранилища в GitHub вече не са достъпни за изтегляне. Според независим изследовател по киберсигурност, който използва онлайн псевдонима Badbyte, хранилището „trhhubsd/ARTEX“ е получило 2449 звезди и е било разклонено (forked) над 600 пъти.

Забележителното при копието в GitHub е, че то променя един-единствен ред в „docker-compose.yml“, за да изтегли изображението „tomicdd/artex“ от Docker Hub. Модифицираната версия крие нова процедура, която предоставя root шел по време на неавтентикирана заявка към крайната точка за вход. Според статистиката, споделена от Docker Hub, изображението е било изтеглено 9000 пъти.

„Добавя се скрита функция verifyCaptcha() към манипулатора за вход: ако полето CAPTCHA започва със секретен маркер, останалата част се изпълнява чрез sh -c като root и резултатът се връща преди каквато и да е проверка на идентификационните данни“, казва изследователят в изявление, споделено с The Hacker News по имейл. „Това е неавтентикиран root шел при всяка инсталация и никога не се забелязва при преглед на кода.“

„Една компрометирана инстанция на ARTEX съхранява откритите уязвимости на своите цели, за които все още не са инсталирани корекции за сигурност, активни идентификационни данни, прихванати сесии и мрежова позиция. Всеки, който контролира задната вратичка, може също така тихо да промени това, което агентите правят при следващото стартиране.“

Установено е, че общо 62 конзоли на ARTEX в интернет обслужват компрометираната със задна вратичка версия между 2 и 4 ноември 2026 г., като първата инстанция се е появила до 20 октомври 2026 г., дванадесет дни след публикуването на Docker изображението. От тях 26 конзоли се намират в САЩ, следвани от 17 в Хонконг и седем в Китай.

Общо 1645 хоста са били открити да обслужват конзолата ARTEX към 4 ноември 2026 г. Освен „tomicdd/artex“, редица имена на пространства (namespaces) в Docker Hub са идентифицирани като публикуващи изображения с името „artex“. Някои от тях са изброени по-долу –

  • congdonglinux/artex (също със задна вратичка и идентично на „tomicdd/artex“)
  • mianhuatang11/artex
  • autumn26/artex
  • andy1099zz/artex
  • dgddw/artex
  • trhhubsd/ARTEX
  • ylh440104/artex

„На автора на задната вратичка не му е трябвало нищо повече. Хората, които е преследвал, вече са били избрали да стартират непроверен инструмент за атаки като root на отворен порт“, коментира Badbyte. „Знаем, че ARTEX е бил използван злонамерено в реална среда и ще продължи да се използва по този начин. Знаем също, че много легитимни, любопитни хора са го инсталирали, за да видят за какво е целият този шум. Те не са се съгласявали да получат чужд root шел на собствения си сървър.“