Abusando dos Runners do GitLab CI como um Framework de Command-and-Control

SOC Prime Team

Seguir

Abusando dos Runners do GitLab CI como um Framework de Command-and-Control

Detection stack

AIDR
Alert
ETL
Query

Relatório de Ameaça
Fluxo de Ataque
Detecções
Simulações

Resumo

O artigo descreve um conceito de prova chamado GitRunner C2 que transforma binários do runner GitLab CI legítimos e assinados digitalmente em uma estrutura de comando e controle. Ao instalar os runners como serviços do Windows, um atacante pode executar comandos arbitrários de PowerShell e exfiltrar dados através da infraestrutura embutida do GitLab. Como o tráfego utiliza HTTPS de saída para gitlab.com, a atividade pode se misturar com as comunicações normais dos desenvolvedores.

Investigação

O pesquisador demonstrou a cadeia de ataque completa, começando com a inscrição através de um comando simples de PowerShell elevado e terminando com a execução interativa de comandos. A investigação contou com os registros operacionais do Sysmon e do PowerShell para registrar a criação de processos, alterações no registro e comandos executados através do Script Block Logging. O estudo mostrou que o comportamento legítimo do runner pode ajudar a evitar a detecção tradicional baseada em EDR e rede.

Mitigação

Os defensores devem ficar de olho em novos serviços do Windows instalados com nomes incomuns ou serviços iniciados a partir de caminhos de arquivos não padrão. Habilitar o PowerShell Script Block Logging é essencial para obter visibilidade dos comandos executados através do runner. As organizações também devem limitar quem pode instalar serviços e monitorar tráfego HTTPS de saída suspeito para o GitLab a partir de endpoints que não são usados para o trabalho de desenvolvimento.

Resposta

Se essa atividade for detectada, isole imediatamente o endpoint afetado para interromper a comunicação de comando e controle. Revogue qualquer Token de Acesso Pessoal do GitLab e tokens de registro do runner vinculados ao ambiente comprometido. Os investigadores devem, então, revisar os registros do PowerShell e os Logs de Eventos do Windows para determinar o escopo dos comandos executados e qualquer exfiltração de dados resultante.

"flowchart TD step_ingress["T1105 u2013 Transferência de Ferramenta de Ingresso: Download do legítimo gitlab-runner-windows-amd64.exe via PowerShell de S3"] step_persistence["T1543.003 u2013 Criar ou Modificar Processo do Sistema: Serviço do Windows: Instalando o runner do GitLab como um serviço nativo do Windows para persistência"] rules_for_persistence("Nome da Regra: Caminho de Binário de Serviço Suspeito (via sistema) ID da Regra: 780e6396-d9f4-42b2-8d73-89918e2dab16") step_trust_subversion["T1553.002 u2013 Subverter Controles de Confiança: Assinatura de Código: Usando o binário do GitLab assinado digitalmente para evitar a detecção"] step_execution["T1059.003 u2013 Interpretador de Comando e Script: Shell de Comando do Windows: Executando payloads de comando via variáveis de CI usando executor de shell"] step_c2["T1071 u2013 Protocolo da Camada de Aplicação: Usando HTTPS (porta 443) para a infraestrutura do GitLab como um relay de C2"] step_exfiltration["T1567.001 u2013 Exfiltração Através de Serviço Web: Exfiltração para Repositório de Código: Movendo arquivos através dos Artefatos do GitLab e Registro de Pacotes Genéricos"] step_ingress –>|conduz_a| step_persistence step_persistence –>|permite| step_trust_subversion step_persistence -.->|detectado_por| rules_for_persistence step_trust_subversion –>|então| step_execution step_execution –>|usa| step_c2 step_c2 –>|conduz_a| step_exfiltration "

Fluxo de Ataque

Narrativa e Comandos de Ataque: Um adversário obteve acesso inicial e pretende estabelecer um canal de Comando e Controle (C2) persistente. Em vez de usar malware conhecido, ele baixa o legítimo gitlab-runner-windows-amd64.exe para se misturar com a atividade de DevOps. Ele utiliza o PowerShell para soltar o arquivo em um diretório temporário e então registrá-lo como um Serviço do Windows chamado “gitlab-runner”. Esse método visa explorar a natureza confiável das ferramentas de CI/CD para contornar a inspeção tradicional de segurança.

Script de Teste de Regressão:

# Simulação da Instalação do GitLab Runner para Validação de Detecção
$ErrorActionPreference = "Stop"

# 1. Defina caminhos e nomes para corresponder exatamente à lógica de detecção
$TargetDir = "C:WindowsTemp"
$BinaryName = "gitlab-runner-windows-amd64.exe"
$BinaryPath = Join-Path $TargetDir $BinaryName
$ServiceName = "gitlab-runner"

Write-Host "[+] Iniciando Simulação: Instalando $BinaryName"

# 2. Simular Criação de Arquivo (Evento Sysmon ID 11)
# Em um ataque real, isso seria um download da web. Aqui criamos um arquivo de teste com o nome específico.
New-Item -Path $BinaryPath -ItemType File -Force | Out-Null
Write-Host "[+] Arquivo criado: $BinaryPath (Aciona Evento ID 11)"

# 3. Simular Instalação de Serviço no Registro (Evento Sysmon ID 13)
# Criando o caminho do serviço no registro para acionar a detecção do ImagePath.
$RegPath = "HKLM:SYSTEMCurrentControlSetServices$ServiceName"
New-Item -Path $RegPath -Force | Out-Null
Set-ItemProperty -Path $RegPath -Name "ImagePath" -Value $BinaryPath
Write-Host "[+] Chave de registro criada e ImagePath: $RegPath (Aciona Evento ID 13)"

Write-Host "[+] Simulação Completa. Verifique o SIEM para alertas."

Comandos de Limpeza:

# Limpeza de artefatos de simulação
$TargetDir = "C:WindowsTemp"
$BinaryName = "gitlab-runner-windows-amd64.exe"
$BinaryPath = Join-Path $TargetDir $BinaryName
$ServiceName = "gitlab-runner"

Remove-Item -Path $BinaryPath -Force -ErrorAction SilentlyContinue
Remove-Item -Path "HKLM:SYSTEMCurrentControlSetServices$ServiceName" -Recurse -Force -ErrorAction SilentlyContinue
Write-Host "[+] Limpeza completa."

Junte-se à plataforma Detection as Code da SOC Prime para melhorar a visibilidade das ameaças mais relevantes para o seu negócio. Para ajudá-lo a começar e gerar valor imediato, agende uma reunião agora com os especialistas da SOC Prime.

Cadastre-se Gratuitamente