H.Modifier le loader pour qu'il utilise des syscalls direct ou indirects

Direct Syscalls: A journey from high to low - RedOpsRedOps

Direct Syscalls vs Indirect Syscalls - RedOpsRedOps - English

1. Contexte : L'architecture Windows

Le système d'exploitation Windows est divisé en deux modes d'exécution principaux :

• User Mode (Ring 3) : Là où s'exécutent les applications classiques. Elles n'ont pas d'accès direct au matériel ou à la mémoire critique.

• Kernel Mode (Ring 0) : Le noyau (Kernel) du système. Il possède des privilèges complets.

Pour qu'une application en User Mode réalise une action privilégiée (ex: lire un fichier, créer un processus), elle doit demander au Kernel de le faire via une System Call (Syscall).

2. La chaîne d'appel standard (The Journey)

Traditionnellement, un programme suit ce chemin :

1. Win32 API (kernel32.dll / advapi32.dll) : Fonctions documentées et faciles à utiliser (ex: CreateProcess).

2. Native API (ntdll.dll) : La couche la plus basse du User Mode. Les fonctions commencent souvent par Nt ou Zw. C'est ici que se prépare le passage vers le Kernel.

3. Syscall Instruction : L'instruction assembleur (syscall en x64) bascule l'exécution vers le Kernel.

3. Le problème : Le Hooking par les EDR

Les solutions de sécurité (EDR/AV) surveillent les activités malveillantes en plaçant des hooks (hameçons) dans la mémoire des processus, principalement au niveau de ntdll.dll.

• Mécanisme : L'EDR remplace les premières instructions d'une fonction (ex: NtWriteProcessMemory) par un saut (JMP) vers son propre moteur d'analyse.

• Résultat : Si l'appel est jugé suspect, l'EDR bloque l'exécution avant même qu'elle n'atteigne le Kernel.

4. La solution : Les Direct Syscalls

Le but est de court-circuiter ntdll.dll pour éviter les hooks.

Principe technique

Au lieu d'appeler la fonction dans ntdll.dll, le développeur reproduit manuellement l'étape finale en assembleur dans son propre code :

1. Placer le SSN (System Service Number) — l'identifiant unique de la fonction système — dans le registre EAX.

2. Préparer les arguments dans les registres adéquats.

3. Exécuter directement l'instruction syscall.

Avantage : Comme l'instruction syscall est exécutée depuis le code de l'attaquant et non depuis la ntdll.dll patchée, l'EDR ne voit jamais passer l'appel en User Mode.

5. Défis et limitations

• Variabilité des SSN : Les numéros de syscall changent à chaque version (parfois chaque mise à jour) de Windows.

  • Solution : Utiliser des techniques comme Hell's Gate ou Halo's Gate pour récupérer dynamiquement les SSN en lisant la ntdll.dll sur le disque ou en mémoire.

• Indicateurs de compromission (IoC) :

  • La présence d'instructions syscall dans un exécutable suspect est une anomalie.

  • Call Stack Analysis : Les EDR modernes vérifient d'où vient l'appel. Si un syscall arrive au Kernel sans passer par ntdll.dll, c'est une détection immédiate.

6. Évolution : Les Indirect Syscalls

Pour contrer l'analyse de la pile d'appel (Call Stack), les attaquants utilisent désormais les Indirect Syscalls :

• On prépare le SSN manuellement.

• Mais au lieu d'exécuter syscall dans notre code, on saute (JMP) vers l'instruction syscall située légitimement à l'intérieur de ntdll.dll.

• Bénéfice : Pour l'EDR, l'appel semble provenir d'un emplacement mémoire légitime.

B. Pratique :

On va d'abord voir avec un debuggeur l'architecture utilisé, c'est à dire le fait de passer de kernel32.dll à ntdll puis à l'instruction syscall en identifiant le SSN via windbg :

On va utiliser le programme réaliser sur la page A.Développer un loader de shellcode qui utilise l'API Windows

Désormais on le lance et on met un breakpoint à VirtualAlloc par exemple :

Ensuite comme on peut le voir NtAllocateVirtualMemory est appellé :

Desormais on jump vers le code exécuté par NtAllocateVirtualMemory pour voir le syscall réalisé et récupérer le SSN donc ça veut dire quand on fera des syscalls direct qu'il faudra aller de nouveau consulter ntdll.dll pour récupérer le SSN :

Bingo : On identifie le syscall et le SSN qui est 18h

Désormais passons au code du syscall direct mais avec un premier exemple non complexe avec peu d'argument :

NtDelayExecution - NtDocntdoc.m417z.com

Il va falloir télécharger nasm :

NASMwww.nasm.us

Donc on commence par définir la définition de la fonction :

#include <windows.h>
#include <stdio.h>

typedef NTSTATUS(NTAPI* pNtDelayExecution)(
  BOOLEAN Alertable,
  PLARGE_INTEGER DelayInterval
);


int main(){

    HMODULE ntdll = GetModuleHandleA("ntdll.dll");
    pNtDelayExecution NtDelayExecution = (pNtDelayExecution)GetProcAddress(ntdll, "NtDelayExecution");

    LARGE_INTEGER delay;
    delay.QuadPart = -150000000; //15 seconde de s

    NtDelayExecution(TRUE,&delay);


    return 0;
}

On lance windbg pour récupérer le SSN :

SSN = 0x34

Désormais on va ecrire un stub assembleur qu'on va exporter et utiliser dans notre code C. On pourrait écrire directement de l'assembleur en C, ça se nomme de l'assembly inline mais ça engendre des problèmes qui ne seront pas abordé puisque c'est un exemple haut level juste pour comprendre comment faire des syscalls direct :

Voici le code assembleur :

; nasm -f win64 stub.asm -o stub.o
global MyNtDelayExecution

section .text

MyNtDelayExecution:
    mov r10, rcx        ; Premier argument (Alertable) passe de rcx à r10
    mov eax, 0x34       ; Le SSN que tu as trouvé dans WinDbg !
    syscall             ; Appel direct au Kernel
    ret

Explication registre :

Pourquoi R10 au lieu de RCX ?

C'est une spécificité qui a lieu lorsqu'on réalise un syscall.

• La Convention d'Appel C (Shadow Space) : En x64, le compilateur C utilise toujours RCX pour le premier argument.

• La contrainte de l'instruction syscall : Lorsqu'on exécutes l'instruction syscall, le processeur écrase automatiquement la valeur du registre RCX pour y sauvegarder l'adresse de retour (le RIP actuel) afin de savoir où revenir une fois le travail fini en Kernel Mode.

• La solution de Microsoft : Comme RCX va être "détruit" par l'instruction syscall, Microsoft a décidé que pour les appels système, le premier argument serait lu dans R10 par le noyau.

C'est pour cela que dans chaque stub de ntdll.dll, la première ligne est systématiquement mov r10, rcx. On sauve l'argument dans R10 avant que RCX ne soit écrasé.

---

2. Rappel des Registres (Convention x64 Windows)

Voici comment les arguments des fonctions (comme NtDelayExecution ou NtAllocateVirtualMemory) sont répartis dans les registres au moment où on entre dans le stub (morceau de code) assembleur :

Registre	Rôle pour un Syscall	Ce qu'il contient dans ton code
RAX	ID de la fonction (SSN)	Le numéro 18h ou 34h que j'avais trouvé
RCX	Argument 1 (Temporaire)	La valeur Alertable ou le ProcessHandle.
R10	Argument 1 (Final)	Reçoit la copie de RCX pour le Kernel.
RDX	Argument 2	L'adresse de délai (&delay) .
R8	Argument 3	Le 3ème paramètre
R9	Argument 4	Le 4ème paramètre
Stack	Arguments 5, 6, ...	Si la fonction a plus de 4 arguments, ils sont sur la pile.

Ce qui nous donne donc en code C :

// gcc demo.c stub.o -o demo.exe

#include <windows.h>
#include <stdio.h>

typedef NTSTATUS(NTAPI* pNtDelayExecution)(
  BOOLEAN Alertable,
  PLARGE_INTEGER DelayInterval
);

extern NTSTATUS MyNtDelayExecution(BOOLEAN Alertable,PLARGE_INTEGER DelayInterval);


int main(){
  LARGE_INTEGER delay;
  delay.QuadPart = -250000000; //15 seconde de s

  MyNtDelayExecution(TRUE,&delay);

  
  return 0;
}

Et ça fonctionne très bien on commence utilisé la fonction extern défini dans notre code assembleur et ensuite on compile comme cela :

nasm.exe -f win64 stub.asm -o stub.o
gcc Loader_8.c stub.o -o demo.exe

Désormais faisons le syscall direct de NtAllocateVirtualMemory qui sera plus dure car il y a plus de 4 arguments donc le 5 et 6 sera sur la stack :

NtAllocateVirtualMemory - NtDocntdoc.m417z.com

NTAPI NtAllocateVirtualMemory(
    _In_ HANDLE ProcessHandle,
    _Inout_ _At_(*BaseAddress, _Readable_bytes_(*RegionSize) _Writable_bytes_(*RegionSize) _Post_readable_byte_size_(*RegionSize)) PVOID *BaseAddress,
    _In_ ULONG_PTR ZeroBits,
    _Inout_ PSIZE_T RegionSize,
    _In_ ULONG AllocationType,
    _In_ ULONG PageProtection
    );

On fait la même méthode on identifie le SSN et ensuite on code notre stub puis notre code C :

Je l'avais identifié c'est 0x18

Du coup avant de faire le syscall direct, regardons la call stack quand on utilise NtAllocateVirtualMemory :

On se rends compte que l'appel à la fonction est bien présente dans la call stack ainsi un edr qui analyse la callstack peut identifier cette appel, pour résoudre ceci faisons appel au syscall direct pour éviter d'avoir dans notre callstack une référence vers une fonction de ntdll :

Du coup voici le stub assembleur :

global MyNtAllocateVirtualMemory
.text
MyNtAllocateVirtualMemory:
    mov r10, rcx                ; 1er arg : ProcessHandle -> passe de RCX à R10
    mov eax, 0x18               ; SSN pour NtAllocateVirtualMemory
    
    ; Note : Les arguments 2 (RDX), 3 (R8) et 4 (R9) sont déjà aux bons endroits.
    ; Les arguments 5 et 6 sont déjà sur la pile, placés par le compilateur C 
    ; juste au-dessus de l'adresse de retour.
    int3           ; permet de placer un breakpoint pour analyser la call stack et regarder les valeurs des registres
    syscall                     ; Appel au Kernel
    ret                         ; Retour au code C

Le code C :

extern NTSTATUS MyNtAllocateVirtualMemory(HANDLE ProcessHandle,PVOID *BaseAddress,ULONG_PTR ZeroBits,PSIZE_T RegionSize,ULONG AllocationType,ULONG PageProtection);
/*Avec syscall*/
HMODULE ntdll = GetModuleHandleA("ntdll.dll");
SIZE_T regionSize = 12;           
HANDLE process = GetCurrentProcess();
PVOID baseadress = NULL;
NTSTATUS STATUS;

STATUS = MyNtAllocateVirtualMemory((HANDLE)(LONG_PTR)-1,&baseadress,0,&regionSize,MEM_COMMIT | MEM_RESERVE,PAGE_READWRITE);

if (STATUS == 0) {
        printf("[+] Succes ! Memoire allouee a : %p\n", baseadress);
    } else {
        printf("[-] Erreur : 0x%08X\n", STATUS);
    }

ça fonctionne mais ça serai cool de bien vérifier ce qu'on fait, si la call stack est clean regarder les registre de la pile pour bien identifier les arguments 5 et 6 de notre fonction :

Grâce à la ligne int3 présent dans notre stub, on va pouvoir obtenir un breakpoint juste avant l'opération syscall :

Quand on lance le go sur windbg on obtient bien notre breakpoint :

A partir de là on peut inspecter la callstack en utilisant la commande : k

On identifie notre stub sur la callstack et ainsi on note l'absence de la fonction NtAllocateVirtualMemory ce qui est un très bon point, cela veut dire que notre implémentation de notre syscall est bien celle utilisé pour alloué de la mémoire sans passer par ntdll.

Regardons désormais les registres :

Le registre RAX a pour valeur 0000000000000018 qui est le SSN de NtVirtualAlloc

Le registe RDX symbolise le deuxième arguments de notre fonction qui est l'adresse de la variable baseadress

STATUS = MyNtAllocateVirtualMemory(.,&baseadress,.,.,.,.);

Donc RDX = 0000009ddddff720

On regarde la valeur dans cette adresse qui normalement doit être égale à 0 car dans notre code on avait ça :

SIZE_T regionSize = 12;           
HANDLE process = GetCurrentProcess();
PVOID baseadress = NULL;

Du coup :

Pour le premier argument de ma fonction qui est dans le registre R10 :

STATUS = MyNtAllocateVirtualMemory((HANDLE)(LONG_PTR)-1,.,.,.,.,.);

On est donc bon pour R10 qui vaut bien -1

Passons au troisième argument de ma fonction qui est situé dans R8 :

STATUS = MyNtAllocateVirtualMemory(,.,0,.,.,.);

R8 est bien égal à 0.

Désormais le quatrième argument qui est situé dans R9 :

STATUS = MyNtAllocateVirtualMemory(,.,,&regionSize,.,.);        

R9 = 0000009ddddff728 qui est l'adresse de regionSize et regionSize pour rappel est egale à 12.

Donc avec la commande dq <adress> on va pouvoir identifier la valeur :

Ainsi c'est bon aussi, il nous reste désormais nos deux derniers arguments qu'on ne peut pas retrouver dans les registres mais sur la stack.

A finir : Il faut trouver comment accéder à la stack et je crois c'est via RSP.