C:\myapplication\myapplication.exe
      C:\myapp\subfolder\myapp.exe
      C:\SoftwareCompany\software.exe
      C:\myapplication\myapplication.dll
      C:\myapp\subfolder\myapp.dll
      C:\SoftwareCompany\software.dll
           

**Um modelo mental prático é:**

o processo carrega libeay32.dll

→ o processo chama OPENSSL_config(NULL)

→ o OpenSSL lê openssl.cnf

→ a secção engine provoca a tentativa de carregamento de uma dll especificada

→ o carregador do Windows aceita a dll e as suas dependências

***Se qualquer passo estiver em falta, a sua DLL não será carregada.***

Uma regra mínima que pode usar durante a depuração:

Se o processo apenas carrega libeay32.dll, isso não é suficiente.
Também tem de chamar o carregamento da configuração do OpenSSL e não o desativar.

- Deve chamar OPENSSL_config para funcionar ou
- CONF_modules_load_file ou
- OPENSSL_no_config não está definido.


Sem verificação de assinatura. Sem verificação. Qualquer DLL especificada é carregada, se o processo chamar OPENSSL_config.
Podemos consultar nomes típicos de DLLs relacionadas com o OpenSSL para enumerar possíveis aplicações a testar mais. Queremos verificar a OPENSSLDIR das DLLs e se o processo está a chamar o OpenSSL_conf.
Podemos verificar a OpenSSLDIR verificando o hash do ficheiro contra a lista neste repositório, ou obter uma cópia da dll relacionada com criptografia e simplesmente executar o openssldir_check na cryptodll (libeay32.dll etc).
Também podemos usar o ProcMon para verificar se o processo chama algum openssl.cnf. Se virmos openssl.cnf no procmon, então sabemos com certeza que a aplicação o chama. Noutros métodos, o que queremos obter é a informação de versão (nos campos do event.code 7) e de que caminho carrega o ficheiro openssl.cnf, verificando o hash do ficheiro contra a lista neste repositório, obtendo uma cópia da mesma DLL e fazendo uma verificação manual.


**Exemplo ao executar openssldir_check.exe**

`openssldir_check32.exe libeay32.dll`

`openssldir_check v1.0 by 0xm1rch`

**Saída:**

`SSLeay_version() returned OpenSSL 1.0.1g 7 Apr 2014`

`SSLeay_version() returned OPENSSLDIR: "/usr/local/ssl"`

- ref https://github.com/mirchr/openssldir_check
> Saída semelhante com o openssldir_check personalizado modificado que está pré-compilado neste repositório.

> A saída dá a versão do OpenSSL 1.0.1g e que a OpenSSLDIR está definida como **/usr/local/ssl**, o que é **altamente interessante!**

> **Sysmon event.code 7** dá-lhe as DLLs do OpenSSL carregadas e também a informação de versão da dll no campo file.pe.file_version.


#### Cenário de Escalação
1. Um serviço é executado como **SYSTEM** e usa OpenSSL
2. A DLL do OpenSSL chama openssl_conf e lê `C:\usr\local\ssl\openssl.cnf` no arranque, mas esse ficheiro é editável ou está em falta
3. Se um utilizador com privilégios baixos puder escrever nessa pasta, pode:
   - Colocar um `openssl.cnf` malicioso
   - Colocar a sua DLL
   - Aguardar pelo reinício do serviço
   - O código é executado como **SYSTEM**

> Resultado: Escalação de privilégios local ao colocar um openssl.cnf que a dll openssl da aplicação carrega e que termina carregando uma dll "maliciosa" personalizada.



### Vulnerabilidade do instalador/desinstalador NSIS

O NSIS é uma framework de instaladores Windows amplamente utilizada. A questão aqui descrita é que, quando um instalador ou desinstalador NSIS é executado com privilégios elevados, pode usar diretórios temporários em C:\Windows\Temp de uma forma com que um utilizador local normal pode interferir.

Na prática, isso significa que um atacante com privilégios baixos pode assumir o controlo de ficheiros em que o instalador confia, como ficheiros de plugins temporários ou ficheiros do desinstalador, e transformar isso em execução de código como SYSTEM. Por outras palavras, a fraqueza não é "o instalador é executado como admin", mas sim que o tratamento de ficheiros temporários do instalador pode permitir que um utilizador sem privilégios sequestre um fluxo de instalação ou desinstalação elevado

#### DLLs Comuns Vistas em Instaladores NSIS

> Nota: Algumas destas são **plugins oficiais do NSIS**, enquanto outras são **plugins de terceiros comuns** frequentemente usados por instaladores NSIS.  
> Ver uma destas DLLs é uma pista, mas não prova absoluta, de que um instalador usa NSIS. Um caminho de ficheiro como `C:\Windows\Temp\*.tmp\*.dll` é uma forte indicação.

| DLL | Propósito típico | Tipo | Notas |
|---|---|---|---|
| `System.dll` | Chama APIs Win32 e funções DLL externas a partir de scripts NSIS | Plugin oficial do NSIS | Um dos indicadores mais fortes de NSIS |
| `nsDialogs.dll` | Constrói diálogos e controlos personalizados do instalador | Plugin oficial do NSIS | Comum em instaladores NSIS modernos |
| `nsExec.dll` | Executa comandos de consola e captura a saída | Plugin oficial do NSIS | Frequentemente usado para comandos auxiliares silenciosos |
| `StartMenu.dll` | Permite ao utilizador escolher uma pasta do Menu Iniciar | Plugin oficial do NSIS | Comum em instaladores clássicos |
| `LangDLL.dll` | Apresenta um diálogo de seleção de idioma | Plugin oficial do NSIS | Aparece frequentemente em instaladores multilingues |
| `Banner.dll` | Mostra banner/UI de progresso durante os passos de instalação | Plugin oficial do NSIS | Maioritariamente cosmético |
| `InstallOptions.dll` | Cria páginas personalizadas de estilo antigo a partir de definições INI | Plugin oficial do NSIS | Amplamente substituído por `nsDialogs.dll` |
| `UserInfo.dll` | Obtém informação sobre o utilizador/conta atual | Plugin oficial do NSIS | Usado para verificações de privilégios ou de conta |
| `Dialer.dll` | Gere o comportamento de ligação dial-up/rede | Plugin oficial do NSIS | Maioritariamente legado |
| `Math.dll` | Fornece auxiliares aritméticos para scripts NSIS | Plugin oficial do NSIS | Menos frequentemente necessário em scripts mais recentes |
| `NSISdl.dll` | Descarrega ficheiros da internet | Plugin oficial do NSIS | Plugin de download mais antigo; frequentemente substituído por `inetc.dll` |
| `Splash.dll` | Mostra um ecrã de abertura | Plugin oficial do NSIS | Maioritariamente legado/cosmético |
| `AdvSplash.dll` | Mostra um ecrã de abertura mais avançado | Plugin comum do NSIS | Papel semelhante ao `Splash.dll` |
| `BgImage.dll` | Mostra uma imagem de fundo na UI do instalador | Plugin oficial/comum do NSIS | Maioritariamente cosmético |
| `inetc.dll` | Descarrega ficheiros via HTTP/FTP | Plugin de terceiros comum do NSIS | Muito comum em instaladores web |
| `InetLoad.dll` | Descarrega ficheiros da internet | Plugin de terceiros comum do NSIS | Alternativa ao `NSISdl.dll` / `inetc.dll` |
| `UAC.dll` | Gere a elevação e o comportamento relacionado com UAC | Plugin de terceiros comum do NSIS | Forte pista relacionada com NSIS |
| `AccessControl.dll` | Altera ACLs e permissões de ficheiros/pastas | Plugin de terceiros comum do NSIS | Usado em instalações sensíveis a admin |
| `Registry.dll` | Operações avançadas no Registo do Windows | Plugin de terceiros comum do NSIS | Mais capaz do que os comandos de registo incorporados em alguns casos |
| `ShellLink.dll` | Cria ou edita atalhos (`.lnk`) do Windows | Plugin de terceiros comum do NSIS | Auxiliar de gestão de atalhos |
| `SimpleFC.dll` | Compara ficheiros ou verifica diferenças entre ficheiros | Plugin de terceiros comum do NSIS | Plugin utilitário/auxiliar |
| `FindProcDLL.dll` | Deteta se um processo está em execução | Plugin de terceiros comum do NSIS | Frequentemente usado antes de atualizações |
| `KillProcDLL.dll` | Termina processos em execução | Plugin de terceiros comum do NSIS | Comum em desinstaladores/atualizadores |
| `NScurl.dll` | Descarrega/transfere dados usando funcionalidade estilo curl | Plugin de terceiros comum do NSIS | Auxiliar de rede mais recente/mais capaz |
| `ZipDLL.dll` | Gere a extração ou criação de arquivos ZIP | Plugin de terceiros comum do NSIS | Utilitário de arquivo |
| `unzipdll.dll` | Extrai arquivos ZIP | Plugin de terceiros comum do NSIS | Plugin de arquivo mais antigo |
| `untgz.dll` | Extrai arquivos `.tar.gz` | Plugin de terceiros comum do NSIS | Menos comum, mas visto em alguns pacotes |
| `VPatch.dll` | Aplica patches/atualizações binárias | Plugin comum relacionado com NSIS | Frequentemente usado em instaladores de patches |
| `CabDLL.dll` | Trabalha com arquivos CAB | Plugin comum relacionado com NSIS | Visto maioritariamente em fluxos de empacotamento mais antigos |
| `nsJSON.dll` | Analisa ou gera dados JSON | Plugin de terceiros comum do NSIS | Mais comum em instaladores com scripts modernos |
| `StdUtils.dll` | Utilitários auxiliares de uso geral para NSIS | Plugin de terceiros comum do NSIS | Frequentemente usado para auxiliares de SO/versão/caminho |
| `ExecDos.dll` | Executa comandos com melhor controlo sobre I/O e espera | Plugin de terceiros comum do NSIS | Alternativa/extensão ao `nsExec.dll` |

#### Indicadores Mais Fortes de NSIS

As seguintes DLLs são especialmente sugestivas de NSIS:

- `System.dll`
- `nsDialogs.dll`
- `nsExec.dll`
- `LangDLL.dll`
- `StartMenu.dll`
- `NSISdl.dll`
- `inetc.dll`
- `UAC.dll`

#### Cuidado

Alguns instaladores extraem estas DLLs temporariamente para uma pasta como:

- `$PLUGINSDIR`

Por isso, podem aparecer apenas em tempo de execução, não junto ao executável do instalador no disco.


### Vulnerabilidades de Redirecionamento DotLocal
**O abuso do redirecionamento DotLocal é um problema de sequestro de DLL do Windows em que uma pasta de aplicação com permissão de escrita permite a um atacante enganar um programa legítimo para carregar primeiro uma DLL maliciosa**

A vulnerabilidade de redirecionamento DotLocal abusa da funcionalidade incorporada do Windows .local / DotLocal DLL redirection. O Windows suporta o redirecionamento de DLLs ao honrar um ficheiro ou pasta com um nome como App.exe.local; quando presente, o carregador verifica primeiro a pasta do executável ou essa pasta .local para as DLLs, e isto pode aplicar-se mesmo quando é especificado um caminho completo da DLL. A Microsoft documenta isto como uma funcionalidade legítima para redirecionar carregamentos de DLLs.

Porque se torna uma vulnerabilidade: se um atacante puder escrever no diretório do executável (caminhos com permissão de escrita para o utilizador), ou num diretório de extração temporário usado por um processo privilegiado, pode criar a pasta Target.exe.local e colocar uma DLL maliciosa onde o Windows a irá preferir. Isso transforma a funcionalidade num sequestro de DLL, pelo que o processo de confiança carrega a biblioteca do atacante em vez da biblioteca pretendida.

#### Controlo manual
Processos identificados com privilégios elevados em caminhos com permissão de escrita global devem ser investigados para ver se são vulneráveis ao redirecionamento DotLocal. Se os consultar e encontrar aplicações. Faça o último controlo usando o ProcMon para ver se o processo tenta carregar bibliotecas a partir da pasta .exe.local criada. Pode usar a ferramenta GetSxsPath para determinar o caminho completo do ficheiro. O Procmon deve mostrar-lhe eventos NAME NOT FOUND / PATH NOT FOUND apontando para um diretório .exe.local se for vulnerável. Com base em relatórios públicos, as aplicações durante a instalação são particularmente vulneráveis durante o processo de instalação.

**Uma boa regra geral é:**
O ProcMon pode fornecer evidência de sondagem .local, mas a ausência de uma falha .exe.local visível não prova que a aplicação não seja suscetível. Para comctl32.dll especialmente, o rasto reflete frequentemente a ligação manifest/SxS em vez de uma simples pesquisa de DLL na pasta da aplicação. 


#### Se um programa carregar:

`C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

#### Verifique isto:

`C:\Path\To\Application.exe.local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

**Determine o caminho de redirecionamento para SxS DotLocal DLL Hijacking** - https://gist.github.com/rxwx/1717e95e5ec11bea12d33e93a3832508

#### Instalador DotLocal Wiz
**WiX Burn EXE bootstrapper** Versões afetadas >= 4, < 4.0.4 < 3.14.0. Isto afeta qualquer instalador construído com a framework de instaladores WiX.
O WiX também permite aos autores substituir o ícone predefinido e usar a UI padrão do WixStdBA ou uma aplicação bootstrapper personalizada, pelo que o EXE pode ser personalizado para parecer do fornecedor em vez de "WiX"

##### Detalhes
Se o bundle não for executado como admin, é usada a pasta TEMP do utilizador e não a pasta TEMP do sistema. Um utilitário é capaz de monitorizar a pasta TEMP do utilizador para alterações e colocar a sua própria DLL na pasta .be/.Local imediatamente quando a pasta .be é criada. Quando o motor burn eleva, a DLL maliciosa recebe privilégios elevados.

> **Ref** https://github.com/wixtoolset/issues/security/advisories/GHSA-7wh2-wxc7-9ph5

"Um processo wixstdba.exe separado é uma boa impressão digital do WiX Burn, mas o indicador mais forte para as versões afetadas é a própria versão do motor Burn: vulnerável se se identificar como <3.14.0 ou 4.0.0–4.0.3."


## Pré-requisitos
Configuração SYSMON bem configurada para capturar eventos de interesse, como event.code 1, 7, 11 e 13 para os caminhos com permissão de escrita para o utilizador e as chaves de registo mencionadas.
 - https://github.com/SwiftOnSecurity/sysmon-config
 - https://github.com/olafhartong/sysmon-modular

Auditoria avançada ativada para alguns dos eventos do Windows.

O Event ID 4688 (criação de processo) tem de ser explicitamente ativado para registar processos recém-criados. 
Por predefinição, não captura a linha de comando usada para iniciar o processo; esta funcionalidade tem de ser especificamente ativada na política de segurança.

Tarefa agendada - 4698 não está ativada por predefinição.


## ACL ⭐
### 🔹 Alguns Principais Comuns de ACL que Cobrem Utilizadores com Sessão Iniciada

| Principal               | Descrição                                                                 |
|--------------------------|-----------------------------------------------------------------------------|
| **Everyone**             | Todos os utilizadores, incluindo Convidados (e em versões mais antigas do Windows, até Anonymous Logon). Muito amplo, normalmente restrito a acesso de leitura. |
| **Authenticated Users**  | Qualquer conta que tenha iniciado sessão com sucesso (local ou de domínio). Exclui utilizadores anónimos. |
| **BUILTIN\Users**        | O grupo local **Users** na máquina. Inclui todas as contas locais padrão (não-admin). |
| **INTERACTIVE**          | Qualquer utilizador com sessão iniciada **localmente na consola** (teclado/sessão). Útil para diferenciar acesso local vs. remoto. |
| **COMPUTERNAME\\Username** | Uma **conta local** específica nesse computador (por exemplo, `LAPTOP01\Bob`). As permissões aplicam-se apenas quando esse utilizador inicia sessão localmente. |
| **DOMAIN\\Username**     | Uma **conta de domínio** específica (por exemplo, `CORP\Alice`). As permissões seguem o utilizador em todas as máquinas associadas ao domínio. |


### 📑 Atributos de ACL (Alguns Dos Interessantes Para Analisar)

Os atributos da Access Control List (ACL) definem que ações um utilizador ou grupo pode realizar em ficheiros ou pastas.  
Aqui estão alguns importantes que vale a pena notar:

| Atributo | Nome / Significado           | Porque É Interessante                                                                 |
|-----------|--------------------------|--------------------------------------------------------------------------------------|
| **F**     | Acesso Total              | Concede **todos os direitos possíveis** (ler, escrever, executar, eliminar, alterar permissões, assumir a propriedade). Equivalente a controlo "ao nível do proprietário". |
| **M**     | Acesso de Modificação            | Permite ler, escrever e eliminar ficheiros/pastas, mas **não alterar ACLs** ou a propriedade. O mais comum para utilizadores regulares. |
| **W**     | Acesso Apenas de Escrita        | O utilizador pode **criar ou modificar conteúdo** mas não o pode ler de volta. Raro, mas útil em cenários de "drop box" (por exemplo, submissões seguras de ficheiros). |
| **WD**    | Write Data / Add File    | Permite especificamente **criar ou escrever em ficheiros num diretório**. Essencial para poder adicionar ou substituir ficheiros dentro de uma pasta. |
| **AD**    | Append Data / Add Subdirectory | Em ficheiros: acrescentar dados ao fim de um ficheiro (não pode substituir). Em pastas: criar novas subpastas dentro. |


## Falsos Positivos
#### Faça as suas consultas, ajuste-as e, no fim, crie alertas a partir delas. 
Pode precisar de fazer alguma lista de permissões (ver abaixo caminhos típicos em ProgramData). A ideia é consultar caminhos típicos com permissão de escrita para o utilizador, mas acontece que os (ficheiros ou pastas) têm a ACL correta definida. Se a mentalidade ofensiva não ajudar a escalar privilégios - coloque-os na lista de permissões.
Filtre os menos interessantes: os que têm a ACL correta, nomes de ficheiros aleatórios (filtre a pasta). Queremos reduzir o ruído e ter uma linha de base. É importante fazer isto depois de verificar que não é uma vulnerabilidade. Para não perder uma tarefa agendada que é vulnerável em todos os clientes.


## Lista de Permissões
Provavelmente precisará de colocar as consultas na lista de permissões. Faça a sua caça, ajuste as consultas e crie alertas a partir delas para capturar novos eventos que ainda não analisou.
##### Provavelmente precisará de lista de permissões:
      C:\ProgramData\Microsoft
      C:\ProgramData\Package Cache
      C:\ProgramData\Packages
      etc.

Outros que podem precisar de lista de permissões, que podem ser comuns, são drivers relacionados com hardware e coisas semelhantes que têm nomes aleatórios..
      

## Metodologia
Não se esqueça de consultar no intervalo de tempo do seu "período de retenção de logs".
Uma boa metodologia é consultar no início um curto intervalo de tempo que vai aumentando progressivamente.
1) 1 dia
2) 1 semana
3) 2 semanas
4) 1 mês
5) 2 meses
6) etc..

Faça a sua caça e verifique os interessantes e ajuste e coloque na lista de permissões.. no fim crie alertas a partir deles para capturar novos eventos..

## Dicas e Truques
Se uma substituição de binário não for possível por causa da ACL correta. Verifique as permissões da pasta e se tem permissões para escrever ficheiros
verifique se o executável tenta carregar alguma dll que não existe. Se sim, crie-as e tem a sua execução de código. Se a substituição de binário não for possível porque é um processo em execução. Verifique possível sideloading de DLL ou verifique se você, como utilizador regular, tem permissões para reiniciar o próprio serviço. Outra forma é verificar se você, como utilizador regular, pode realizar um "shutdown" do qual escapa no último segundo. Um início de shutdown para processos e se escapar dele, pode conseguir substituir o binário do processo terminado. Se o serviço estiver em modo Autostart e não tiver permissões para iniciar/parar o serviço, o que pode verificar é se tem SeShutdownPrivilege e, se sim, iniciar um reinício com shutdown /r /t 0.

Se um serviço está a gerar o processo e se não for possível substituir o binário, o binário não tenta carregar nenhuma DLL em falta. Não desista - talvez o caminho não esteja entre aspas e tenha permissões de escrita e possa usar isso?

Construa as suas consultas camada sobre camada.. por isso verifique criações de serviços/tarefas agendadas, verifique a criação de processos com o parent como serviços ou processo relacionado com tarefas agendadas (svchost.exe com argumento Schedule). É possível que algum sistema crie o serviço ou a tarefa agendada mas o caminho do binário etc. não exista e a criação do processo nunca aconteça. Mas a vulnerabilidade continua lá e podem ser criados eventos diferentes relacionados com ela.

Para reduzir a carga das consultas (desempenho) e provavelmente a lista de permissões.. pode ser uma boa ideia ter consultas separadas para clientes/servidores. Assim, um conjunto de consultas usado apenas para os endpoints cliente e o mesmo conjunto usado para endpoints servidor.

A criação genérica de processos por SYSTEM é uma consulta de alto valor. Captura muitos cenários.. além de serviços e schtask a gerar processos filhos, também captura o msiexec.exe a gerar um processo filho. Também captura se um executável de c:\windows\ccmcache está a gerar um processo filho a partir de um caminho com permissão de escrita para o utilizador. Se fossemos ordenar executáveis em vulnerabilidade, eu ainda diria que o services.exe está relacionado com más configurações de software e o schtasks é mais uma má configuração do administrador..

Se tentou todas as consultas e não teve sucesso. se quiser caçar mais fundo, e fazer um pouco mais de trabalho - vá atrás de cada processo filho de services.exe e schtasks (svchost.exe com argumento Schedule), independentemente de onde. Enumere a empresa e procure também os que estão em caminhos típicos protegidos por admin (Program Files & Program Files (x86)). É mais comum do que pensa que os fornecedores de software estraguem a ACL mesmo em caminhos tipicamente protegidos. Use os eventos de criação de processos e os eventos de serviços e tarefas agendadas. Para tarefas agendadas - consulte cada campo Command e campo Argument. O campo argument pode estar a apontar para um ficheiro de script num caminho com permissão de escrita para o utilizador ou na raiz C. Os campos command podem estar a apontar para um binário que tem uma ACL insegura. Também pode analisar C:\PROGRA~3, que é a representação de nome curto (DOS) 8.3 de C:\ProgramData.

## Processos de desinstalação
É provável que, se um utilizador pode acionar uma instalação, também possa acionar uma desinstalação. Os processos de desinstalação são de interesse independentemente de onde esteja o caminho do ficheiro.
Se a ACL não estiver correta - uma substituição de binário provavelmente causará problemas.
Consulte também a criação de ficheiros típicos de desinstalação usando Sysmon event.code:11.
Queremos fazer isto para capturar todos os desinstaladores sem confiar nos eventos de criação de processos. Isto porque não é comum que os utilizadores façam realmente a desinstalação de aplicações instaladas.. Simplesmente não se importam com isso e, portanto, será mais fácil perder alguns eventos de desinstalação que existem mas nunca são acionados.

### Exemplo de nomes de processos de desinstalação
#### Nomes Genéricos Comunsuninstall.exe – Mais genérico e amplamente utilizado.
          unins000.exe, unins001.exe – Comum com instaladores Inno Setup.
          unwise.exe – Frequentemente usado por pacotes mais antigos do Wise Installer.
          uninst.exe – Versão abreviada, frequentemente encontrada em software legado.
          uninstaller.exe – Variante ligeiramente mais longa e descritiva.
          remove.exe – Por vezes usado para instaladores mínimos.
          setup.exe (com parâmetro /uninstall ou /remove) – Algumas aplicações reutilizam o executável do instalador para a desinstalação.
          appname_uninstall.exe (por exemplo, chrome_uninstall.exe)
          update.exe (com --uninstall) – Visto em aplicações como Slack ou Discord que usam instaladores Squirrel.

#### Padrões a Considerar

          *_uninstall.exe – Muitas aplicações prefixam o nome da aplicação, por exemplo, teams_uninstall.exe, zoom_uninstall.exe.
          *_cleanup.exe – Ferramentas de remoção têm frequentemente variantes de limpeza, por exemplo, driver_cleanup.exe.
          *_remover.exe – Outro estilo comum de nomenclatura de AV/fornecedor.


## Ficheiros PE / Binários com execução de código ao carregar
### Considere consultar os que estão na lista tanto em logs windows/sysmon como em logs procmon
| Extensão | Tipo PE | Execução de código ao carregar? | Ponto de entrada / mecanismo | Notas |
|-----------|---------|--------------------------|-------------------------|-------|
| `.exe` | Executável PE | Sim | PE `AddressOfEntryPoint` | O código inicia quando o executável é lançado |
| `.dll` | DLL PE | Sim | `DllMain` / callbacks TLS | O código pode executar quando a DLL é carregada num processo |
| `.sys` | Driver de kernel PE | Sim | `DriverEntry` | O código de inicialização do driver executa quando o driver é carregado |
| `.scr` | Executável PE | Sim | PE `AddressOfEntryPoint` | Essencialmente um executável; `.scr` é principalmente uma convenção |
| `.cpl` | DLL PE | Sim | `DllMain` + `CPlApplet` | Carregado pela infraestrutura do Painel de Controlo |
| `.ocx` | DLL PE / ActiveX | Sim | `DllMain` + pontos de entrada COM/ActiveX | A inicialização da DLL ocorre quando é carregada |
| `.drv` | DLL PE / driver legado | Normalmente | `DllMain` ou ponto de entrada específico do driver | Depende do tipo específico de `.drv` |
| `.efi` | Binário PE/COFF EFI | Sim | Ponto de entrada EFI | O código executa quando carregado pelo UEFI |
| `.ax` | DLL PE | Sim | `DllMain` + interfaces DirectShow | A inicialização da DLL ocorre ao carregar |
| `.acm` | DLL PE | Sim | `DllMain` + pontos de entrada ACM | Carregado como codec do Audio Compression Manager |
| `.ime` | DLL PE | Sim | `DllMain` + pontos de entrada IME | A inicialização da DLL ocorre quando é carregada |
| `.tsp` | DLL PE | Sim | `DllMain` + pontos de entrada TAPI | A inicialização da DLL ocorre quando é carregada |
| `.pyd` | DLL PE | Sim | `DllMain` + inicialização de módulo Python | Extensão Python nativa |
| `.node` | DLL PE | Sim | `DllMain` + inicialização de addon Node.js | Addon Node.js nativo |
| `.xll` | DLL PE | Sim | `DllMain` + pontos de entrada Excel XLL | Carregado por `EXCEL.EXE` |
| `.wll` | DLL PE | Sim | `DllMain` + carregamento de add-in Word | Carregado por `WINWORD.EXE` |



## Ficheiros de script
### Considere consultar os que estão na lista
| Extensão | Linguagem / Tipo           | Propósito / Utilização                                         | Contexto de Execução                                          |
|-----------|---------------------------|---------------------------------------------------------|------------------------------------------------------------|
| .bat      | Batch Script               | Tarefas de automação de linha de comandos legadas, scripts simples     | `cmd.exe` (Command Prompt)                                  |
| .cmd      | Batch Script (estilo NT)    | Semelhante a `.bat`, preferido em sistemas baseados em NT         | `cmd.exe` (Command Prompt)                                  |
| .vbs      | VBScript                   | Tarefas de automação, scripts de início de sessão, scripts de administração           | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .vbe      | VBScript (codificado)         | Versão codificada de `.vbs` para ofuscação              | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .ps1      | Script PowerShell          | Tarefas modernas de automação e configuração do Windows       | PowerShell (`powershell.exe`, `pwsh.exe`)                   |
| .js       | JScript                    | Versão da Microsoft do JavaScript para tarefas WSH          | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .jse      | JScript (codificado)          | Versão encriptada de `.js` para ofuscação               | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .wsf      | Windows Script File (XML)  | Misturar VBScript, JScript e outros scripts em formato XML       | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .wsh      | Windows Script Host Settings | Definições de configuração para scripts WSH                  | Windows Script Host (`wscript.exe`, `cscript.exe`)          |
| .jar      | Java Archive               | Aplicações Java empacotadas como um único ficheiro             | `java.exe` (consola) / `javaw.exe` (sem janela de consola)       |
| .hta      | HTML Application (HTA)     | Scripts Windows com GUI usando HTML, CSS e JScript/VBScript | `mshta.exe` (Microsoft HTML Application Host)          |
| .com      | Aplicação MS-DOS / Executável DOS | Programas executáveis legados, pequenos utilitários de linha de comandos | Executado diretamente como programa; no Windows moderno, programas .com clássicos de 16 bits executam através do NTVDM em Windows de 32 bits, e não são suportados nativamente em Windows x64/ARM |
| .chm     | Compiled HTML Help          | Ficheiros de ajuda/documentação offline para programas Windows   | `hh.exe` (Microsoft HTML Help Viewer)                           |

## Scripts de Arranque/Início de Sessão

Os Scripts de Arranque e de Início de Sessão (e de Encerramento ou Fim de Sessão) são scripts de automação que executam (gpscript.exe) automaticamente em computadores associados ao domínio ou quando os utilizadores iniciam sessão, e são normalmente implementados usando Group Policy Objects (GPOs) a partir de um controlador de domínio num ambiente Windows Active Directory.

Arranque/Encerramento
- Executam como: conta Local System (privilégios elevados).

Início/Fim de Sessão
- Executam como: utilizador atual (privilégios elevados se administrador).
### Utilizações comuns:
- Mapeamento de unidades de rede para todos os utilizadores
- Instalação de software
- Aplicação de definições a nível de sistema
- Iniciar ou configurar serviços
- Executar scripts ou executáveis

### Chaves de Registo Afetadas

Quando um script de arranque/início de sessão é executado via GPO:

| Hive / Caminho | Propósito |
|-------------|---------|
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logon | Rastreia scripts de início de sessão do utilizador, a sua ordem de execução, estado, hora da última execução e parâmetros. |
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logoff | Rastreio semelhante para scripts de fim de sessão. |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Startup | Informação de rastreio de scripts de arranque (aplica-se a todos os utilizadores). |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown | Informação de scripts de encerramento. |

#### Procure caminhos graváveis pelo utilizador para scripts e executáveis no processo filho de gpscript.exe, ou partilhas de rede graváveis ou genéricas (SYSVOL). 
Leia os scripts que são executados e verifique se existem más configurações como outros caminhos graváveis pelo utilizador ou caminhos que não existem ou informação sensível. Procure possíveis palavras-passe usadas (net use z: \\server\share /user:domain\username password) ou outra informação sensível. 

**Categorias de Má Configuração de Scripts de Início de Sessão**
- SS1 – Credenciais em texto simples
- SS2 – Permissões inseguras (script de início de sessão modificável por utilizador comum)
- SS3 – Partilhas inexistentes (que podem ser criáveis por utilizador comum)
- SS4 - Administradores com scripts de início de sessão

**Más Configurações de Scripts de Início de Sessão**

1. SS1 - Credenciais em texto simples dentro de um script de início de sessão
2. SS2 - Permissões de partilha inseguras
3. SS2 - Permissões de ficheiro inseguras
4. SS2 - Permissões NETLOGON/SYSVOL inseguras
5. SS2 - Permissões de script de início de sessão inseguras
6. SS2 - Permissões de script de início de sessão GPO inseguras
7. SS3 - Partilhas inexistentes
8. SS4 - Administradores com script de início de sessão
9. SS4 - Administradores com scripts de início de sessão mapeados a partir de partilha inexistente



## MSIExec / Reparações MSI
##### Os nossos testes não deram qualquer resultado na escalada de privilégios em cenários onde conseguíamos lançar o edge e escapar para um prompt de cmd. Isto deve-se provavelmente ao facto de os navegadores baseados em chromium estarem a personificar o utilizador/restringir o processo de renderização para executar como SYSTEM e não permitirem que o internet explorer/edge lance cmd ou outros processos como o utilizador SYSTEM. Acreditamos que se nenhum navegador baseado em chromium estiver instalado (como o firefox) ou versões mais antigas. Uma escalada de privilégios poderia ser possível se conseguisse lançar tal processo e escapar a partir desse para um prompt de comando.

Se quiser enumerar possíveis eventos relacionados com isto, consulte por msiexec.exe como processo pai com cmd.exe OU conhost.exe OU powershell.exe OU pwsh.exe como processo filho.
Contacte os utilizadores cuja consulta devolve resultados e pergunte-lhes o que instalaram/repararam. Também pode verificar event.provider: "MsiInstaller" e event.code: (1033 OR 11707) ou semelhante para obter mais contexto sobre qual instalador msi foi instalado por volta do mesmo timestamp.
Também pode tentar isto você mesmo no Software Center e instalar as aplicações e procurar prompts de comando que pode pausar antes de desaparecerem marcando uma secção na janela. Depois escape usando as mesmas técnicas mencionadas no link abaixo.



##### Consulta de exemplo```
(event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1 AND winlog.event_data.IntegrityLevel: System AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))
OR
(event.provider: Microsoft-Windows-Security-Auditing AND event.code: 4688 AND winlog.event_data.TokenElevationType: "%%1936" AND winlog.event_data.MandatoryLabel: "S-1-16-16384" AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))