HTTP-форвардеры/ретрансляторы
Сокрытие атакующих хостов с помощью редиректоров/ретранляторов трафика с помощью iptables или socat.
Цель
Редиректоры или ретранляторы трафика — это, по сути, прокси между сервером red teaming (скажем, сервером для отправки фишинговых писем или C2) и сервером-жертвой — жертва <> re-director <> team server.
Цель хоста редиректора, как обычно такая:
- Скрыть сервер красной команды, скрыв его IP-адрес. Другими словами, жертва увидит трафик, исходящий от хоста редиректора, а не от командного сервера.
- Если службы реагирования на инциденты обнаружат подозрительную активность, исходящую от перенаправителя, его можно "легко" вывести из эксплуатации и заменить другим, что "проще", чем перестраивать командный сервер.
Переадресация HTTP с помощью iptables
Я рассмотрю простые HTTP-серверы пересылки, которые просто прослушивают заданный интерфейс и порт и перенаправляют весь трафик, который они получают через этот порт, на порт прослушивателя на командном сервере.
Моё окружение в этой лаборатории такое:
- Командный сервер и порт прослушивания: 10.0.0.2:80
- Редирект хост и порт прослушивания: 10.0.0.5:80
- Хост жертвы: 10.0.0.11
Простой способ создать редиректор HTTP — использовать Linux-систему и ее возможности iptables.
Ниже показано, как превратить Linux-систему в редиректор HTTP. В этом случае весь HTTP-трафик на 10.0.0.5:80 (перенаправитель) будет перенаправлен на 10.0.0.2:80 (сервер группы):
iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.0.2:80
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
Проверяем успешность создания правил iptables:
Тестирование iptables
Смоделируем упрощенный обратный шелл от системы-жертвы 10.0.0.11 к атакующей системе 10.0.0.2, используя нашу систему-перенаправитель 10.0.0.5 в качестве прокси, и проверим трафик, проходящий по проводу — если перенаправитель был настроен правильно, мы должны увидеть, что системы 10.0.0.11 и 10.0.0.2 не будут общаться напрямую - весь трафик будет проходить через ящик на 10.0.0.5 и 10.0.0.2 (атакующая система) не будет виден жертве 10.0.0.11:
При более внимательном рассмотрении трафика/диалогов между конечными точками мы ясно видим, что система-жертва 10.0.0.11 ни разу не взаимодействовала напрямую с атакующей системой 10.0.0.2 — все коммуникации проходили через хост-перенаправитель 10.0.0.5, как описано ранее:
Переадресация HTTP с помощью SOCAT
SOCAT — еще один инструмент, который можно использовать для переадресации трафика по "тупому пайпу". Среда в этом упражнении остается такой же, как и в предыдущем сценарии.
Настройка редиректора HTTP с помощью socat такая:
socat TCP4-LISTEN:80,fork TCP4:10.0.0.2:80
Сокрытие атакующих хостов с помощью редиректоров/ретранляторов трафика с помощью iptables или socat.
Цель
Редиректоры или ретранляторы трафика — это, по сути, прокси между сервером red teaming (скажем, сервером для отправки фишинговых писем или C2) и сервером-жертвой — жертва <> re-director <> team server.
Цель хоста редиректора, как обычно такая:
- Скрыть сервер красной команды, скрыв его IP-адрес. Другими словами, жертва увидит трафик, исходящий от хоста редиректора, а не от командного сервера.
- Если службы реагирования на инциденты обнаружат подозрительную активность, исходящую от перенаправителя, его можно "легко" вывести из эксплуатации и заменить другим, что "проще", чем перестраивать командный сервер.
Переадресация HTTP с помощью iptables
Я рассмотрю простые HTTP-серверы пересылки, которые просто прослушивают заданный интерфейс и порт и перенаправляют весь трафик, который они получают через этот порт, на порт прослушивателя на командном сервере.
Моё окружение в этой лаборатории такое:
- Командный сервер и порт прослушивания: 10.0.0.2:80
- Редирект хост и порт прослушивания: 10.0.0.5:80
- Хост жертвы: 10.0.0.11
Простой способ создать редиректор HTTP — использовать Linux-систему и ее возможности iptables.
Ниже показано, как превратить Linux-систему в редиректор HTTP. В этом случае весь HTTP-трафик на 10.0.0.5:80 (перенаправитель) будет перенаправлен на 10.0.0.2:80 (сервер группы):
iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.0.2:80
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
Проверяем успешность создания правил iptables:
Тестирование iptables
Смоделируем упрощенный обратный шелл от системы-жертвы 10.0.0.11 к атакующей системе 10.0.0.2, используя нашу систему-перенаправитель 10.0.0.5 в качестве прокси, и проверим трафик, проходящий по проводу — если перенаправитель был настроен правильно, мы должны увидеть, что системы 10.0.0.11 и 10.0.0.2 не будут общаться напрямую - весь трафик будет проходить через ящик на 10.0.0.5 и 10.0.0.2 (атакующая система) не будет виден жертве 10.0.0.11:
При более внимательном рассмотрении трафика/диалогов между конечными точками мы ясно видим, что система-жертва 10.0.0.11 ни разу не взаимодействовала напрямую с атакующей системой 10.0.0.2 — все коммуникации проходили через хост-перенаправитель 10.0.0.5, как описано ранее:
Переадресация HTTP с помощью SOCAT
SOCAT — еще один инструмент, который можно использовать для переадресации трафика по "тупому пайпу". Среда в этом упражнении остается такой же, как и в предыдущем сценарии.
Настройка редиректора HTTP с помощью socat такая:
socat TCP4-LISTEN:80,fork TCP4:10.0.0.2:80
EfAuLTWEbPRoxy;
