Статья Приключения неуловимой малвари

[tabac]

Этой статьей мы начинаем серию публикаций о неуловимых малвари. Программы для взлома, не оставляющие следов атаки, известные также как fileless («бестелесные», невидимые, безфайловые), как правило, используют PowerShell на системах Windows, чтобы скрытно выполнять команды для поиска и извлечения ценного контента. Обнаружить хакерскую деятельность без вредоносных файлов — сложно выполнимая задача, т.к. антивирусы и многие другие системы обнаружения работают на основе сигнатурного анализа. Но хорошая новость состоит в том, что такое ПО все же существует. Например, UBA-системы, способные обнаружить вредоносную активность в файловых системах.
Когда я впервые начал изучать тему крутых хакеров, не использующих традиционные способы заражения, а лишь доступные на компьютере жертвы инструменты и программное обеспечение, я и не подозревал, что вскоре это станет популярным способом атаки. Профессионалы в области безопасности говорят, что это становится трендом, а пугающие заголовки статей – тому подтверждение. Поэтому я решил сделать серию публикаций на эту тему.


Великий и ужасный PowerShell

Я писал о некоторых из этих идей раньше в серии обфускации PowerShell, но больше исходя из теоретического представления. Позже я наткнулся на сайт для гибридного анализа, где можно найти образцы малвари, «отловленной» в дикой природе. Я решил попробовать использовать этот сайт для поиска образцов fileless-вредоносов. И мне это удалось. Кстати, если вы захотите отправиться в свою собственную экспедицию по поиску вредоносных программ, вам придется пройти проверку на этом сайте, чтобы они знали, что вы делаете работу как white hat специалист. Как блогер, который пишет о безопасности, я прошел ее без вопросов. Я уверен, вы тоже сможете.

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

В случае с PowerShell и другими образцами сценариев (Visual Basic, JavaScript и т. д.), я смог увидеть и сам код. Например, я наткнулся на такой PowerShell экземпляр:

Вы также можете запустить PowerShell в кодировке base64, чтобы избежать обнаружения. Обратите внимание на использование Noninteractive и Hidden параметров.

Если вы прочитали мои записи по обфускации, то вы знаете, что параметр -e указывает на то, что содержимое кодируется в base64. Кстати, гибридный анализ помогает также и с этим, декодируя все обратно. Еcли вы захотите попробовать декодировать base64 PowerShell (далее – PS) самостоятельно, нужно выполнить эту команду:

 [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($EncodedText))

Вникай глубже

Я декодировал наш PS-сценарий с помощью этого метода, ниже представлен текст программы, правда слегка мной модифицированный:

Заметьте, что скрипт был привязан к дате 4 сентября 2017 и передавал сессионные cookies.

Я писал об этом стиле атаки в серии по обфускации PS, в которой кодированный в base64 скрипт сам загружает недостающие вредоносные программы с другого сайта, задействуя из библиотеки .Net Framework объект WebClient, чтобы сделать всю тяжелую работу.

Для чего это нужно?

Для программного обеспечения безопасности, сканирующего журналы событий Windows или файерволла, кодировка base64 предотвращает обнаружение строки «WebClient» по простому текстовому шаблону в целях защиты от выполнения такого веб-запроса. И так как все «зло» вредоносного ПО затем загружается и передается в наш PowerShell, этот подход таким образом позволяет полностью уклоняться от обнаружения. Вернее, это я так думал сначала.

Оказывается, с включением продвинутого логирования журнала Windows PowerShell (см. мою статью ) вы сможете увидеть загруженную строку в журнале событий. Я (как и другие ) считаю, что Microsoft следует включить данный уровень ведения журнала по умолчанию. Поэтому при включенном расширенном логировании мы увидим в журнале событий Windows выполненный запрос загрузки из PS скрипта по примеру, который мы разобрали выше. Поэтому имеет смысл его активировать, согласны?


Добавим дополнительные сценарии

Хакеры ловко скрывают атаку PowerShell в макросах Microsoft Office, написанных на Visual Basic и на других скриптовых языках. Идея заключается в том, что жертва получает сообщение, например, от службы доставки, с вложенным отчетом в формате .doc. Вы открываете этот документ, который содержит макрос, и в конечном итоге он сам запускает вредоносный PowerShell.

Часто сам сценарий Visual Basic обфусцируется так, что он свободно уклоняется от антивирусов и других сканеров вредоносных программ. В духе уже изложенного, я решил в качестве упражнения закодировать приведенный выше PowerShell в JavaScript. Ниже результаты моей работы:

Обфусцированный JavaScript, прячущий наш PowerShell. Реальные хакеры делают это на раз-два.

Это еще одна из техник, которую я встретил на просторах сети: использование оболочки Wscript.Shell для запуска кодированного PowerShell. Кстати, JavaScript сам по себе является средством доставки вредоносных программ. Многие версии Windows имеют встроенный Windows Script Host, который сам умеет запускать JS.
В нашем случае, вредоносный скрипт JS вложен как файл c .doc.js расширением. Windows, как правило, показывает только первый суффикс, поэтому он будет отображаться жертве как документ Word.

Значок JS отображается только в иконке в виде свитка. Неудивительно, что многие люди будут открывать это вложение, думая, что это Word-документ.


В моем примере я изменил приведенный выше PowerShell, чтобы загрузить сценарий с моего веб-сайта. Удаленный сценарий PS просто печатает «Evil Malware». Как видите, он совсем не злой. Конечно, реальные хакеры заинтересованы в получении доступа к ноутбуку или серверу, скажем, через командую оболочку. В следующей статье я покажу, как это сделать, используя PowerShell Empire.

Автор: varonis

 

[tabac]

Приключения неуловимой малвари, часть II: скрытные VBA-скрипты

Я поклонник сайта гибридного анализа (hybrid analysis, далее HA). Это своего рода зоопарк вредоносов, где вы можете спокойно наблюдать за дикими «хищниками» c безопасного расстояния, не подвергаясь нападению. HA запускает вредоносное ПО в безопасных средах, записывает системные вызовы, создаваемые файлы и интернет-трафик, и выводит вам все эти результаты для каждого анализируемого образца. Таким образом, вы можете не тратить свое время и силы, самостоятельно разгадывая запутанный код, а сразу же понять все намерения хакеров.

Примеры HA, которые привлекли мое внимание, используют либо закодированный JavaScript или скрипты Visual Basic для Приложений (VBA), встроенные как макрос в документы Word или Excel, и прикладываемые к фишинговым письмам. При открытии эти макросы запускают сеанс PowerShell на компьютере жертвы. Хакеры обычно отправляют в PowerShell поток команд в кодировке Base64. Это все сделано для того, чтобы сделать атаку трудной для обнаружения веб-фильтрами и антивирусным ПО, реагирующими на определенные ключевые слова.

К счастью, HA автоматически декодирует Base64 и сразу показывает все в читаемом виде. По сути, вам не нужно фокусироваться на том, как эти сценарии работают, потому что вы сможете видеть полный вывод команд для запускаемых процессов в соответствующем разделе HA. См. пример ниже:

Гибридный анализ перехватывает команды, закодированные в Base64, отправляемые в PowerShell:

… и затем декодирует их для вас. #волшебно

В предыдущем посте я создал свой собственный слегка обфусцированный JavaScript контейнер для запуска сеанса PowerShell. Затем мой сценарий, как и множество вредоносных программ на основе PowerShell, загружает следующий сценарий PowerShell с удаленного веб-сайта. Тогда в качестве примера я загружал безвредный PS, печатающий сообщение на экране. Но времена меняются, и теперь я предлагаю усложнить сценарий.


PowerShell Empire и Обратный Шелл

Одна из целей этого упражнения, показать, как (относительно) легко хакер может обойти классические средства защиты периметра и антивирусы. Если ИТ-блогер без навыков программирования, такой как я, за пару вечеров может создать необнаруживаемый вредонос (fully undetected, FUD), представьте себе возможности заинтересованного в этом юного хакера!

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

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

Как-то я уже писал о пост-эксплуатационной среде выполнения PowerShell Empire. Давайте вспомним, что это такое.

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

Давайте проведем маленький эксперимент. Я настроил безопасную среду для тестирования вредоносных программ в облаке Amazon Web Services. Вы можете последовать моему примеру, чтобы быстро и безопасно показать работающий пример данной уязвимости (и не быть уволенным за запуск вирусов внутри периметра предприятия).

Если вы запустите консоль PowerShell Empire, то увидите примерно следующее:

Сперва вы запускаете процесс listener на вашем хакерском компьютере. Введите команду «listener», и укажите IP-адрес вашей системы с помощью «set Host». Затем запустите процесс listener командой «execute» (ниже). Таким образом вы запустите со своей стороны ожидание сетевого соединения от удаленного шелла:

Для другой стороны вам нужно будет сгенерировать агентский код, введя команду «launcher» (см.ниже). Это сгенерирует PowerShell-код для удаленного агента. Обратите внимание, что он кодируется в Base64, и представляет собой вторую фазу полезной нагрузки. Другими словами, мой JavaScript-код теперь вытянет этого агента для запуска PowerShell вместо безобидного вывода текста на экран и подключится к нашему удаленному серверу PSE для запуска обратного шелла.

Магия обратного шелла. Эта закодированная команда PowerShell соединится с моим listener и запустит удаленную оболочку.

Чтобы показать вам этот эксперимент, я взял на себя роль невинной жертвы и открыл Evil.doc, тем самым запустив наш JavaScript. Помните первую часть? PowerShell был настроен так, чтобы его окно не всплывало, поэтому жертва не заметит ничего необычного. Тем не менее, если вы откроете Диспетчер задач Windows, вы увидите фоновый процесс PowerShell, который все равно у большинства не вызовет никакой тревоги. Потому что это обычный PowerShell, не правда ли?

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

Затем я ввел команду «interact», чтобы открыть оболочку в PSE – и вот он я! Короче говоря, я взломал сервер Taco, который сам и настроил когда-то.

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

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


Вернемся к реальности

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

Вредоносная программа, которую я в конечном итоге нашел на HA, это \скрипт VBA, который был встроен в документ Word. То есть мне не нужно даже подделывать расширение doc, это вредоносное ПО действительно самый обычный с виду документ Microsoft Word. Если вам интересно, то я выбрал вот этот образец, называемый rfq.doc.

Я быстро узнал, что зачастую вы не сможете напрямую вытащить из документа вредоносные сценарии VBA. Хакеры сжимают и прячут их, и они не видны во встроенных макро-инструментах Word. Вам понадобится специальный инструмент для его извлечения. К счастью, я наткнулся на сканнер OfficeMalScanner Фрэнка Болдуина. Спасибо тебе, Фрэнк.

Используя этот инструмент, я смог вытащить сильно запутанный код VBA. Он выглядел как-то так:

Обфускация была сделана профессионалами своего дела. Я был впечатлен!

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

Автор: varonis

 

[tabac]

Приключения неуловимой малвари, часть III: запутанные VBA-cкрипты для смеха и прибыли

В последних двух постах (тут и тут) мы говорили о безфайловых, но при этом довольно безобидных методах атаки. Теперь мы готовы, наконец, взяться за настоящую 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, и большие перспективы для средств поведенческой аналитики.

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

В следующей части мы рассмотрим более продвинутые типы безфайловых атак.

Автор: varonis

 

[tabac]

Приключения неуловимой малвари, часть IV: DDE и поля документа Word

В этой статье я собирался погрузиться в еще более сложный многоэтапный cценарий безфайловой атаки с закреплением в системе. Но тут я наткнулся на невероятно простую атаку без кода — не требуется никаких макросов Word или Excel! И это гораздо более эффективно доказывает мою изначальную гипотезу, лежащую в основе этой серии статей: преодолеть внешний периметр любой организации – совсем несложная задача.
Первая атака, которую я опишу, использует уязвимость Microsoft Word, которая основана на устаревшем протоколе динамического обмена данными (DDE). Она уже была исправлена. Вторая использует более общую уязвимость в Microsoft COM и возможности передачи объектов.


Назад в будущее с DDE

Кто-нибудь еще помнит DDE? Вероятно, немногие. Это был один из первых протоколов взаимодействия между процессами, который позволял приложениям и устройствам передавать данные.

Я сам немного знаком с ним, потому что раньше я проверял и тестировал телеком-оборудование. В то время DDE позволял, например, передавать для операторов колл-центров идентификатор звонящего абонента в CRM приложение, которое в конечном итоге открывало карточку клиента. Для этого вы должны были подключить кабель RS-232 между телефоном и компьютером. Вот были деньки!

Как оказалось, Microsoft Word все еще поддерживает DDE.

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

Коды полей – это еще одна древняя функция MS Word, которая позволяет добавлять динамический текст и немного программирования в документ. В качестве самого очевидного примера можно привести поле «номер страницы», который можно вставить в нижний колонтитул с помощью значения {PAGE \*MERGEFORMAT}. Это позволяет автоматическим образом генерировать номера страниц.

Подсказка: вы сможете найти пункт меню Полe (Field) в разделе Вставка (Insert)

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

В итоге, хакеры поняли, что этим приложением DDE может быть командная оболочка, которая, конечно же, запускает PowerShell, а оттуда хакеры могут делать всё, что им угодно.
На скриншоте ниже видно, как я использовал данную скрытную технику: маленький сценарий PowerShell (далее – PS) из поля DDE загружает другой PS скрипт, который запускает вторую фазу атаки.

Спасибо Windows за всплывающее предупреждение, о том что встроенное поле DDEAUTO скрытно пытается запустить оболочку

Предпочтительным методом эксплуатации уязвимости является использование варианта с полем DDEAUTO, которое автоматически запускает сценарий при открытии документа Word.
Давайте подумаем, что с этим можно сделать.

Как начинающий хакер, вы можете, например, отправить фишинговое письмо, притворившись, что вы из ФНС, и встроить поле DDEAUTO со скриптом PS для первого этапа (дроппер по сути). Причем вам даже не нужно делать никакого реального кодирования макросов и пр., как я это делал в предыдущей статье.

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

И прежде, чем жертва успеет произнести хоть что-то, хакеры окажутся самыми богатыми подростками на селе.

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

DDE и поля

Позже Microsoft все-таки отключила DDE в Word, но перед этим компания заявила, что эта функция была просто неправильно использована. Их нежелание что-то менять понятно. Из своего опыта я сам наблюдал такой пример, что обновление полей при открытии документа было включено, но макросы Word были отключены ИТ-службой (но с показом уведомления). Кстати, соответствующие параметры вы сможете найти в разделе настроек Word.

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

Но скорее всего, пользователи все равно пропустят это предупреждение и активируют обновление полей в Word. Это одна из редких возможностей поблагодарить Microsoft за отключение опасной функции DDE.

Насколько трудно сегодня найти непропатченную систему Windows?

Для этого тестирования я использовал среду AWS Workspaces для получения доступа к виртуальному рабочему столу. Таким образом я получил непропатченную виртуальную машину с MS Office, которая позволила мне вставить поле DDEAUTO. Не сомневаюсь, что подобным же образом можно найти и другие компании, которые до сих пор не установили нужные патчи безопасности.

Тайна предметов

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

Чтобы понять этот сценарий, давайте вспомним Модель компонентного объекта Microsoft, или сокращенно COM (Component Object Model).

COM существует с 1990-х годов, и определяется как «нейтральная к языку программирования объектно-ориентированная модель компонентов» на основе удаленных вызовов процедур RPC. Для общего понимания терминологии COM прочтите этот пост на StackOverflow.

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

Оказывается, COM-приложение также может запускать сценарий — JavaScript или VBScript. Технически это называется скриптлет. Возможно, вы встречали расширение.sct у файлов в Windows – это и есть официальное расширение для скриплетов. По сути, они являются кодом скрипта, заключенного в XML обертку:

<?XML version="1.0"?>

<scriptlet>
<registration
description="test"
progid="test"
version="1.00"
classid="{BBBB4444-0000-0000-0000-0000FAADACDC}"
remotable="true">
</registration>
<script language="JScript">
<![CDATA[

var r = new ActiveXObject("WScript.Shell").Run("cmd /k powershell -c Write-Host You have been scripted!");

]]>
</script>
</scriptlet>

Хакеры и пентестеры обнаружили, что есть отдельные утилиты и приложения в Windows, которые принимают COM-объекты и, соответственно, скриптлеты тоже.

Я могу передать скриптлет в утилиту Windows, написанную на VBS, известную как pubprn. Она находится в недрах C:\Windows\system32\Printing_Admin_Scripts. Кстати, есть и другие утилиты Windows, которые принимают объекты в качестве параметров. Для начала рассмотрим этот пример.

Вполне естественно, что оболочку можно запустить даже из сценария печати. Вперед, Microsoft!

В качестве тестирования я создал простой удаленный скриптлет, который запускает оболочку и печатает забавное сообщение «Вас только что проскриптовали!». По сути, pubprn создает экземпляр объекта scriptlet, позволяя коду VBScript запустить оболочку. Данный метод предоставляет явные преимущества хакерам, которые хотят незаметно проникнуть и спрятаться в вашей системе.

В следующем посте я объясню, как скриптлеты COM могут быть использованы хакерами с помощью таблиц Excel.

Вам в качестве домашней работы – посмотреть это видео с Derbycon 2016 года, которое объясняет, как именно хакеры использовали скриптлеты. А также прочитать эту статью про скриптлеты и какой-то моникер.

Автор: varonis

 

[tabac]

Приключения неуловимой малвари, часть V: еще больше DDE и COM-скриплетов

В этой серии статей мы изучаем методы атак, которые предполагают минимальные усилия со стороны хакеров. В прошлой статье мы рассмотрели, что можно вставить сам код в полезную нагрузку автоматического поля DDE в Microsoft Word. Открыв такой документ, вложенный в фишинговое письмо, неосторожный пользователь сам позволит злоумышленнику закрепиться на своем компьютере. Однако в конце 2017 года Microsoft закрыла данную лазейку для атак на DDE.

Исправление добавляет запись реестра, которая отключает функции DDE в Word. Если же вам все же нужна данная функциональность, то вы можете вернуть этот параметр, включив старые возможности DDE.

Однако оригинальный патч охватывал только Microsoft Word. Существуют ли эти DDE-уязвимости в других продуктах Microsoft Office, которые также можно было бы использовать в атаках без лишнего кода? Да, конечно. Например, вы также можете найти их в Excel.


Ночь живых DDE

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

А пока давайте разберемся с очередной злой стороной DDE в версии для Excel. Так же, как и в Word, некоторые скрытые возможности DDE в Excel позволяют вам выполнить код без особых усилий. Как выросший на Word пользователь, я был знаком с полями, но совсем не знал о функциях в DDE.

Я был поражен, узнав, что в Excel я могу вызвать командную оболочку из ячейки, как показано ниже:

Вы знали, что так было можно? Лично я – нет


Эта возможность запустить оболочку Windows любезно предоставлена нам DDE. Можно придумать много других приложений, к которым вы можете подключиться с помощью встроенных в Excel функций DDE. Вы думаете о том же, о чем и я?

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

Просто вставить чуть-чуть PowerShell для загрузки и выполнения удаленного кода в Excel


Но есть нюанс: вы должны явно ввести эти данные в ячейку, чтобы эта формула выполнилась в Excel. Как же хакер сможет выполнить эту команду DDE удаленно? Дело в том, что когда таблица Excel открыта, то Excel попытается обновить все ссылки в DDE. В настройках Trust Center уже давно есть возможность отключить это или предупреждать при обновлении ссылок на внешние источники данных.

Даже без последних патчей можно отключить автоматическое обновление ссылок в DDE


Microsoft первоначально сам советовал компаниям в 2017 году отключить автоматические обновления ссылок, чтобы предотвратить уязвимости DDE в Word и Excel. В январе 2018-го Microsoft выпустил патчи для Excel 2007, 2010 и 2013, которые по умолчанию отключают DDE. Эта статья в Computerworld живописует все детали патча.


Ну а что же журналы событий?

Microsoft все же отказалась от DDE для MS Word и Excel, признав тем самым, наконец, что DDE больше похож на баг, чем на функциональность. Если же вы по какой-либо причине еще не установили эти исправления, то вы все равно можете уменьшить риск атаки на DDE, отключив автоматическое обновление ссылок и включив параметры, которые запрашивают пользователей об обновлении ссылок при открытии документов и электронных таблиц.

А теперь вопрос на миллион: если вы стали жертвой данной атаки, будут ли сеансы PowerShell, запущенные из полей Word или ячейки Excel, отображаться в журнале?

Вопрос: логируются ли сеансы PowerShell запущенные через DDE? Ответ: да


Когда вы запускаете сеансы PowerShell непосредственно из ячейки Excel, а не как макрос, Windows будет регистрировать эти события (см. выше). При этом я не берусь утверждать, что службе безопасности будет легко потом соединить все точки между сеансом PowerShell, документом Excel и почтовым сообщением и понять, где же было начало атаки. Я еще вернусь к этому в последней статье моей нескончаемой серии о неуловимой малвари.


Как там наш COM?

В предыдущей статье я затрагивал тему скриплетов COM. Сами по себе они являются удобной технологией, которая позволяет вам передавать код, скажем, JScript, просто как объект COM. Но затем скриптлеты обнаружили хакеры, и это позволило им закрепляться на компьютере жертвы без использования лишних инструментов. Это видео с конференции Derbycon демонстрирует встроенные инструменты Windows, например, regsrv32 и rundll32, которые принимают удаленные скриптлеты в качестве аргументов, и хакеры, по сути, проводят свою атаку без помощи вредоносных программ. Как я показывал в прошлый раз, вы можете легко запускать команды PowerShell с помощью скриптлета на JScript.

Выяснилось, что один очень сообразительный исследователь нашел способ запуска скриплета COM в документе Excel. Он обнаружил, что при попытке вставить в ячейку ссылку на документ или рисунок, в нее вставляется некий пакет. И этот пакет спокойно принимает на вход удаленный scriptlet (см. ниже).

Бум! Еще один скрытный бесшумный метод для запуска оболочки с помощью скриптлетов COM


После низкоуровневой инспекции кода исследователь выяснил, что это на самом деле баг в программном обеспечении пакета. Он не предназначался для запуска скриплетов COM, а лишь для ссылок на файлы. Я не уверен, существует ли уже патч для этой уязвимости. В моем собственном исследовании на виртуальном рабочем столе Amazon WorkSpaces с предустановленным пакетом Office 2010 я смог воспроизвести его результаты. Однако, когда я чуть позже попробовал снова, у меня уже не получилось.

Я очень надеюсь, что рассказал вам много интересного и в то же время показал, что хакеры могут проникнуть таким или другим похожим способом и в вашу компанию. Даже если вы устанавливаете все последние патчи Microsoft у хакеров по-прежнему много инструментов для закрепления в системе: начиная от макросов VBA, с которых я начинал эту серию, и вплоть до вредоносной нагрузки в Word или Excel.

В последней (я обещаю) статье этой саги, я расскажу о том, как обеспечить разумную защиту.

Автор: varonis

 

[tabac]

Приключения неуловимой малвари: многосторонняя оборона (заключительные мысли)

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

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

Я имею в виду понятие многосторонняя оборона (Defense In-Depth, или DiD). Это очень практичный подход к борьбе с продвинутыми хакерами, которые смеются над средствами защиты периметра и программным обеспечением для сканирования подписи файла.

Есть ли у DiD проблемы? Конечно. Те же самые профессионалы в области безопасности, которые сперва потеряли веру в традиционные меры защиты, теперь продвигают белый cписок приложений, которые могут быть вам полезны, особенно после факта первоначального проникновения.

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

Вопрос: Можете ли вы обойти средства защиты безопасности Windows, тайком передавая команды в regsvr32.exe? Ответ: да


Серьезно о безопасности данных

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

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


Защита здравого смысла

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

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

• Оцените риски путем инвентаризации того, что вам нужно защитить. Обозначьте персональные и другие конфиденциальные данные, которые, как правило, разбросаны по всей файловой системе. Вы должны выяснить, кто работает с ними и кто действительно должен иметь к ним доступ. Предостережение: это не так-то уж и легко сделать, как может показаться, но если у вас есть подходящие инструменты, то вы справитесь;
• Защитите данные. Теперь, когда вы нашли данные, ограничьте потенциальный ущерб будущих нарушений: сократите слишком широкий и глобальный доступ на основе групп, упростите структуры разрешений и избегайте прямых прав на уровне пользователя. Минимизируйте общий потенциальный риск, удаляя устаревшие данные и архивируя данные, которые больше не нужны активно в работе;
• Поддерживайте безопасное состояние, автоматизируя рабочие процессы предоставления доступа, регулярной проверки и аттестации прав, а также хранения данных на основании политик;
• И, наконец, постоянно проводите мониторинг необычного поведения пользователей и систем.

Автор: varonis