Продолжим разговор за интересные случаи в работе пентестеров. В прошлом посте речь шла о внешних тестированиях на проникновение, сегодня же расскажем о наиболее занимательных внутренних пентестах, реализованных нами за последнее время. Суть их в том, что мы должны были, находясь во внутреннем периметре заказчика, получить максимальные привилегии в домене и добраться до каких-либо важных данных. Случалось удивляться. Но обо всем по порядку.

Случай 1. Менеджер паролей хорошо, но им нужно уметь пользоваться

Мы проводили внутреннее тестирование на проникновение для крупного клиента, у которого уже были натасканные сисадмины и служба ИБ. В ходе работ получили несколько учеток, с которыми смогли уже ходить по сети и подключаться к машинам других пользователей. В какой-то момент обосновались на машине одного из сисадминов и обнаружили там эльдорадо. Сисадмин использовал действительно сложные пароли (подобрать такие было бы трудно) и даже хранил их в keepass’e. Но вот незадача: сам менеджер паролей никогда не блокировался — ни через 15 минут, ни в момент блокировки экрана. С таким бонусом мы без шума и пыли получили административные права в критичных системах заказчика.

Похожий случай был и у другого клиента. Тоже сложные пароли, тоже keepass, правда там все-таки стояла автоблокировка через 15 минут. Как мы смогли это использовать? Дождались, когда админ залочил рабочий стол и ушел (на обед?). Дальше дело было за малым.

Если вы используете менеджеры паролей, используйте их с умом — включайте опцию блокировки при lock screen’е и при отсутствии активности в течение 1–5 минут.

Случай 2. Уволенные сотрудники

Очень часто в ходе внутренних пентестов мы получаем доступы, подбирая пароли — пользователям обычно лень придумывать сложные комбинации, особенно когда парольная политика требует их обновления каждый месяц. Часто просто изменяют цифры — так, superpassword_03.2019 спустя месяц превращается в superpassword_04.2019 и далее по списку.

Но иногда заказчики попадаются совсем уж на ровном месте. Так, проводя атаку password spraying в одной из компаний, мы получили некоторое количество учеток и одна из них нас особенно заинтересовала: она имела достаточно широкие права, хоть и не админские. Для нее был установлен легкий пароль (qaz12345), а в комментариях к этой записи в AD значилось, что данный сотрудник уволен — судя по дате, почти год назад. То есть после увольнения учетную запись не заблокировали, а просто сбросили пароль до «дефолтного» и поставили опцию «сменить пароль при 1-ом входе». На счастье заказчика мы стали первыми, кому предлагалось это сделать.

Случай 3. Патчи? Неее, не надо

Самый сложный этап внутреннего пентеста — получение первой учетной записи. Существует много средств и способов, как это сделать, начиная со шпионского дефиле по офису в поисках заветных стикеров с паролями и ловли страждущих на клонированный офисный вай-фай, заканчивая атаками на Kerberos и спреингом паролей учетных записей. Но иногда уже при первоначальном сканировании можно обнаружить ПО, которое никто не обновлял уже десять тысяч лет (зачем вообще обновлять софт во внутренней инфраструктуре?).

В одном таком проекте набрели на управляющее ПО от HP, в котором нашлась RCE без аутентификации — из нее и получили часть учетных записей.

?\_(?)_/?

Казалось, дальше все будет просто — Mimikatz, да и дело в шляпе, однако выяснилось, что полученные учетки не обладают нужными нам привилегиями. Как говорится, в готовности к облому наша сила: с помощью магии nmap’a и скрипта smb-enum-shares выяснили, что одна из учеток имела права локального админа на тестовом сервере, которым в этот момент активно занимались доменные админы=).

Случай 4. Блокировки

Напоследок поговорим немного про возможные блокировки доступов. Работы по «внутрянке» мы проводим чаще всего с удаленным доступом. Схема выглядит так: подключаемся к VPN, получаем внутренний адрес, после этого цепляемся к выделенной для нас машине по RDP. И с этой машины мы уже начинаем вести работы, но для этого нам нужно каким-то образом донести свой инструментарий. У многих наших клиентов для получения доступов в интернет используются прокси-серверы с белыми списками сайтов, иногда даже с белыми списками портов (например, можно подключиться к веб-сайту на 80 порт, но на 8081 уже нельзя). Это действительно несколько затрудняет работу, особенно если запрещают копипаст через RDP.

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

Мучиться пришлось недолго. Прокси действительно блокировал многое, не было возможности даже просто подключиться к своему http-серверу (его нет в белых списках), копипаст запрещен, браузер отказывался ходить куда-либо, кроме http (80/tcp) и https(443/tcp), и куда-то, кроме внутренних порталов. Попробовали wget через powershell — тоже не работает, без прокси не ходит, а прокси запрещает. Зато встроенная утилита винды FTP отлично работала — правил на firewall’е, которые бы блокировали такой трафик, не было. Так мы протащили весь наш инструментарий внутрь периметра и смогли отлично поработать.

Напоследок

Повторю рекомендации из предыдущей части, потому что повторение — мать заикания учения. Проводите периодические тестирования на проникновение — они помогут вам найти тонкие места в вашей защите, как, например, в кейсе 3. Вы можете считать, что патчить системы во внутреннем периметре не обязательно, но иногда это приводит к тяжелым последствиям.

Постройте систему патч-менеджмента — устраняйте не только «громкие» уязвимости (вроде EternalBlue или BlueKeep), но и менее известные, но не менее опасные в случае их эксплуатации (как в случае с HP AM). Словом, следите за всеми вашими системами.