Tls fingerprint что это
Как соцсети нас отслеживают? — техническая сторона
Вступительное от редакции:
В статье «Почему твои аккаунты банят» мы упоминали о технических данных, из за которых вы можете ловить блокировки. В этой статье мы более подробно разберемся по каким именно параметрам социальные сети нас отслеживают.
Крайне рекомендуем прочесть эту статью несколько раз, информация, изложенная в ней, будет полезна при работе как с платным, так и с условно-бесплатным трафиком.
Статью написал наш товарищ Stan Lee.
Здесь и далее от лица автора:
Я изучил большой объем статей по безопасности и решил поделится знаниями в этом вопросе. Проведем легкий ликбез.
Изначально статья предполагалась для вилочников и была про Антифрод. Но эта информация универсальна и отлично подходит под работу с аккаунтами в соц.сетях.
Что такое антифрод?
Антифрóд (от англ. anti-fraud «борьба с мошенничеством »), или фрод-мониторинг — система, предназначенная для оценки финансовых транзакций в Интернете на предмет подозрительности с точки зрения мошенничества и предлагающая рекомендации по их дальнейшей обработке. Как правило, сервис антифрода состоит из стандартных и уникальных правил, фильтров и списков, по которым и проверяется каждая транзакция.
Так говорит википедия, на самом же деле антифрод системы нас окружают начиная с перехода в поиск гугла.
Антифрод сегодня — это набор правил, фильтров и параметров, призванных отличить типичного пользователя (добропорядочного), от нетипичного (злоумышленника). Самые жесткие антифрод системы стоят в банках, после в букмекерских конторах.
Букмекерские конторы, как и Модераторы соцсетей крайне не заинтересованы в людях, использующих мультиаккаунты. А, соответственно, вкладывают огромные деньги в развитие своих антифрод-систем.
На сегодняшний день все антифрод системы можно разделить на 2 вида:
Про поведенческую антифрод систему сказано многое – нужно быть типичным юзером соц.сети – не сидеть 24/7 в сети, после регистрации не бежать сразу заливать рекламу, не загружать сразу миллион фото и не подписываться на 400 человек за первые 30 минут и т.д. В рамках данной статьи поведенческие факторы пользователя мы рассматривать не будем. В контексте данной статьи мы рассмотрим программно-аппаратный вид антифрода.
IP, куки и фингерпринты (Fingerprint )
На просторах интернета я часто замечаю советы “мастеров” анонимизации. Все просто – покупаешь прокси сервер или вообще находишь бесплатный (что крайне не рекомендую) меняешь браузер или, что еще забавнее, чистишь куки и все – ты новый человек. Никто тебя не найдет, никто тебя не узнает.
Да, так и было, но лет 10-15 назад. И это не точно.
IP адрес
Всего 4 миллиарда адресов, на 7 миллиардов жителей земли и десятки миллиардов устройств работающих в сети интернет.
IP адрес уже как много лет не является уникальным идентификатором, безусловно его нужно менять при создании каждой новой личности, но это лишь один из сотен параметров идентификации.
Самое важное, чтобы IP адрес не был признан антифрод-системой как хостинг адрес, т.е. адрес на котором подключены сервера. Нам нужен так называемый резидентный IP. Т.е то, что считается домашним IP. Поэтому нужно проверять те прокси, которые мы покупаем, этот метод будет описан в следующей части.
Самое главное — чтобы ваш IP соответствовал или находился рядом с вашим DNS сервером.
Это одна из наиболее частых проблем при работе с прокси или другими методами переадресации (VPN, туннель) так называемый DNS leak или утечка DNS.
Что такое DNS?
Простыми словами: вы набираете в браузере google.ru, но в сети интернет все адреса состоят только из цифр. Сперва идет запрос к системе доменных имен – какой там адрес у google.ru, DNS выдает адрес, после чего ваш запрос уходит по адресу, все это делается за миллисекунды.
Вот что из этого получится:
Как видите, мой DNS сервер находится в Финляндии, а IP говорит, что я в Питере. Как результат, я сразу получаю 30 % риска от антифрод системы, т.к. мой IP и DNS значительно отличаются. На деле же вы можете купить прокси Новосибирска, DNS — в Питере. И все, вас взяли на карандаш.
Будьте внимательны на утечки DNS.
Куки
На сегодняшний день куки используются для идентификации на веб.ресурсах, чтоб вы каждый раз пароль не вводили, и как один из сотен показателей антифрод систем, позволяющих нас однозначно идентифицировать.
Есть ли смысл набивать cookies для эмуляции реальной личности?
Набивать cookies путем хаотичного посещения различных вебсайтов не имеет смысла по трем причинам:
1) На всех крупных ресурсах cookie файлы имеют флажок http-only, который означает, что cookie-файлы могут быть получены только в http-запросе. И не могут быть получены в javascript запросе. Соответственно, ваши cookie-файлы не могут быть получены другими ресурсами.
2) Если бы крупные сервисы, к примеру PayPal или Amazon, пытались получить ваши cookie-файлы, полученные от других ресурсов — это была бы чистой воды XSS атака. За такого рода действия сервисы, ее использующие, в лучшем случае, получили бы многомиллиардные штрафы. Поэтому делать так никто не будет.
3) Для того, чтобы оценить какие ресурсы посещал пользователь, не нужно получать его cookies, гораздо проще (и что самое главное законнее) получить данные напрямую из истории его браузера. Это решение очень элегантное, быстрое и не классифицируется как атака, а значит — легитимное.
Что же тогда помогает идентифицировать нас? Как работают антифрод-системы?
В современном мире способы браузерной идентификации пользователя достигли вершины своего развития. На первую роль вышли уникальные, характеристики вашей системы, до которых можно было дотянуться средствами браузера. Они состоят из десятков первостепенных и сотен второстепенных параметров, а всё вместе это — Browser fingerprint.
Фингерпринт (Fingerprint) – дословно отпечаток пальца.
Browser fingerprint, он же цифровой отпечаток браузера или, в некоторых случая, отпечаток цифрового устройства.
В сфере информационных технологии фингерпринтом принято называть возможность однозначно идентифицировать человека через его устройство, настройки, программное обеспечение и другие пользовательские характеристики.
Технологию фингерпринтинга можно трактовать, как существенную уязвимость в информационной безопасности. В то же время, как нарушение приватности и конфиденциальности пользователей.
В этом случае, Интернет-пользователя, можно однозначно идентифицировать без его ведома и согласия. А такое понятие как анонимность в Интернете, предоставляющие ощущение свободы, недосягаемости и безнаказанности окажется только мнимым, т. е. его просто не будет существовать.
Вы можете понять какую информацию выдает о вас ваш браузер, просто посетив следующие ресурсы:
А также, сотни других, однако далее я буду пользоваться сервисом f.vision
Вот, что показывает этот чудный сканер, когда я перехожу на него со своей рабочей машины:
Что мы видим:
Пойдем дальше. Видите браузер зеленым, а IP желтым?
Это значит, что антифрод-системе всё, вроде бы, нравится в параметрах моего браузера. Но IP, под которым я сижу, не дает ему покоя. Хотя я просто сижу дома, без каких либо технологий анонимизации.
Причина тому следующая, мой браузер передает то, что работает с языками – Русский и Английский. А, в свою очередь, IP только Русский. Также ситуация и с системой. Браузер говорит, что работает под Windows 7, а IP скрывает свою систему. Часто здесь написано Linux, т.к. почти все прокси подняты на Линукс серверах, ибо в разы дешевле и стабильнее.
Не думаю, что это очень важно, т.к. вот мой реальный пример, я просто сижу из дома, как и миллиарды других пользователей, которые знать не знают через какой там они сервер сидят в Инсте или ставят ставочку.
5.Хеши
Вот здесь-то начинается самое интересное. Представленные здесь хешы — те самые базовые уникальные параметры, которые однозначно идентифицирует вашу машину.
Создав ее слепок единожды (как бы вы не меняли IP, браузеры, чистили куки и прочее) запомнившая вас антифрод система узнает вас на раз-два.
5.1. HSTS – честно признаться, не то чтобы знаю, что делает этот параметр. На деле, что-то связанное с протоколом HTTPS, там все запутанно, но тем не менее это параметр идентификации.
5.2. WebGL – очень важный параметр инициализации вас.
Если говорить простыми словами, с помощью данного элемента можно через браузер взаимодействовать с вашей видеокартой, получая ее мощности и кучу информации. Включая ваш реальный IP, будьте вы хоть за тремя VPN сразу (да такое случалось, по рассказам с форумов). Также данный элемент однозначно идентифицирует вашу видеокарту. И пока вы ее не смените, вас всегда будет идентифицировать.
5.3. Canvas – великий и ужасный канвас, гроза всех обходчиков антифрода, элемент HTML 5.
Что говорит википедия:
Используется, как правило, для отрисовки графиков для статей и игрового поля в некоторых браузерных играх. Но также может использоваться для встраивания видео в страницу и создания полноценного плеера. Помимо этого, используется в WebGL для аппаратного ускорения 3D графики.
Ну и что скажите вы – ну рисует и рисует, больно нужная технология!
Так-то оно так, только эту штуковину стали использовать в антифрод-системах. Дело в том, что канвас, отрисовывается определенным образом при сочетании таких параметров как версия и сборка системы, ваша видеокарта и многих других.
По факту, чтобы его подделать надо действительно дать ту отрисовку, которая дает такая же система у другого пользователя. Уже имеющаяся в базе антифрода.
Вы же не пишете сами операционные системы и не паяете видеокарты, т.е. они унифицированы и условно у 30 Васей из 100 000 посетителей, был такой же слепок системы – винда 7, расширение такое-то, видеокарта такая-то, инвидеа гтх 950, к примеру.
Антифрод делает проверку канвас сверяет его с раннее полученным от 30 Вась, сходится — значит, все ок, система реальная, а вы — молодец. Не сходится – санкции, либо бан, либо вас берут на карандаш. Самое же плохое когда ваш канвас на 100% уникальный.
Представьте, база анифрод-системы из миллиона слепков параметров компьютеров и телефонов. Среди них всегда можно найти совпадение да не большую, вполне вероятно, но уникальность машин не выше 99% и тут появляетесь вы – весь из себя уникальный.
Вот что говорит об этом форум по безопасности:
Проще говоря, вас возьмут сразу на карандаш.
5.4. Plagins (Плагины) – каждый пользователь добавляет всякие плагины, расширения браузера. Зачастую, этот набор не индивидуален, но в купе с другими параметрами создает ваш фингерпринт.
5.5. Audio (еще этот фингерпринт называют Uber cookie – уберкуки). Это взаимодействие вашего браузера с вашей звуковой картой. Как работает точно, не знаю, но тоже представляет один из наборов параметров, который вас идентифицирует.
Аудио фингерпринтинг основывается на проверке аудио подсистемы вашего браузера при помощи AudioContext API.
Консорциум Всемирной Паутины (World Wide Web Consortium) дает следующее определение API:
Высокоуровневый JavaScript API для обработки и синтезирования аудио в веб-приложениях. Главный принцип заключается в наличии аудио графика, в котором объединен ряд AudioNode объектов для визуализации характеристик воспроизведения. Предполагается, что основная обработка будет производиться в базовой реализации (оптимизированный Assembly / C / C++ code), но также поддерживается прямая обработка и синтез в JavaScript
AudioContext отпечаток это хеш, производная аудио стека. Работает AudioContext таким образом, что веб-сайт запрашивает у браузера смоделировать синусоид основанный на результатах аудио стека вашего ПК. Полученный результат отправляется серверам и используется как энтропия в уникальной идентификации вашего ПК.
Вы можете проверить, как работает снятие отпечатка AudioContext на этой странице: CLICK
Технология использующаяся повсеместно, привнесет еще один штрих в вашу личность, DOM-модель одна из базовых.
5.7. Fonts (Шрифты) — Шрифт отпечатка пальца — это то, какие шрифты у вас есть, и как они нарисованы. Основываясь на измерении размеров заполненных текстовыми элементами HTML можно создать идентификатор, который можно использовать для отслеживания одного и того же браузера с течением времени. Фингерпринт с метрической меткой на основе шрифта плотно скрещен с отпечатком на холсте. Это, вероятно, более слабый метод отпечатка, поскольку холст получает не только ограничивающие прямоугольники, но и пиксельные данные. С другой стороны, такой отпечаток гораздо труднее защитить. Перевод текста — это тонкая и сложная часть веб-браузера. Некоторые системные записи еще более сложны, заставляя браузеры полагаться на библиотеки, предоставленные ОС для текстового макета. Эти библиотеки являются независимыми базами кода и не ведут себя одинаково. В том числе Pango на GNU / Linux, интерфейс графического устройства (GDI) или DirectWrite для Windows и Core Text в Mac OS X. Браузеры дополнительно накладывают свои собственные настройки поверх основного текстового рендеринга.
Ну что, появилось желание сделать шапочку из фольги?
5.7. TLS Fingerprint
Самый «непопулярный» отпечаток, который используется во большенстве сервисов google. Отпечаток TLS(SSL) также сообщит информацию о Вашем реальном браузере.
Тест — https://ja3er.com/
И это только базовые параметры. Если же вы нажмете «Start advanced test», то запустите расширенный тест. После чего, на вас вывалятся сотни параметров. Впрочем, они скорее интересны специалистам в области компьютерной безопасности, чем нам.
В случае оставшихся вопросов не забудь подписаться:
Больше годноты на канале — Довольный Арбитражник
Обсудить и задать вопросы в чате — Арбитраж трафика | Довольный
Использование TLS fingerprinting для выявления угроз
В статье хотим рассказать про технологию TLS fingerprinting, про которую недостаточно материалов в русскоязычном сегменте. Попробуем это исправить. Статья частично переводит тематические материалы авторов описываемых методов (тут и тут), а также содержит описание практической реализации от Акрибии.
Не будем глубоко погружаться в детали работы SSL/TLS (далее будем говорить TLS), но кратко поясним детали.
Использование TLS само по себе благо, так как с его помощью шифруются данные. Но с обратной стороны создатели вредоносов используют его же, чтобы скрываться в шифрованном трафике (в данной статье как раз будет уклон в эту сторону) и затруднять их обнаружение и нейтрализацию.
Чтобы инициировать сеанс TLS, клиент отправляет «пакет» приветствия серверу после трёхстороннего установления связи TCP. Этот «пакет» и способ его создания зависят от пакетов и методов шифрования, используемых при создании клиентского приложения. Если сервер принимает соединение TLS, он ответит пакетом приветствия, тем самым продолжая согласование шифрования.
Поскольку согласование шифрования TLS передаётся в открытом виде, то можно отследить и идентифицировать клиентские приложения.
В этом и суть технологии TLS fingerprinting, если кратко. А теперь немного подробнее.
TLS fingerprinting
Суть технологии в захвате элементов пакета приветствия клиента, которые остаются статичными от сеанса к сеансу для каждого клиента. На их основе можно создать «отпечаток пальца» для распознавания конкретного клиента в последующих сеансах. Записываются следующие поля:
Кроме того, данные собираются из трех конкретных расширений (если они доступны):
алгоритм для шифрования данных;
хэш функция для проверки содержимого.
Использование такого набора данных позволяет с большой точностью идентифицировать используемый клиент (например, браузер).
Пакет приветствия клиента — это первый пакет в любом TLS-соединении. Это позволяет принимать решение о последующих мерах в начале сеанса до того, как потребуется подмена протокола или эмуляция.
Можно захватывать пакеты приветствия клиента TLS с высокой степенью точности по всем портам с абсолютно нулевым требованием для захвата обоих направлений потока. Это означает, что датчики в среде с асимметричной маршрутизацией или с ограничениями ресурсов, потенциально вызывающими отбрасывание пакетов, все равно могут собирать пакеты приветствия клиента, независимо от того, были ли они скрыты из-за работы на нестандартных портах.
Пакеты приветствия клиента возникают достаточно редко, поэтому дополнительная обработка хэшей не повлечет значительных затрат.
Наиболее очевидное использование TLS Fingerprinting – пассивное обнаружение. Технология позволяет обнаруживать широкий спектр потенциально нежелательного трафика, не требуя доступа к конечным точкам. Можно обнаруживать как конкретные вредоносы по их поведению и/или обращениям к командным центрам, так и обычный софт, используемый не по назначению или в обход действующих правил.
Например, к серверу Exchange могут обращаться только почтовые клиенты или браузер, если используется OWA, поэтому соединение из скрипта на Python будет подозрительным.
Итого: TLS Fingerprinting предназначен для быстрой идентификации известных TLS-соединений и отслеживания неизвестных TLS-соединений. Входные данные принимаются либо посредством прослушивания трафика, либо при чтении PCAP файлов.
Есть несколько готовых реализаций, наиболее поддерживаемых комьюнити:
пассивный метод с использованием хэшей JA3 и JA3S;
активный инструмент снятия отпечатков пальцев с сервера TLS – хэши JARM.
JA3 и JA3S
Метод JA3 используется для сбора десятичных значений байтов для следующих полей в пакете приветствия клиента: версия TLS, набор шифров, список расширений протоколов TLS, эллиптические кривые и форматы эллиптических кривых. Затем он объединяет эти значения вместе по порядку, используя символ «,» для разграничения каждого поля и «-» для разграничения каждого значения в каждом поле.
Порядок полей следующий:
Если в ClientHello нет расширений TLS, поля остаются пустыми:
Эти строки затем хэшируются MD5. Пример отпечатка JA3:
JA3S – это хэш идентификации сервера. Метод JA3S заключается в сборе десятичных значений байтов для следующих полей в пакете приветствия сервера: версия TLS, набор шифров и список расширений протоколов TLS. После сбора значений, происходит процесс объединения этих значений вместе по порядку, используя «,» для разграничения каждого поля и «-» для разграничения каждого значения в каждом поле.
Порядок полей, следующий:
Если в Server Hello нет расширений TLS, поля остаются пустыми.
Эти строки затем хэшируются MD5 для создания 32-символьного отпечатка пальца.
Это отпечаток JA3S:
JA3 и JA3S – это методы снятия отпечатков TLS. JA3 отслеживает способ, которым клиентское приложение обменивается данными через TLS, а JA3S отслеживает ответ сервера. Вместе они создают отпечаток криптографического согласования между клиентом и сервером.
Теперь перейдем к описанию активного метода JARM.
JARM работает, активно отправляя 10 пакетов приветствия клиента TLS на целевой сервер и фиксируя определенные атрибуты ответов приветствия сервера. Затем агрегированные ответы сервера TLS хэшируются определенным образом для получения отпечатка JARM. JARM отправляет разные версии, шифры и расширения TLS в разном порядке для сбора уникальных ответов. Хэш JARM представляет собой гибридный нечеткий хэш, он использует комбинацию обратимого и необратимого алгоритма хеширования для создания 62-символьного отпечатка.
Отпечатки JARM можно использовать:
убедиться, что все серверы в группе имеют одинаковую конфигурацию TLS;
сгруппировать разрозненные серверы в сети Интернет по конфигурации, указав, например, что сервер может принадлежать Google, Yandex или Apple;
определить приложения или инфраструктуру по умолчанию;
выявить командные центры и других вредоносные серверы в сети Интернет.
Первые 30 символов состоят из шифра и версии TLS, выбранных сервером для каждого из 10 отправленных приветствий клиента. «000» означает, что сервер отказался согласовывать приветствие с этим клиентом. Остальные 32 символа представляют собой усеченный хэш SHA256 совокупных расширений, отправленных сервером, без учета данных сертификата x509. При сравнении отпечатков JARM, если первые 30 символов совпадают, но последние 32 отличаются, это будет означать, что серверы имеют очень похожие конфигурации, принимают одинаковые версии и шифры, но используют различные расширения, что не позволяет их считать полностью идентичными.
Исторически так сложилось, что индустрия кибербезопасности была сосредоточена в основном на индикаторах компрометации (IOC) и индикаторах атаки (IOA). То есть когда вредоносное ПО/хост и т.п. будут кем-то обнаружены, исследователи или вендоры платформ TI вычленяют уникальные или не очень признаки выявленного вредоноса или атаки типа IP, домена, хэша файла и т.п. и публикуют их в «чёрных списках». Проблема в том, что к этому моменту вредоносное ПО уже распространено, и специалисты ИБ автоматически переходят в оборону.
Интернет-сканирование JARM в сочетании с другими метаданными и историческим анализом даёт возможность упреждающей идентификации IOC для новых вредоносов. Например, можно сканировать Интернет с помощью JARM, сопоставлять известные результаты JARM с историей домена, IP и репутацией вместе с данными сертификата для создания черного списка. Это позволяет перейти к возможности программного создания высокоточных списков блокировки до того, как первая вредоносная программа будет распространена.
Можно использовать JARM автоматически сканируя все хосты назначения, детектируемые в сети компании, для обогащения событий, и использовать сводную таблицу, чтобы не сканировать одни и те же хосты несколько раз. Затем можно запускать запросы заведомо плохих JARM или использовать список для корреляции.
Чтобы упростить процесс, можно использовать готовое решение. В настоящее время хэши JARM умеют считать продукты Palo Alto Networks и используют их API для обогащения целевого JARM.
Примеры реализации
Если нет возможности или желания использовать готовые решения от Palo Alto и пр., можно реализовать в своей инфраструктуре свое средство мониторинга трафика, например, на основе Zeek (ранее назывался Bro) – популярного open-source продукта, заточенного специально для этого.
Zeek собирает огромное количество информации из первоначального согласования TLS, т.к. оно обрабатывается в открытом виде. Таким образом, хотя мы не можем видеть всё, что связано с шифрованием TLS, мы всё же можем получить общее представление о том, что происходит.
Zeek умеет выполнять снятие отпечатков TLS с помощью хэша JA3\JA3S.
Если у нас уже есть Zeek, в него попадает трафик, то для полноценного мониторинга нам понадобится SIEM (можно обойтись и без SIEM, но тогда обрабатывать логи Zeek’а придется вручную). Допустим, SIEM у нас все же есть. Помимо инструментов обработки трафика и событий Zeek нам еще потребуются списки готовых хэшей, чтобы было с чем сравнивать.
В случае в JA3 – все просто. Есть готовый инструмент, к которому можно обращаться по API для проверки выявленного хэша JA3 и принятия решения – нормально это или не очень.
Хэши JA3S, соответствующие вредоносам, достать чуть сложнее. Есть, например, небольшая подборка тут, есть и еще, нужно только искать или считать самостоятельно.
С хешами JARM еще немного сложнее, если у вас нет Palo Alto, их нужно собирать по разрозненным отчетам аналитиков или считать самостоятельно и вести собственные белые и черные списки. Но на github тоже попадаются тематические подборки, например, эта. Мы ее задействуем в дальнейшем при проработке правил по JARM.
Далее приведем некоторые описания правил, которые мы реализуем у себя. Также есть неплохой доклад от Splunk с примерами алгоритмов и правил мониторинга по хэшам JA3/JA3S. Доступен здесь. Правила можно адаптировать под любую SIEM.
Выявление признака конкретного вредоноса по хэшам JA3\JA3S. Вот, например, готовые значения для Emotet и TrickBot:
Выявления нового хэша JA3, ранее не появляющегося в сети.
Список клиентского ПО в любой сети, как правило, достаточно статичен, и, если появится что-то новенькое – это однозначно повод разобраться. Правда, это может быть новая версия уже известного ПО, тогда ее нужно добавить в белый список.
Выявления хэшей JA3 не из белого списка.
Общее правило, которое позволит обратить внимание на любую активность, которая явно не помечена заранее как разрешенная. Сюда могут попасть, как новые ранее неизвестные клиентские устройства или приложения, так и вредоносы, попавшие к вам в сеть. В любом случае – трекать это стоит.
Выявления хэшей JA3\JA3S из чёрного списка.
Это правило нацелено на выявление хэшей заведомо вредоносного ПО.
Выявление обращений к C&C по хэшам JARM.
При выявлении обращения к TLS-серверу, неизвестному нам или ранее не появляющемуся в логах, необходимо посчитать его JARM хэш (можно вручную, можно скриптом или с использованием SOAR), при совпадении с хэшем, соответствующим известному C&C серверу, блокируем соединение, изолируем хост и расследуем инцидент.
Выявление JA3 хэшей, не характерных для системы.
При появлении на хостах с Windows JA3 хэшей, характерных для Linux или смартфонов (Android/IOS), стоит обратить внимание на такие хосты. Это может являться признаком работы вредоносов (ну или запущенного эмулятора/виртуалки в режиме NAT). Кейс особенно заслуживает внимание, если выявлен на рабочей станции обычного пользователя, далекого от мира IT.
Выявление JA3 хэшей, характерных для разных браузеров одного семейства.
Сейчас достаточно сложно на один хост поставить две разные версии Firefox или Chrome (виртуальные машины в режиме NAT не в счёт). Такое выявление может свидетельствовать о том, что злоумышленники пытались адаптироваться под установленный софт, но после обновления софта не успели или забыли обновить свой Fingerprint. Хост лучше изолировать и провести расследование.
Выявление JA3 хэшей, характерных для популярных сетевых библиотек языков программирования.
Ни для кого не секрет, что сейчас ВПО пишется не только на C/C++. Часто встречаются образцы, которые написаны на Python или Golang. Стандартные библиотеки, такие как requests (для python) или http (для Golang), имеют характерные отпечатки в рамках нескольких версий. В случае выявления такого хэша на рабочем месте разработчиков, вероятно, это нормально. Но, если хэши «всплывут» на рабочем компьютере рядового пользователя, то точно следует провести тщательную проверку, так как с большой вероятностью это будет свидетельством активности вредоноса. Также стоит поддерживать списки актуальных JA3 хэшей для популярных сетевых библиотек, чтобы минимизировать ложные срабатывания.
Важно: Список хэшей JARM (и JA3S тоже) необходимо регулярно пополнять новыми выявленными C&C серверами, полученную самостоятельно или от сторонних исследователей.
При использовании средств защиты сети, которые умеют вычислять хэши JARM самостоятельно и на лету, соединения с серверами из черных списков можно и нужно блокировать автоматически.
В завершении хотим подчеркнуть, что развитие и популяризация технологии TLS Fingerprinting, по нашему мнению, совсем не за горами, и способствует этому внедрение TLS 1.3.
В версиях стандарта TLS до 1.3 у клиента была возможность сообщать, к какому серверу он хочет обратиться — SNI (Server Name Indication). Чаще всего в HTTPS для этого использовалось поле HOST, чтобы на одном IP и порту могли работать несколько HTTPS-сайтов. Соответственно и так, без всяких fingerprint, было видно, кто куда идет. Понятно, что речь идёт про легитимные обращения, атакующие всегда могли подделать SNI.
В стандарте TLS 1.3 появилась возможность шифровать имя запрашиваемого сайта – Encrypted SNI (ESNI), и безопасники потеряли возможность видеть, куда идёт обращение.
Правда ESNI уже запретили в Китае, и были попытки блокировок в России. Однако ESNI стал часто встречаться, в том числе в инструментах злоумышленников, и без TLS fingerprinting становится сложно понимать, куда происходят обращения в сети.
Авторы статьи:
Михаил Кравченко, SOC-аналитик;
Александр Минин, руководитель направления Threat Intelligence @AAMinin;
Анна Шестакова, руководитель направления мониторинга ИБ.