Вместо ILSpy — вредоносное расширение: атакующие скомпрометировали сайт на WordPress

6 апреля 2026 года сообщили о компрометации сайта ilspy.org: вместо обычной загрузки посетителей перенаправляли на стороннюю страницу, где им предлагали установить расширение браузера. По описанию инцидента, схема была нацелена прежде всего на разработчиков, которые искали популярный .NET-декомпилятор ILSpy.

Официальный репозиторий ILSpy на GitHub действительно указывает загрузку через релизы и другие официальные каналы, а не через отдельный домен с установщиком. В описании репозитория сказано: Download: latest release, а ссылка ведёт на GitHub Releases.

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

Это не классическая подмена исполняемого файла, а более хитрый сценарий. Вместо .exe или архива пользователю предлагают установить расширение браузера. Такой подход опасен тем, что расширения нередко запрашивают широкий доступ: к вкладкам, содержимому страниц, cookie-файлам, истории переходов и данным форм. Вредоносное расширение потенциально могло красть сессионные cookie, введённые пароли и отслеживать трафик пользователя.

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

Пользователям ILSpy и похожих инструментов уже сейчас стоит скачивать программы только из официальных репозиториев и страниц релизов; не устанавливать «обязательные» расширения ради простой загрузки файла; проверять конечный адрес перехода перед скачиванием; а для команд разработки — добавить в внутренние инструкции прямые ссылки на официальные релизы GitHub, чтобы сотрудники не искали установщики через случайные сайты.