Payloads and shells

Сначала авторизация — это механизм, а не оружие

Всё ниже — это теория того, как формируется канал пост-эксплуатации и как защитники его видят. Здесь нет рабочего payload, и он не нужен: можно полностью понять reverse-шеллы, bind-шеллы и то, как их ловят, ни разу не направив ни один на систему, которой ты не владеешь. Единственные законные места, где можно наблюдать, как шелл дозванивается обратно, — это CTF-машина, намеренно уязвимая VM, которую ты сам поднял, или входящий в скоуп пентест с письменной авторизацией. В терминах MITRE ATT&CK эксплойт купил нам плацдарм; payload — это то, что устанавливает Execution (выполнение), а затем Persistence (TA0003) — удержание этого кода доступным. Мы изучаем соединение и дерево процессов именно для того, чтобы защитник мог разорвать цепочку в самой узкой точке. Запусти шелл против цели, на которую у тебя нет авторизации, — и ты не изучаешь безопасность, а совершаешь преступление.

Payload — это что-выполнится-дальше; шелл — это разговор

Эксплойт отвечает на вопрос «как перенаправить выполнение». Payload отвечает на вопрос «выполнение моё — что теперь делать?». При переполнении стека байты, перезаписавшие адрес возврата, указывали куда-то; payload — это код, который ждёт в этой точке назначения. Исторически это был сырой shellcode, внедрённый в тот же буфер; на современных системах с неисполняемым стеком это чаще цепочка, вызывающая существующую функцию, чтобы породить дочерний процесс. В любом случае цель самого распространённого payload скромна и разрушительна: запустить командный интерпретатор — /bin/sh, bash, cmd.exe, powershell — и подключить его стандартный ввод и вывод к сетевому сокету. Эта подводка — вся суть. Локальный шелл бесполезен удалённому атакующему; шелл, чья клавиатура и экран — это TCP-соединение, — это удалённый терминал.

Шелл, таким образом, — это просто интерактивный командный интерпретатор, чей ввод-вывод перенаправлен по сети. Как только он у тебя есть, ты печатаешь команду на своей машине, она выполняется на их, а вывод возвращается обратно. Всё остальное в пост-эксплуатации — повышение привилегий, латеральное движение, доставка инструментов — происходит через этот канал. Вот почему именно сам канал — это место, где ведётся вся битва за обнаружение.

Reverse против bind: кто кому звонит

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

Bind-шелл открывает слушающий порт на жертве и ждёт. Атакующий подключается входящим соединением к этому порту. Концептуально это самый простой вариант — и почти всегда неправильный на практике: входящие соединения из интернета на случайный высокий порт внутреннего хоста — это ровно то, что периметровый файрвол и NAT существуют блокировать. Жертва обычно за NAT, без публичного IP и без проброса входящих портов, так что подключаться попросту не к чему.

Reverse-шелл переворачивает направление. Жертва сама звонит наружу атакующему, который слушает. Это проходит мимо двух вещей, убивающих bind-шеллы: мимо NAT (исходящие соединения — это как работает любой нормальный клиент) и мимо входящих правил файрвола (которые обычно по умолчанию пропускают исходящий трафик). Вот почему «reverse» — это дефолт почти на каждом реальном пентесте: не потому, что он скрытнее, а потому, что это единственный, который вообще соединяется. Атакующий часто слушает на 443, чтобы трафик сливался с HTTPS и обычно выпускался наружу.

Как защитник его ловит: egress-фильтрация и EDR

Reverse-шелл работает только благодаря одному обычно-верному допущению: исходящий трафик разрешён по умолчанию. Большинство сетей жёстко контролируют то, что входит, и едва смотрят на то, что выходит. Egress-фильтрация — это поправка защитника: относиться к исходящему трафику с тем же подозрением, что и к входящему. Сделанная хорошо, она означает, что хост может дотянуться только до явного allowlist пунктов назначения и портов; всё остальное отбрасывается. Против этого жертва звонит наружу — и пакет упирается в стену: слушателя атакующего нет в allowlist, поэтому соединение никогда не завершается. Всё преимущество reverse-шелла — «исходящее бесплатно» — испаряется. Именно поэтому атакующие туннелируют через 443, DNS или настоящий облачный сервис: они пытаются выглядеть как трафик, который allowlist уже пропускает.

Вторая линия — это EDR (Endpoint Detection and Response) — агент, наблюдающий за самим хостом, а не за проводом. Даже идеально TLS-зашифрованный reverse-шелл на 443 оставляет на эндпойнте отпечатки, которых сеть никогда не видит:

• Аномальное дерево процессов. Процесс веб-сервера (nginx, php-fpm, java) не должен быть родителем /bin/sh или cmd.exe. Это ребро «родитель — потомок» — одно из самых сигнальных обнаружений вообще: оно означает, что сервис, обрабатывающий запросы, только что породил интерактивный шелл.
• Шелл с сокетом в качестве стандартного ввода-вывода. У нормального bash на файловых дескрипторах терминал. У reverse-шелла на stdin/stdout — сетевой сокет. EDR, инспектирующий, на что указывают дескрипторы шелла, видит это сразу.
• Поведенческая последовательность. Породился шелл, потом whoami, потом сетевая разведка, потом загрузка — сам плейбук пост-эксплуатации и есть сигнатура.

Как рассуждает зрелый инженер

Будь ты атакующим на авторизованном пентесте или защитником, урок один и тот же: payload — это легко; канал — это узкое место. Атакующий, знающий лишь «reverse-шелл на 443», встаёт намертво перед сетью с исходящим allowlist и EDR. Защитник, блокирующий только входящее, оставил дверь reverse-шелла нараспашку. Устойчивая ментальная модель — мыслить в терминах направления соединения, его пункта назначения и процесса, которому оно принадлежит, — потому что каждое из этого есть место, где можно либо спрятаться, либо обнаружить. Дефолты тут важнее всего: сеть, разрешающая весь исходящий трафик, — это сеть, допускающая, что reverse-шелл сработает, а хост, чей веб-сервер может породить шелл незаметно, — это хост, допускающий, что payload выполнится тихо.