Эта статья является частью серии «Fileless Malware». Все остальные части серии:
- Приключения неуловимой малвари, часть I
- Приключения неуловимой малвари, часть II: Скрытные VBA-скрипты
- Приключения неуловимой малвари, часть III: запутанные VBA-скрипты для смеха и прибыли (мы тут)
В последних двух постах (тут и тут) мы говорили о безфайловых, но при этом довольно безобидных методах атаки. Теперь мы готовы, наконец, взяться за настоящую fileless малварь. Сайт для гибридного анализа (hybrid analysis, далее HA) – это ресурс, на который я полагаюсь, чтобы найти этих вредоносных «тварей». Как правило, информации, которую HA предоставляет для каждого образца: системные вызовы, интернет-трафик и т.д. – достаточно, чтобы удовлетворить типичные запросы ИТ-безопасности. Меня неумолимо тянет погрузиться в один из этих сильно запутанных образцов кода, чтобы увидеть, что же на самом деле там происходит.
Если вы захотите повторить за мной, то я рекомендую вам проделывать это в песочнице, например, в Amazon Web Services. А если вы проверяете это на своем компьютере, то не забудьте закомментировать системные вызовы, которые запускают PowerShell.
Внутри запутанного кода VBA
Вредоносная программа, которую я в конечном итоге нашел на сайте гибридного анализа, является сценарием VBA, который был встроен в документ Word. Как я упоминал в прошлый раз, чтобы увидеть фактический код, вам понадобится OfficeMalScanner Фрэнка Болдуина.
После извлечения сценария я загрузил код в библиотеку макросов MS Word, а потом запустил его пошаговую отладку с помощью встроенного отладчика. Моя цель состояла в том, чтобы лучше понять то, что было скрыто за обфускацией: поиграть в ИБ-аналитика и испытать успехи и разочарования, связанные с этой работой.
Если вы, как и я, впервые решили заняться этим в отладчике, то, скорее всего, вы выпьете не одну кружку чая (или кофе), пробираясь через умопомрачительно сложный код или наблюдая, помаргивая, на переменную L_JEK, которой присваивается строка «77767E6C797A6F6».
Работая с этим запутанным сценарием VBA, я понял, что лишь очень малая его часть выполняет полезную работу. Большинство же кода там лишь для того, чтобы сбить вас с пути.
В итоге я сделал снимок экрана небольшой части кода, выполняющего всю злую работу по старту командной строки PowerShell, которая в конечном итоге запускается макросом VBA.
Хитро: просто возьмите шестнадцатеричное значение и вычтите 7 для реального ASCII.
Это очень просто. Код VBA содержит в нескольких переменных запись итоговой командной строки в шестнадцатеричном представлении, а затем просто преобразует ее в символьную строку. Единственная «обманка» здесь была в том, что шестнадцатеричные значения были смещены на 0x07. Так, например, первая часть шестнадцатеричной строки получается из L_JEK, которой было присвоено значение «77767E6C797A6F6». Если вы возьмете 0x77 и вычтете 0x07, вы получите hex 0x70. Сделайте то же самое для 0x76 и вы получите hex 0x6F. Посмотрите их в любой таблице кодов ASCII, и вы увидите, что она соответствует первым двум буквам «powershell».
На самом деле, это не самое сложное запутывание, но этого ведь и не требуется! Все, что нужно сделать, это проскочить мимо антивирусных сканеров, ищущих конкретные ключевые слова или их представления в виде ASCII строк. Что этот образец достаточно хорошо и делает. Наконец, после того, как скрипт воссоздает командную строку, он запускает ее через функцию CreateProcess (см. ниже):
Закомментируйте системные вызовы или установите перед ними точку остановки.
Задумайтесь на секунду об этом. Документ Word был отправлен сотруднику в фишинговом письме. При открытии документа этот сценарий VBA автоматически запускает сеанс PowerShell, чтобы начать следующий этап атаки. Никаких исполняемых файлов, а обфусцированные скрипты спокойно уклоняются от антивирусов и прочих сканеров.
Вот оно Зло!
Ради любопытства я скачал еще один макрос с сайта HA (ниже), чтобы посмотреть, а что еще бывает. Этот второй код делает примерно то же самое, что и приведенный выше.
Секретный код, встроенный в VBA.
Но зато этот код немного более изобретателен в том, как он восстанавливает командную строку. Есть функция декодирования, называемая «d», которая отфильтровывает символы из базовой строки, сравнивая их со второй контрольной строкой. Это уже идея уровня средней школы, и она тоже отлично выполняет свою работу: легко уклоняется от сканеров и обманывает админов, которые лишь мельком просматривают логи на предмет необычных действий.
Следующая остановка
В моей серии первых публикаций по обфускации я показал, что журнал событий Windows записывает достаточно много деталей из сеансов PowerShell, то есть, если вы включите соответствующие настройки, чтобы иметь возможность провести глубокий анализ после факта взлома.
Конечно, в этом тоже есть определенная сложность безфайловых атак, так как практически невозможно определить делает ли сценарий PowerShell что-то плохое, просто проверяя там команды во время просмотра событий журнала безопасности.
Почему, спросите вы?
Потому что сеансы PowerShell запускаются все время, и злобный код из PowerShell сессии одного хакера может быть запущен в то же время, что и легитимный код из PowerShell добропорядочного ИТ-администратора. Если уведомления будут приходить вам каждый раз, когда PS-скрипт загружает что-то из интернета, будет генерироваться слишком много ложно-положительных срабатываний.
Вывод можно сделать следующий: мы видим неспособность традиционных средств защиты периметра остановить такие атаки, фишинговые рассылки и вредоносные программы FUD, и большие перспективы для средств поведенческой аналитики.
Короче говоря, это заведомо проигрышная битва пытаться остановить хакеров от проникновения внутрь периметра. Лучшая стратегия состоит в том, чтобы определить необычный и подозрительный доступ к файлам и запуск приложений, а затем ответить на них, деактивируя учетные записи или принимая другую меру в ответ на нарушение.
В следующей части мы рассмотрим более продвинутые типы безфайловых атак.
