Wiki para reunir recursos de endurecimento de infraestrutura de Red Team
Esta wiki tem como objetivo fornecer um recurso para configurar uma infraestrutura resiliente de Red Team. Foi criada para complementar a palestra de Steve Borosh (@424f424f) e Jeff Dimmock (@bluscreenofjeff) no BSides NoVa 2017, intitulada "Doomsday Preppers: Fortifying Your Red Team Infrastructure" (slides)
Se você tiver uma adição que gostaria de fazer, envie um Pull Request ou abra uma issue no repositório.
OBRIGADO a todos os autores do conteúdo referenciado nesta wiki e a todos que contribuíram!
Ao projetar uma infraestrutura de red team que precise resistir a uma resposta ativa ou durar por um engajamento de longo prazo (semanas, meses, anos), é importante segregar cada ativo com base na função. Isso proporciona resiliência e agilidade contra o Blue Team quando os ativos da campanha começam a ser detectados. Por exemplo, se o e-mail de phishing de uma avaliação for identificado, o Red Team precisaria apenas criar um novo servidor SMTP e um servidor de hospedagem de payloads, em vez de configurar todo um servidor de equipe.
Considere segregar estas funções em ativos diferentes:
Cada uma dessas funções provavelmente será necessária para cada campanha de engenharia social. Como a resposta ativa a incidentes é típica em uma avaliação de Red Team, um novo conjunto de infraestrutura deve ser implementado para cada campanha.
Para aumentar a resiliência e o ocultamento, todo ativo de back-end (ou seja, servidor de equipe) deve ter um redirector posicionado à sua frente. O objetivo é sempre ter um host entre nosso alvo e nossos servidores de back-end. Configurar a infraestrutura dessa maneira torna a criação de nova infraestrutura muito mais rápida e fácil - não há necessidade de montar um novo servidor de equipe, migrar sessões e reconectar ativos não queimados no back-end.
Tipos comuns de redirectors:
Cada tipo de redirector possui múltiplas opções de implementação que melhor se adequam a diferentes cenários. Essas opções são discutidas em mais detalhes na seção Redirectors da wiki. Os redirectors podem ser hosts VPS, servidores dedicados ou até mesmo aplicativos executados em uma instância de Platform-as-a-Service.
Aqui está um exemplo de design, mantendo em mente a segregação funcional e o uso de redirectors:
A Vision for Distributed Red Team Operations - Raphael Mudge (@armitagehacker)
Infrastructure for Ongoing Red Team Operations - Raphael Mudge
Advanced Threat Tactics (2 of 9): Infrastructure - Raphael Mudge
Cloud-based Redirectors for Distributed Hacking - Raphael Mudge
How to Build a C2 Infrastructure with Digital Ocean – Part 1 - Lee Kagan (@invokethreatguy)
Automated Red Team Infrastructure Deployment with Terraform - Part 1 - Rasta Mouse (@_RastaMouse)
A reputação percebida de um domínio variará muito dependendo dos produtos que seu alvo está usando, bem como de sua configuração. Como tal, escolher um domínio que funcione para seu alvo não é uma ciência exata. A coleta de inteligência de código aberto (OSINT) será fundamental para ajudar a fazer uma estimativa sobre o estado dos controles e quais recursos verificar em relação aos domínios. Felizmente, os anunciantes online enfrentam os mesmos problemas e criaram algumas soluções que podemos aproveitar.
expireddomains.net é um mecanismo de busca para domínios recentemente expirados ou removidos. Ele fornece pesquisa e filtros avançados, como idade de expiração, número de backlinks, número de snapshots do Archive.org e pontuação do SimilarWeb. Usando o site, podemos registrar domínios previamente usados, que virão com idade de domínio, que se pareçam com nosso alvo, que se pareçam com nossa personificação ou simplesmente que provavelmente se misturarão na rede do nosso alvo.
Ao escolher um domínio para C2 ou exfiltração de dados, considere escolher um domínio categorizado como Finanças ou Saúde. Muitas organizações não realizarão inspeção SSL (SSL middling) nessas categorias devido à possibilidade de problemas legais ou de sensibilidade de dados. Também é importante garantir que o domínio escolhido não esteja associado a nenhuma campanha anterior de malware ou phishing.
A ferramenta CatMyFish de Charles Hamilton(@MrUn1k0d3r) automatiza pesquisas e verificação de categorização web com expireddomains.net e BlueCoat. Ela pode ser modificada para aplicar mais filtros às pesquisas ou até mesmo realizar monitoramento de longo prazo dos ativos que você registrar.
Outra ferramenta, DomainHunter de Joe Vest (@joevest) e Andrew Chiles (@andrewchiles), retorna categorização BlueCoat/WebPulse, IBM X-Force e Cisco Talos, idade do domínio, TLDs alternativos disponíveis, links do Archive.org e um relatório em HTML. Além disso, realiza verificações de uso em campanhas conhecidas de malware e phishing usando Malwaredomains.com e MXToolBox. Esta ferramenta também inclui suporte a OCR para contornar os captchas do BlueCoat/WebPulse. Confira o post no blog sobre o lançamento inicial da ferramenta para mais detalhes.
Outra ferramenta, AIRMASTER de Max Harley (@Max_68), usa expireddomains.net e Bluecoat para encontrar domínios categorizados. Esta ferramenta usa OCR para contornar o captcha do BlueCoat, aumentando a velocidade da pesquisa.
Se um domínio previamente registrado não estiver disponível ou você preferir um domínio auto-registrado, é possível categorizar domínios você mesmo. Usando os links diretos abaixo ou uma ferramenta como Chameleon de Dominic Chell (@domchell). A maioria dos produtos de categorização ignorará redirecionamentos ou conteúdo clonado ao determinar a categorização do domínio. Para mais informações sobre o uso do Chameleon, confira o post de Dominic Categorisation is not a security boundary.
Por fim, certifique-se de que suas configurações de DNS foram propagadas corretamente.
As palavras fácil e phishing nunca parecem combinar. Configurar uma infraestrutura de phishing adequada pode ser um verdadeiro incômodo. O tutorial a seguir fornecerá o conhecimento e as ferramentas para configurar rapidamente um servidor de phishing que passa pela "maioria" dos filtros de spam atuais e fornece uma interface RoundCube para uma experiência de phishing fácil, incluindo comunicação bidirecional com seu alvo. Existem muitas configurações e posts por aí sobre phishing. Este é apenas um método.
Depois de ter um domínio que passe nas verificações adequadas listadas na seção anterior e ter seu servidor de phishing ativo, você precisará criar alguns registros "A" para seu domínio, como na imagem.
Em seguida, faça ssh para o seu servidor de phishing e certifique-se de ter um hostname FQDN adequado listado em seu /etc/hosts. Exemplo "127.0.0.1 email.yourphishingserver.com email localhost"
Agora, você instalará o front-end web para fazer phishing em poucos passos fáceis. Comece baixando a versão mais recente "BETA" do iRedMail em seu servidor de phishing. A maneira fácil é clicar com o botão direito no botão de download, copiar o endereço do link, usar wget para baixar diretamente para o seu servidor de phishing. Em seguida, descompacte-o com "tar -xvf iRedMail-0.9.8-beta2.tar.bz2". Navegue até a pasta descompactada e torne o script iRedMail.sh executável (chmod +x iRedMail.sh). Execute o script como root, siga os prompts e você precisará reiniciar para finalizar tudo.
Você vai querer garantir que todos os registros DNS adequados estejam apontando para o seu servidor de e-mail. (https://docs.iredmail.org/setup.dns.html). Para DKIM, o novo comando deve ser "amavisd-new showkeys" para listar sua chave DKIM.
Para DMARC, podemos usar (https://www.unlocktheinbox.com/dmarcwizard/) para gerar nossa entrada dmarc.
Agora, crie um usuário para fazer phishing.
Faça login na interface RoundCube com seu novo usuário e faça phishing com responsabilidade!
O Cobalt Strike fornece funcionalidade personalizável de spearphishing para suportar pentest ou phishing por e-mail de red team. Ele suporta modelos em HTML e/ou formatos de texto simples, anexos, um endereço de devolução (bounceback), incorporação de URL, uso de servidor SMTP remoto e atrasos de envio por mensagem. Outra característica interessante é a capacidade de adicionar um token único à URL incorporada de cada usuário para rastreamento de cliques.
Para informações mais detalhadas, confira estes recursos:
Para exercícios de red-team e phishing onde a confiança do cliente e a OPSEC importam, manter os dados capturados do cliente e a infraestrutura primária nos próprios servidores do cliente (on-premises) fornece vantagens significativas sobre soluções somente em nuvem. Esta abordagem usa ativos de nuvem apenas para redirectors e fronts finos, mantendo operações sensíveis internamente.
Uma configuração robusta de Evilginx on-premises normalmente consiste em:
O bloqueio por cookie reduz hits de bots e varreduras automatizadas, exigindo um cookie específico para acessar o portal de phishing:``` (http.host eq "portal.example.com") and (not http.cookie contains "session_token=abc123def456") and not (http.host eq "landing.example.com" and http.request.uri.path eq "/favicon.ico")
Esta regra redireciona solicitações para o domínio do portal que não contêm o cookie necessário, enquanto isenta solicitações de favicon para evitar loops de redirecionamento.
### Exemplo de Configuração do Caddy```caddyfile
# Redirect direct IP access to prevent fingerprinting
1.2.3.4 {
redir https://legitimate-site.com{uri} permanent
}
landing.example.com {
log {
output file /var/log/caddy/landing_access.log
format console
}
tls internal
encode gzip
reverse_proxy http://127.0.0.1:8000
}
portal.example.com {
log {
output file /var/log/caddy/portal_access.log
format console
}
tls internal
encode gzip
reverse_proxy https://evilginx:443 {
transport http {
versions 1.1
tls_insecure_skip_verify
tls_server_name portal.example.com
}
header_up Host portal.example.com
header_up X-Forwarded-Proto https
}
}
Execute o Evilginx no nó interno com as flags apropriadas:```bash ./evilginx2 -p ./phishlets -t ./redirectors -developer -debug
**Importante:** O Evilginx só deve ser acessível a partir da rede privada; nunca publique seu IP em DNS público.
### Checklist de OPSEC e Endurecimento
1. **Nunca exponha IPs do Evilginx em DNS público** - Use apenas rede privada
2. **Mantenha dados sensíveis apenas nos servidores clientes** - Redirecionadores não devem armazenar credenciais capturadas
3. **Endureça os redirecionadores** - Alterne domínios, use TTLs curtos, implante múltiplos redirecionadores efêmeros
4. **Implemente regras de WAF/firewall** - Use verificações de cookies, listas de permissão de IP ou validação de UA
5. **Separe registro e retenção** - Mantenha logs de acesso no Caddy e logs de captura no host do Evilginx
6. **Evite impressões digitais** - Não use padrões previsíveis ou impressões digitais TLS idênticas
Essa abordagem híbrida (redirecionador público/captura privada) oferece a resiliência do cloud fronting, mantendo as vantagens de segurança e legais de manter operações sensíveis on-premises.
## Frameworks de Phishing
Além de montar sua própria configuração de phishing ou usar uma estrutura de pentest ou red teaming, como o Cobalt Strike, existem inúmeras ferramentas e frameworks dedicados a phishing por e-mail. Embora este wiki não entre em detalhes sobre cada framework, alguns recursos para cada um estão listados abaixo:
### Gophish
* [Site Oficial do Gophish](https://getgophish.com/)
* [Repositório GitHub do Gophish](https://github.com/gophish/gophish)
* [Guia do Usuário do Gophish](https://www.gitbook.com/book/gophish/user-guide/details)
### Phishing Frenzy
* [Site Oficial do Phishing Frenzy](https://www.phishingfrenzy.com/)
* [Repositório GitHub do Phishing Frenzy](https://github.com/pentestgeek/phishing-frenzy)
* [Apresentando o Phishing Frenzy - Brandon McCann (@zeknox)](https://www.pentestgeek.com/phishing/introducing-phishing-frenzy)
### The Social-Engineer Toolkit
* [Repositório GitHub do The Social-Engineer Toolkit](https://github.com/trustedsec/social-engineer-toolkit)
* [Manual do Usuário do The Social-Engineer Toolkit](https://github.com/trustedsec/social-engineer-toolkit/raw/master/readme/User_Manual.pdf)
### FiercePhish (anteriormente FirePhish)
* [Repositório GitHub do FiercePhish](https://github.com/Raikia/FiercePhish)
* [Wiki do FiercePhish](https://github.com/Raikia/FiercePhish/wiki)
# Redirecionadores
## SMTP
"Redirecionador" pode não ser a melhor palavra para descrever o que vamos realizar, mas o objetivo é o mesmo que com nossos outros redirecionamentos. Queremos remover qualquer vestígio da origem do nosso phishing dos cabeçalhos finais do e-mail e fornecer um buffer entre a vítima e nosso servidor backend. Idealmente, o redirecionador SMTP deve ser rápido de configurar e fácil de descomissionar.
Há duas ações principais que queremos configurar um redirecionador SMTP para executar:
### Sendmail
#### Remover cabeçalhos anteriores do servidor
Adicione a seguinte linha ao final de `/etc/mail/sendmail.mc`:```bash
define(`confRECEIVED_HEADER',`by $j ($v/$Z)$?r with $r$. id $i; $b')dnl
Adicione ao final de /etc/mail/access:```bash
IP-to-Team-Server TAB RELAY
Phish-Domain TAB RELAY
[Removing Sender’s IP Address From Email’s Received From Header](https://www.devside.net/wamp-server/removing-senders-ip-address-from-emails-received-from-header)
[Removing Headers from Postfix setup](https://major.io/2013/04/14/remove-sensitive-information-from-email-headers-with-postfix/)
#### Configurar um endereço catch-all
Isto encaminhará qualquer e-mail recebido em *@phishdomain.com para um endereço de e-mail escolhido. Isto é extremamente útil para receber quaisquer respostas ou mensagens de rejeição (bounce-backs) a um e-mail de phishing.```bash
echo PHISH-DOMAIN >> /etc/mail/local-host-names
Adicione a seguinte linha logo antes de //Mailer Definitions// (perto do final) de /etc/mail/sendmail.mc:```bash
FEATURE(virtusertable', hash -o /etc/mail/virtusertable.db')dnl
Adicione a seguinte linha ao final de `/etc/mail/virtusertable`:```bash
@phishdomain.com external-relay-address
Nota: Os dois campos devem ser separados por tabulação
O Postfix oferece uma alternativa mais fácil ao sendmail com maior compatibilidade. O Postfix também oferece suporte completo a IMAP com o Dovecot. Isso permite que testadores se correspondam em tempo real com alvos de phishing que respondem à mensagem original, em vez de depender do endereço catch-all e ter que criar uma nova mensagem usando sua ferramenta de phishing.
Um guia completo para configurar um servidor de e-mail Postfix para phishing está disponível no post de Julian Catrambone (@n0pe_sled) Mail Servers Made Easy.
Nota: Ao usar redirecionadores C2, um listener externo deve ser configurado em seu framework de pós-exploração para enviar tráfego de staging através do domínio do redirecionador. Isso fará com que o host comprometido faça staging através do redirecionador, assim como o tráfego C2.
O socat pode ser usado para redirecionar pacotes DNS recebidos na porta 53 para nosso servidor da equipe. Embora esse método funcione, alguns usuários relataram problemas de staging com o Cobalt Strike e/ou problemas de latência usando esse método. Editado em 21/04/2017: O seguinte comando socat parece funcionar bem graças aos testes de @xorrior:``` socat udp4-recvfrom:53,reuseaddr,fork udp4-sendto::53; echo -ne
[Redirecting Cobalt Strike DNS Beacons - Steve Borosh](https://medium.com/rvrsh3ll/redirecting-cobalt-strike-dns-beacons-e3dcdb5a8b9b)
### iptables para DNS
As regras de encaminhamento DNS do iptables demonstraram funcionar bem com o Cobalt Strike. Não parece haver nenhum dos problemas que o socat tem ao lidar com esse tipo de tráfego.
Um exemplo de conjunto de regras de redirecionamento DNS está abaixo.```bash
iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination <IP-GOES-HERE>:53
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
Também, altere a política da cadeia "FORWARD" para "ACCEPT"
Alguns podem ter a necessidade de hospedar um servidor c2 em uma rede interna. Usando uma combinação de IPTABLES, SOCAT e túneis SSH reversos, podemos certamente alcançar isso da seguinte maneira.
Neste cenário, temos nosso redirecionador volátil usando IPTables para encaminhar todo o tráfego DNS usando a regra de exemplo descrita anteriormente nesta seção. Em seguida, criamos um túnel reverso de encaminhamento de porta SSH do nosso servidor c2 interno para o nosso redirecionador principal. Isso encaminhará qualquer tráfego que o redirecionador principal receber na porta 6667 para o servidor c2 interno na porta 6667. Agora, inicie o socat no nosso servidor de equipe para bifurcar qualquer tráfego TCP de entrada na porta 6667 para a porta UDP 53, que é onde nosso c2 de DNS precisa escutar. Finalmente, configuramos de forma semelhante uma instância do socat no redirecionador principal para redirecionar qualquer tráfego UDP de entrada na porta 53 para o nosso túnel SSH na porta 6667.
Nota: Ao usar redirecionadores C2, um listener externo deve ser configurado no seu framework de pós-exploração para enviar tráfego de staging através do domínio do redirecionador. Isso fará com que o host comprometido faça staging através do redirecionador, assim como o próprio tráfego C2.
O socat fornece um redirecionamento de 'tubo burro'. Qualquer requisição que o socat receber na interface/porta de origem especificada é redirecionada para o IP/porta de destino. Não há filtragem ou redirecionamento condicional. O Apache mod_rewrite, por outro lado, fornece vários métodos para fortalecer seu phishing e aumentar a resiliência da sua infraestrutura de testes. O mod_rewrite tem a capacidade de realizar redirecionamento condicional com base em atributos da requisição, como URI, user agent, query string, sistema operacional e IP. O Apache mod_rewrite usa arquivos htaccess para configurar conjuntos de regras sobre como o Apache deve lidar com cada requisição de entrada. Usando essas regras, você poderia, por exemplo, redirecionar requisições ao seu servidor com o user agent padrão do wget para uma página legítima no site do seu alvo.
Em resumo, se o seu redirecionador precisar realizar redirecionamento condicional ou filtragem avançada, use o Apache mod_rewrite. Caso contrário, o redirecionamento com socat e filtragem opcional com iptables será suficiente.
O socat pode ser usado para redirecionar qualquer pacote TCP de entrada em uma porta especificada para o nosso servidor de equipe.
A sintaxe básica para redirecionar a porta TCP 80 no localhost para a porta 80 em outro host é:``` socat TCP4-LISTEN:80,fork TCP4::80
Se o seu redirecionador estiver configurado com mais de uma interface de rede, o socat pode ser vinculado a uma interface específica, por endereço IP, com a seguinte sintaxe:```
socat TCP4-LISTEN:80,bind=10.0.0.2,fork TCP4:1.2.3.4:80
Neste exemplo, 10.0.0.2 é um dos endereços IP locais do redirecionador e 1.2.3.4 é o endereço IP do servidor de equipe remoto.
Além do socat, o iptables pode realizar redirecionamento de 'tubo burro' via NAT. Para encaminhar a porta local 80 do redirecionador para um host remoto, use a seguinte sintaxe:``` iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination :80 iptables -t nat -A POSTROUTING -j MASQUERADE iptables -I FORWARD -j ACCEPT iptables -P FORWARD ACCEPT sysctl net.ipv4.ip_forward=1
### SSH para HTTP
Abordámos anteriormente a utilização de SSH para túneis DNS. O SSH funciona como um meio sólido e robusto para ultrapassar NAT e obter uma forma de o implante se ligar a um redirector e ao seu ambiente de servidor. Antes de configurar um redirector SSH, deve adicionar as seguintes linhas a `/etc/ssh/sshd_config`:```text
# Allow the SSH client to specify which hosts may connect
GatewayPorts yes
# Allow both local and remote port forwards
AllowTcpForwarding yes
Para encaminhar a porta local 80 do redirecionador para o seu servidor interno, use a seguinte sintaxe no servidor interno:``` tmux new -S redir80 ssh -R *:80:localhost:80 Ctrl+B, D
Pode também encaminhar mais de uma porta, por exemplo, se quiser que 443 e 80 fiquem abertas ao mesmo tempo:```
tmux new -S redir80443
ssh <redirector> -R *:80:localhost:80 -R *:443:localhost:443
Ctrl+B, D
Ao servir payloads e recursos web, queremos minimizar a capacidade dos respondedores de incidentes de revisar arquivos e aumentar as chances de executar o payload com sucesso, seja para estabelecer C2 ou coletar inteligência.
Uso e exemplos do Apache Mod_Rewrite por Jeff Dimmock:
Outros usos e exemplos do Apache mod_rewrite:
Para configurar automaticamente o Apache Mod_Rewrite em um servidor redirector, confira o post do blog de Julain Catrambone (@n0pe_sled) Configuração Automática do Mod_Rewrite e a ferramenta acompanhante.
A intenção por trás do redirecionamento de tráfego C2 é dupla: ocultar o servidor da equipe de backend e parecer um site legítimo se navegado por um respondedor de incidentes. Através do uso do Apache mod_rewrite e perfis C2 personalizados ou outros proxies (como com Flask), podemos filtrar de forma confiável o tráfego C2 real do tráfego investigativo.
Baseando-se em "Redirecionamento C2" acima, outro método é fazer seu servidor redirector usar o SSL Proxy Engine do Apache para aceitar solicitações SSL de entrada e fazer proxy dessas solicitações para um listener HTTPS reverso. A criptografia é usada em todas as etapas, e você pode rotacionar certificados SSL no seu redirector conforme necessário.
Para fazer isso funcionar com suas regras mod_rewrite, você precisa colocar suas regras em "/etc/apache2/sites-available/000-default-le-ssl.conf", assumindo que você usou o LetsEncrypt (também conhecido como CertBot) para instalar seu certificado. Além disso, para habilitar o mecanismo SSL ProxyPass, você precisará das seguintes linhas no mesmo arquivo de configuração:```bash
SSLProxyEngine On
ProxyPass / https://DESTINATION_C2_URL:443/ ProxyPassReverse / https://DESTINATION_C2_URL:443/
SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off
### Outros Recursos de Apache mod_rewrite
* [Automatizando Apache mod_rewrite e Perfis Cobalt Strike](https://posts.specterops.io/automating-apache-mod-rewrite-and-cobalt-strike-malleable-c2-profiles-d45266ca642)
* [mod-rewrite-cheatsheet.com](http://mod-rewrite-cheatsheet.com/)
* [Documentação Oficial do Apache 2.4 mod_rewrite](http://httpd.apache.org/docs/current/rewrite/)
* [Introdução ao Apache mod_rewrite](https://httpd.apache.org/docs/2.4/en/rewrite/intro.html)
* [Um Guia Detalhado de mod_rewrite para Apache](http://code.tutsplus.com/tutorials/an-in-depth-guide-to-mod-rewrite-for-apache--net-6708)
* [Verificador de Sintaxe Mod_Rewrite/.htaccess](http://www.htaccesscheck.com/)
# Modificando o Tráfego C2
## Cobalt Strike
O Cobalt Strike modifica seu tráfego com perfis Malleable C2. Os perfis oferecem opções altamente personalizáveis para modificar a aparência do tráfego C2 do seu servidor na rede. Os perfis Malleable C2 podem ser usados para fortalecer a evasão de resposta a incidentes, imitar adversários conhecidos ou se passar por aplicações internas legítimas usadas pelo alvo.
* [Perfis Oficiais Malleable C2 - GitHub](https://github.com/rsmudge/Malleable-C2-Profiles)
* [Documentação Malleable Command and Control - cobaltstrike.com](https://www.cobaltstrike.com/help-malleable-c2)
* [Cobalt Strike 2.0 - Malleable Command and Control - Raphael Mudge](http://blog.cobaltstrike.com/2014/07/16/malleable-command-and-control/)
* [Cobalt Strike 3.6 - Um Caminho para Escalação de Privilégios - Raphael Mudge](http://blog.cobaltstrike.com/2016/12/08/cobalt-strike-3-6-a-path-for-privilege-escalation/)
* [Um Novo Mundo Corajoso: Malleable C2 - Will Schroeder (@harmj0y)](http://www.harmj0y.net/blog/redteaming/a-brave-new-world-malleable-c2/)
* [Como Escrever Perfis Malleable C2 para Cobalt Strike - Jeff Dimmock](https://bluescreenofjeff.com/2017-01-24-how-to-write-malleable-c2-profiles-for-cobalt-strike/)
* [Evasão em Memória (Série de vídeos) - Raphael Mudge](https://www.youtube.com/watch?v=lz2ARbZ_5tE&list=PL9HO6M_MU2nc5Q31qd2CwpZ8J4KFMhgnK)
Ao começar a criar ou modificar perfis Malleable C2, é importante manter em mente os limites de tamanho de dados para a colocação das informações do Beacon. Por exemplo, configurar o perfil para enviar grandes quantidades de dados em um parâmetro de URL exigirá muitas solicitações. Para mais informações sobre isso, confira a postagem do blog de Raphael Mudge [Cuidado com Downloads Lentos](https://blog.cobaltstrike.com/2018/03/09/beware-of-slow-downloads/).
Se você encontrar problemas com seu perfil Malleable C2 e notar que o console do teamserver está exibindo erros, consulte a postagem do blog de Raphael Mudge [Promessas Quebradas e Perfis Malleable C2](https://blog.cobaltstrike.com/2018/06/04/broken-promises-and-malleable-c2-profiles/) para dicas de solução de problemas.
## Empire
O Empire usa Perfis de Comunicação, que oferecem opções de personalização para os URIs de solicitação GET, user agent e cabeçalhos. O perfil consiste em cada elemento, separado pelo caractere pipe, e é definido com a opção `set DefaultProfile` no menu de contexto `listeners`.
Aqui está um exemplo de perfil padrão:```bash
"/CWoNaJLBo/VTNeWw11212/|Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1)|Accept:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*|Accept-Language:en-en"
Alternativamente, o valor de DefaultProfile pode ser definido modificando o arquivo /setup/setup_database.py antes da configuração inicial do Empire. Isso alterará o Perfil de Comunicação padrão que o Empire usará.
Além do Perfil de Comunicação, considere personalizar os URIs de staging do servidor Empire, os cabeçalhos do servidor e o conteúdo padrão da página web seguindo os passos apresentados no post de Joe Vest (@joevest) Empire - Modifying Server C2 Indicators.
Aproveitar serviços web legítimos e confiáveis para C2 pode fornecer uma vantagem valiosa em relação ao uso de domínios e infraestrutura que você configurou. O tempo e a complexidade de configuração variam de acordo com a técnica e o serviço utilizados. Um exemplo popular de aproveitamento de serviços de terceiros para redirecionamento de C2 é o Domain Fronting.
Domain Fronting é uma técnica usada por serviços e aplicativos de evasão de censura para rotear tráfego através de domínios legítimos e altamente confiáveis. Serviços populares que suportam Domain Fronting incluem Google App Engine, Amazon CloudFront e Microsoft Azure. É importante observar que muitos provedores, como Google e Amazon, implementaram mitigações contra Domain Fronting, então alguns recursos vinculados ou informações fornecidas neste wiki podem estar desatualizados quando você tentar usá-los.
Em resumo, o tráfego usa o nome DNS e SNI do provedor de serviços confiável; o Google é usado no exemplo abaixo. Quando o tráfego é recebido pelo Edge Server (ex: localizado em gmail.com), o pacote é encaminhado para o Origin Server (ex: phish.appspot.com) especificado no cabeçalho Host do pacote. Dependendo do provedor de serviços, o Origin Server encaminhará diretamente o tráfego para um domínio especificado, que apontaremos para nosso servidor de equipe, ou um aplicativo proxy será necessário para realizar o salto final de encaminhamento.
Para informações mais detalhadas sobre como o Domain Fronting funciona, consulte o whitepaper Blocking-resistant communication through domain fronting e a documentação do meek do Projeto TOR.
Além dos domínios frontáveis padrão, como qualquer domínio google.com, é possível aproveitar outros domínios legítimos para fronting.
Para mais informações sobre a caça a domínios frontáveis, confira:
Muitos provedores de PaaS e SaaS fornecem um subdomínio ou URL estático para uso com uma instância provisionada. Se o domínio associado for geralmente altamente confiável, as instâncias podem fornecer confiança extra à sua infraestrutura de C2 em comparação com um domínio comprado e VPS.
Para configurar o redirecionamento, você precisará identificar um serviço que emita um subdomínio ou URL estático como parte de uma instância. Em seguida, a instância precisará ser configurada com redirecionamento baseado em rede ou aplicação. A instância atuará como um proxy, semelhante aos outros redirecionadores discutidos neste wiki.
Outra técnica interessante que merece mais pesquisa é o uso de buckets Amazon S3 excessivamente permissivos para C2. Confira o post S3 Buckets for Good and Evil de Andrew Luke (@Sw4mp_f0x) para mais detalhes sobre como os buckets S3 podem ser usados para C2. Esta técnica pode ser combinada com os recursos de C2 de terceiros do Empire para usar os buckets S3 legítimos do alvo contra eles.
Para outro exemplo de uso de PaaS para C2, confira Databases and Clouds: SQL Server as a C2 de Scott Sutherland (@_nullbind).
Outros serviços de terceiros foram usados na natureza para C2 no passado. Aproveitar sites de terceiros que permitem a postagem ou modificação rápida de conteúdo gerado pelo usuário pode ajudá-lo a evadir controles baseados em reputação, especialmente se o site de terceiros for geralmente confiável.
Confira estes recursos para outras opções de C2 de terceiros:
A infraestrutura de ataque é frequentemente fácil de identificar, parecendo uma casca de um servidor legítimo. Precisaremos tomar medidas adicionais com nossa infraestrutura para aumentar a probabilidade de nos misturarmos com servidores reais, seja entre a organização alvo ou serviços que o alvo possa concebivelmente usar.
Os Redirecionadores podem ajudar a se misturar redirecionando URIs inválidos, expirando links de payloads de phishing ou bloqueando técnicas comuns de respondedores de incidentes; no entanto, atenção também deve ser dada ao host subjacente e seus indicadores.
Por exemplo, no post Fall of an Empire, John Menerick (@Lord_SQL) aborda métodos para detectar servidores Empire na internet.
Para combater esses e indicadores semelhantes, é uma boa ideia modificar os padrões de tráfego C2, modificar as páginas de destino do servidor, restringir portas abertas e modificar os cabeçalhos de resposta padrão.
Para mais detalhes sobre como fazer isso e outras táticas para múltiplos frameworks de ataque, confira estes posts:
A infraestrutura de ataque pode ser atacada da mesma forma que qualquer outro host conectado à internet, e deve ser considerada ALTAMENTE sensível devido aos dados em uso e às conexões com ambientes alvo.
Em 2016, vulnerabilidades de execução remota de código foram divulgadas nas ferramentas de ataque mais comuns:
iptables deve ser usado para filtrar tráfego indesejado e restringir o tráfego entre os elementos de infraestrutura necessários. Por exemplo, se um servidor de equipe Cobalt Strike servir apenas ativos para um redirecionador Apache, as regras do iptables devem permitir apenas a porta 80 do IP de origem do redirecionador. Isso é especialmente importante para qualquer interface de gerenciamento, como SSH ou a porta padrão 50050 do Cobalt Strike. Considere também bloquear IPs de países que não são alvo. Como alternativa, considere usar firewalls de hipervisor fornecidos pelos seus provedores de VPS. Por exemplo, a Digital Ocean oferece Cloud Firewalls que podem proteger um ou vários droplets.
chattr pode ser usado em servidores de equipe para impedir que diretórios cron sejam modificados. Usando chattr, você pode restringir qualquer usuário, incluindo root, de modificar um arquivo até que o atributo chattr seja removido.
SSH deve ser limitado apenas à autenticação por chave pública e configurado para usar usuários com direitos limitados para o login inicial. Para segurança adicional, considere adicionar autenticação multifator ao SSH.
Atualização! Nenhuma lista de segurança está completa sem um lembrete para atualizar regularmente os sistemas e aplicar hot-fixes conforme necessário para remediar vulnerabilidades.
Claro, esta lista não é exaustiva do que você pode fazer para proteger um servidor de equipe. Siga práticas comuns de endurecimento em toda a infraestrutura:
Há uma série de recursos disponíveis online discutindo a configuração e o design seguros de infraestruturas. Nem toda consideração de design será apropriada para toda infraestrutura de ataque, mas é útil saber quais opções estão disponíveis e o que outros testadores estão fazendo.
Aqui estão alguns desses recursos:
Os tópicos abordados neste wiki fortalecem as infraestruturas de ataque, mas geralmente exigem uma boa quantidade de tempo para projetar e implementar. A automação pode ser usada para reduzir bastante os tempos de implantação, permitindo que você implante configurações mais complexas em menos tempo.
Confira estes recursos sobre automação de infraestrutura de ataque:
Documente tudo - Executar uma infraestrutura complexa de Red Team significa muitas partes móveis. Certifique-se de documentar a função de cada ativo e para onde seu tráfego é enviado.
Divida os ativos entre diferentes provedores de serviços e regiões - Os ativos de infraestrutura devem ser distribuídos entre vários provedores de serviços e regiões geográficas. Os membros da Blue Team podem aumentar os limites de monitoramento contra provedores identificados como realizando ativamente um ataque e podem até bloquear completamente um determinado provedor de serviços. Nota: tenha em mente as leis internacionais de privacidade ao enviar dados criptografados ou sensíveis através das fronteiras.
Não exagere - É fácil ficar animado com técnicas avançadas e querer jogar tudo contra um alvo. Se você está emulando uma ameaça adversária específica, use apenas técnicas que o ator de ameaça real usou ou técnicas dentro do conjunto de habilidades do ator de ameaça. Se o seu teste de red team atacar o mesmo alvo a longo prazo, considere começar "fácil" e trabalhar com o tradecraft mais avançado conforme suas avaliações progridem. Evoluir a técnica do red team junto com a blue team empurrará consistentemente a organização para frente, enquanto atingir a blue team com tudo de uma vez pode sobrecarregá-la e retardar o processo de aprendizado.
Monitore os logs - Todos os logs devem ser monitorados durante todo o engajamento: logs SMTP, logs Apache, tcpdump em redirecionadores socat, logs iptables (específicos para encaminhamento de tráfego ou filtragem direcionada), weblogs, logs Cobalt Strike/Empire/MSF. Encaminhe os logs para um local central, como com rsyslog, para facilitar o monitoramento. A retenção de dados do terminal do operador pode ser útil para revisar o uso histórico de comandos durante uma operação. @Killswitch_GUI criou um programa fácil de usar chamado lTerm que registrará todos os comandos do terminal bash em um local central. Registre toda a saída do terminal com lTerm. Confira o post de Vincent Yiu CobaltSplunk para um exemplo de como enviar logs do Cobalt Strike para o Splunk para monitoramento e análise avançados de infraestrutura.* Implementar alertas de eventos de alto valor - Configure a infraestrutura de ataque para gerar alertas de eventos de alto valor, como novas sessões de C2 ou capturas de credenciais. Uma forma popular de implementar alertas é por meio da API de uma plataforma de chat, como o Slack. Confira as seguintes publicações sobre alertas no Slack: Slack Shell Bot - Russel Van Tuyl (@Ne0nd0g), Slack Notifications for Cobalt Strike - Andrew Chiles (@AndrewChiles), Slack Bots for Trolls and Work - Jeff Dimmock (@bluscreenfojeff)
Identificar a resposta a incidentes - Se possível, tente identificar passiva ou ativamente as ações de resposta a incidentes antes do início da avaliação. Por exemplo, envie um e-mail de phishing mediano ao alvo (usando infraestrutura não relacionada) e monitore o tráfego que essa infraestrutura recebe. As investigações da equipe de resposta a incidentes podem revelar muitas informações sobre como a equipe opera e qual infraestrutura utiliza. Se isso puder ser determinado antes da avaliação, pode ser filtrado ou redirecionado diretamente.
Um GRANDE OBRIGADO a todas as seguintes pessoas (listadas em ordem alfabética) que contribuíram com ferramentas, dicas ou links para incluir na wiki, e outro OBRIGADO a qualquer pessoa que escreveu uma ferramenta ou publicação referenciada nesta wiki!