В этом году, кажется, я превзошла саму себя: не только за счет кликбейтных и вызывающих названий, но и потому что один из них оказался в бизнес-секции вместо заявленного научпопа

Даже чуть волнительно, это же надо как-то посерьезнее быть, чтоли 🤓

Думаю, ближе к делу опубликуют расписание с аннотациями. See ya!

Атаки с использованием программ-вымогателей. Никакого rocket science: вот список первоочередных вопросов, который перед вами поставит любая внешняя команда по реагированию

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

На основе этих данных пробуем провести атрибуцию угрозы, группировки или семейства используемой программы: это поможет нам приоритезировать поиск и анализ, а также выбирать конкретные действия по реагированию. Для поиска нам в помощь гугол, данные TI (странно, что никто из TI-поставщиков еще не догадался сохранять и обрабатывать обезличенные примеры записок с привязкой к профилю🤔), иногда помогает репозиторий F6 или тот же твиттер. Еще информация может быть тут и даже на самых обычных форумах

1️⃣ Общие вопросы. Кратко:
— как именно был обнаружен инцидент (сами, кто-то сообщил, сработка средств мониторинга/безопасности и так далее)? Что вообще фиксировали? Есть ли какие-то временные рамки, конкретные дата/время?
— какие хосты подверглись атаке (сколько от общего количества конечных узлов, сервера, пользовательские рабочие станции)? Какая операционная система задействована (Windows, nix-based, если виртуализация, то какая именно)? Какие сервисы? Есть ли то, что их объединяет (прикладное назначение, сетевой сегмент)?
— какие действия уже были предприняты?
— имеются ли резервные копии, остался ли доступ к ним? Есть ли план по восстановлению работоспособности?
— с прицелом на будущее:
а) уточнить по активам, опубликованным в сеть Интернет. Что по демилитаризованной зоне? Мы же с вами знаем, что в случае с шифровальщиками у нас по факту три основных вектора: фишинг, экспулатация уязвимостей и сервисы удаленного доступа, в частности - RDP
б) имеется ли возможность централизованного сбора данных? Функционирует ли доменная среда?

Проработка этих вопросов сразу может позволить существенно сократить время расследования

2️⃣ Имеется ли файл самого шифровальщика? Другое найденное ВПО? Если да, то файл программы-вымогателя мы отдаем на реверс.
Нужно выяснить, как работает вредонос, какое шифрование использует, как распространяется (если заложено функционалом), возможные алгоритмические ошибки, при которых все же есть шанс расшифровать данные или какую-либо их часть, и так далее

Отдельно проговариваем:

🔵 Ни во время, ни после шифрования НЕ отключать от питания хосты повсеместно, а если речь о виртуализации, то ставить машины на паузу. Во-первых, вы потеряете волатильные данные, которые могут быть полезны для расследования инцидента, а во-вторых, если на системе шифрование уже началось, то может быть только хуже: после неожиданного прерывания процесса шанс восстановить какие-либо данные точно уменьшится, даже с купленным ключом дешифрования. А может страшного ничего и не произойти, но это всегда про риски
🔵 Не восстанавливаем зараженные машины из бэкапов, если еще нет понимания картины инцидента и данных о первичном проникновении злоумышленника в сеть. Навосстанавливаем себе тех же самых бэкдоров
🔵 Не перезаливаем хосты, даже если «работа стоит» и «ну очень надо». В случае острой необходимости, важно перед этим снять с него данные. А вдруг этот хост окажется основной точкой активности или нулевым пациентом, а значит, будет содержать самую ценную информацию для расследования?
🔵 А какой срок ротации журналов? На время расследования лучше сразу приостановить данные процессы, особенно в случаях малой глубины хранения или критических систем. Будет не очень хорошо, если через сутки мы поймем, что нужны журналы, которые хранятся пару часов

Дальше уходим в анализ, разбираемся, какие источники данных есть, а все решения - в зависимости от полученных результатов. Нет единого пути для всего: иногда первым и лучшим решением будет в принципе отключиться от Интернета на какое-то время или строить все с нуля

Главное, не построить с нуля с теми же ошибками, что были до

Yara Yara Daze

Всем, кто занимается malware analysis, точно знаком такой инструмент, как YARA 😉. С помощью него во многих компаниях 🔴 составляют наборы сигнатурных правил для определения и классификации вредоносов.

🤔 So, что такое хорошие YARA-правила? Это правила, которые могут детектировать предназначенный им класс или семейство ВПО, не детектируют ничего лишнего (false positive) и способны сохранять актуальность, даже если ВПО подвергается небольшим изменениям.

😏 Нет общего совета, как сделать хорошее YARA-правило — это зависит от сампла к самплу. Мы поделимся некоторыми Tips&Tricks про детект строк, которые будут полезны начинающим:

🔹 Не стоит забывать fullword — этот модификатор на строки гарантирует, что сигнатурная строка не будет находиться между буквенно-цифровыми символами (осторожнее с golang).

🔹 filesize выручает в тех случаях, когда сампл маленький и кроме общих сигнатур в нем ничего нет:

   rule CustomSocksProxy {
      strings:
          $a_1 = "SOCKS5 Proxy listening" wide
          $a_2 = "New connection from" wide
      condition:
          uint16(0) == 0x5a4d and filesize < 100KB and all of ($a_*)
  }

🔹 Лучше избегать сигнатур длиной в 3-4 символа.

🔹 Иногда очень полезно прописывать условие расстояния между строками. Например, если в файле есть какие-нибудь white- / blacklist, как имена процессов, можно ограничить их расположение в окне конкретной длины:

rule CheckProcessList {
      strings:
          $base = "\\system32\\cmd.exe" wide
          $str2 = "\\task.exe" wide
          $str3 = "cmd.exe" wide
          $str4 = "\\alg.exe" wide
          $str5 = "powershell.exe" wide
      condition:
      for all of ($str*): (@ - @base < 100) and for all of ($str*): (@base - @ < 100)
  }

🔹 Строки логирования лучше не разбивать на подстроки длиной 4-5 символов, если там общие слова, которые могут встретиться в любом контексте: детект подстроки \\\\dc2 в строке \nUsing:\n\t session_enum.exe \\\\dc1 \\\\dc2 \n — плохой детект.

🔹 Чтобы детект строк пережил различные кодировки, чередование заглавных и строчных букв, можно использовать три модификатора wide ascii nocase:

   rule SomeAPTScript {
      strings:
          $a1 = "GetRef(" ascii wide
          $a2 = " & ChrW(\"&H\" &" ascii wide
          $a3 = "Mid(" ascii wide
          $a4 = "Join(" ascii wide
          $a5 = "=0 Step -2" ascii wide
          $a6 = "Function [" ascii wide
          $a7 = "MSXML2.ServerXMLHTTP" ascii wide
          $v1 = "<Script " ascii nocase wide
          $v2 = "VBSCript" ascii nocase wide
          $v3 = "JSCript" ascii nocase wide
          $wscript = "WScript.CreateObject(\"WScript.Shell\")" ascii nocase wide
      condition:
          filesize < 30KB and $wscript and 2 of ($v*) and 5 of ($a*)
  }

И, конечно, главное — не забывать смотреть в документацию YARA 👀, следить за обновлениями и подсматривать на рули коллег.

Успехов в работе.

#tips #malware #YARA
@ptescalator

Недавно у нас тут был вопрос для обсуждения из разряда как отличить хорошее yara-правило от плохого. Как раз к теме, у ребят из эска вышел даже пост⬆️

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

Может, и вам есть, чего добавить? Соберем все бест практис в одном месте :)