Второй, куда менее очевидный момент, который упускают автоматизаторы - это vhostы (когда на одном порту может быть сразу множество сайтов). И, важный момент, - ни кто не гарантирует, что будет связь между DNS и заголовком Host. Иногда админы убирают старые сайты удаляя просто DNS-запись, забывая при этом удалить сам сайт. И такая простая pipeline автоматизация как subfinder | httpx | katana уже не заметит такие сайты.
Искать фактические сайты на веб-серверах можно ffuf или gobuster (особенно после моего коммита https://github.com/OJ/gobuster/pull/249). И далее добавлять соответствие ip hostname в /etc/hosts. Но если говорить об автоматизации с этим подходом возникают сложности - при одновременном сканировании сразу множества сайтов (а на периметре их обычно десятки, сотни) наши скрипты будут мешать друг другу используя при этом единый файл hosts. Решение тут - это Linux namespace, позволяющий запустить любой процесс с персональными точками монтирования. И вот таким волшебным sheebang (https://piware.de/2012/12/running-a-script-with-unshared-mount-namespace/) в любом скрипте автоматизации #!/usr/bin/env -S sudo unshare -m sudo -u user bash мы можем запускать проверки внося изменения в hosts локально, не мешая другим скриптам. После чего автоматизация не пройдёт мимо даже скрытого (без dns) сайта.

Популярные pipeline автоматизации от project discovery типа domain | sites | urls | vulns, которыми пользуются для быстрой оценки веба, упускают две важные вещи. Первая это конечно же POST-параметры, которые представляют собой более 50% поверхности атак. Оно и понятно, ведь тело запроса не передать через pipe так же просто как url.
Но несмотря на практически полный игнор POST-параметров (https://github.com/projectdiscovery/katana/issues/423 даже не планируют) katana и nuclei всё же можно заставить работать с ними.
Для katana даже если мы укажем -automatic-form-fill в выхлопе мы всё равно не увидим заветных параметров форм, но если мы сделаем json output то сможем получить то что нужно:
katana -u site.com -jsonl -or -ob | jq -r '.request.method,.request.endpoint,.request.body' | paste - - - | while read method url body; do ... done
С nuclei дела обстоят немного сложнее. На самом деле фаззинг-движок nuclei вполне способен итерироваться по POST-параметрам, но вот nuclei не предоставляет ни какого интерфейса для задания POST-параметров через опции командной строки. Однако nuclei принимает множество форматов для входных данных, не все он ещё хорошо умеет парсить, но вот через формат openapi мы вполне можем задать ему POST-запрос:
nuclei -im openapi -l <(./to_openapi.py 'POST' 'http://site.com/auth' 'user=a&pass=b') -dast -t dast/vulnerabilities
Наконец соединить katana и nuclei с поддержкой POST-параметров:
katana -u site.com -jsonl -or -ob | jq -r '.request.method,.request.endpoint,.request.body' | paste - - - | while read method url body; do
nuclei -im openapi -l <(./to_openapi.py "$method" "$url" "$body") -dast -t dast/vulnerabilities
done
И такая автоматизация уже по-взрослому начнёт искать веб-уязвимости.
Надеюсь что в будущем такие костыли будут не нужны и станет возможным более удобное использование (https://github.com/projectdiscovery/nuclei/issues/6011).

Анализ ACL (прав доступа) в Active Directory не такая простая задача и руками обычно не реализуется. Для злоумышленника она зачастую даёт хитрую неочевидную тропку до доменного админа.
Bloodhound, которым обычно проводят такой анализ, фиксирует лишь те ACE что понимает и что представляет угрозу. Но как увидеть полную картину и получить для анализа абсолютно все ACE? Задача усложняется ещё и тем что DACL имеет достаточно не удобный бинарный формат, затрудняющий его свободный анализ. Тот же bloodhound и impacket анализирует его лишь побитовым сравнением масок и флагов, не давая реальной возможности анализировать ACL самостоятельно и видеть больше чем позволено BH. Вот если бы бинарные ACE можно было превратить в текстовый канонический и greppable формат, что бы все мисконфиги было видно даже невооружённым взглядом.

Пару лет назад я заметил, что только в библиотеке skelsec/winacl есть функционал для полного декодирования ACE в канонический понятный вид. В итоге я сделал pull request в winacl (https://github.com/skelsec/winacl/pull/8) и в ldap шелл msldap (https://github.com/skelsec/msldap/pull/28), в котором теперь можно запрашивать ACL и выводить их в понятной и greppable форме для произвольных объектов.

Так на одном из недавних Red team инструмент msldap сильно помог в выявлении уязвимых прав доступа к шаблону сертификата ADCS, оставаясь при этом ниже радаров SOC и тихом захвате инфраструктуры через ESC4.

Однажды в голову мне пришла идея разработать немного-немало свой собственный google. Чтоб его можно было запустить в локальной сети и отыскать там любые секреты где нибудь в глубине публичных сетевых дисков, ftp или вебе. И что бы такая система понимала не только текстовые файлы, но и офисные документы, архивы, исполняемые файлы, картинки, звук, словом всё что только может прийти в голову и что нельзя искать простым текстовым поиском.
Интернет сегодня нельзя представить без поисковика, но почему в локальной сети иная картина? Ведь как известно общедоступные ресурсы это вечная головная боль всех админов, а для пентестеров их анализ слишком дорогостоящая по времени работа.
Разработать в одиночку и за умеренное время собственный аналог google непростая задача. К решению данной проблемы я пытался подойти с разных сторон и за всё время два или три раза полностью переписывал всю систему с нуля. Но в итоге мне удалось найти очень простое и элегантное решение, почти не требующее кодинг - создать систему построенную из готовых компонентов (GNU), легко масштабируемую и также легко внедряемую (docker). Да ещё и понимающую google дорки (opensearch).
Такая система может быть одинаково полезна как пентестерам когда перед тобой сотни шар, так и защитникам - ведь систему можно настроить на непрерывный регулярный краулинг всех общедоступных ресурсов.
В статье https://habr.com/ru/companies/ussc/articles/878340/ я детально описываю идею моей системы, её несложную логику работы а так же настройку и примеры использования.

Рубрика hardware - превращаем обычный ноутбук в cyberdesk.
Отличные доп мониторы для ноутбука - laptomo (ссылку не прикладываю, тк не реклама). Каждый монитор имеет независимое подключение либо typeC-hdmi либо typeC-typeC. Питание usbA-usbC. При этом есть поддержка сквозной передачи питания typeC от монитора в ноутбук на тот случай если в ноутбуке только один typeC. Комплектация включает в себя все необходимые провода. Размер и вес как у ноутбука.
Идеально для 14". И отличная вещь в командировках и внутренних пентестах.👍