Реально тонкое взаимодействие 🕊

В ходе реверс-инжиниринга протокола одного из бразильских банковских троянов обнаружилось использование интересного сетевого фреймворка — RealThinClient. Процесс общения между клиентом и сервером в этом фреймворке построен на сериализации структур вызова функции в строковый формат и их последующей десериализации на другой стороне. Это делает RTC не только мощным инструментом разработки, но и удобной платформой для скрытого обмена командами — например, в случае малварного поведения.

Сначала клиент и сервер проходят через кастомное рукопожатие, в ходе которого устанавливаются ключи шифрования и дешифрования для обеих сторон. После этого фреймворк предоставляет возможность выполнять функции на стороне как клиента, так и сервера.

Перейдем сразу к примеру и на нем разберемся в логике работы инструмента. Клиент хочет залогиниться на сервере и отправляет запрос, как на скриншоте.

Что здесь происходит

1. Клиент формирует запрос:

• Устанавливает параметр FC (function call) в значение Login.

• Добавляет параметры: логин, пароль и id. Они передаются в виде структуры-словаря RE=3 (record), содержащей ключи user, pwd, id и т. п. В user можно передать зашифрованный малварный запрос. RE обозначает тип rtc_Record — это структура вида «ключ:значение», аналогичная словарю или JSON-объекту.

• На стороне Delphi это будет примерно так:

with FunctionCall.Param do
begin
  asText['user'] := '...'; // rtc_Text
  asText['pwd'] := '';     // rtc_Text
  asString['id'] := '8DF313279CD34B81A3FB438708B4E8F1'; // rtc_String
end;

А при сериализации все это превратится в следующее:

RE=3;
user:T=...;
pwd:T=...;
id:S=...

📁 Когда мы вызываем удаленную функцию через RTC SDK, мы создаем объект TRtcFunctionInfo — это класс, который описывает удаленную вызываемую функцию, ее имя, параметры и результат выполнения. Он используется как на клиенте (для упаковки вызова), так и на сервере (для распаковки и выполнения). Объект TRtcFunctionInfo упаковывается в контейнер TRtcValue и сериализуется в строку или поток байтов.

TRtcValue может хранить любой поддерживаемый тип данных: строку, число, массив, запись, дату, вложенную функцию и т. п. Фактически он используется везде, где нужно передать или получить данные по сети, например в параметрах удаленной функции (Param.asValue[...]) или результатах выполнения функций (Result.asValue). Это делает его гибким, но и потенциально непрозрачным, что хорошо для скрытой передачи команд, особенно если используются вложенные структуры типа rtc_Function.

• Перед отправкой запроса клиент регистрирует хендлер OnLoginResult для обработки результата выполнения функции на сервере.

2. Запрос отправляется на сервер RTC:

• Сервер принимает HTTP-запрос и интерпретирует параметр FC как указание на то, какую функцию нужно вызвать.

• На стороне сервера вызывается обработчик для функции Login. Выполняется Delphi-процедура, связанная с этим именем.

3. Сервер отвечает:

• Результат функции возвращается клиенту, и он вызывает свой хендлер OnLoginResult для обработки полученного ответа.

• Ответ сервера десериализуется обратно в TRtcValue, чтобы мы смогли снова получить доступ к его структуре. Сервер может вернуть не просто данные, а вложенный вызов функции. Это структура, поле в которой содержит rtc_Function, rtc_Record или rtc_Array, которые клиент десериализует и выполняет.

Например:

if xData.isType = rtc_Record then
  ExecuteRec(xData.asRecord)
else if xData.isType = rtc_Array then
  ExecuteArr(xData.asArray)

👾 Это может успешно использоваться в малвари: сервер возвращает зашифрованное описание команды, которую клиент должен выполнить. Таким образом, в легитимный RTC-поток можно прятать вполне себе вредоносное поведение.

#reverse #hacktool
@ptescalator

APT-группировка Cloud Atlas атакует предприятия ОПК России 🌎

В конце прошлого — начале текущего года группа киберразведки обнаружила миграцию управляющей инфраструктуры и эволюцию вредоносных документов в арсенале Cloud Atlas, ознаменовавшие начало новой кампании группировки в отношении предприятий оборонно-промышленного комплекса России.

Наблюдение за выявленной вредоносной инфраструктурой позволило в режиме реального времени отслеживать весь размах новой киберактивности группировки Cloud Atlas, в том числе вскрыть BEC-атаки с использованием электронной почты ранее зараженных предприятий ОПК России для отправки вредоносных документов Microsoft Office в адрес контрагентов.

📫 Вектором проникновения традиционно выступала фишинговая рассылка электронных писем с вредоносными документами Microsoft Office во вложении. Информация об управляющей инфраструктуре и вредоносные VB-скрипты были скрыты в альтернативном потоке данных (1Table) документов. Открытие файлов приводило к выполнению этих скриптов, которые взаимодействовали с API Google Sheets для передачи информации о зараженной системе и загрузки бэкдора PowerShower с последующей эксфильтрацией украденных данных в облачные хранилища (более подробно — в нашем прошлом исследовании).

По содержанию вредоносные вложения представляли собой приглашения на курсы повышения квалификации, документы об антикоррупционных проверках и мобилизационных мероприятиях, акты сверки взаимных расчетов, справки в отношении сотрудников, резюме соискателей на должность оператора ЧПУ.

🤷‍♂️ Обнаруженные документы — по большей части характерные для государственного сектора шаблоны — отсутствуют в открытом доступе и, вероятнее всего, были украдены из сетей ранее атакованных предприятий. Во избежание раскрытия предприятий, в сетях которых присутствует группировка, из зараженных документов накануне использования в новых атаках удалялись метаданные, о чем свидетельствуют временные метки их модификации.

Активность АРТ-группировки Cloud Atlas отслеживается с 2014 года. Традиционной географией атак являются страны СНГ. В 2024 году вектор кибератак существенно сместился в сторону России, их высокая интенсивность, частота миграции атакующей инфраструктуры и эволюции вредоносных документов сохраняются до настоящего времени.

Прогнозируется сохранение высокого уровня опасности киберугроз для российских учреждений и организаций, исходящих от APT-группировки Cloud Atlas.

🧐 Подробнее читайте на нашем сайте.

#TI #APT #Malware
@ptescalator

Team46 и TaxOff: две стороны одной медали 😑

В марте 2025 года специалисты TI-департамента экспертного центра безопасности Positive Technologies (PT Expert Security Center, PT ESC) исследовали атаку, в которой использовалась зарегистрированная примерно в это же время уязвимость нулевого дня CVE-2025-2783 в браузере Chrome. Использование этой уязвимости и саму атаку описали исследователи из «Лаборатории Касперского», однако последующая цепочка заражения осталась без атрибуции.

🪞 В отчете описана атрибуция данной атаки к группировке TaxOff, о которой мы писали ранее. Кроме того, приводятся данные, которые позволяют считать еще одну найденную нами ранее группировку Team46 и TaxOff одной и той же группой.

Начальным вектором атаки было фишинговое письмо, содержащее ссылку, при переходе по которой жертва активировала one-click exploit, приводящий к установке бэкдора Trinper группировки TaxOff в скомпрометированной системе. В этой атаке был обнаружен бэкдор группировки Team46.

Группировка Team46 была ранее замечена в атаках, использующих DLL-Hijacking для Яндекс Браузера (CVE-2024-6473).

📖 Подробнее читайте на нашем сайте.

#TI #APT #cve
@ptescalator

Группа киберразведки PT ESC подготовила отчет по итогам первого квартал 2025 года ✍️

В нем собрали наиболее интересные атаки хакерских группировок на инфраструктуры российских государственных организаций и частных компаний.

🐍 Была замечена активность таких группировок, как PseudoGamaredon, Cloud Atlas, DarkGaboon и других. Основные цели — кража данных, получение доступа к внутренним системам для шпионажа.

📩 В течение всего квартала фиксировались фишинговые кампании от имени различных государственных ведомств. В рассылках встречались как архивы с вредоносным ПО, названия которых мимикрировали под тему письма, так и документы с эксплойтами для известных уязвимостей.

📑 Наряду с этим злоумышленники распространяли и безвредные на первый взгляд файлы, например поддельные приказы о проверках, оформленные в официальном стиле, но не содержащие вредоносной нагрузки. Это позволяло письмам успешно проходить антивирусную проверку, после чего в ход шли приемы социальной инженерии — злоумышленники пытались выстроить диалог и получить доступ во внутренний контур компании.

😏 Ознакомиться с отчетом можно на сайте Positive Technologies.

#TI #APT #malware #ioc
@ptescalator

Yara Yara Daze

Всем, кто занимается malware analysis, точно знаком такой инструмент, как YARA 😉. С помощью него во многих компаниях 🔴 составляют наборы сигнатурных правил для определения и классификации вредоносов.

🤔 So, что такое хорошие YARA-правила? Это правила, которые могут детектировать предназначенный им класс или семейство ВПО, не детектируют ничего лишнего (false positive) и способны сохранять актуальность, даже если ВПО подвергается небольшим изменениям.

😏 Нет общего совета, как сделать хорошее YARA-правило — это зависит от сампла к самплу. Мы поделимся некоторыми Tips&Tricks про детект строк, которые будут полезны начинающим:

🔹 Не стоит забывать fullword — этот модификатор на строки гарантирует, что сигнатурная строка не будет находиться между буквенно-цифровыми символами (осторожнее с golang).

🔹 filesize выручает в тех случаях, когда сампл маленький и кроме общих сигнатур в нем ничего нет:

   rule CustomSocksProxy {
      strings:
          $a_1 = "SOCKS5 Proxy listening" wide
          $a_2 = "New connection from" wide
      condition:
          uint16(0) == 0x5a4d and filesize < 100KB and all of ($a_*)
  }

🔹 Лучше избегать сигнатур длиной в 3-4 символа.

🔹 Иногда очень полезно прописывать условие расстояния между строками. Например, если в файле есть какие-нибудь white- / blacklist, как имена процессов, можно ограничить их расположение в окне конкретной длины:

rule CheckProcessList {
      strings:
          $base = "\\system32\\cmd.exe" wide
          $str2 = "\\task.exe" wide
          $str3 = "cmd.exe" wide
          $str4 = "\\alg.exe" wide
          $str5 = "powershell.exe" wide
      condition:
      for all of ($str*): (@ - @base < 100) and for all of ($str*): (@base - @ < 100)
  }

🔹 Строки логирования лучше не разбивать на подстроки длиной 4-5 символов, если там общие слова, которые могут встретиться в любом контексте: детект подстроки \\\\dc2 в строке \nUsing:\n\t session_enum.exe \\\\dc1 \\\\dc2 \n — плохой детект.

🔹 Чтобы детект строк пережил различные кодировки, чередование заглавных и строчных букв, можно использовать три модификатора wide ascii nocase:

   rule SomeAPTScript {
      strings:
          $a1 = "GetRef(" ascii wide
          $a2 = " & ChrW(\"&H\" &" ascii wide
          $a3 = "Mid(" ascii wide
          $a4 = "Join(" ascii wide
          $a5 = "=0 Step -2" ascii wide
          $a6 = "Function [" ascii wide
          $a7 = "MSXML2.ServerXMLHTTP" ascii wide
          $v1 = "<Script " ascii nocase wide
          $v2 = "VBSCript" ascii nocase wide
          $v3 = "JSCript" ascii nocase wide
          $wscript = "WScript.CreateObject(\"WScript.Shell\")" ascii nocase wide
      condition:
          filesize < 30KB and $wscript and 2 of ($v*) and 5 of ($a*)
  }

И, конечно, главное — не забывать смотреть в документацию YARA 👀, следить за обновлениями и подсматривать на рули коллег.

Успехов в работе.

#tips #malware #YARA
@ptescalator

Yara-Yara-Yara!

🐧 Когда со строками разобрались, можно приступить к генерации байтовых сигнатур. Обычно их стараются делать как можно реже, так как для их генерации приходится смотреть на голый ассемблер 😗

Но рано или поздно найдется сампл, в котором не будет нужных строк для детекта 😶. Приведем парочку советов и примеров 😌, как перестать бояться и начать делать генерировать байтовые сигнатуры на код:

🐾 Практически нет смысла писать сигнатуру на пролог функции и ее завершение: поверьте, эти push\pop почти везде одинаковые 😤

🐾 Старайтесь ухватиться за константы или необычную последовательность инструкций: часто в бэкдорах злоумышленники используют кастомное шифрование пакетов, которые очень приятно детектить

$code1 = {
    FF C6           // inc     esi
    B8 99 99 99 99  // mov     eax, 99999999h
    F7 EE           // imul    esi
    D1 FA           // sar     edx, 1
    8B C2           // mov     eax, edx
    C1 E8 1F        // shr     eax, 1Fh
    03 D0           // add     edx, eax
  }

🐾 Компилятор может изменить порядок инструкций, или даже вставить выравнивающие nop 😨. Будет не лишним использовать пропуски между инструкциями — { <byte inst> [5-6] <byte inst2> }

🐾 Все оффсеты (в jmp, call и т.д.) надо заменять на знаки ?, поскольку смещения меняются компилятором /*разве что в рукописном шеллкоде это не так*/ Можно оставлять старшие 1-2 байта оффсета в сигнатуре — они почти всегда 00 или ff

$code61  = {
    68 DF 71 00 00  // push    71DFh           ; request
    53              // push    ebx             ; fd
    E8 ?? ?? ?? ??  // call    _ioctl 
  } // если вопросы стоят в конце байт-конструкцции, их можно вовсе убрать

🐾 Стоит учитывать, что один и тот же opcode может оперировать разными регистрами от сампла к самплу 😫. Чтобы сигнатура была актуальной, нужно затереть байты операндов знаками ? в инструкции

$code21  = {
    89 ??                 // mov     edi, esi
    83 C? 01              // add     esi, 1
    83 E? 1F              // and     edi, 1Fh
    0F B6 ?? ?? 10        // movzx   edx, byte ptr [edx+eax+10h]
    83 C? 01              // add     eax, 1
    30 ?? ?? 28 03 00 00  // xor     [ebx+edi+328h], dl
    83 F? 0C              // cmp     eax, 0Ch
  }

🐾 Можно сделать выбор из нескольких вариантов (<opcode1> | <opcode2>), когда в серии самплов используются разные opcode для цепочки инструкций

  $code_3 = {
    80 34 (0? | 1? | 2? | 3?) 02  // xor byte ptr [eax + esi], 3
    4?                            // inc eax
    3D ?? ?? 00 00                // cmp eax, 0x21e6
    (7C | 72) ??                  // jl 0x10001322 \ jb ????????
    B? ?? ?? 00 00
  }

Все эти ассемблерные манипуляции с байтовыми сигнатурами зачастую приходится делать с декодером опкодов и инструкций. К счастью, один из наших коллег создал плагин для помощи 😏 в генерации сигнатур, который заменяет все параметризуемые участки сигнатуры на ? и группы (x | y). Инструмент yarg работает как плагин к Ida Pro, генерируя к выбранному участку кода готовую сигнатуру для Yara-правила. Вам останется только найти участок кода, подходящий для создания сигнатуры 🙂

Успехов в работе!

#tips #malware #YARA
@ptescalator