В 2024 году мы — команда практического анализа защищенности «Инфосистемы Джет» — выполнили 130 проектов и выяснили, что в среднем достаточно 10 часов, чтобы вывести крупные суммы со счетов, остановить производство или слить критичную информацию. В работе мы используем сложные методы, но из-за низкой защищенности организаций часто хватает базовых техник[1] и общедоступного ПО. Наши наблюдения подтверждаются исследованиями кибератак[2]: в 83% случаев злоумышленники добивались успеха за счет «простых» методов — фишинг, эксплуатация уязвимостей по умолчанию или слабые пароли. State of art атаки с поиском 0-day — это скорее исключение. Обычно компании взламывают куда более прозаичными способами.

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

Отсутствие настройки групповых политик и небезопасное хранение паролей. Хищение денежных средств через «1С: Зарплата и управление персоналом»

К нам обратилась микрофинансовая организация. Необходимо было проверить возможность хищения денежных средств со счетов этой организации. Работы проводились методом «черного ящика[3]», с моделированием «внешнего нарушителя».

Шаги

  1. Для начала мы просканировали беспроводной эфир и выбрали «жертвой» сеть заказчика с наибольшим числом клиентов. С помощью общедоступного программного обеспечения (ПО) Eaphammer создали поддельную точку доступа с таким же названием. В результате перехватили учетные данные сотрудника заказчика, включая хешированное значение пароля (T1016.002, T1557.002).

  2. Далее мы восстановили пароль из хеша и смогли подключиться к сети заказчика с полученными учетными данными. Таким образом реализовали атаку «злой двойник[4]» (T1110.002).

  3. От имени скомпрометированного пользователя провели разведку ИТ-инфраструктуры заказчика: собрали информацию о домене, групповых политиках, сети и т.д. (T1615).

  4. Создали доменную УЗ устройства. Из-за недостатков в настройке групповых политик каждая УЗ устройства имела привилегию GenericWrite и могла изменять DEFAULT DOMAIN POLICY (T1136.001).

  5. Используя доступ к групповой политике DEFAULT DOMAIN POLICY, мы создали пользовательскую УЗ и добавили ее в локальную группу «Администраторы». Так получили административный доступ к контроллеру домена (T1484.001).

  6. С помощью собранной на третьем шаге информации определили УЗ сотрудников из бухгалтерии, в том числе УЗ главного бухгалтера. Мы нашли его активную сессию на одном из компьютеров и удаленно подключились к нему в нерабочее время. В рабочих папках обнаружили текстовый файл с паролями для различных внутренних систем, в том числе пароль для 1С:ЗУП (T1087.002, T1021.004, T1552.001).

  7. Далее выполнили аутентификацию под УЗ главного бухгалтера на сервере 1С:ЗУП. В итоге получили возможность осуществлять платежи (создавать начисления, платежные поручения, редактировать номера счетов зачисления и пр.) (T1078, T1657).

Затруднительным этапом был незаметный вывод денежных средств без прохождения внутренних согласований и проверок банков. Мы нашли четыре возможности это сделать:

  • изменение номера счета зачисления существующего сотрудника;

  • создание нового начисления существующему сотруднику;

  • оформление переработки существующему сотруднику;

  • создание платежного поручения созданному нами сотруднику.

Выводы

Мы достигли поставленной цели и показали возможность хищения денежных средств. Однако реализация описанной атаки привела бы не только к потере денег, но и к утечке УЗ и персональных данных сотрудников.

Атака была бы невозможна, если бы заказчик:

  • ввел дополнительную защиту Wi-Fi (настроил проверку подлинности RADIUS-сервера Wi-Fi на клиентских устройствах, реализовал аутентификацию клиентских устройств по сертификатам);

  • безопасно настроил групповые политики домена;

  • ограничил сетевые права доступа к финансовым системам;

  • организовал защищенное хранение паролей.

Доступ к персональным данным сотрудников из внешней сети

Следующая организация поставила цель скомпрометировать персональные данные, хранящиеся в ее системах. Работы проводились методом «черного ящика».

Шаги

  1. Мы собрали информацию о заказчике в открытых источниках и обнаружили веб-портал. Проанализировав утечки, нашли учетные данные сотрудника заказчика и с их помощью аутентифицировались на этом веб-портале. Тип утечки свидетельствовал о том, что у сотрудника на его личном или корпоративном компьютере, с которого совершался доступ к веб-порталу, был установлен стиллер[5] (T1593.002, T1078.003).

  2. Веб-портал оказался системой обучения сотрудников. На одной из страниц системы была возможность оставлять комментарии с прикрепленными файлами, при этом проверка этих файлов осуществлялась некорректно. В результате в качестве файла мы загрузили PHP-шелл и получили доступ к контейнеру Kubernetes (T1505.003).

  3. В переменных окружения контейнера мы обнаружили информацию для подключения к базе данных MySQL (порт, логин и пароль). Для получения доступа к базе данных на странице веб-портала загрузили новый файл с кодом приложения Adminer для управления базами данных через браузер. Таким образом мы получили доступ к базе данных MySQL (T1613, T1552.007, T1105).

  4. Как мы выяснили, база данных MySQL содержала незашифрованные персональные данные всех сотрудников заказчика. Мы достигли поставленной цели (T1530).

Выводы

Полученный доступ позволил бы злоумышленнику развивать атаку внутри инфраструктуры без использования фишинга или привлечения внимания персонала. Мы передали данные о найденной уязвимости и предоставили рекомендации по ее устранению. Заказчик завел внутренний инцидент и исправил уязвимость.

Реализация атаки стала возможной из-за:

  • наличия учетных данных сотрудника в открытых источниках утечек;

  • наличия опции загрузки вредоносных файлов в открытом веб-портале;

  • недостаточной защищенности контейнера Kubernetes и возможности исполнения системных команд;

  • наличия в переменных окружения конфиденциальных данных для подключения к базе данных MySQL.

Удаление резервных копий. Доступ к изолированной сети и случайные находки

Для следующего заказчика — строительной компании — нам предстояло выполнить проверку доступа к серверам резервного копирования, расположенным в изолированном сегменте сети с отдельным доменом Active Directory (далее — домен Б). Работы проводились методом «черного ящика», имитировался внешний посетитель, подключивший свой компьютер в информационную розетку на территории заказчика.

Шаги

  1. Мы сгенерировали список с адресами электронной почты сотрудников заказчика из сочетания популярных имен и наименования домена. Далее проверили наличие этих УЗ через внешний почтовый сервер и на существующие почтовые адреса выполнили фишинговую рассылку со ссылкой на фальшивую страницу, имитирующую единую форму авторизации заказчика. В результате в 10% из дошедших писем сотрудники перешли по ссылке, а в 7% — ввели свои учетные данные. Никто не сообщил об инциденте в службу поддержки (T1589.002, T1608.005, T1566.002, T1056.002).

  2. С полученной УЗ мы подключились к информационной розетке в офисе заказчика и собрали информацию о пользователях, группах, привилегиях и используемом центре сертификации (ЦС). Анализ доступных шаблонов сертификатов показал уязвимость — любой доменный пользователь мог выпустить сертификат на имя администратора домена. Выпустив такой сертификат, мы получили права доменного администратора и скомпрометировали домен А (Т1615, Т1649).

  3. Чтобы попасть из домена А в целевой домен среды резервного копирования Б, необходимо было найти пользователей, обладающих УЗ в обоих доменах. При анализе собранной информации мы нашли группу «отдел резервного копирования», в которую входили администраторы домена А (T1087.002).

  4. Используя информацию о сессиях пользователей на устройствах, мы выявили рабочий компьютер одного из администраторов домена А. Чтобы обойти защиту антивирусного средства Kaspersky Security Center (KSC) на хосте администратора домена, мы сначала аутентифицировались в KSC и отключили защиту. После по RDP подключились на сам хост и расшифровали пароли, сохраненные в браузере Google Chrome (T1021.001, T1562.001, T1555.003).

  5. Среди извлеченных оказались учетные данные к системе виртуализации изолированного сегмента. Так мы получили полный контроль над виртуальными машинами домена Б, включая его контроллер домена в изолированном сегменте (T1078, Т1565.001).

В ходе наблюдения за администратором домена А мы поймали момент с открытой базой паролей в KeePass[6] на его рабочем компьютере. В результате мы получили доступ к множеству других внутренних информационных систем с правами администратора, в том числе к Confluence, где хранились схемы и документация по резервному копированию (T1555.005, T1213.002).

Выводы

Мы показали возможность привилегированного доступа к серверам резервного копирования. Полученный доступ открыл возможность менять настройки резервного копирования или удалять важные данные. Причем изолированный сегмент не стал преградой.

Реализация атаки стала возможной из-за:

  • низкой осведомленности сотрудников о правилах ИБ;

  • использования уязвимых шаблонов сертификатов;

  • небезопасных настроек политик в антивирусном средстве KSC;

  • хранения пользователями своих учетных данных в браузере.

Компрометация платежной системы. Достижение цели через смежные системы

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

Шаги

  1. После подключения к сети мы получили сетевые параметры УЗ пользователя домена. Первичная разведка не выявила уязвимости целевой системы Ц, но дала информацию о ее связях со смежными. Поэтому было предложено расширить анализ и включить в работы найденные смежные системы (T1078.001, T1016.001).

  2. Для одной из смежных систем С для аутентификации использовалась система WSO2 Identity Server (WSO2 IS). Мы просканировали ее и обнаружили уязвимость в устаревшей версии ПО WSO2 – CVE-2022-29464. Эта уязвимость позволяет удаленно выполнить код через загрузку файла[7]. В итоге эксплуатации уязвимости с помощью вредоносного скрипта Java Server Pages Shell был получен доступ на сервер WSO2 IS (T1595.002, T1190, T1059.004).

  3. Далее с использованием доступа к серверу был получен административный доступ к веб-панели управления WSO2 IS. С помощью полученного доступа cоздали дублирующую УЗ администратора целевой информационной системы Ц (T1136.001).

  4. С помощью этой УЗ удалось пройти аутентификацию и получить доступ с правами администратора в целевой системе Ц (Т1078.004).

Выводы

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

Атака стала возможной благодаря:

  • раскрытию технической информации о связях систем;

  • отсутствию обновлений системы WSO2 IS;

  • использованию одинаковых учетных данных в смежной и целевой системах.

Общие рекомендации

Несмотря на улучшение средств защиты информации и общее развитие информационной безопасности, пентесты показывают, что популярные техники и общедоступное ПО остаются эффективными для достижения целей злоумышленников.

Составили топ частых недостатков за 2024 год, которые встречали на проектах.

Отсутствие обновлений и как следствие — устаревшие протоколы:

  • Net-NTLMv1, LLMNR, NetBIOS, mDNS (множественные уязвимости);

  • MS-EFSRPC (уязвимость PetitPotam);

  • SMBv1 (уязвимость Eternal Blue CVE-2017-0144);

  • CIFS (уязвимость NULL Session CVE-1999-0519);

  • незащищенный RDP (уязвимость Bluekeep CVE-2019-0708);

  • отсутствие контроля использования IPv6 (уязвимость CVE-2011-1652).

 Недостаточная защита аутентификации технических и пользовательских УЗ:

  • использование словарных, слабых или одинаковых паролей;

  • отсутствие защиты от перебора учетных данных;

  • применение учетных данных по умолчанию

Ошибки в настройке Active Directory и сертификатов:

  • доступность административных интерфейсов из сети Интернет;

  • возможность подмены SAM-Account-Name и эскалации привилегий (CVE-2021-42278 и CVE-2021-42287);

  • уязвимости центра сертификации (возможность реализации атак ESC1, ESC2, ESC8 и др.);

  • отсутствие ограничений на добавление новых устройств в домен.

Раскрытие информации и недостатки веб-безопасности:

  • перечисление пользователей и внутренних IP-адресов, облегчающее разведку;

  • наличие уязвимостей в веб-приложениях (XSS, SSRF, устаревшие версии Apache);

  • отсутствие аутентификации в API (Swagger, Redis) и IoT-устройствах (камеры Hikvision, принтеры Kyocera).

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

Авторы:

Виктория Тхай, эксперт по информационной безопасности, «Инфосистемы Джет»
Айыына Илларионова, аналитик, «Инфосистемы Джет»


[1] Техника в рамках MITRE ATT&CK — это конкретный способ, с помощью которого злоумышленник достигает тактической цели в рамках атаки. Подробнее про MITRE ATT&CK — Techniques: https://attack.mitre.org/techniques/.

[2] Отчет компании Verizon Communications 2023 Data Breach Investigations Report: https://www.verizon.com/business/resources/reports/2023-data-breach-investigations-report-dbir.pdf.

[3] Тестирование методом «черного ящика» («тестирование с нулевым разглашением») проводится без наличия у пентестера какой-либо информации о тестируемом ресурсе. Основная цель этого тестирования — позволить пентестеру вести себя как настоящему злоумышленнику с точки зрения изучения возможных способов использования общедоступной и обнаруживаемой информации.

[4] Атака «злой двойник» — это атака, направленная на перехват учетных данных, с использованием поддельной точки доступа Wi-Fi, которая неотличима от подлинной.

[5] Стиллер (от англ. «красть») — это вредоносное ПО, предназначенное для кражи конфиденциальной информации пользователя.

[6] KeePass Password Safe — это система для хранения паролей.

[7] Подробнее про уязвимость CVE-2022-29464: https://bdu.fstec.ru/vul/2022-02512.

Комментарии (1)


  1. SteveVess
    01.08.2025 14:31

    В ЗУП платёжка просто печ форма