Отличи меня, если сможешь: как дипфейки и вредоносные тестовые задания меняют наем в ИТ
Обычное собеседование все чаще превращается в инструмент кибератаки. Злоумышленники маскируются под кандидатов, рекрутеров и представителей известных компаний, используют дипфейки, поддельные документы и вредоносные тестовые задания. Целью становятся как специалисты, ищущие работу, так и работодатели, которым пытаются продать сфабрикованную личность.
Проблема промышленного шпионажа через фиктивный найм появилась задолго до распространения искусственного интеллекта. Компании годами пытались переманивать сотрудников конкурентов, чтобы получить доступ к внутренним процессам, технологиям и коммерческой информации. Еще в 2000 году Intel обвиняла Broadcom в систематическом найме инженеров с целью завладеть корпоративными секретами. С похожими претензиями к Broadcom обращались Rockwell и исследовательская компания Sarnoff.
Фальшивые собеседования, проводимые ради сбора сведений о другой организации, давно считаются одним из методов промышленной разведки. Однако теперь интервью может использоваться не только для получения информации. Оно становится способом доставить вредоносную программу непосредственно на компьютер доверчивого кандидата.
Как атакуют соискателей
Сценарий обычно начинается с убедительного предложения о работе. Преступники создают профиль рекрутера, копируют стиль общения реальной компании, используют логотипы, фирменные шаблоны и правдоподобное описание вакансии. После нескольких сообщений кандидату предлагают выполнить техническое задание.
Чаще всего речь идет о проверке кода в репозитории на GitHub, GitLab или Bitbucket. На первый взгляд задание выглядит стандартно: клонировать проект, установить зависимости, запустить приложение и найти ошибку. Опасность скрывается внутри файлов проекта, скриптов сборки или сторонних пакетов.
Один из распространенных механизмов связан с npm. После выполнения команды установки менеджер пакетов может автоматически запустить сценарий, указанный в файле `package.json`. Если в него встроен вредоносный код, программа начнет выполняться еще до того, как разработчик успеет изучить проект.
Так на компьютер могут попасть бэкдоры, похищающие пароли, криптографические ключи, токены доступа, содержимое буфера обмена и файлы. Некоторые вредоносные компоненты делают снимки экрана, собирают сведения о системе и устанавливают связь с удаленным сервером. В результате атакующий получает возможность управлять устройством или использовать украденные учетные данные для дальнейшего проникновения.
Опасность может скрываться и в расширениях Visual Studio Code, конфигурационных файлах, скриптах автоматизации и зависимостях, которые выглядят привычно для разработчика. Чем выше уровень специалиста, тем привлекательнее его устройство для преступников: на нем могут храниться ключи от облачной инфраструктуры, репозиториев и корпоративных сервисов.
Реальный сценарий с тестовым заданием
Один из разработчиков Python рассказывал, как едва не стал жертвой подобной схемы. Ему предложили должность ведущего инженера в небольшом криптовалютном стартапе. Для прохождения отбора нужно было клонировать репозиторий, изучить код и выполнить команду `npm install`.
При проверке проекта специалист обнаружил в `package.json` скрипт `prepare`. Менеджер npm запускает такой сценарий автоматически после установки зависимостей. Скрипт загружал файл, замаскированный под часть тестового задания. Внутри находился бэкдор, который поэтапно формировал адрес внешнего сервера, подключался к нему и предоставлял злоумышленникам удаленный доступ к компьютеру.
Атака не сработала, однако очевидно, что разработчик мог быть лишь одной из целей массовой кампании. Подобные схемы опасны именно масштабом: преступникам не нужно убеждать каждого человека вручную, если один и тот же репозиторий можно отправить десяткам специалистов.
Ранее похожие операции связывали с группировкой Lazarus. Она распространяла поддельные предложения о работе среди сотрудников ИТ-компаний и организаций химической отрасли, пряча трояны за документами и заданиями. Существуют и преступные объединения, которые специализируются именно на атаках через фиктивный найм, включая группировку с показательным названием Contagious Interview.
Дипфейки атакуют рекрутеров
Угроза исходит и с другой стороны процесса. Рекрутеры сталкиваются с кандидатами, чью личность невозможно надежно подтвердить по видеосвязи. Искусственный интеллект позволяет в реальном времени изменять лицо, голос и мимику участника интервью.
Иногда такая подмена выглядит относительно безобидно. Например, более опытный специалист может пройти собеседование вместо знакомого, чтобы помочь ему получить работу. Но для компании это все равно означает финансовые риски: нанятый человек может не обладать заявленными навыками и не справиться с задачами.
Гораздо серьезнее ситуация, когда за фальшивым кандидатом стоит организованная группа. Ее цель может заключаться в получении доступа к корпоративным системам, исходному коду, внутренним документам или данным клиентов. В таком случае компания рискует столкнуться не с ошибкой найма, а с подготовленной шпионской операцией.
По оценкам Gartner, к 2028 году фальшивым может оказаться каждый четвертый соискатель на собеседовании. Даже если прогноз не реализуется буквально, тенденция очевидна: визуальное подтверждение личности больше нельзя считать достаточным доказательством.
Как распознать подозрительное интервью
Полностью полагаться на качество изображения или естественность голоса опасно. Современные инструменты синтеза становятся реалистичнее, а сбои могут быть краткими и незаметными. Тем не менее насторожить должны несоответствия в биографии, странная манера отвечать на уточняющие вопросы, задержки между репликами и неестественная синхронизация речи с движением губ.
Полезно менять формат проверки. Кандидата можно попросить выполнить короткое действие в реальном времени: написать на бумаге текущую дату, повернуть голову, показать определенный жест или ответить на вопрос, связанный с предыдущими этапами отбора. Ни один такой признак не является абсолютным доказательством, но совокупность несоответствий повышает вероятность мошенничества.
Работодателю важно самостоятельно проверять резюме, профессиональные профили и историю занятости. Контакт с бывшими работодателями следует устанавливать через официальные каналы, а не по номерам и адресам, которые предоставил сам кандидат. Для критически важных должностей полезно проводить несколько этапов интервью с разными сотрудниками.
Как безопасно выполнять тестовые задания
Разработчикам не стоит запускать неизвестный проект на основном рабочем компьютере. Для проверки кода лучше использовать отдельную виртуальную машину, контейнер с ограниченными правами или временное устройство без доступа к корпоративным учетным записям.
Перед установкой зависимостей необходимо изучить `package.json`, файлы сборки, сценарии `preinstall`, `install`, `postinstall` и `prepare`. Следует обращать внимание на непонятные сетевые запросы, загрузку файлов, обфусцированный код и пакеты с необычными названиями.
Команду установки нельзя воспринимать как безобидную формальность. Менеджер пакетов способен выполнять скрипты с правами текущего пользователя, поэтому запуск в домашнем каталоге с доступом к ключам SSH и конфигурациям облачных сервисов может привести к серьезной утечке.
Безопаснее сначала установить зависимости в режиме, запрещающем выполнение скриптов, проверить состав проекта и только после этого запускать отдельные компоненты. Если работодатель настаивает на запуске непонятного бинарного файла, требует отключить защиту системы или отказывается объяснить происхождение кода, от задания лучше отказаться.
Что должны изменить компании
Организациям необходимо защищать не только рекрутинговые системы, но и сам процесс найма. Нельзя отправлять кандидатам внутренние репозитории, реальные конфигурации и рабочие ключи доступа. Тестовые проекты должны быть специально подготовлены для отбора: без секретов, производственных зависимостей и возможности обращения к корпоративной инфраструктуре.
При найме на чувствительные позиции стоит разделять этапы проверки личности, технических навыков и доступа к системам. Даже успешно пройденное интервью не должно автоматически открывать сотруднику широкие права. Доступ следует выдавать постепенно, с многофакторной аутентификацией и постоянным контролем действий.
Рекрутинговым командам также нужны инструкции по работе с подозрительными кандидатами и поддельными профилями. Важно заранее определить, кто отвечает за проверку документов, каким способом подтверждаются рекомендации и когда к процессу подключаются специалисты по информационной безопасности.
Новый стандарт доверия
Дипфейки не отменяют собеседования, но делают недостаточными привычные признаки доверия. Красивое резюме, видеозвонок и профиль в профессиональной сети больше не гарантируют, что перед компанией находится именно тот человек, за которого он себя выдает.
Безопасный найм будет строиться на сочетании нескольких мер: проверке личности, многоэтапных интервью, практических заданий в изолированной среде, минимальных правах доступа и внимательном отношении к необычным просьбам. Для разработчиков главным правилом остается простая рекомендация: неизвестный код нельзя запускать на устройстве, где хранятся рабочие секреты.
Искусственный интеллект ускоряет создание убедительных подделок, но он же помогает выявлять аномалии. Компании могут анализировать поведение учетных записей, проверять происхождение документов и отслеживать подозрительную активность. Однако технологии не заменят критическое мышление: в эпоху дипфейков доверие должно подтверждаться действиями, а не только изображением человека на экране.