# T1129 - Módulos Compartilhados ## Descrição Sistemas operacionais modernos disponibilizam mecanismos nativos para carregar código reutilizável em tempo de execução - os chamados módulos compartilhados. No Windows, esses módulos são as DLLs (Dynamic-Link Libraries); no Linux e macOS, são os arquivos `.so` (shared objects) e `.dylib` (dynamic libraries), respectivamente. Essas estruturas existem para permitir que múltiplos processos compartilhem o mesmo código sem precisar duplicá-lo na memória. Adversários exploram essa capacidade legítima para executar payloads maliciosos de forma discreta. Em vez de criar executáveis que chamam aténção por si sós, eles empacotam funcionalidades de ataque - como comunicação com C2, injeção de processos ou coleta de credenciais - dentro de módulos compartilhados que são carregados por processos legítimos do sistema. Essa abordagem dificulta a detecção porque o processo pai visível é frequentemente confiável. No Windows, as funções `LoadLibrary` e `LoadLibraryEx` da [[t1106-native-api|Native API]] (parte do `NTDLL.dll`) permitem carregar DLLs de caminhos locais arbitrários ou caminhos UNC de rede. No Linux e macOS, o mesmo é feito via funções `dlopen` e `dlsym` da biblioteca `dlfcn.h`. Malwares como [[s0373-astaroth|Astaroth]] e [[s0455-metamorfo|Metamorfo]] - ambos com forte presença em campanhas direcionadas ao Brasil - utilizam módulos compartilhados para separar a lógica de evasão da lógica de payload, tornando a análise forense mais complexa. **Contexto Brasil/LATAM:** Famílias de malware bancário que historicamente atacam o Brasil, incluindo o [[s0455-metamorfo|Metamorfo]] e variantes do [[s0373-astaroth|Astaroth]], fazem uso extensivo de DLL sideloading e carregamento de módulos para se infiltrar em processos confiáveis do sistema operacional. Esse padrão é especialmente prevalente em campanhas contra o setor [[_sectors|financeiro]] brasileiro, onde os adversários precisam evadir soluções de segurança robustas implantadas por bancos e fintechs. O grupo [[g0129-mustang-panda|Mustang Panda]], com atuação documentada em campanhas de espionagem na América Latina, também utiliza essa técnica como parte de sua cadeia de ataque. ## Attack Flow ```mermaid graph TB A[T1566 Entrega do Payload] --> B[T1129 Carregamento de Módulo] B --> C[T1055 Injeção em Processo] C --> D[T1071 C2 via Protocolo Legítimo] D --> E[Persistência Estabelecida] ``` ## Como Funciona **1. Preparação** O adversário empacota o payload malicioso como uma DLL (Windows) ou shared object (Linux/macOS). O módulo é projetado para ser carregado por um processo legítimo - via DLL sideloading, substituição de DLL em diretório local, ou carregamento explícito via chamada de API. **2. Execução** O módulo é carregado em memória por um processo confiável. No Windows, isso ocorre via `LoadLibrary()` ou `LoadLibraryEx()`. No Linux, via `dlopen()`. O código malicioso executa no contexto do processo pai, herdando suas permissões e sua reputação perante ferramentas de segurança. **3. Pós-execução** Com o módulo carregado, o adversário tem execução de código no contexto do processo hospedeiro. A partir daí, pode estabelecer [[t1071-application-layer-protocol|comunicação C2]], realizar [[t1055-process-injection|injeção em outros processos]], coletar credenciais ou executar ações de impacto - tudo sem criar novos processos suspeitos. **Exemplo de artefato de detecção:** ```bash # Windows - Sysmon Event ID 7: ImageLoaded # Indicadores de carregamento suspeito de DLL: # ImageLoaded: C:\Users\Public\msvcr100.dll (DLL em caminho incomum) # Process: C:\Windows\System32\svchost.exe (processo legítimo como hospedeiro) # Signed: false # OriginalFileName: (ausente ou incompatível) # Linux - auditd: syscall openat + mmap # type=SYSCALL msg=... syscall=openat # a0=AT_FDCWD a1=/tmp/.cache/libssl.so.1.1 # type=EXECVE: carregamento de .so de /tmp ou /dev/shm é altamente suspeito ``` ## Detecção **Fontes de dados:** Sysmon Event ID 7 (ImageLoaded), Windows Event ID 4688, auditd (Linux - syscalls `openat`, `mmap`), EDR telemetry de carregamento de módulos, análise de cadeia de processos (parent-child). ```yaml title: Carregamento de Módulo Compartilhado de Caminho Suspeito id: a1f3b2d4-5e6c-4a8d-b9e0-2f3a4c5d6e7f status: experimental description: > Detecta carregamento de DLL ou shared object a partir de diretórios não padrão (ex: %TEMP%, %PUBLIC%, %APPDATA%), indicativo de DLL sideloading ou execução via módulo malicioso. logsource: category: image_load product: windows detection: selection: ImageLoaded|contains: - '\AppData\Local\Temp\' - '\Users\Public\' - '\ProgramData\' Signed: 'false' filter_legitimate: ImageLoaded|contains: - '\Microsoft\EdgeUpdaté\' - '\Google\Updaté\' condition: selection and not filter_legitimate falsepositives: - Instaladores legítimos que carregam DLLs temporárias durante setup - Ferramentas de desenvolvimento que usam diretórios de usuário level: medium tags: - attack.execution - attack.t1129 - attack.defense_evasion - attack.t1574.002 ``` ## Mitigação | Mitigação | Recomendação Prática | |-----------|---------------------| | [[m1038-execution-prevention\|M1038 - Execution Prevention]] | Implementar políticas de AppLocker ou WDAC que restrinjam o carregamento de DLLs não assinadas ou provenientes de diretórios fora de `%SystemRoot%` e `%ProgramFiles%`. No Linux, usar controles de AppArmor ou SELinux para restringir quais processos podem carregar bibliotecas de caminhos arbitrários. | ## Threat Actors que Usam - [[g0129-mustang-panda|Mustang Panda]] ## Software Associado - [[gh0st-rat|gh0st RAT]] (malware) - [[s0203-hydraq|Hydraq]] (malware) - [[s0196-punchbuggy|PUNCHBUGGY]] (malware) - [[s0603-stuxnet|Stuxnet]] (malware) - [[s0373-astaroth|Astaroth]] (malware) - [[s1185-lightspy|LightSpy]] (malware) - [[s0607-killdisk|KillDisk]] (malware) - [[s0455-metamorfo|Metamorfo]] (malware) - [[darkwatchman|DarkWatchman]] (malware) - [[s0438-attor|Attor]] (malware) --- *Fonte: [MITRE ATT&CK - T1129](https://attack.mitre.org/techniques/T1129)*