Инструменты разработчика · Кодер и декодер Base64
Как декодировать подозрительную команду PowerShell Base64, не запуская ее
· Почему это важно
base64 безопасность
Злоумышленники используют Base64, чтобы скрыть сценарии от случайного просмотра. В этом посте показано, как декодировать полезную нагрузку -EncodedCommand без ее выполнения, почему выходные данные могут выглядеть странно в декодере UTF-8 и на что обращать внимание.
Запланированная задача с аргументом из символов 2,000 — где появляются закодированные команды и почему они являются красным флагом
Сисадмин обнаруживает запланированную задачу с помощью 2,000-характер -EncodedCommand аргумент, который выглядит подозрительно. Задача выполняется под учетной записью службы с высокими привилегиями.
Соблазн вставить команду в PowerShell и запустить ее, чтобы посмотреть, что она делает, опасен; если команда вредоносная, ее выполнение поставит под угрозу систему. Более безопасный подход — локально декодировать Base64 и прочитать вывод в виде текста, прежде чем решать, запускать ли что-либо. В этом посте объясняется, как безопасно декодировать команды PowerShell без их выполнения, почему выходные данные могут выглядеть искаженными в стандартном декодере UTF-8 и на что следует обратить внимание, чтобы оценить, является ли команда безопасной или подозрительной.
Декодируйте, никогда не выполняйте — правило, которое обеспечивает безопасность анализа, и почему декодер только для браузера хорошо подходит
Ключевой момент заключается в том, что PowerShell использует кодировку UTF-16LE для -EncodedCommand, а не UTF-8, поэтому каждый второй байт представляет собой ноль, который стандартные инструменты интерпретируют как нулевой терминатор. Правило анализа любого подозрительного кода простое: декодируйте, но никогда не выполняйте. Это относится к командам в кодировке Base64, сжатым сценариям, сценариям из ненадежных источников и всему, что находится в цепочке незнакомой кодировки. Выполнение сценария — это точка невозврата; как только он запустится, в системе произошли изменения, доступ был предоставлен, а данные были удалены.
Декодирование и чтение сценария в виде текста позволяет оценить его перед необратимым шагом. Второе правило — использовать инструмент, который работает локально и не отправляет запросы по сети. Браузерный декодер идеален, поскольку он портативен, не требует дополнительного программного обеспечения и сохраняет подозрительную полезную нагрузку на вашем устройстве, не загружая ее на какой-либо сервер. Если этот инструмент отправляет сообщения в удаленную службу декодера, не используйте его; полезная нагрузка затем предоставляется этой службе. Параметр PowerShell -EncodedCommand принимает строку Base64, которая при декодировании содержит сценарий PowerShell.
Почему декодированные байты отличаются от текста UTF-8 — проверьте шаблон байтов UTF-16LE в шестнадцатеричном виде, а не просите этот текстовый инструмент UTF-8 интерпретировать его.
Однако PowerShell не использует для этого кодировку UTF-8; он использует UTF-16LE (с прямым порядком UTF-16). В UTF-16 каждый символ ASCII представлен двумя байтами: код символа, за которым следует нулевой байт. Буква A — это 41 00 в шестнадцатеричном формате. Буква B — 42 00. Строка типа Hello отображается как 48 00 65 00 6C 00 6C 00 6F 00 в UTF-16LE байты. Если это кодировка Base64, результат содержит закодированную форму всех этих байтов, включая все нули. Декодирование с помощью стандартного декодера UTF-8 приводит к искажению текста или усечению первого нулевого байта, поскольку UTF-8 обрабатывает нулевые байты как ограничители строки.
Вывод выглядит как Привет вместо Привет, с кажущимися случайными символами или отсутствующим текстом. Проработанный пример показывает проблему и решение. Предположим, что команда PowerShell кодирует простую строку Write-Host Hello. PowerShell UTF-16LE кодирует это в байты, включая все нули, Base64 кодирует байты и создает длинную строку, например VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA. Скопируйте эту строку в кодировщик и декодер Base64 в своем браузере и нажмите «Декодировать». Декодер по умолчанию попытается интерпретировать результат как текст UTF-8 и выдать поврежденный или усеченный вывод из-за встроенных нулей.
Рабочий пример: декодирование безобидной закодированной команды — чтение текста после чередующихся нулевых байтов.
Решение состоит в том, чтобы вместо этого использовать шестнадцатеричное представление. Переключитесь в шестнадцатеричный вид, и вы увидите байты: 57 00 72 00 69 00 74 00 65 00 2D 00 4B 00 6F 00 73 00 68 00 20 00 22 00 48 00 65 00 6C 00 6C 00 6F 00 22 00. Чтение этих байтов как пар UTF-16LE дает W-r-i-t-e---K-o-s-h---H-e-l-l-o-. С опытом вы сможете читать шестнадцатеричный код UTF-16LE напрямую или записать байты в файл и декодировать их с помощью сценария PowerShell или Python, запускаемого локально.
Практический подход — обратить внимание на шаблон и помнить, что PowerShell использует UTF-16LE. Если вы декодируете PowerShell -EncodedCommand в браузере и результат выглядит неправильно, посмотрите на шестнадцатеричное представление, а не на текстовое. Шестнадцатеричное представление показывает каждый байт индивидуально. Каждый символ ASCII отображается как два байта с нулем между ними. Если в байтах записаны вредоносные команды, такие как New-AdminAccount, обратный поиск DNS или экспорт учетных данных безопасности, команда является подозрительной. Если байты содержат что-то безобидное, например список каталогов или простой сценарий, команда, скорее всего, безвредна.
Вложенное кодирование и сжатие — Base64 внутри Base64 и потоки gzip, которые нельзя прочитать как текст.
Шестнадцатеричное представление труднее читать, чем обычный текст, но оно безопаснее, чем гадать по поврежденному выводу UTF-8. Вложенное кодирование и сжатие усложняют анализ вредоносного ПО. Команда PowerShell может закодировать в Base64 другую строку Base64 или сжать сценарий с помощью gzip, а затем закодировать результат в Base64. Во вложенном сценарии вы декодируете внешний Base64, читаете результат и обнаруживаете, что это сам Base64. Раскодируйте и его и продолжайте, пока не найдете читаемый текст или двоичный формат, который вы не сможете интерпретировать. Gzip и другие форматы сжатия начинаются с магических байтов (1F 8B для gzip), видимых в шестнадцатеричном представлении.
Если вы декодируете Base64 и шестнадцатеричное представление начинается с 1F 8B, байты представляют собой сжатый поток, требующий распаковки. Кодер и декодер Base64 показывает шестнадцатеричный код, помогая идентифицировать эти шаблоны, не выполняя никаких действий. Сжатые или дополнительно закодированные полезные данные вызывают подозрение, поскольку они добавляют слои обфускации.
Что записывать в отчет об инциденте — расшифрованный текст, источник и хэши, а не саму полезную нагрузку.
Законные команды редко требуют нескольких этапов кодирования. Запись результатов для отчета об инциденте требует дисциплины и точности. Запишите точную строку Base64, которую вы проанализировали, где вы ее нашли и когда. Если вы его расшифровали и обнаружили подозрительные команды, опишите команды, но пока не включайте в отчет полный скрипт; сценарий может быть сложным или длинным.
Включите хеш (SHA-256) декодированного сценария, чтобы можно было проверить и отследить обнаружение. Если команда явно вредоносная или использует известные методы эксплуатации, прежде чем предпринимать какие-либо действия, привлеките группы реагирования на инциденты и службы безопасности. Никогда не выполняйте команду самостоятельно, чтобы увидеть, что она делает. Если специалистам по реагированию на инциденты необходимо выполнить его для тестирования, они делают это в изолированной среде, где любой ущерб локализован. Ваша задача — расшифровать и оценить риск на безопасном расстоянии. В этой статье не рассматривается полный спектр анализа вредоносного ПО, изолированных сред и определения причин атак.
Что сюда не входит: выполнение в песочнице, инструменты анализа вредоносного ПО и атрибуция.
Это темы для специалистов по безопасности и групп реагирования на инциденты. Целью здесь является безопасное декодирование закодированной команды PowerShell без ее выполнения, чтобы вы могли прочитать сценарий и оценить, стоит ли его исследовать дальше. Кодировка Base64 — это запутывание, а не защита. Любой, у кого есть кодировка и декодер, может извлечь сценарий. Злоумышленники используют Base64, чтобы избежать обычного обнаружения и предотвратить случайную проверку, а не скрыть свои намерения от анализа. Декодированная команда PowerShell, которая извлекает и выполняет удаленный сценарий, является вредоносной независимо от того, декодируете ли вы ее самостоятельно или это делает инструмент безопасности.
Следующий практический шаг после расшифровки подозрительной команды — сообщить о ней соответствующей команде. Если это ваша собственная система, определите, была ли задача создана намеренно и кем. Проверьте дату создания и учетную запись, которая его запланировала. Если задача неавторизована, отключите ее, сохраните данные для криминалистической экспертизы и выясните, как злоумышленник получил привилегию на ее создание. Если команда содержит сетевые запросы или механизмы сохранения, такие как изменение реестра или создание запланированных задач, она почти наверняка является вредоносной.
Вывод: Base64 — это запутывание, а не защита: как кодировщик и декодер Base64 декодирует полезную нагрузку локально, не покидая вашей машины.
Если он выполняет законные функции администрирования и детали создания в порядке, это может быть законный административный сценарий, который закодирован по причинам, связанным с политикой безопасности или интеграцией с более крупным инструментом автоматизации. Ни в коем случае не выполняйте его; пусть ваша оценка декодированного текста повлияет на ваше решение. Безопасное декодирование подозрительных команд Base64 PowerShell выполняется в соответствии с простым процессом. Используйте кодировщик и декодер Base64 для декодирования строки, не загружая ее и не выполняя ничего. Посмотрите на шестнадцатеричное представление, чтобы понять, что представляют собой байты.
Если вы видите шаблоны UTF-16LE (чередующиеся нулевые байты), помните, что PowerShell использует UTF-16LE и читайте соответственно. Выявляйте любые подозрительные шаблоны, такие как сетевые запросы, повышение привилегий или механизмы сохранения. Точно запишите детали отчета об инциденте, включая исходную строку Base64 и ее хэш. Никогда не выполняйте команду самостоятельно; оставьте это специалистам по реагированию на инциденты в контролируемой среде. Доверьтесь своему местному декодированию и своей оценке открытого текста, и пусть это будет определять ваши следующие действия.