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

Теперь, когда организации переходят на Microsoft 365 такими быстрыми темпами, мы видим новый вектор атаки — приложения Azure.

Как вы увидите ниже, злоумышленники могут создавать, маскировать и развертывать вредоносные приложения Azure для использования в своих фишинговых кампаниях. Приложения Azure не требуют одобрения со стороны Microsoft и, что более важно, они не требуют выполнения кода на компьютере пользователя, что позволяет легко обходить средства обнаружения и антивирусы на рабочих станциях.

После того, как злоумышленник убедит жертву установить вредоносное приложение Azure, он сможет выяснить, к какой организации принадлежит жертва, получить доступ к файлам жертвы, прочитать ее электронные письма, отправить электронные письма от имени жертвы (отлично подходит для внутренней фишинг-атаки) и в целом намного больше.

Что такое приложения Azure?

Microsoft создала службу приложений Azure, чтобы дать пользователям возможность создавать собственные облачные приложения, которые могут вызывать и использовать API-интерфейсы и ресурсы Azure. Это упрощает создание мощных настраиваемых программ, интегрируемых с экосистемой Microsoft 365.

Одним из наиболее распространенных API в Azure является MS Graph API. Этот API позволяет приложениям взаимодействовать с окружением пользователя, а именно: пользователями, группами, документами OneDrive, почтовыми ящиками Exchange Online и чатами.

Подобно тому, как ваш телефон под управлением iOS будет спрашивать вас, можно ли разрешить приложению доступ к вашим контактам или местоположению, Azure попросит предоставить приложению доступ к необходимым ресурсам. Очевидно, злоумышленник может использовать эту возможность, чтобы обманным путем дать приложению доступ к одному или нескольким конфиденциальным облачным ресурсам.

Как устроена атака

Чтобы выполнить эту атаку, у злоумышленника должно быть непосредственно само веб-приложение и тенант Azure для его размещения. После настройки магазина мы можем начинать фишинговую кампанию, используя ссылку для установки приложения Azure:

Ссылка в электронном письме направляет пользователя на контролируемый злоумышленниками веб-сайт (например, myapp.malicious.com), который, в свою очередь, перенаправляет жертву на страницу входа Microsoft. Процесс проверки подлинности полностью обрабатывается Microsoft, поэтому использование многофакторной проверки подлинности не является решением проблемы.

Как только пользователь входит в свой экземпляр O365, для вредоносного приложения будет создан токен, и пользователю будет предложено авторизоваться и предоставить приложению необходимые разрешения. Вот как это выглядит для конечного пользователя (и должно выглядеть очень знакомо, если пользователь ранее устанавливал приложения в SharePoint или Teams):

Вот разрешения MS Graph API, которые запрашиваются злоумышленником в коде нашего приложения:

Как видите, злоумышленник контролирует имя приложения («MicrosoftOffice») и ярлык (мы использовали ярлык OneNote). URL-адрес является действительным URL-адресом Microsoft, сертификат также действителен.

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

Нажав «Accept», жертва предоставляет нашему приложению разрешения от имени своей учетной записи, то есть приложение сможет читать электронные письма жертвы и получать доступ к любым файлам, к которым есть доступ у жертвы.

Этот шаг является единственным, требующим согласия жертвы, с этого момента злоумышленник имеет полный контроль над учетной записью и ресурсами пользователя.

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

Полученные возможности

Эта атака идеальна для следующих активностей:

• Разведка (получение списка учетных записей, групп, объектов в пользовательском тенанте);
• Внутренний фишинг;
• Кража данных с файловых ресурсов и электронной почты.

Чтобы проиллюстрировать мощь нашего приложения Azure, мы создали забавную консоль для отображения ресурсов, к которым мы получили доступ в рамках проверки нашего PoC (proof of Concept):

Раздел «Me» показывает детали попавшейся жертвы:

Раздел «Users» покажет нам вышеуказанные метаданные для каждого отдельного пользователя в организации, включая адрес электронной почты, номер мобильного телефона, должность и многое другое, в зависимости от атрибутов Active Directory организации. Один только этот вызов API может вызвать массовое нарушение политик защиты персональных данных, особенно в рамках GDPR и CCPA.

Раздел «Calendar» показывает нам события календаря жертвы. Мы также можем назначать встречи от её имени, просматривать существующие встречи и даже удалять будущие встречи.

Возможно, наиболее важным разделом в нашем консольном приложении является раздел «RecentFiles», который позволяет нам видеть любой файл, к которому пользователь обращался в OneDrive или SharePoint. Мы также можем загружать или изменять файлы (включая файлы с вредоносными макросами для развития атаки).

ВАЖНО: когда мы получаем доступ к файлу через этот API, Azure создает уникальную ссылку. Эта ссылка доступна любому человеку из любого места, даже если организация не разрешает анонимный обмен ссылками для рядовых пользователей 365.

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

Раздел «Outlook» дает нам полный доступ к электронной почте жертвы. Мы можем видеть получателей любого сообщения, фильтровать их по приоритету, отправлять электронные письма (внутренний фишинг) и многое другое.

Читая электронные письма жертвы, мы можем выявлять круг её коммуникаций и наиболее уязвимые контакты из этого круга, отправлять внутренние фишинговые письма от имени нашей жертвы и таким образом развивать атаку внутри организации. Мы также можем использовать адреса электронной почты жертвы и контактов из её круга, чтобы отфильтровать данные, которые мы находим в 365.

Более того, у Microsoft есть API, предоставляющий информацию об актуальном круге общения жертвы:

Как мы упоминали выше, мы можем изменять файлы пользователя при наличии соответствующих прав. А что, если мы воспользуемся API для модификации файлов?

Один из вариантов — превратить наше вредоносное приложение Azure в программу-вымогатель, которая удаленно шифрует файлы, к которым у жертвы есть доступ на изменение в SharePoint и OneDrive:

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

Другие источники:

• Кевин Митник представил аналогичный метод облачного шифрования, который применим к почтовым ящикам;
• Krebs On Security также написал хороший пост о такой атаке в своем блоге.

Актуальность проблемы. Как насчет отключения всех сторонних приложений?

Microsoft не рекомендует настраивать запрет пользователям на предоставление разрешений приложениям:

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

Как можно обнаружить злоупотребление приложениями Azure?

Простейший способ обнаружить незаконные разрешения — это отслеживать события предоставления доступа в Azure AD и регулярно просматривать ваши «Enterprise Applications» на портале Azure.

Всегда задавайте себе вопросы:

• Знаю ли я это приложение?
• Принадлежит ли оно организации, которую я знаю?

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

Как удалить вредоносные приложения?

На портале Azure перейдите в раздел «Enterprise Applications» на вкладке «Azure Active Directory» и удалите приложения. Рядовой пользователь может удалить предоставленные ранее разрешения, перейдя по адресу myapps.microsoft.com, проверив перечисленные там приложения и отменив разрешения по мере необходимости.

Для получения подробных инструкций также смотрите официальные рекомендации Microsoft.

Автор оригинала: ERIC SARAGA.

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

Исследовательская группа по безопасности Varonis отреагировала на несколько случаев заражений Qbot в 2019 году, в основном в США. Похоже, что разработчики Qbot не сидели сложа руки: они создавали новые штаммы с новой функциональностью, попутно улучшая возможности предотвращения обнаружения командами, отвечающими за информационную безопасность.

Новый штамм отличается от предыдущего двумя главными деталями:

• Вместо попыток подбора паролей доменного пользователя, этот штамм использует уже скомпрометированного пользователя, чтобы построить карту доступных сетевых папок;
• Он отсылает данные жертвы на сервер FTP, вместо использования POST-запросов HTTP.

Обнаружение. Как он работает

Мы запустили заражённый файл в нашей лаборатории и обнаружили схожие показатели того, что он вредоносен с теми, что были в нашем предыдущем исследовании —внедрение в процесс «explorer.exe», подключение к тем же URL, те же механизмы обеспечения постоянного присутствия в реестре и на диске, и та же замена копии файла на «calc.exe».

Данный штамм содержал зашифрованный конфигурационный файл, с некорректным расширением «.dll». Используя динамический анализ процесса «explorer.exe», мы установили, что ключ для расшифровки зашифрованного RC4 конфигурационного файла — это хэш SHA1 уникальной строки, которую вредонос создаёт для каждого устройства (мы знаем, что это не случайный набор символов, поскольку предыдущая вариация Qbot создала ту же строку для того же устройства).

Вот расшифрованные нами конфигурационные данные для нашего устройства:

Эта конфигурация содержит следующие данные:

• Время инсталляции;
• Время последнего вызова со стороны C2;
• Внешний IP жертвы;
• Список сетевых папок в окружении жертвы.

Фаза I: загрузчик

Имена файлов: JVC_82633.vbs.

SHA1: f38ed9fec9fe4e6451645724852aa2da9fce1be9.

Так же как и предыдущая версия, эта вариация Qbot использовала файл VBS для загрузки основных вредоносных модулей.

Фаза II: обеспечение постоянства присутствия в системе и внедрение в процессы

Ровно как предшествующий образец, загрузчик запускает модули ядра вредоносного ПО и обеспечивает постоянство их присутствия в ОС. Эта версия копирует себя в %Appdata%\Roaming\Microsoft\{Произвольная строка} вместо %Appdata%\Roaming\{Произвольная строка}, но при этом значения ключей реестра и задачи, выполняемые по расписанию, остались идентичными.

Основная полезная нагрузка внедряется во все активные процессы, запущенные от имени пользователя.

Фаза III: кража данных — путь на сервер хакера

После обеспечения присутствия в системе, зловред пытается подключиться к своему C2-серверу по URI content.bigflimz.com. Эта версия собирает важные для своих целей данные с компьютера жертвы и отправляет их по FTP, используя жёстко заданные, прописанные в коде, логин и пароль.

Этот сервер содержал собранные от жертв зашифрованные данные, со следующим принципом именования:"artic1e-*6 символов и после них ещё 6 цифр*-*POSIX-время*.zip".

Мы открыли указанный FTP-сервер и обнаружили эту папку со следующим содержимым:

Мы ещё не смогли расшифровать zip-файлы, чтобы определить, какие данные были украдены.

Устранение последствий и восстановление

Поскольку мы обнаружили лишь одно заражённое устройство, нашими рекомендациями были:

1. Отключить заражённое устройство от сети и стереть данные на диске, после чего настроить окружение в соответствии с тем, что было до заражения;
2. Добавить к функционалу используемых средств ИБ отслеживание сетевых соединений, чтобы быть уверенными, что другие устройства не будут подключаться к IP-адресам, замеченным во вредоносной активности;
3. Обращать пристальное внимание на оповещения от Varonis, особенно относящиеся к поведенческим аномалиям.

Автор оригинала: DOLEV TALER и BEN ZION LAVI.

Перевод: Varonis (https://www.varonis.com/ru/).

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

Как работает ханипот

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

Существует множество креативных и полезных способов, которые придумали защищающиеся, для обнаружения и демаскировки незваных гостей с использованием ханипотов. Например, классическая приманка «Kippo» знаменита своей манерой маскироваться под уязвимую службу SSH, доступную из интернета со слабой учётной записью. Kippo выманивает атакующего своей легкодоступностью, при этом скрытно записывает всю происходящую внутри активность.

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

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

Современные ханипоты могут быть где угодно

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

С помощью бесплатного трекера CanaryToken, защищающийся может встроить отслеживающую ссылку на основе DNS протокола или веб-ссылки, которые запускаются как только открывается PDF-файл. CanaryToken собирает IP-адреса любого, кто пытается открыть отслеживаемый файл, который может содержать конфиденциальную информацию.

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

Другие ханипоты отслеживают украденные учётные данные, принимая форму поддельного логина и пароля (т.н. «Honeycredentials»), хранящихся в файле с «важным» названием в относительно легкодоступном для атакующего месте внутри сети. Если злоумышленник пытается воспользоваться этими учётными данными, защищающейся стороне сразу же приходит уведомление о попытке использовать украденную информацию для получения доступа к аккаунту.

Еще одним применением ханипотов является использование отслеживающих ссылок, чтобы знать, когда атакующий публикует ваши ссылки в Skype, WhatsApp или другом мессенджере. Это возможно благодаря тому, что большинство чат-приложений автоматически переходят по ссылкам, чтобы сгенерировать URL-превью. Несмотря на то, что логируемый IP-адрес принадлежит приложению-мессенджеру, а не атакующему, такая тактика позволяет узнать, передаются ли отслеживаемые ханипот-ссылки кому-то другому или нет, даже если атакующий достаточно умён, чтобы никогда по ним не нажимать.

Ханипотом может воспользоваться кто угодно

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

Трекинговые веб-ссылки легко встраиваются в веб-страницы, запускаемые скрипты или почтовые сообщения и являются бесплатными для всех. Если атакующий открывает ссылку напрямую или через открытие файла, вызывающего URL, защищающийся может узнать информацию об аппаратных, программных и сетевых данных злоумышленника. Даже если атакующий пытается скрыть свой реальный IP-адрес с помощью VPN, информация о его реальной личности всё равно может утечь. Grabify может выявлять такие отличия, как несовпадение часовых поясов или раскладки клавиатуры, несоответствующих месторасположению IP-адреса, или даже обнаруживать использование атакующим VPN или Tor для сокрытия своей информации.

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

Ханипоты генерируют оперативные предупреждения

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

Исследователь в области информационной безопасности Кевин Бюмонт (Kevin Beaumont) развернул RDP ханипот-сеть под названием «BluePot» для выявления в «диких условиях» эксплоитов BlueKeep, чтобы своевременно предупреждать об эксплоитах-червях и предотвращать широкомасштабные атаки наподобие NotPetya и WannaCry.

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

Источник: https://www.varonis.com/ru/

Новая разновидность вредоносного ПО класса вирусов-вымогателей зашифровывает файлы и добавляет к ним расширение «.SaveTheQueen», распространяясь через системную сетевую папку SYSVOL на контроллерах доменов Active Directory.

Наши заказчики столкнулись с этим вредоносом недавно. Приводим наш полный анализ, его результаты и выводы ниже.

Обнаружение

Один из наших заказчиков связался с нами после того, как они столкнулись с новым видом шифровальщика-вымогателя, который добавлял расширение «.SaveTheQueen» к новым зашифрованным файлам в их среде.

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

SYSVOL — это ключевая папка для каждого контроллера домена, используемая для доставки объектов групповых политик (GPO) и скриптов входа и выхода из системы на компьютеры домена. Содержимое данной папки реплицируется между контроллерами домена для синхронизации этих данных на сайтах организации. Запись в SYSVOL требует высоких доменных привилегий, однако, после компрометации, этот актив становится мощным инструментом для атакующих, которые могут использовать его для быстрого и эффективного распространения вредоносной нагрузки по домену.

Цепочка аудита Varonis помогла быстро выявить следующее:

• Инфицированная учетная запись пользователя создавала файл с именем «hourly» в SYSVOL;
• Много файлов журналов создавались в SYSVOL — каждый назван именем доменного устройства;
• Много разных IP-адресов получали доступ к файлу «hourly».

Мы заключили, что файлы журналов использовались для отслеживания процесса заражения на новых устройствах, и что «hourly» — это запускаемое по расписанию задание, которое выполняло вредоносную нагрузку на новых устройствах, используя скрипт Powershell — образцы «v3» и «v4».

Вероятно, атакующий получил и использовал привилегии администратора домена для записи файлов в SYSVOL. На инфицированных узлах атакующий запускал код PowerShell, который создавал задание расписания для того, что открыть, расшифровать и запустить вредоносное ПО.

Расшифровка вредоноса

Мы безрезультатно опробовали несколько способов расшифровки образцов:

Мы уже почти готовы были сдаться, когда решили попробовать способ «Magic» великолепной утилиты Cyberchef авторства GCHQ. «Magic» пытается угадать шифрование файла, используя перебор паролей для разных типов шифрования и измеряя энтропию.

Примечание переводчика.

«Magic» определил, что был использован упаковщик GZip с кодировкой base64, благодаря чему мы смогли распаковать файл и обнаружить код для внедрения — «инжектор».

Дроппер: «В районе эпидемия! Поголовные прививки. Ящур»

Дроппер представлял собой обычный файл .NET без какой-либо защиты. После чтения исходного кода с помощью DNSpy мы поняли, что его единственной целью было внедрение шелл-кода в процесс winlogon.exe.

Шелл-код или простые сложности

Мы использовали инструмент авторства Hexacorn — shellcode2exe для того, чтобы «скомпилировать» шелл-код в исполняемый файл для отладки и анализа. Затем мы обнаружили, что она работал как на 32-, так и на 64-битных машинах.

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

Когда же мы разобрали скомпилированный шелл-код с помощью x64dbg, мы заметили, что он подгружал динамические библиотеки .NET , такие как clr.dll и mscoreei.dll. Это показалось нам странным — обычно злоумышленники стараются сделать шелл-код настолько маленьким, насколько это вообще возможно, вызывая нативные функции ОС вместо их загрузки. Зачем кому-либо нужно встраивать в шелл-код функционал Windows, вместо прямого вызова по запросу?

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

Мы нашли инструмент Donut, который, как нам показалось, мог скомпилировать похожий шелл-код. Вот его описание с GitHub:

Donut генерирует шелл-код x86 или x64 из VBScript, JScript, EXE, DLL (включая сборки .NET). Этот-шелл-код может быть внедрён в любой процесс Windows для выполнения в оперативной памяти.

Для подтверждения нашей теории мы скомпилировали наш собственный код, используя Donut, и сравнили его с образцом — и… да, мы обнаружили ещё один компонент использованного инструментария. После этого, мы уже смогли извлечь и проанализировать оригинальный исполняемый файл на .NET.

Защита кода

Этот файл был обфусцирован с помощью ConfuserEx:

ConfuserEx — это .NET проект с открытым кодом для защиты кода других разработок. ПО этого класса позволяет разработчикам защищать свой код от реверс-инжиниринга с помощью таких способов, как: замена символов, маскировка потока команд управления и скрытие ссылочного метода. Авторы вредоносного ПО используют обфускаторы с целью избежания обнаружения и чтобы сделать более трудной задачу реверс-инжиниринга.

Благодаря ElektroKill Unpacker мы распаковали код:

Сам процесс выглядит следующим образом:

1. Вредонос изучает локальные и подключенные диски на устройстве жертвы:

2. Ищет файлы для шифрования:

3. Пытается завершить процесс, использующий файл, который он собирается зашифровать.

4. Переименовывает файл в «Исходное_имя_файла.SaveTheQueenING», используя функцию MoveFile, и зашифровывает его.

5. После того, как файл зашифрован открытым ключом автора, вредонос снова переименовывает его, теперь в «Исходное_имя_файла.SaveTheQueen».

6. Происходит запись файла с требованием выкупа в ту же папку:

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

Вирус-шифровальщик НЕ шифрует файлы, хранящиеся в директориях:

• C:\Windows
• C:\Program Files
• C:\Program Files (x86)
• C:\Users\AppData
• C:\inetpub

Также он НЕ шифрует следующие типы файлов: EXE, DLL, MSI, ISO, SYS, CAB.

Итоги и выводы

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

Мы думаем, что автор вредоноса:

• Написал вирус-вымогатель со встроенным внедрением в процесс winlogon.exe, а также функциональностью шифрования и расшифровки файлов;
• Замаскировал вредоносный код с помощью ConfuserEx, преобразовал результат с помощью Donut и дополнительно скрыл дроппер base64 Gzip;
• Получил повышенные привилегии в домене жертвы и использовал их для копирования зашифрованного вредоноса и заданий по расписанию в сетевую папку SYSVOL контроллеров домена;
• Запустил скрипт PowerShell на устройствах домена для распространения вредоноса и записи прогресса атаки в журналы в SYSVOL.

Если Вас заинтересовал данный продукт или любой другой, или у вас есть вопросы, вы можете запросить у нас презентацию.