# T1574.014 - AppDomainManager Injection ## Técnica Pai Sub-técnica de [[t1574-hijack-execution-flow|T1574 - Sequestro de Fluxo de Execução]], que cobre métodos pelos quais adversários redirecionam o fluxo de execução de processos legítimos para carregar código malicioso. ## Descrição Adversários sequestram o mecanismo de carregamento de assemblies do .NET por meio da classe `AppDomainManager`, forçando aplicativos .NET legítimos a carregar e executar payloads maliciosos dentro de seus próprios processos. O .NET Framework usa `AppDomainManager` para criar e gerenciar domínios de aplicação - ambientes de execução isolados dentro de um processo que hospedam assemblies `.exe` ou `.dll`. Essa técnica, conhecida como **AppDomainManager Injection**, funciona de duas formas principais: - **Via arquivo de configuração** - o adversário modifica o `.config` do aplicativo alvo (ex: `app.exe.config`) inserindo as chaves `<appDomainManagerAssembly>` e `<appDomainManagerType>`, que instruem o CLR a carregar um assembly personalizado como gerenciador de domínio antes de qualquer código do aplicativo legítimo - **Via variáveis de ambiente** - as variáveis `APPDOMAIN_MANAGER_ASM` e `APPDOMAIN_MANAGER_TYPE` podem ser definidas no contexto do processo para o mesmo efeito, sem necessidade de modificar arquivos em disco - **Via domínio de aplicação customizado** - o adversário cria programaticamente um `AppDomain` personalizado dentro do processo alvo e carrega um assembly malicioso nele A vantagem crítica dessa técnica é que o payload é executado **dentro do processo legítimo**, herdando sua identidade, permissões e reputação. Se o processo alvo for um utilitário administrativo assinado pela Microsoft - como `msbuild.exe`, `regsvcs.exe` ou aplicativos LOB corporativos - o payload se mistura ao tráfego legítimo e evade controles de lista de permissão de processos. O malware [[s1152-imaploader|IMAPLoader]], associado a campanhas de espionagem atribuídas a agentes iranianos, utilizou AppDomainManager Injection para carregar seus módulos dentro de processos .NET confiáveis, dificultando a detecção em ambientes protegidos por EDRs que confiam em processos assinados. No contexto latino-americano, essa técnica é relevante em ambientes governamentais e corporativos que executam sistemas ERP, portais de conformidade tributária e ferramentas de integração com sistemas legados - frequentemente desenvolvidos em .NET - onde um `.config` modificado pode comprometer todo o pipeline de processamento de dados fiscais ou financeiros sem alterar nenhum binário protegido. ## Attack Flow ```mermaid graph TB A([Acesso ao sistema<br/>Windows com .NET]) --> B{Vetor de injeção} B --> C[Modificação de<br/>arquivo .config] B --> D[Variável de ambiente<br/>APPDOMAIN_MANAGER_ASM] B --> E[AppDomain<br/>programático customizado] C --> F[CLR lê configuração<br/>na inicialização do app] D --> F E --> G[Assembly malicioso<br/>carregado no domínio] F --> H[AppDomainManager<br/>malicioso instanciado] H --> G G --> I[Execução de payload<br/>dentro do processo legítimo] I --> J{Objetivo do adversário} J --> KPersistência encoberta\nsem novos processos] J --> LColeta de credenciais\ne segredos do app] J --> M[Comúnicação C2<br/>usando contexto do processo] ``` ## Como Funciona **Passo 1 - Identificação do alvo e preparação do assembly malicioso** O adversário identifica uma aplicação .NET legítima com privilégios elevados ou acesso a dados sensíveis - tipicamente um serviço Windows, utilitário de gerenciamento ou aplicativo LOB executado por usuários privilegiados. Em seguida, compila um assembly .NET personalizado que herda de `AppDomainManager`, sobrescrevendo o método `InitializeNewDomain()` para executar o payload malicioso durante a inicialização do domínio de aplicação. **Passo 2 - Configuração do hijack** O adversário implanta o assembly malicioso em um caminho acessível ao processo alvo - preferêncialmente no mesmo diretório do executável ou em um caminho listado no `probing path`. Depois, modifica o arquivo `.config` do aplicativo adicionando as chaves: ```xml <appDomainManagerAssembly>MaliciousAssembly, Version=1.0.0.0, Culture=neutral</appDomainManagerAssembly> <appDomainManagerType>MaliciousNamespace.MaliciousManager</appDomainManagerType> ``` Alternativamente, define `APPDOMAIN_MANAGER_ASM` e `APPDOMAIN_MANAGER_TYPE` como variáveis de ambiente do processo, sem tocar em arquivo algum. **Passo 3 - Execução furtiva e persistência** Na próxima inicialização do aplicativo legítimo, o CLR do .NET carrega automaticamente o assembly malicioso e instancia o `AppDomainManager` customizado antes de qualquer código do aplicativo original. O payload é executado com a identidade e o token de acesso do processo hospedeiro. Como nenhum novo processo é criado e o binário principal permanece intacto, a técnica evade monitoramento de criação de processos e ferramentas que verificam apenas integridade de executáveis - tornando a persistência difícil de detectar sem análise de assemblies carregados em runtime. ## Detecção ```yaml title: AppDomainManager Injection via Arquivo de Configuração .NET id: c4a1e8d3-2b7f-4c9a-b5e1-7d2f3a08c6e4 status: experimental description: > Detecta modificação de arquivos .config de aplicações .NET para inserção de chaves AppDomainManager, indicando possível tentativa de sequestro de fluxo de execução via T1574.014. logsource: category: file_event product: windows detection: selection_config_write: TargetFilename|endswith: '.config' TargetFilename|contains: - '\Program Files\' - '\Windows\System32\' - '\Windows\SysWOW64\' selection_content: Contents|contains: - 'appDomainManagerAssembly' - 'appDomainManagerType' - 'APPDOMAIN_MANAGER_ASM' condition: selection_config_write or selection_content falsepositives: - Frameworks de teste (xUnit, NUnit) que usam AppDomainManager para isolamento - Aplicações legítimas de virtualização .NET level: high tags: - attack.persistence - attack.privilege-escalation - attack.t1574.014 ``` ## Mitigação | ID | Mitigação | Descrição | |---|-----------|-----------| | M1022 | [[m1022-restrict-file-and-directory-permissions\|M1022 - Restrict File and Directory Permissions]] | Restringir permissões de escrita em arquivos `.config` de aplicações críticas. Somente administradores ou contas de serviço dedicadas devem ter acesso de escrita ao diretório de instalação de aplicativos .NET. Monitorar via SACL (System ACL) qualquer escrita em `.config` de aplicações privilegiadas. | | - | Monitoramento de CLR | Habilitar log de carregamento de assemblies .NET via ETW (Event Tracing for Windows) com o provedor `Microsoft-Windows-DotNETRuntime`. Alertar para assemblies carregados de caminhos não padrão dentro de processos de alta confiança. | | - | Controle de variáveis de ambiente | Monitorar definição de variáveis de ambiente `APPDOMAIN_MANAGER_ASM` e `APPDOMAIN_MANAGER_TYPE` por processos não administrativos, especialmente em contextos de serviços Windows. | ## Contexto Brasil/LATAM O Brasil possui um ecossistema extenso de aplicações .NET - especialmente no [[government|setor público]] e no [[financial|setor financeiro]] - desenvolvidas para integração com sistemas tributários como a SEFAZ, o eSocial, o SPED Contábil e plataformas de nota fiscal eletrônica. Esses sistemas LOB (line-of-business) são alvos de alto valor: processar dados fiscais e financeiros de grandes empresas, rodar com privilégios elevados, e raramente receber atualização de segurança rápida. Um arquivo `.config` malicioso inserido nesses sistemas pode comprometer o pipeline inteiro de processamento tributário sem acionar nenhum alerta baseado em criação de processo. Grupos de espionagem com foco em infraestrutura governamental da América Latina - como campanhas atribuídas a atores de estado-nação com interesse nos setores de [[energy|energia]], [[telecommunications|telecomúnicações]] e [[government|governo]] - têm demonstrado sofisticação crescente no abuso de mecanismos do .NET para evasão de EDR. O [[s1152-imaploader|IMAPLoader]], documentado em campanhas de espionagem de atores iranianos, exemplifica o nível de sofisticação que agentes patrocinados por estado aplicam a essa técnica - e que pode ser replicado em operações direcionadas à LATAM. A ausência de monitoramento ETW (Event Tracing for Windows) para carregamento de assemblies .NET é um gap defensivo predominante em SOCs brasileiros, tornando esta técnica especialmente eficaz na região. Para equipes de defesa no Brasil, a prioridade é habilitar logs do provedor `Microsoft-Windows-DotNETRuntime` via ETW e aplicar [[m1022-restrict-file-and-directory-permissions|M1022]] nos diretórios de instalação de aplicações .NET críticas - especialmente aquelas conectadas a sistemas da Receita Federal, bancos e operadoras de saúde. ## Referências *Fonte: [MITRE ATT&CK - T1574.014](https://attack.mitre.org/techniques/T1574/014)* ## Notas Relacionadas - [[_defenses|Hub de Defesas]] - controles preventivos e detecções - [[t1574-hijack-execution-flow|T1574 - Hijack Execution Flow]] - técnica pai