Исследователи Palo Alto Networks Unit 42 прогнали 685 339 запросов по 913 брендам и получили около 250 тысяч несуществующих доменов, которые LLM уверенно выдают как настоящие. Этот фантомный сквоттинг уже перестал быть академической страшилкой: такие адреса можно быстро зарегистрировать и превратить в фишинговую инфраструктуру, а для разработчиков и компаний это еще один неприятный сюрприз в AI-first цепочке поставок.
О проблеме сообщает Dark Reading со ссылкой на исследование Unit 42, опубликованное 30 июня 2026 года. Схема выглядит почти обидно простой. Модель советует пользователю или AI-агенту правдоподобный URL для портала, API или корпоративного сервиса, хотя такого домена в природе нет. Дальше злоумышленнику остается зарегистрировать этот адрес раньше защитников, повесить на него фишинговую страницу, вредоносный backend или фальшивый endpoint и ждать, пока туда придет человек или автономный агент. В отличие от обычного фишинга, здесь приманку доставляет не письмо и не баннер, а «доверенный» AI-помощник, уже встроенный в рабочий процесс.
Масштаб у истории неприятный не только из-за цифры в 250 тысяч. Исследователи пишут, что параллельно обнаружили более 13,2 тысячи уже подтвержденных вредоносных URL, связанных с теми же брендами. То есть речь не о чисто теоретическом классе угроз, а о новом слое поверх вполне реального ландшафта фишинга и supply chain-атак. Unit 42 отдельно подчеркивает: LLM теперь работают как доверенная зависимость в enterprise-среде. Если раньше команды боялись поддельных пакетов, скомпрометированных репозиториев и вредоносных обновлений, то теперь в эту же цепочку добавляется еще и URL, придуманный моделью с убедительным видом человека, который «точно знает, куда идти».
По сути, фантомный сквоттинг переносит логику slopsquatting из мира пакетов в мир веб-инфраструктуры. Вместо несуществующей библиотеки модель выдает несуществующий домен. Вместо случайной опечатки, как в typosquatting, здесь проблема еще хуже: адрес не похож на чужую ошибку, он рождается внутри самой модели как правдоподобное продолжение бренда, названия сервиса или документации. Йохан Эдхолм, сооснователь Detectify, описал механику без лишней драмы: атакующему достаточно зондировать модели, находить повторяющиеся вымышленные домены, регистрировать наиболее полезные имена и размещать за ними вредоносный контент. Дешево, масштабируемо и, что особенно важно, трудно замечается на старте.
Почему защитные системы здесь запаздывают, тоже понятно. Обычные URL-фильтры, репутационные движки и threat intelligence привыкли, что домен сначала где-то засветится, соберет телеметрию, попадет в фиды и только потом начнет блокироваться. У выдуманного LLM адреса этой истории нет. Он «рождается чистым»: без репутации, без записей в блоклистах, без следов прошлых кампаний. А если домен зарегистрирован за считаные часы до атаки, защитник видит просто новый сайт, который пока ничем не отличается от любого легитимного молодого домена. Эдхолм прямо говорит: это позволяет обходить защиту, завязанную на плохую репутацию адреса, потому что рекомендация приходит от доверенного ассистента, а не от злоумышленника, который еще должен заработать доверие жертвы.
Самый показательный эпизод в исследовании связан с фишинговым набором Montana Empire. По данным Unit 42, команда мониторинга заранее отметила один «высокорисковый» домен, связанный с почтовым e-commerce-сервисом, а спустя 23 дня он был зарегистрирован и использован в реальной атаке. Более того, злоумышленник, как утверждают исследователи, собрал весь phishing kit при помощи AI coding assistant: от копирования легитимных витрин до PHP-backend и Telegram-управления. Это, пожалуй, самый неприятный момент во всей истории. AI здесь участвует с обеих сторон: сначала модель стабильно выдумывает нужный домен, потом другая модель помогает собрать инструментарий под будущую кампанию.
Для разработчиков картина выглядит особенно приземленно. Представим AI-ассистента, который подсказывает endpoint стороннего сервиса, URL корпоративного портала льгот или webhook для CI/CD. Если этот адрес попадает в код, скрипт автоматизации, внутреннюю документацию или настройки агентной системы без независимой проверки, компания сама протягивает провод к чужому серверу. В классическом сценарии это утечка учетных данных или токенов. В более неприятном варианте приложение начинает отправлять данные на инфраструктуру атакующего, а автономный агент делает это вообще без участия человека. Собственно, исследователи и предупреждают, что следующая стадия эволюции угрозы может обходиться уже без клика пользователя: ошибочный URL будет не просто советом, а командой к действию для системы.
Для бизнеса отсюда следует не модный, а довольно скучный вывод: LLM пора перестать считать просто удобным интерфейсом. Если AI-ассистент рекомендует URL, этот URL должен проходить ту же проверку, что и сторонняя зависимость, новый SaaS или неизвестный пакет. В практическом плане это означает проверку адресов по официальной документации и allowlist, запрет AI-агентам на свободные подключения к произвольным новым доменам, минимальные привилегии для сервисных учеток и отдельный контроль любых AI-сгенерированных endpoint'ов в коде и инфраструктуре. Иначе получится смешная, но дорогая история: компания годами строила secure SDLC, а потом доверила критический переход на сайт строке, которую модель придумала «по смыслу».
Главный вопрос теперь не в том, будут ли такие атаки расти, а в том, насколько быстро команды перестроят свои процессы под реальность, где ошибается уже не только человек, но и доверенный генератор ссылок. Чем глубже LLM и агентные системы встраиваются в разработку, поддержку и внутренние сервисы, тем ближе фантомный сквоттинг к статусу обычной операционной проблемы, а не экзотики для исследовательских блогов. Подробнее об исходном материале можно посмотреть в .