Хакеры не останавливаются на использовании одних и тех же инструментов, например популярным сканером был Advanced Port Scanner, а в посте выше использовали NetScan. Ещё есть множество реализаций сканеров, на powershell, wsf etc

Мы можем бесконечно гоняться за утилитами и основываться на Tools-based detection ✋. Давайте обратимся к пирамиде боли Дэвида Бьянко. Мы нанесем максимальный ущерб атакующим, только научившись обнаруживать их поведение.

В случае со сканером, у нас один процесс создает много соединений:

🔤 на один ip и много портов
🔤 на много ip и много портов
🔤 на много ip и один порт

В идеальной ситуации, у нас будет настроен span/netflow начиная с коммутатора доступа, если бы 😅 В лучшей ситуации span будет с агрегации или ядра, и сетевые сканирования мы сможем обнаружить ids, nta, ndr, но не в широковещательном домене (если без коммутатора доступа).

В случае с хостом, правило будет зависеть от функционала вашего siem/edr.

Например XP-rules, сетевые соединения с одного хоста на 10 разных:

event NetworkCreate:
    key:
        object.process.name, event_src.host
    filter {
        filter::Network_connections_windows
     }

rule NetworkScan: NetworkCreate[10] with different(dst.ip)

Мы можем сделать правило от обратного на основе событий с хостов, которые сканят.

🔤 События от 5 разных хостов (нужно не забыть добавиь адресав исключения):

event NetworkCreate:
    key:
        src.ip
    filter {
        filter::Network_connections_windows
     }

rule NetworkScan: NetworkCreate[5] with different(dst.ip)

🔤 Много портов на одном хосту. Этим правилом мы можем ничего не увидеть) хочется верить, что вряд ли виндовые хосты будут сканить по всем портам). Подключение на 3 рахных порта

event NetworkCreate:
    key:
        src.ip, event_src.host
    filter {
        filter::Network_connections_windows
     }

rule NetworkScan: NetworkCreate[3] with different(dst.port)

Поверх этих правил можно сделать вложенную корреляцию, чтобы усложнить логику и уменьшить количество фолсов))

#detection@detectioneasy