Атаки на браузеры являются достаточно популярным вектором для злоумышленников, которые через различные уязвимости в программах для серфинга в Интернете или через слабо защищенные плагины к ним пытаются проникать внутрь корпоративных и ведомственных сетей. Начинается это обычно на вполне легальных и даже внесенных в белые списки сайтах, которые при этом имеют уязвимости, используемые злоумышленниками. Дополнения (add-on), расширения (extensions), плагины (plugin), будучи однажды установленными даже в благих целях, начинают мониторить пользовательскую активность, “сливать” разработчикам историю посещенных сайтов, внедрять в посещаемые страницы назойливую рекламу, иногда вредоносную. Пользователи часто даже не понимают, что рекламный банер, который они видят на странице сайта, добавлен ими же установленным плагином, а не является изначально внедренным на странице. А иногда такие плагины и расширения и вовсе служат входной дверью для злоумышленников на компьютеры пользователей, с которых начинается победное шествие по внутренней сети предприятия. Именно через такие расширения злоумышленники могут устанавливать вредоносный код, отслеживать данных или красть их. При этом не всегда мы в состоянии заставить всех пользователей правильно настраивать свои браузеры и следить за их конфигурацией. Что же делать в такой ситуации, когда всего один пользователь может стать самым слабым звеном и открыть “ворота в ад”? Решения по мониторингу сетевого трафика могут помочь и в данном кейсе.
Одно из исследовательских подразделений Cisco, Cisco Cognitive Intelligence, которое появилось у нас после покупки много лет назад чешской компании Cognitive Security, выявило, что многие вредоносные плагины к браузерам имеют уникальные характеристики, которые можно выявлять и отслеживать в рамках анализа именно сетевого трафика. Единственное отличие, которое присутствует по сравнению с предыдущими тремя рассмотренными ранее кейсами (обнаружение утечек, вредоносного кода и кампании DNSpionage) — чтобы детектить активность плагинов, внедряющих рекламу, на показе которой зарабатывают злоумышленники, или сливающих ваши данные, вам надо либо самостоятельно провести большое исследование (мы потратили около года на анализ нескольких тысяч плагинов, чтобы выявить шаблоны поведения и описать их), либо довериться производителю решения класса NTA, который содержит в себе такую возможность.
Вот как выглядит такая возможность в решении Cisco Stealthwatch. Мы видим, что с двух адресов внутренней сети с адресами 10.201.3.45 и 10.201.3.108 фиксируется активность, связанная с накрутками кликов (click fraud), внедрением рекламы в страницы (Ad injection), вредоносной рекламой.
Очевидно, что мы хотим провести расследование данной активности:
Мы видим, что узел в корпоративной сети взаимодействует с доменом, расположенном на легальном Amazon (поэтому заблокировать по IP-адресу не получится; если вы не Роскомнадзор, конечно). Однако применение различных алгоритмов машинного обучения к трафику показывает, что эта активность именно вредоносная.
Еще более глубокое погружение позволяет нам понять еще больше деталей по угрозе.
Например, кейс #CADP01 связан с вредоносным кодом AdPeak, который внедряет дополнительную рекламу в посещаемые Web-страницы и за их показ злоумышленники зарабатывают деньги.
Кейс #CDPY01 связан с потенциально нежелательным приложением, которое внедряет рекламу в сессию браузера и может привести к последующему заражению компьютера.
Так как выявление вредоносной активности браузера может быть признаком уже случившегося заражения, нам необходимо провести расследование, которое покажет, с кем взаимодействует в нашей сети скомпрометированный узел, что это за узел, какова его роль, какой пользователь за ним работает и т.п.
Например, упомянутый узел 10.201.3.45 относится к группе Development (развитие или разработка ПО). Мы также видим все ассоциированные с данным узлом потоки данных и основные события безопасности.
Интересно, что чаще всего интересующий нас узел взаимодействует с локальными DNS-серверами, что наводит на мысли о возможной атаке на DNS или через DNS (вспомним о DNSpionage или Sea Turtle, описанных в прошлой заметке).
Что мы видим в списке событий безопасности? Flow Denied. Что это такое? Ответ на этот вопрос сильно зависит от контекста, так как соединения внутренних узлов с внутренними сильно отличаются от соединения внутренних узлов с внешними, и может означать совсем разное. Например, если у внутреннего узла много запрещенных соединений (потоков) с внутренним ресурсом через один и тот же порт, то, вероятно, это неверная конфигурация какого-либо приложения. Множество запрещенных потоков с различным портам или внутренним узлам, говорит, скорее всего, о разведке, одном из первых этапов в рамках любой атаки. Заблокированные потоки изнутри к внешним Интернет-узлам могут характеризовать работу вредоносного кода, утилит удаленного доступа (RAT), утечку информации и много других “интересных” событий, которые определены вашей политикой безопасности как запрещенные. И коль скоро они выявляются вашей системой анализа сетевого трафика, то значит, что-то у вас не так.
Этот кейс интересен тем, что он немного меняет взгляд на возможности систем класса NTA, которые опираются на анализ Netflow (или иных flow-протоколов) в своей работе. Видно, что такие системы способны не только работать на сетевом уровне, но и позволяют подняться нам гораздо выше и выявлять атаки на прикладном уровне, которые далеко не всегда видны межсетевому экрану или даже средствам защиты оконечных устройств.
Одно из исследовательских подразделений Cisco, Cisco Cognitive Intelligence, которое появилось у нас после покупки много лет назад чешской компании Cognitive Security, выявило, что многие вредоносные плагины к браузерам имеют уникальные характеристики, которые можно выявлять и отслеживать в рамках анализа именно сетевого трафика. Единственное отличие, которое присутствует по сравнению с предыдущими тремя рассмотренными ранее кейсами (обнаружение утечек, вредоносного кода и кампании DNSpionage) — чтобы детектить активность плагинов, внедряющих рекламу, на показе которой зарабатывают злоумышленники, или сливающих ваши данные, вам надо либо самостоятельно провести большое исследование (мы потратили около года на анализ нескольких тысяч плагинов, чтобы выявить шаблоны поведения и описать их), либо довериться производителю решения класса NTA, который содержит в себе такую возможность.
Вот как выглядит такая возможность в решении Cisco Stealthwatch. Мы видим, что с двух адресов внутренней сети с адресами 10.201.3.45 и 10.201.3.108 фиксируется активность, связанная с накрутками кликов (click fraud), внедрением рекламы в страницы (Ad injection), вредоносной рекламой.
Очевидно, что мы хотим провести расследование данной активности:
Мы видим, что узел в корпоративной сети взаимодействует с доменом, расположенном на легальном Amazon (поэтому заблокировать по IP-адресу не получится; если вы не Роскомнадзор, конечно). Однако применение различных алгоритмов машинного обучения к трафику показывает, что эта активность именно вредоносная.
Еще более глубокое погружение позволяет нам понять еще больше деталей по угрозе.
Например, кейс #CADP01 связан с вредоносным кодом AdPeak, который внедряет дополнительную рекламу в посещаемые Web-страницы и за их показ злоумышленники зарабатывают деньги.
Кейс #CDPY01 связан с потенциально нежелательным приложением, которое внедряет рекламу в сессию браузера и может привести к последующему заражению компьютера.
Так как выявление вредоносной активности браузера может быть признаком уже случившегося заражения, нам необходимо провести расследование, которое покажет, с кем взаимодействует в нашей сети скомпрометированный узел, что это за узел, какова его роль, какой пользователь за ним работает и т.п.
Например, упомянутый узел 10.201.3.45 относится к группе Development (развитие или разработка ПО). Мы также видим все ассоциированные с данным узлом потоки данных и основные события безопасности.
Интересно, что чаще всего интересующий нас узел взаимодействует с локальными DNS-серверами, что наводит на мысли о возможной атаке на DNS или через DNS (вспомним о DNSpionage или Sea Turtle, описанных в прошлой заметке).
Что мы видим в списке событий безопасности? Flow Denied. Что это такое? Ответ на этот вопрос сильно зависит от контекста, так как соединения внутренних узлов с внутренними сильно отличаются от соединения внутренних узлов с внешними, и может означать совсем разное. Например, если у внутреннего узла много запрещенных соединений (потоков) с внутренним ресурсом через один и тот же порт, то, вероятно, это неверная конфигурация какого-либо приложения. Множество запрещенных потоков с различным портам или внутренним узлам, говорит, скорее всего, о разведке, одном из первых этапов в рамках любой атаки. Заблокированные потоки изнутри к внешним Интернет-узлам могут характеризовать работу вредоносного кода, утилит удаленного доступа (RAT), утечку информации и много других “интересных” событий, которые определены вашей политикой безопасности как запрещенные. И коль скоро они выявляются вашей системой анализа сетевого трафика, то значит, что-то у вас не так.
Этот кейс интересен тем, что он немного меняет взгляд на возможности систем класса NTA, которые опираются на анализ Netflow (или иных flow-протоколов) в своей работе. Видно, что такие системы способны не только работать на сетевом уровне, но и позволяют подняться нам гораздо выше и выявлять атаки на прикладном уровне, которые далеко не всегда видны межсетевому экрану или даже средствам защиты оконечных устройств.
