8 декабря компания FireEye сообщила, что в результате успешной атаки высококвалифицированной APT-группировке удалось получить доступ к инструментам, которые компания использовала как арсенал Red Team команды.

Невольно новость отсылает к 2017 году, когда в сеть попал инструментарий ЦРУ и АНБ для взлома инфраструктуры. Эти утечки подарили миру большое количество разнообразных утилит: от эксплойтов для домашних роутеров и Smart TV до серверов управления зараженными хостами. Наибольший резонанс произвел эксплоит EternalBlue, использовавшийся в шифровальщиках WannaCry, Petya, NotPetya, которые парализовали деятельность компаний по всему миру.
Возвращаясь к текущему кейсу, компания FireEye уверяет, что в составе утекших данных нет 0-day эксплойтов и инструментов эксплуатации неизвестных ранее техник. Также FireEye опубликовала на GitHub набор правил (YARA, Snort, OpenIOC, ClamAV) для детектирования утекшего инструментария.

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

git clone https://github.com/fireeye/red_team_tool_countermeasures

Я Сергей Рублев, руководитель SOC (Security Operations Center) в компании «Инфосекьюрити».
В этой статье подробно рассмотрю амбициозный проект Sigma Rules, девиз которого: «Sigma для логов — это как Snort для трафика и Yara для файлов».



Речь пойдет про три аспекта:

• Применимость синтаксиса Sigma-правил для ведения базы знаний сценариев выявления угроз
• Возможности инструментария по генерации правил для коробочных SIEM-систем
• Ценность для SOC текущего наполнения публичных репозиториев Sigma-правил

Мы используем систему оценок CVSS с момента возникновения нашей базы уязвимостей и первого нашего продукта — XSpider (надеюсь, кто-то его еще помнит). Для нас очень важно поддерживать базу знаний, которую мы используем в своих продуктах и услугах, в актуальном состоянии. Поскольку рекомендации по работе с CVSS-метриками не покрывают все возможные варианты уязвимостей, иногда приходится задаваться вопросом: «Как лучше проставить метрики, чтобы итоговая оценка отражала реальную опасность уязвимости?».

Мы постоянно следим за развитием стандарта, поэтому давно ждали окончательной версии CVSSv3. Открывая спецификацию, я прежде всего хотел ответить на вопросы: «Что стало лучше?», «Что именно изменилось?», «Сможем ли мы использовать новый стандарт в наших продуктах?» и — поскольку к ведению базы часто подключаются молодые специалисты — «Как быстро можно овладеть методикой оценки?», «Насколько четкими являются критерии?».

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