@vbengin корреляции пишите?)

Огонь шутка! :) И да у меня есть pt siem! Правда я сейчас очень редко выхожу в сеть , но где-то с завтра в полном доступе. Пиши в чем вопрос

корреляцию Bruteforce_success_to_dst_by_user юзаете?

у меня с ней проблемы, как и с кодом 0х18. пользователь ввел пароль не верно 2 раза а у меня 575 событий по этому поводу

У меня есть

Это не совсем правильное правило, надо бы поправить его в облаке. Правило работает на событие 4771 0х18 (событие ошибочной переаутентификации), срабатывает тотально на все УЗ, и в домене таких событий куча, а вот событий 4769 и 4776 пролетят мимо этого правила из-за другого статуса action (access, а не login).

Чего собственно с этим делать. 1. Можно увеличить нижний порог (всё-таки если перебор, то попыток будет много, например, до 50). 2. Добавить события 4769 и 4776. 3. Иисключить события 4771, либо обложить дополнительными фильтрами, только на значимые subject.name. У меня сейчас под рукой правило от PT_ESC, оно немного «титанически нечитаемое» но говорят рабочее и со временем именно такими заменят дефолтные правила, могу заслать.

Вообще интересно, ошибок преаутентификации KERBEROS из-за неверного пароля (eventid 4771 с reason="0x18") – на порядок больше чем неуспешных logon-ов из-за неверного пароля (eventid 4625 с reason="0xc000006a"). Кто скажет где нам будет полезно 4771 и при этом промолчит 4625?

 

вот спасибо

у меня тот же звездец

добавить 4678, 4776, исключить 4771. 4625 не должен молчать. Но я тут мимо проходил

События логгируют разные этапы аутентификации по Kerberos ЕМНИП. может,ссылки ниже помогут:

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771




https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4625

Я неправильно сформулировал мысль. 4771 в теории хорошее событие позволяющее ловить брут на всех сервисах связанных с доменом а не только при переборе учётки при авторизации  непосредственно на тачку. Но оно фолзит, и даже не только при смене пароля но и  просто так. Ограничивать по существенным учеткам вариант мне не нравиться, просто потому что у всех свой подход к определению "существенная" . Получается для него надо крутить Счётчик на срабатывание, 50 может даже больше,  в отличие от других событий.

Оно фолсит из за того, что так устроен керберос

Имхо, если настроена доменная политика на блокировку, неудачные аутентификации одной учетки можно пристально не смотреть, максимум дашборд настроить и реагировать на массовые блокировки. А вот множество учеток с одного ip.

Это интереснее и оно не фолзит.

вот вот...

@vbengin а есть правило где просто брут без удачной авторизации в конце?

Доброго дня. А встречали ресурсы, где playbook готовые выложены?