> For the complete documentation index, see [llms.txt](https://stacked-rwx.gitbook.io/public/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stacked-rwx.gitbook.io/public/malware-development/direct-syscall.md).

# Direct Syscall

Syscalls é uma abreviação para **System Calls**, em português, chamadas do sistema. Toda vez que um programa quer fazer algo sensível, como ler arquivos, criar processos ou acessar a memória, ele precisa pedir permissão ao sistemas operacional, e isso é feito através da system calls (ou syscalls).

Algumas funções da API do Windows é responsável por fazer essas syscalls, como CreateFile, ReadProcessMemory, VirtualAlloc, etc.

O fluxo dessas chamadas funciona da seguinte forma:

<figure><img src="/files/Jwl9NJFN16IvGv2TVPkX" alt=""><figcaption></figcaption></figure>

EDRs e AVs costumam monitorar a API do Windows usando Hooks, injeção de DLLs ou interceptação do userland/kernel.

Ou seja... quando um malware usa funções padrão como VirtualAllocEx ou CreateRemoteThread, ele está usando as mesmas rotas que o EDR já está monitorando.

A solução para esse problema se chama Direct Syscall.

### **Como funciona o Direct Syscall?**

O processo é simples:

* Identificar o número da syscall (Syscall ID) correspondendo a função que deseja usar.
* Escrever a rotina assembly que faz a syscall diretamente, sem que ela passe pela ntdll.dll.
* Chamar a syscall diretamente, o que evita os hooks do EDR que ficam nas funções mais altas.\
  Simples, não?

{% hint style="info" %}
Para pegar o número da Syscall, é interessante usar alguma ferramenta como a SysWhisper ou a SysWhisper2/3. Essa ferramenta vai gerar wrappers para as syscalls diretas. Ou melhor ainda, existe a técnica de hell's gate que pode ser usada para reconstruir syscalls em tempo real a partir da memória.
{% endhint %}

### Fluxo do funcionamento do Direct Syscall

<figure><img src="/files/xozsEsm4HilBmKunpTeB" alt=""><figcaption></figcaption></figure>

No inicio desse artigo, eu expliquei o fluxo de como a syscall funciona, agora vou explicar com base na imagem, o funcionamento do Direct Syscall.

**Programa:** É o nosso shellcode, malware, seja lá o que for.\
**Direct Syscall:** Em vez de chamar NtAllocateVirtualMemory, você chama diretamente o número da syscall dessa função (0x18), pulando a ntdll.dll.\
**Syscall:** Essa é a parte onde ela executa a função do Kernel diretamente, sem passar por pontos monitorados.

**Mas onde está o Bypass?**\
A linha vermelha é o espaço onde é monitorado pelo EDR: Api Function, ntdll.dll e Userland Hooks. A linha que sai do programa e vai direto para "Direct Syscall" mostra o caminho que ignora toda essa monitoração, indo direto ao Kernel.

### Explicando alguns termos

**Userland (Ring 3):** É o espaço onde rodam os programas normais. Não têm acesso direto ao hardware nem ao kernel.\
**Kernel mode (Ring 0):** É o espaço onde rodam partes do sistema operacional. Tem acesso total ao sistema.

<figure><img src="/files/vjD1aiMtv6HKuMhHd3E5" alt=""><figcaption></figcaption></figure>

**Userland Hooks:** Hooks são formas de interceptar, enganchar, fisgar e modificar o comportamento de funções.

* Em termos simples, os EDRs colocam hooks nas funções mais usadas do sistema, justamente para monitorá-las.<br>

  **Exemplo:** Um programa chama `VirtualAllocEx()` → essa função vai cair dentro de `ntdll.dll` → o EDR colocou um *hook* dentro dessa função para ver o que você está fazendo.<br>

  Desse jeito, o EDR sabe quando você cria processos, quando injeta memória e até quando faz algumas chamadas suspeitas.<br>

  Esses Userland Hooks normalmente são Inline Hooks, IAT Hooks ou Detours. (Irei explicar no próximo artigo!)

É isso! Se gostou, compartilha e comenta!