Охота на угрозы @BIS SUMMIT

23.09 на конференции за 20 минут знакомил аудиторию с проблематикой Threat hunting-а. Тема обширная, говорить о ней можно значительно дольше, поэтому в отведенный тайм-слот имел цель донести почему это нужно и важно. 
Основная мысль презентации выражается примерно в следующем. 
Для того, чтобы сделать сигнатуру защиты от угрозы, необходимо эту угрозу сначала найти и проанализировать. Традиционно компании, занимающиеся исследования в области ИБ и предоставляющие своим клиентам защиту от угроз, вынуждены искать их in the wild. В случае APT поиск ITW зачастую невозможен (ну, как минимум, не очень эффективен), так как ВПО и прочие TTP, используемые в APT-кампаниях отличаются высокой кастомизацией. Именно поэтому для защиты корпорации от кастомизированных атак, необходимо уметь искать угрозы (== Threat hunting) не ITW, а непосредственно в корпоративной инфраструктуре. ТН не является простой задачей, поскольку для этого нужны специализированные инструменты, процессы, опытный персонал. Понятно, что компания, занимающаяся поиском угроз ITW и обеспечивающая для своих продуктов удовлетворительное качество обнаружения/зашиты, сконцентрировав всю мощь своего ТН на конкретной инфраструктуре конкретного предприятия, покажет еще больший Detect rate, ибо законы сохранения работают и здесь: с уменьшением объема анализа, уровень выявления повышается.
К сожалению, природа Человека такова, что ему сложно верить в то, что он понимает плохо, поэтому в презентацию были добавлены несколько тяжелых слайдов о том, как работает ТН изнутри в надежде на то, что эта вершина айсберга будет иметь положительный эффект: усилит веру в ТН и, в то же время, не загрузит окончательно, создав противоположный эффект в виде отвращения.
В завершение были приведены пара обфусцированных случаев из практики - как они были обнаружены и расследованы, несмотря на то, что в одном вовсе не применялось ВПО, а в другом использовались образцы, не обнаруживаемые на момент проведения расследования.
Я искренне надеюсь, что мне удалось просто рассказать о сложном - еще со времен института я считаю эту способность наивысшей добродетелью преподавателя, так как именно это способствует разжиганию того самого интереса аудитории, на котором впоследствии можно добиться небывалых результатов в понимании предметной области. 

Update 31.03.2017
1. Выкладываю презентацию

Охота на угрозы на BIS summit 2016 from Sergey Soldatov

2. Про то же самое еще есть статья в журнале БДИ.

Классификация инцидентов

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

С операционной точки зрения пользой может быть тот самый "triage", необходимый для приоритезации усилий, а при постфактумном анализе, скажем, за квартал, - поможет понять сколько инцидентов какой Критичности, или, если хотите, Приоритета, у меня было за период, чтобы планировать ресурсы на мой Incident Response в будущие периоды более осмысленно, чем ППП.

Проблема всех попадающихся в Google классификаций в том, что они нередко дают противоречивые результаты, что позволяет одному аналитику получить уровень High, другому - Low, и при этом каждому быть правым. Вот давайте попробуем по этому классифицировать это. Если это просто малварь, тогда - Low-Medium, если же это APT, то надо считать High. Причем, все еще интереснее, так как пока это не было исследовано - это было APT, а когда это разобрали и добавили детекты - это уже обычное ВПО :), но не будем этим загружаться.

Следующие характеристики хочется учесть при определении Критичности: тип атаки (что-то совсем непонятное и ранее невиданное ~ APT или целевая работа людей, обычная малвара или просто "нежелательное ПО", админ ошибся или пользователь нарушил что-то и т.п.), факт успешности (если был какой-то инструмент или ВПО - были ли они запущены на жертве или не успели), ну и, насколько это возможно, ущерб (хотя бы в терминах "фактический" - есть подтверждения, что увели деньги, унесли данные и имиджевые потери, ну а если фактов ущерба нет - хотя бы в терминах "большой"\"небольшой".

И вот что получилось.

			Ущерб
			Фактический	Потенциально большой	Потенциально небольшой
Тип инцидента	APT		CRITICAL	HIGH
	Сетевая атака		HIGH	MEDIUM	LOW
	Malware: Trojan, Criptor, etc	Запущено /активно		MEDIUM
		Не запущено /неактивно		MEDIUM	LOW
	Scan, Misuse, Configuration error
	Adware, Riskware, Potentially unwanted program

Если у вас что-то серьезное (APT или по вам шарятся какие-то неэтичные ребята), то это -  HIGH, если предполагается наличие CRITICAL, то должен быть подтвержденный ущерб.
Если у вас просто новая недектируемая (т.к. детектируемую просто убьет антивирус) малвара - MEDIUM, но если она успела натворить Ущерб - надо повышать до HIGH.
Если ошибки пользователей или админов имеют потенциально большой ущерб - это MEDIUM, сюда же можно отнести какие-нибудь рекогносцировки неэтичных ребят, так как они еще не успели начать работать. Если же ущерб небольшой - это LOW. Я не стал рисовать, Misuse с фактическим ущербом, который надо бы классифицировать как HIGH, ибо склонен считать, что админы и пользователи у нас с вами достаточно профессиональны.
Если вы нашли ПО, которое не имеет вредоносного функционала, а просто нежелательно - это LOW.

Сигнатурные и Контекстные ложные срабатывания

Все в этом мире относительно. Именно поэтому для результативности безопасности нам важен контекст, поскольку технологические сигнатуры (не важно на что: на конкретный файл или на последовательность действий) производителем СЗИ выпускаются на среднестатистическую ситуацию, которая может быть сильно различна от инфраструктуры к инфраструктуре. В качестве иллюстрации можно привести сигнатуры на отстуки по C2 ботнетов - это безусловно нехороший знак для рабочих станций рядовых сотрудников HR или бухгалтерии, однако, это вполне может быть ОК для сотрудников подразделений RnD, исследующих ботсети, и для них фиксируемые алерты в контексте конкретной ситуации вполне могут быть ложными срабатываниями. Важным моментом здесь является то, что технологически сигнатура отработала корректно и мячик находится уже на стороне адаптации решения к конкретной среде. Перевод СЗИ из дефолтной конфигурации в адаптированную для конкретной инфраструктуры - очевидная вещь о которой много написано, и сегодня не про это (хотя, в моей практике были комичные случаи, когда я так и не смог убедить в необходимости конфигурирования СЗИ из коробки :) - поэтому, если в необходимости адаптации под свою сеть есть сомнения - этому можно посветить отдельный пост).

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

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

IoNA: Сетевой трафик winlogon

Рассуждая о безопасности мы часто упоминаем индикаторы компрометации - все те же сигнатуры, все то же перечисление зла. Однако, для понимания происходящего, тем более для хантинга, надо не просто находить по индикаторам, а отличать "нормальное" от "подозрительного"/"не нормального" - для чего надо неплохо разбираться в том, что может быть нормальным. Имея знания о "нормальности" подход будет примитивным и, вместе с тем, вполне себе эффективным: из общего количества активностей убрали все, что "нормальны"/известны, а с оставшимися - явно ненормальными или неизвестными - разбираемся. По результатам разбора можно пополнить свой багаж знаний о "нормальности" поведения - т.е. копить не только IoC-и, но и IoNA - индикаторы нормальной активности :)

Оказывается, процесс winlogon тоже генерит сетевой трафик. Причем эта его активность не вызвана никакими инъекция зловредов в него - это его нормальная активность в случае, если у пользователя смонтированы папки WebDAV. Более того, если у вас используется WPAD, то winlogon пойдет сначала на сервер wpad, получит настройки прокси, а затем с ними устремится подключать шары. Если посмотреть dll-ки, подгруженные в winlogon, демонстрирующий такое поведение, то там можно будет обнаружить компоненты Internet Explorer: %SYSTEMROOT%\system32\urlmon.dll, %SYSTEMROOT%\system32\iertutil.dll, %SYSTEMROOT%\system32\WININET.dll, %SYSTEMROOT%\system32\jsproxy.dll. Сетевой трафик от winlogon можно наблюдать в момент входа пользователя в Windows (== момент подключения сетевых папок WebDAV).

Таким образом, наш IoNA выглядит так:
1. Сетевой трафик (WPAD - если есть, HTTP - на сервер с папкой WebDAV) от легитимного процесса winlogon.exe.
2. Подгруженные в winlogon библиотеки IE.
3. У пользователя подключена сетевая папка WebDAV.

В заключение хочется отметить, что это нормальное поведение может являться неплохим вектором атаки на winlogon, - уже как на клиента Интернет... - время покажет.

Два сценария мониторинга

Несомненно, заслуживает уважения стремление Человечества все автоматизировать. Однако, концептуально непреодолимая проблема в том, что машина не может догадываться (некоторая продвинутость в вопросах машинного обучения заставляет в этом сомневаться , но на практике я не видел полностью автоматических систем безопасности, полагаю, сначала появятся пентестеры-автоматы, и это будет предвестником безопасников-автоматов :) ), а рейтинговые системы порой дают результаты, оспаривающие здравый смысл, что может служить почвой для анекдотов и прочего народного творчества. Поэтому, приходится нехотя соглашаться, что автоматикой мы способны задетектить то, с чем аналитик когда-то разбирался и придумал некоторый алгоритм, как это обнаруживать. Но, очевидная правда в том, что безопасность - бесконечная игра в кошки-мышки, где защищающие постоянно отстают от нападающих и вынуждены уже постфактумно, получив какие-либо артефакты, разгадывать неведанные, тайные и запутанные замыслы атакующих. Поскольку от детских проблем прекрасно спасает автоматика, а кибератака - эффективный инструмент влияния, получающий всю большую популярность одновременно с повышением своей эффективности, мы имеем, что для обеспечения этого эффективного влияния атакующий должен использовать недетские TTP, способные обходить автоматические средства защиты, бить в те места, где автоматика бессильна, обнажая пробельные места в защите.
Вот, как раз, эти-то пробельные места и компенсируются трудом аналитика, проводящего расследования компьютерных атак (== инцидентов ИБ). Широко смотря на проблему разделение задач такое: робот - детектит все то, что известно, а все что не известно - детектит аналитик и учит этому робота, создавая корреляционные правила/сигнатуры и т.п.. Так обеспечивается замкнутый цикл мониторинга, реализованный через симбиоз человека и робота - основа построения комплексной услуги и системного подхода.

На практике это выглядит как два сценария мониторинга. Первый назовем "Alerting" (или "Alerts"). Его суть заключается в том, что под известные TTP, выраженные в цепочках событий\нотификаций систем безопасности (да и любых других систем, способных генерить логи вообще) создаются алерты, свидетельствующие о том, что данная цепочка была обнаружена, а следовательно - обнаружена соответствующая ей атака. Достоверность (% ложных срабатываний) такого алерта будет полностью зависеть от качества цепочки (корреляционного правила, сигнатуры). Здесь задача службы мониторинга - а) понять что алерт - не фолса, б) инициировать процесс реагирования на инцидент и отработки последствий. Этот случай - классический, все, кого я спрашивал о том, что он думает о мониторинге и SOC, - отвечали примерно это.
Второй сценарий, назовем его "Hunting", менее очевидный, но все понимают его необходимость при попытке ответить на вопрос: "Откуда берутся корреляционные правила". Да, сценарий, когда аналитик почитал новости и сделал новую детектирующую цепочку все равно относится к Первому сценарию, поскольку аналитик автоматизировал уже известную атаку. А вот если хочется защищаться от неизвестных атак, обеспечивая комплексную услугу, - аналитику надо самому находить атаки, анализируя неочевидные индикаторы и признаки, совокупность которых создаст подозрения, расследование которых приведет к выявлению новых, ранее не встречаемых ITW атак. Вот это - Второй сценарий, позволяющий создавать эти корреляционные правила, и далее - учить автомат самостоятельно, насколько это возможно, это детектировать и обезвреживать.

Указанные два подхода к мониторингу принципиально отличаются и, вместе с тем, прекрасно дополняют друг друга до единого целого, необходимого, в конечном счете, потребителю. Для Первого можно придумать SLA со временем реакции и временем решения, для второго - нет. Для первого важна реалтаймовая корреляция, что обычно возникает в сознании при слове "SIEM", для второго - важна возможность разнопланового анализа, структурирование в момент поиска, позволяющее одни и те же события в разное время увидеть и интерпретировать по-разному. Первый сценарий - больше operations, оперативная готовность, тогда как Второй - research, планирование и развитие. Оба сценария важны, невозможно добиться желаемого результата реализовать лишь какой-то из них, однако, Второй, как любые исследования, достаточно дорог (нужны люди, инструменты, время), а поэтому может эффективно выполняться, скорее, специализированным компаниям, уже проводящим такие исследования в рамках своей основной деятельности, и поэтому - обречен на аутсорсинг, что, на мой взгляд, - нормально.
Очевидно, что Hunting, применяемый к угрозам ITW, а полученные сигнатуры - к угрозам на данном конкретном предприятии, дает значительно меньший эффект, чем сценарий, когда весь исследовательский потенциал специализированного аутсорсера направлен на Hunting в рамках данной конкретной инфраструктуры, в результате которого созданные корреляционные правила/сигнатуры для данной конкретной инфраструктуры, - именно поэтому он интересен для понимающего заказчика. Hunting атак ITW, сопряженный с Alerting-ом в конкретном предприятии можно сравнить со стрельбой вслепую - если везет, то по направлению предполагаемого противника, тогда как Hunting по данной конкретной инфраструктуре в совокупности с Alerting-ом по ней же, аналогичен прицельному снайперскому огню, эффективность которого, безусловно, выше.

Новые методы эксплуатации инъекций в ORM

27.05 мне в очередной раз посчастливилось выступать на HITB@AMS. Даю ссылку на нашу презу. Также она доступна на сайте конференции. Этот доклад - продолжение темы, подсвеченной на ZN, но более расширенное и углубленное. Заниматься этим подстегивало весьма незначительное количество публикаций по теме, надеемся, нам удастся, хотя бы частично, заполнить этот информационный вакуум.

New methods for exploiting ORM injections in Java applications from Mikhail Egorov

Как обычно, в нашем докладе были демки, которые традиционно доступны на YouTube у Миши, ссылки на видео есть на слайдах презентации, дублирую здесь:
Exploiting JPQL injection against EclipseLink ORM
Exploiting HQL injection against Hibernate ORM with Unicode method
Exploiting HQL injection against Hibernate ORM with Java Constants method

После доклада был вопрос, на котором стоит также остановиться: "Как находить такие инъекции?" Они находятся также как и обычные SQLi, однако, в отличии от них они эксплуатируются несколько иначе. Собственно, доклад как раз о том, как такие инъекции эксплуатировать - предложены методы, которыми можно пользоваться в зависимости от комбинации СУБД-ORM - см таблицу на слайде 81.

Хонипоты в интерпрайзе

В презентации, рассказывая про атаки, я упомянул (этого нет в слайдах, но, по-моему, это было сказано), что с подавляющим большинством атак достаточно эффективно сражаются стандартные средства защиты, типа IPS, антивирусов и пр., и лишь небольшой процент (я слышал цифру ~1%) можно отнести к сложным целевым атакам (aka "APT"), с которыми надо работать как-то по-другому - используя другие инструменты с более глубоким вовлечением именно аналитика. 

Я много игрался с хонипотами, но потребность в них по-прежнему не очевидна. Просматриваются две основные идеи их применения. Во-первых, это может замедлить потенциальную атаку, о чем с некоторой подменой смысла повествовалось в статье уважаемого института. Однако, беря во внимание первый абзац этого поста, если мы имеем дело с "типовой" атакой, мои "стандартные" средства защиты прекрасно с этим справятся и без хонипота. Если же мы имеем дело с профессиональной атакой, то такой злоумышлениик раскусит наш хонипот за время, едва ли имеющее важное значение в общем таймлайне атаки. В этом случае, эффективность хонипота сводится к эффективности стандартной IDS - просто обнаружить то, с чем далее надо разбираться. Следует признаться, что когда в Амстердаме мы показывали видео про то, как ловить "хакеров" с помощью kippo, народ в зале отметил, что демонстрируемое поведение позволяет судить о далеко не высоком профессионализме атакующего. Если же мы будем разворачивать более хорошую эмуляцию (high-interaction honeypots), то это - полноценная новая система, которая, по Закону сохранения, утянет ресурсы, которые было бы куда более разумно потратить на обеспечение безопасности реальных информационных активов. Итого, от сложных неизвестных атак мы этим не защитимся, от известных - поможет "антивирус" (далее буду использовать как собирательный образ типовых привентивных технических средств обеспечения безопасности).

Второй задачей, решаемой хонипотом, обычно называют возможность исследования атаки: пока злоумышленник понимает, что он атакует хонипот, мы собираем эвиденс, который позволяет нам расследовать что происходит. Понятно, что едва ли нужно расследовать типовые атаки, где "антивирус" все заблокирует... Однако, хонипот не нужен и для сложных атак, поскольку, а) как было отмечено выше, его быстро раскусят, б) в случае необходимости расследования сложной целевой атаки у нас есть неотъемлемый "хонипот" - вся наша инфраструктура и приложения. Поэтому не надо сразу кидаться все вычищать, надо сначала понаблюдать и разобраться - это позволит избежать потенциальных проблем и радикально повысить эффективность вашего респонса. Об этом пишут все умные книжки про Incident response и об этом же говорил коллега в презентации (шикарная, на мой взгляд преза, полезно ознакомиться) - прежде чем кидаться в бой, надо максимально изучить противника (ну, безусловно, надо смотреть по обстоятельствам, не надо злоупотреблять "созерцанием и ничего не деланием", никогда не надо перегибать палку, красота - посередине). Итого, для исследования сложных атак в интерпрайзе хонипот тоже не нужен, так как все самое нужное и актуальное можно собраться собственно с защищаемой сети. А для "типовых" атак - достаточно, что хонипоты или любые другие подобные эмуляторы есть у производителей систем "антивирусов", которые я использую, и они регулярно и своевременно поставляют мне сигнатуры, защищающие меня от ~99% зла.