V
для бедных есть arpwatch + ansible
Size: a a a
2019 July 05
EO
анализаторы, вы штаны на скольк оборотов подворачиваете например?
l
появился на свитче неизвестный mac в arp таблице - автоматом запирать в специальный vlan
Так мак можно поставить от соседнего устройства, а его выключить.
EO
Так мак можно поставить от соседнего устройства, а его выключить.
а это уже другой риск
Z
для бедных есть arpwatch + ansible
👍
A
Коллеги, а подскажите, есть ли существенные отличия между полями Windows Event ID 1 и Windows Event ID 4688. На первый взягляд - у ID1 полей больше, но везде рекомендуют собирать оба. При этом нигде не пишут почему так.
AK
Коллеги, а подскажите, есть ли существенные отличия между полями Windows Event ID 1 и Windows Event ID 4688. На первый взягляд - у ID1 полей больше, но везде рекомендуют собирать оба. При этом нигде не пишут почему так.
Windows Event ID 1 - это наверное вы Sysmon имеете ввиду
A
Так точно, для меня он настолько уже сжился с понятием мониторинга винды, что уточнять не стал
AK
Ну Sysmon в первую очередь могет собирать хэши, чего нельзя сделать стандартным журналом винды
RS
Ну Sysmon в первую очередь могет собирать хэши, чего нельзя сделать стандартным журналом винды
Applocker может
AK
Applocker может
Честно, на практике не видел ещё инфраструктур, использующих Applocker, хотя решение само по себе неплохое
A
С моей точки зения sysmon собирает больше, чем родные события ОС позволяют, но везде рекомендации комбинировать, например, RedCannary или Atomic Threat Coverage
MI
В sysmon-1 можно сразу играться с ParentImage.
В win-4688 ParentProcessName доступно только в win10 (могу ошибаться), до этого - только ppid.
Но и sysmon, и win-4688 в parent логируют именно Parent Process, а не Caller Proces. Это не одно и то же.
Та же СreateProcessA API позволяет назначать родителем не самого Caller, а другой процесс.
В win-4688 ParentProcessName доступно только в win10 (могу ошибаться), до этого - только ppid.
Но и sysmon, и win-4688 в parent логируют именно Parent Process, а не Caller Proces. Это не одно и то же.
Та же СreateProcessA API позволяет назначать родителем не самого Caller, а другой процесс.
y
апплокер собирает оч специфичный хеш - authentihash, у него супер специфичное применение и это совсем не то что вы ожидаете от него увидеть
y
это не md5/sha от бинаря
y
sysmon eid 1 тащит. хеши, + киллерфича - processguid/parent processguid , можно делать корреляции, как автоматизировано (https://github.com/Neo23x0/sigma/blob/master/rules/windows/process_creation/win_kernel_and_3rd_party_drivers_exploits_token_stealing.yml) для детекшена, так и позднее при расследованиях, вручную
y
мы в atomic threat coverage не говорим что нужно собирать и то и то. мы говорим и подсвечиваем что почти все правила из открытого репо sigma на этих двух источниках основаны. там нет ни одного правила в котором можно было бы справиться wel eid 4688 и при этом нельзя было бы с помощью sysmon eid 1.
блин, но это не очевидно -.- надо бы подсветить как-то
блин, но это не очевидно -.- надо бы подсветить как-то
y
вообще логика AND/OR в списке Data Needed для правил обнаружения давно в беклоге -.- подниму приоритет
RS
апплокер собирает оч специфичный хеш - authentihash, у него супер специфичное применение и это совсем не то что вы ожидаете от него увидеть
это известно. сопоставить его с известными источниками белых и чёрных списков не выйдет (точнее, я не знаю, отдаёт ли кто-то в фидах такое)
но увидеть что-то на сопоставлении их друг с другом можно (при несовпадении, естественно и с учётом постоянных обновлений)
но увидеть что-то на сопоставлении их друг с другом можно (при несовпадении, естественно и с учётом постоянных обновлений)