CAV3RN е модулна шпионска рамка, която става все по-трудна за откриване в мрежата.

Нейният най-нов комуникационен компонент скрива трафика за отдалечен контрол зад Google Apps Script – услуга, която много организации използват легитимно.

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

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

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

От Kaspersky заявяват в доклад, споделен с Cyber Security News (CSN), че CAV3RN може да избира директна уеб връзка или пренасочване чрез Google Apps Script за всеки обмен на данни, като използва DNS отговори, за да вземе това решение.

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

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

CAV3RN използва Google Apps Script като C2 реле

Компонентът представлява 64-битова Windows DLL библиотека, която започва с докладване на списък с близки DLL файлове и техните версии.

След това той редовно запитва DNS системата кой комуникационен маршрут да използва. Тази лека проверка превръща обикновено изглеждащите DNS търсения в контролен сигнал за зловредния код.

Отговорът с DNS A-запис насочва модула или към директен HTTPS, или към Google Apps Script, в зависимост от последното му число и текущото състояние на грешка на връзката.

Ако маршрутът през Google се провали, следващото търсене може да го насочи към директен HTTPS. Този резервен модел наподобява скрит канал в DNS трафика – друга техника, която прави рутинното разрешаване на имена полезно за атакуващите.

Когато е избран режимът на Google, CAV3RN изпраща POST заявка към внедряване на Apps Script, което действа като реле.

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

Зловредният код може също така да проверява дали неговият идентификатор за внедряване в Google (deployment ID) е актуален. Той сравнява част от криптографски хеш с DNS отговор и ако има разминаване, изтегля нов идентификатор на малки части чрез DNS отговори.

Това позволява на операторите да ротират Google релето, без да подменят самия зловреден код.

Модулният брокер добавя устойчивост

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

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

Тази архитектура дава на операторите гъвкавост, надхвърляща възможностите на единична задна врата (backdoor). Брокерът може да върне опис на компонентите, а комуникационният модул може да му предава получените задачи.

Директният HTTPS трафик отива към контролиран от атакуващия бекенд и изисква персонализирана клиентска заглавна част (header), което добавя още един детайл, който защитниците могат да използват при разследване на необичаен трафик.

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

Те също така трябва да избягват да третират трафика, хостван в Google, като автоматично безопасен, тъй като кампании със зловреден софтуер чрез Azure Functions показват как легитимни хоствани услуги могат да бъдат пренасочени за таен контрол.

Мониторингът на мрежата трябва да съпоставя DNS търсенията, веригите от пренасочвания и активността на процесите, вместо да разчита само на един индикатор.

Организациите, които открият тези признаци, трябва да изолират засегнатото устройство, да запазят съответните регистрационни файлове и да проверят за допълнително заредени DLL файлове.

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