IoNA: ADS офисных приложений

Полезно следить за ADS.

Подозрительные с первого взгляда ADS вида "c:\programdata\temp:58a5270d", создаваемые офисными приложениями powerpnt.exe, winword.exe, excel.exe - нормальная активность, если имеет место использование ПО Office Tab.

Охота на угрозы @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.