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
          $wnoscript = "WScript.CreateObject(\"WScript.Shell\")" ascii nocase wide
      condition:
          filesize < 30KB and $wnoscript 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

Trust but verify, или Как выбирать TI-источники с умом 😏

В жизни подавляющего большинства SOC-центров наступает момент, когда требуется дополнить свой инструментарий данными киберразведки (threat intellegence, TI).

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

Ни для кого не секрет, что чем больше событий обрабатывает СЗИ, тем дороже обходится избыточный поток фолзов. Если подключать TI-источники без их предварительной проверки, то количество ложных срабатываний может возрасти кратно. Чтобы этого избежать, предлагаем рассмотреть следующие этапы.

Этап 1️⃣

Для начала следует заново познакомиться с тем, что вы защищаете, а именно:

• Изучить инфраструктуру своей организации, критически значимые активы (например, серверы, БД).
• Понять, что и от чего вы защищаете.
• Какие СЗИ используются в системе защиты организации.
• Уточнить, какие TI-источники используются в продуктах «из коробки» и используются ли.

На базе полученной информации требуется определить приоритеты защиты и потенциальные векторы атак, релевантные для вашей организации (все это еще называют ландшафтом угроз). Полученная информация позволит приступить к следующему этапу — выбору TI-источников.

Этап 2️⃣

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

• Точность детектирования. Отношение числа положительных срабатываний к общему числу срабатываний на основе TI-контента от конкретного источника.

• Покрытие детектирования. Отношение числа срабатываний на основе данных от TI-источника к общему числу срабатываний, зафиксированных на конкретном СЗИ.

• Релевантность потока данных. На базе информации из этапа 1 (ландшафта угроз) у нас есть представление, что для нас релевантно, а что нет. Имеется в виду, например, наличие в потоке данных информации, специфичной для определенной отрасли или региона, описания активностей хакерских группировок или алгоритма работы определенного семейства ВПО. То есть всего того, что вы посчитаете полезным для использования у себя в организации в процессе построения процессов ИБ. Чем больше контекста связано с нашим ландшафтом, тем выше значение метрики.

• Своевременность потока данных. Это оценка того, как велика разница между временем появления (или обнаружения) угрозы и временем поставки данных. Чем меньше разница между этими временами, тем выше шанс обнаружить попытку реализации этой угрозы вовремя.

• Обновляемость потока данных. Метрика, позволяющая оценить, насколько сильно изменяется поток данных между итерациями поставки. По сути говоря, это критерий, отвечающий на вопрос, как много уникальных индикаторов приносит источник за единицу времени (например, за сутки).

Никто не мешает вам придумать собственные метрики и опираться на них в процессе выбора источников данных. Например, вы можете оценить удобство структуры поставки данных (в каком формате они приходят, есть ли возможность их кастомизации под себя), частоту поставки (например, раз в сутки, раз в час, раз в 10 минут) или наличие определенных недостатков при поставке (дубликатов данных, нарушение SLA).

Этап 3️⃣

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

#TI #tips
@ptescalator

😍 Выступления, которые точно нельзя пропустить на киберфестивале Positive Hack Days 22—24 мая

Для их посещения офлайн нужно приобрести билет. Онлайн-трансляция будет доступна на сайте PHDays Fest бесплатно.

22 мая

(Ex)Cobalt. Новый зверинец группы: пума, осьминог и другие

Зал 23 «Да Винчи», Киберхаб (15:00–15:50)

Группа (Ex)Cobalt является одним из наиболее активных threat-акторов, атакующих Россию. Начав в 2016 году с финансово мотивированных атак, группа сместила фокус на кибершпионаж. Помимо компаний в сферах энергетики, образования и телекоммуникаций, группа нацелена на компрометацию разработчиков ПО, стремясь расширить масштаб компрометаций за счет атак на цепочку поставок.

(Ex)Cobalt постоянно расширяет и усложняет арсенал используемых вредоносных программ. В своем докладе Станислав Пыжов, ведущий специалист группы исследования угроз TI-департамента PT ESC, и Игорь Ширяев, старший специалист департамента комплексного реагирования на киберугрозы в PT ESC, расскажут об эволюции тактик и техник группы и ее новом инструментарии — с подробностями расследований.

23 мая

Смотрим глубже: ищем подозрительные COM-запросы на уровне ALPC

Зал 23 «Да Винчи», Киберхаб (11:00–11:50)

Павел Максютин, ведущий специалист отдела экспертизы PT Sandbox, подробно разберет работу протоколов COM и RPC, опишет существующие технологии обнаружения вредоносных действий, а также расскажет, как обнаруживать вредоносные COM- и RPC-запросы на уровне Advanced Local Procedure Call — механизма межпроцессного взаимодействия в операционных системах Windows.

Один на один с Rust

Лекторий Positive Labs, Киберхаб (14:00–15:00)

В своем докладе Владислав Лунин, старший специалист группы исследования сложных угроз, поделится опытом реверс-инжиниринга исполняемых файлов, написанных на Rust: в последнее время часто приходится сталкиваться с ВПО, написанным на этом языке. ВПО бывает как очень простое, так и очень сложное по своей реализации, и чаще всего данная сложность обусловлена именно особенностями языка.

Владислав расскажет, какие подходы применяет для обратного проектирования, а также с какими сложностями он сталкивался и как их преодолевал.

24 мая

Мастер-класс «Создание антифишинговой кампании»

Зал 13 «Гальвани», Киберарена (10:30–13:30). Нужна регистрация. Трансляции не будет.

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

Делиться опытом будет Фёдор Гришаев, специалист направления реагирования и исследования угроз.

#PHDays