Кто продаёт вход в корпоративную сеть и как поймать Initial Access Broker до основной атаки

Initial Access Broker, или IAB, взламывает организацию не ради немедленного шифрования серверов. Брокер получает рабочий доступ, проверяет его, собирает сведения о жертве и продаёт вход другой преступной группе. Покупателем может стать оператор ransomware, похититель данных, мошенник или участник целевой шпионской операции. Такой рынок сокращает путь от первого проникновения до ущерба, поскольку покупателю не нужно самостоятельно искать уязвимость или красть пароль.

Я не советую искать особую «сигнатуру IAB». Универсального индикатора не существует. Защитникам нужно связывать четыре группы событий, подозрительную авторизацию, разведку внутри инфраструктуры, создание резервного способа входа и резкую смену поведения оператора. Чем раньше SOC объединит эти сигналы в одну временную линию, тем выше шанс закрыть доступ до кражи данных, удаления резервных копий и запуска шифровальщика.

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

Что на самом деле продаёт брокер доступа

К середине 2026 года рынок IAB остаётся частью более широкой модели crime-as-a-service. Свежий отчёт Europol относит брокеров, инфостилеры, эксплуатацию публичных приложений, фишинг и инсайдеров к действующим источникам первоначального доступа для ransomware-операций. Разные исследования расходятся в оценке частоты отдельных методов, поскольку одни компании изучают сообщения на криминальных площадках, другие расследуют уже подтверждённые атаки. Общий вывод совпадает, украденные учётные данные и уязвимые внешние сервисы остаются двумя главными путями внутрь.

Товаром служит не только пара из логина и пароля. В объявлениях и закрытых сделках встречаются доступы к VPN, RDP, Citrix, SSH, межсетевым экранам, облачным панелям, почте и системам удалённой поддержки. Брокер также может продать веб-шелл, активную cookie, токен единого входа, ключ API, скомпрометированную учётную запись подрядчика или уже установленный RMM-агент.

Проверенный доступ ценнее сырой базы паролей. Перед продажей брокер нередко устанавливает отрасль и размер компании, уровень привилегий, наличие Active Directory, средства защиты, доступность резервных копий и предполагаемую ценность данных. Некоторые продавцы создают дополнительного администратора или оставляют второй канал связи. Другие ограничиваются проверкой входа, чтобы снизить риск обнаружения.

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

Отдельный риск создают личные компьютеры сотрудников. Инфостилер на домашнем устройстве способен украсть сохранённый пароль корпоративного VPN, cookie рабочей почты, токен SSO или ключ от панели разработчика. Корпоративный EDR ничего не покажет, поскольку заражение произошло за пределами управляемой инфраструктуры. Первым наблюдаемым событием станет вход с формально правильными реквизитами.

Какие признаки видны до продажи и после неё

Первый полезный сигнал часто появляется в системе идентификации. Проверять нужно не только страну и IP-адрес. Геолокация даёт много ложных срабатываний из-за поездок, мобильных операторов, облачных прокси и корпоративных VPN. Гораздо сильнее выглядит сочетание нового источника, неизвестного устройства, редкого приложения, необычного способа MFA и непривычных действий сразу после входа.

Особого внимания требуют регистрация нового метода MFA, выпуск ключа доступа, добавление OAuth-приложения, создание сервисного субъекта, изменение правил почты и сброс пароля через службу поддержки. Такие операции позволяют сохранить контроль даже после смены основного пароля.

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

На Windows полезно сопоставлять события 4624, 4625, 4648 и 4672. Событие 4624 означает успешный вход, 4625 фиксирует отказ, 4648 появляется при явном использовании других учётных данных, 4672 сообщает о назначении специальных привилегий новой сессии. Тип входа 10 обычно связан с RDP или другим удалённым интерактивным сеансом. Тип 3 означает сетевой вход и сам по себе не доказывает боковое перемещение.

$start = (Get-Date).AddDays(-7)
 
 Get-WinEvent -FilterHashtable @{
     LogName   = 'Security'
     Id        = 4624, 4625, 4648, 4672
     StartTime = $start
 } | ForEach-Object {
     $xml = [xml]$_.ToXml()
     $data = @{}
 
     foreach ($field in $xml.Event.EventData.Data) {
         $data[$field.Name] = $field.'#text'
     }
 
     [PSCustomObject]@{
         Time        = $_.TimeCreated
         EventId     = $_.Id
         User        = $data.TargetUserName
         Domain      = $data.TargetDomainName
         LogonType   = $data.LogonType
         SourceIp    = $data.IpAddress
         Workstation = $data.WorkstationName
         Process     = $data.ProcessName
     }
 } | Where-Object {
     $_.EventId -ne 4624 -or $_.LogonType -in '3', '10'
 } | Sort-Object Time

Локальная команда годится для первичного разбора, но не заменяет централизованный сбор. На рабочей станции журналы могут перезаписаться, а атакующий способен удалить часть событий. SIEM должен получать данные с контроллеров домена, серверов, VPN, IdP, межсетевых экранов, WAF, DNS, прокси, облачных платформ и EDR.

В Microsoft Sentinel можно начать с поиска адресов, которые за короткое время породили отказы, а затем успешную авторизацию. Запрос нужно адаптировать к собственной схеме журналов и исключениям.

union isfuzzy=true SigninLogs, AADNonInteractiveUserSignInLogs
 | where TimeGenerated > ago(7d)
 | extend
     Result = tostring(ResultType),
     Country = tostring(LocationDetails.countryOrRegion),
     DeviceId = tostring(DeviceDetail.deviceId)
 | summarize
     Failures = countif(Result != "0"),
     Successes = countif(Result == "0"),
     Users = dcount(UserPrincipalName),
     UserList = make_set(UserPrincipalName, 20),
     Countries = make_set(Country, 10),
     Devices = make_set(DeviceId, 20),
     Applications = make_set(AppDisplayName, 20)
     by IPAddress, bin(TimeGenerated, 30m)
 | where Failures >= 10 and Successes >= 1
 | order by Failures desc

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

На конечных системах подозрение вызывает не отдельная административная команда, а цепочка. Сразу после внешнего входа оператор запускает whoami, hostname, systeminfo, ipconfig, nltest, quser, net user, опрашивает группы домена, проверяет защитное ПО и ищет файловые серверы. Затем появляется новый пользователь, задача планировщика, сервис, RMM-агент или туннель.

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

Кейсы, которые ломают привычное представление об IAB

Летом 2025 года исследователи описали брокера GoldMelody, который использовал утёкшие ASP.NET Machine Keys. Подписанные злоумышленником данные ViewState позволяли выполнять код на IIS-серверах, а вредоносные модули работали преимущественно в памяти. Обычный поиск новых файлов мог ничего не найти. Такой сценарий показывает, почему при подозрении на компрометацию веб-сервера нужно проверять процессы, загруженные модули, сетевые соединения и криптографические ключи, а не только диск.

В 2025 году брокеры, связанные с операторами Play, эксплуатировали уязвимости SimpleHelp вскоре после публикации сведений о них. Публичный RMM-сервис одновременно давал удалённое выполнение команд и удобный канал администрирования. Пример подтверждает неприятную закономерность, после выхода исправления у защитников не всегда есть несколько недель. Массовая эксплуатация может начаться почти сразу.

В 2026 году Microsoft разобрала цепочки, где инфостилер заражал личное устройство, забирал корпоративные VPN-реквизиты, SSO-токены и cookies, а дальнейший вход выглядел как работа настоящего пользователя. Такой случай легко пропустить, если SOC анализирует только процессы на корпоративных компьютерах.

Ещё один важный вывод касается криминальных объявлений. Продавец может преувеличить уровень доступа, перепродать старые данные или заявить о взломе, которого не было. В июне 2026 года исследователи зафиксировали объявление брокера о продаже реквизитов, собранных во время масштабной парольной атаки, но отдельно указали, что заявление продавца не удалось подтвердить. Публикация на форуме служит поводом для проверки, а не готовым доказательством компрометации.

Как локализовать инцидент и не оставить запасную дверь

Сброс одного пароля редко решает проблему. Брокер мог сохранить cookie, refresh token, ключ SSH, дополнительный фактор MFA, локального администратора или веб-шелл. Реагирование должно закрыть все формы доступа и одновременно сохранить доказательства.

1. Зафиксируйте время первого подозрительного события, пользователя, приложение, устройство, IP-адрес, способ аутентификации и идентификаторы сессии.
2. Сохраните журналы IdP, VPN, EDR, WAF, DNS, прокси, межсетевых экранов, почты, облачных сервисов и контроллеров домена.
3. Заблокируйте новые входы, отзовите активные сессии и refresh tokens, затем смените пароль с доверенного административного устройства.
4. Проверьте методы MFA, ключи доступа, OAuth-согласия, сервисные субъекты, правила переадресации почты и делегированные права.
5. Найдите все системы, где использовалась скомпрометированная учётная запись, включая резервные копии, гипервизоры, средства развёртывания и панели управления.
6. Проверьте новых пользователей, сервисы, задачи планировщика, ключи SSH, веб-шеллы, туннели и программы удалённого доступа.
7. Установите первопричину. Если атакующий эксплуатировал VPN-шлюз или веб-приложение, смена пароля не остановит повторный вход.
8. После очистки продолжайте усиленный мониторинг. Перепроданный доступ мог попасть к нескольким покупателям.

Что должно появиться в SOC

• Инвентаризация всех внешних сервисов, включая забытые VPN, тестовые панели, RMM и интерфейсы подрядчиков.
• Фишинг-устойчивая MFA для почты, VPN, облачных панелей и привилегированных учётных записей.
• Централизованные журналы авторизации с достаточным сроком хранения.
• Контроль регистрации новых факторов MFA, приложений OAuth, ключей и административных учётных записей.
• Корреляция внешнего входа с разведкой, повышением привилегий и закреплением.
• Отдельный мониторинг appliance-систем, где нельзя установить полноценный EDR.
• Готовый сценарий отзыва токенов, смены секретов и изоляции пограничного устройства.

Где защита обычно переоценивает себя

MFA заметно снижает риск, но не защищает украденную активную сессию, подтверждённый пользователем вредоносный запрос или сброс фактора через службу поддержки. Предпочтение стоит отдавать FIDO2, аппаратным ключам и passkeys, а критичные операции нужно связывать с доверенным устройством и условным доступом.

EDR также не закрывает всю поверхность. Атака может начаться на VPN-шлюзе, гипервизоре, почтовой платформе, облачной учётной записи или личном компьютере сотрудника. Практические меры по защите внешних сервисов, удалённого доступа, журналов и резервных копий собраны в руководстве CISA.

Главный вывод остаётся прежним. IAB нужно ловить не по названию группы и не по адресу из чужого отчёта. Ищите момент, когда легитимная учётная запись начинает вести себя нелегитимно, пограничный сервер создаёт исходящий канал, а новый пользователь или токен превращает временный вход в постоянный. Закрытая на этом этапе дверь обходится дешевле расследования, которое начинается после удаления резервных копий и публикации украденных данных.