Обнаружение известного вредоносного кода в зашифрованном с помощью TLS трафике (без дешифровки)

    В данной статье рассматривается работа группы исследователей компании Cisco, доказывающая применимость традиционных методов статистического и поведенческого анализа для обнаружения и атрибуции вредоносного ПО, использующего TLS в качестве метода шифрования каналов взаимодействия, без дешифровки или компрометации TLS-сессии, а также описание решения Encrypted Traffic Analytics, реализующая принципы, заложенные в данном исследовании.

    Повсеместное использование протокола TLS вредоносным ПО создало новые проблемы для средств защиты, так как традиционные методы обнаружения поиском по шаблону (сигнатуре) неприменимы в данном случае. Тем не менее, TLS всё ещё имеет целый набор доступных стороннему наблюдателю возможностей, которые могут быть использованы для поиска вредоносного ПО как при анализе трафика со стороны клиента, на котором запускается зашифрованное соединение, так и анализируя обращения к серверу, к которому строится зашифрованный туннель. При этом мы можем анализировать только установление защищённого соединения, без доступа в передаваемую конфиденциальную информацию, и без расшифровки последней. В большинстве случаев такой анализ позволяет сделать довольно точную атрибуцию устанавливаемого соединения на принадлежность к тому или иному семейству ВПО, даже если мы имеем дело с единственным полностью зашифрованным соединением. Чтобы проверить эту гипотезу группа сотрудников Cisco — Blake Anderson, Subharthi Paul, David McGrew, провела детальное исследование «Deciphering Malware's use of TLS (without Decryption)», препринт работы свободно доступен по адресу arxiv.org/abs/1607.01639, каким именно образом вредоносные и корпоративные приложения используют TLS. Был проведён анализ нескольких миллионов зашифрованных с помощью TLS соединений, проверена возможность атрибуции 18 семейств ВПО использующих тысячи уникальных образцов ВПО и десятки тысяч вредоносных TLS-соединений. Одним из важнейших результатов данной работы была проверка корректности работы механизмов обнаружения «песочниц» и других используемых инструментов анализа.

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

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

    Как и откуда мы можем получить эту информацию? Мы можем собрать её непосредственно на сетевых устройствах, коммутаторах и маршрутизаторах, которые позволяют собирать сетевую телеметрию (несемплированный Netflow/IPFIX) для анализа информации о соединениях, а также передать для анализа первый пакет инициализации зашифрованного TLS-соединения (Initial Data Packet, IDP), для анализа TLS-метаданных. Также мы можем собрать сопутствующую информацию о DNS и HTTP-запросах, для повышения точности обнаружения и снижения числа ошибок и информацию о глобальной репутации или подозрительном поведении на основании информации из облачного центра репутации.

    image

    Архитектура решения выглядит следующим образом:

    image

    В качестве примера использования данной технологии в целях сбора информации об используемых криптографических параметрах (соответствие требованиям регуляторов, например, для аудита соответствия PCI-DSS):

    image

    Обнаружение вредоносного ПО (информация из глобального облачного центра Cisco Cognitive Analytics, CTA):

    image

    Обнаружение вредоносного ПО (корреляция глобальной и локальной информации):

    image

    Пример расследования инцидента:

    image

    Подтверждённая угроза:

    image

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

    Наконец, мы продемонстрировали, что атрибуция известного вредоносного ПО может быть сделана только на основе анализа сетевого трафика без расшифровки TLS-соединения.

    Была достигнута точность обнаружения в 90.3% при атрибуции семейства ВПО, в случае, когда мы ограничены единственным зашифрованным соединением, и точность в 93.2% при анализе всех доступных зашифрованных соединений в рамках пятиминутного окна анализа. Для анализа первых пяти минут активности известных образцов ВПО использовалась система динамического анализа Cisco ThreatGrid. Были собраны десятки тысяч уникальных образцов вредоносного ПО, и проанализированы их сотни тысяч вредоносных, зашифрованных соединений. Была собрана телеметрия о миллионах зашифрованных TLS соединений в корпоративных сетях, для сравнения с телеметрией, сгенерированной вредоносными соединениями.

    Был разработан открытый инструментарий для эффективного сбора и предварительной обработки и конвертации в JSON сетевой телеметрии (проект Joy), собирающий всю необходимую для анализа информацию — IP источника и назначения, порты источника и назначения, протоколы, частотно-временные характеристики передаваемых размеров пакетов, частотное побайтное распределение и энтропию, незашифрованную информацию об установлении TLS-соединения. Весь анализ производится только на уровне сети, без необходимости установки каких-либо агентов на оконечных устройствах.

    Дополнительные материалы:
    Скачать официальный отчет Cisco по аналитике зашифрованного трафика
    Cisco 110,24
    Cisco – мировой лидер в области сетевых технологий
    Поделиться публикацией
    Комментарии 31
    • 0
      Заголовок неправильный, вы с TLS ничего не делаете и сделать не можете. Вы анализируете только открытую часть трафика. Зачем эта джинса?
      • 0
        Заголовок корректный относительно приведенного в статье оригинального документа. В целом, на удивление хороший материал; увы, для узкого круга иссоедователей и имеющий ограниченную временную применимость.
        • +3
          Заголовок абсолютно корректный и отражает суть проделанной работы и используемых технологий — использование только SPLT (частотно-временные характеристики размеров пакетов), BD/BE (побайтное распределение/энтропия) для многих семейств вредоносов уже даёт точность порядка 70% и выше.
          image

          Общее представление о точности той или иной комбинации можно посмотреть тут (первая колонка — точность обнаружения, вторая — инвертированный false detect rate, для получения привычной частоты ложных срабатываний обоих родов вычтите из 100% цифру из второй колонки):
          image
        • 0
          Простите, я немного не понял.
          То есть для исследования был использован корпоративный (!!!) трафик (пусть и нерасшифрованный по Вашим словам) пользователей коммутаторов, маршрутизаторов и сетевых устройств Cisco в рамках программы телеметрии?
          Я правильно всё изложил?
          • +1

            Ну, отчет Касперского о том, что 23% россиян заклеивают веб-камеру, из той же оперы ;)

            • –1
              Простите, но очень хотелось бы получить ответ от автора.
            • +1
              Использовалась телеметрия из нескольких офисов Cisco, конечно же, насколько мне известно. У нас довольно большая территориально-распределённая сеть разных офисов, так что для моделирования они подходят неплохо.
              • 0
                Спасибо за ответ.
                Мне кажется, об этом стоило бы указать в статье прямо, потому что я по прочтении как-то совсем разочаровался в продукции Cisco.
                Вы это разочарование развеяли, правда, «насколько мне известно» осадочек оставляет :)

                А если кроме шуток, то в свете найденных NSA-админок и бэкдоров в роутерах Cisco любая информация о телеметрии и анализе трафика весьма настораживает.

                Никак официально не прокомментируете?
                • +1
                  (к CISCO отношения не имею, просто высказать свое понимание материала)
                  Насколько понял, тут под телеметрией назван Netflow/IPFIX — суть отключаемые вещи, вы их можете и не отдавать, если не хотите, чтобы «на стороне» кто-то смотрел трафик. Основной посыл статьи, опять же, с моего видения — для качественного детекта имеющегося в корп. сети ВПО можно просто проанализировать куда ВПО стучится, с какой частотой и т.д., а далее использовать любой Threat Intelligence сервис на предмет сопоставления собранных данных с уже известными. Т.е. при желании вы можете у себя все это сами организовать на отдельной железке, завернув туда netflow, настроить, к примеру, splunk и подключив TI. Только это долго и с непонятным результатом, а тут предлагается решение «из коробки», хотя и с передачей части данных трафика «на сторону». Насколько целесообразна такая передача трафика для конкретной организации — решать уже вам как CISO.
                  • 0
                    Именно так, только ещё нужно написать свои классификаторы, а чтобы их написать — нужны образцы трафика ВПО и легитимных приложений, плюс понимание что искать.
                  • 0
                    Телеметрия анализируется локально (в Stealthwatch — habrahabr.ru/company/cisco/blog/229073 ), наружу отдаётся только то, на чём можно сделать глобальную корреляцию (и то, если это явно настроить). Отдаётся информация о внешних IP, хэшах ВПО, FQDN-имена запрашиваемых сайтов — для того чтобы понять инфраструктуру вредоноса.
              • –1
                Ждите от зловредов добавления рандомного наполнителя трафика, нивелирующего частотно-временной анализ пакетов :)
                • 0
                  Это не так просто сделать, как кажется на первый взгляд, плюс это само по себе является хорошим индикатором для систем статического и динамического анализа — легитимное ПО так не делает.
                  • –1
                    Это легко сделать и применяется в некоторых приложениях уже. ЕМНИП, например в ssh.
                  • 0
                    Нужно не просто рандомно добавлять наполнение — нужно его добавлять таким образом, чтобы в сумме получалось похоже на имитируемое приложение.
                    • –1
                      Нет, достаточно чтобы ни на что не было похоже. Не существует базы статистических характеристик трафика всех существующих приложений.
                      • 0
                        Существует, и не одна. Более того, сделать свою базу (для своей компании) вполне посильная задача, полно open-source инструментов. Есть и целый класс коммерческих решений Network Behavior Anomaly Detection — en.wikipedia.org/wiki/Network_Behavior_Anomaly_Detection
                        • –1
                          То, на что вы ссылаетесь, осуществляет сигнатурный анализ сетевых пакетов, т.е. функция аналогична функции файлового антивируса. Для пакетов с шифрованием неприменима. Без сигнатур такие решения могут лишь набрать статистику в режиме обучения и следить в дальнейшем за их отклонениями, т.е. неприменима для нового программного обеспечения (а вредонос таковым и является). Именно потому, что «Не существует базы статистических характеристик трафика всех существующих приложений.» Принципиально такого существовать не может, поэтому нельзя определить вредонос по отсутствию его в такой мифической базе.
                          • 0
                            Никаких сигнатур там нет — есть анализ поведения и/или аномалий. Можно, конечно и их назвать сигнатурами второго порядка, но это уже терминологические дебаты. Работает это следующим образом — строятся базовые линии поведения для заданных временных интервалов (например, минута/ 5 минут/ 30 минут/ час / неделя и т.д.), для них ищем аномалии для заданной группы хостов, либо ищем поведение, характерное для вредоносов. Про новое ПО в статье нет ни слова, более того, написано что это работает для известного ВПО.
                            • –1
                              Никаких сигнатур там нет

                              А как вы это понимаете?
                              Most security monitoring systems utilize a signature-based approach to detect threats. They generally monitor packets on the network and look for patterns in the packets which match their database of signatures representing pre-identified known security threats. NBAD-based systems are particularly helpful in detecting security threat vectors in 2 instances where signature-based systems cannot (i) new zero-day attacks (ii) when the threat traffic is encrypted such as the command and control channel for certain Botnets.

                              In order for NBAD to be optimally effective, a baseline of normal network or user behavior must be established over a period of time.
                              • –1
                                «Большинство систем мониторинга (безопасности) используют сигнатурный подход для обнаружения угроз. Обычно они мониторят содержимое сетевых пакетов и ищут шаблоны, которые в их базе данных шаблонов представляют заранее идентифицированные, известные угрозы. NBAD-системы в большей степени полезны в обнаружении векторов угроз в двух случаях, когда системы, использующие сигнатурный подход не могут [обнаружить] новые, неизвестные ранее атаки, когда трафик угрозы идёт по зашифрованному каналу, как происходит в случае каналов контроля и управления [вредоносного ПО] для некоторых ботнетов».
                                «Для того, чтобы NBAD был максимально эффективен, необходимо использовать базовые линии нормального сетевого или пользовательского поведения, которые должны вычисляться на протяжении определённого временного периода».
                                И где тут сказано, что NBAD использует сигнатуры?
                                • –1
                                  Нда, я некорректно прочитал. NBAD не использует сигнатурный анализ, они применимы только для софта, который сначала устанавливают, а затем в режиме обучения набирается статистика. То есть неприменимы к новому софту «изкаропки», нужен период когда софт заведомо работает правильно. Потому что не существует баз готовой статистики «правильного трафика» для произвольного существующего софта. Итого, NBAD неприменимы для обнаружения зловредов без применения дополнительно систем с сигнатурным анализом. Таким образом, зловред (троян) использующий шифрование и рандомизацию трафика для размытия частотно-временных характеристик своих пакетов становится невидим как для сетевых антивирусных решений с сигнатурным анализом пакетов, так и для NBAD систем.
                                  • 0
                                    Именно для решения данной проблемы и используется глобальная репутация — мы видим обращения к нетипичным внешним IP/FQDN и смотрим их репутацию (плюс известную нам из TALOS корреляцию c инфраструктурой ботнетов). Обойти все три технологии обнаружения одновременно можно, но крайне трудозатратно и дорого.
                          • 0
                            А можно про open-source инструменты чуть подробнее? Snort вроде несколько про другое, как я понимаю, а что еще есть разумное и рабочее в этом контексте?
                            • 0
                              Алексей Лукацкий писал про них недавно на Хабре — habrahabr.ru/company/cisco/blog/346160
                              • 0
                                Инструмент, который использовали авторы — github.com/cisco/joy
                                В решении ETA функции сбора телеметрии (локально в сети, с помощью виртуальных или аппаратных коллекторов) делает Stealthwatch, он же запрашивает глобальную систему репутации Cognitive Threat Analytics об репутации и взаимосвязи внешних элементов (внешние IP, к которым шли необычные обращения, SHA256 хэши файловых образцов, если используется Cisco AMP, запрашиваемые во внешний мир подозрительные URL и FQDN). CTA требует явной настройки и по умолчанию выключен.
                      • 0
                        Обнаружим-не обнаружим, а «телеметрию» (не принадлежащие компании данные) соберем, мало ли для чего ещё пригодится.
                        • 0
                          Телеметрия собирается локально, на сенсоры, установленные в сети. Не хотите делать глобальную корреляцию — никто не заставляет, по умолчанию она выключена.
                        • 0
                          Вот бы к снорту или сурикате правила запилили.
                          • 0
                            Для зашифрованного трафика? Боюсь, для этого надо написать препроцессор, по сложности сопоставимый с самим Snort.
                          • +1
                            Есть такие правила, для SURICATA например. Обнаруживают TOR, по корреляциям в длинах фрагментов TLS. lists.emergingthreats.net/pipermail/emerging-sigs/2017-October/028439.html

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое