Antivirus, PowerShell et ORC pour le Live-Forensics

Magazine
Marque
MISC
HS n°
Numéro
23
Mois de parution
février 2021
Spécialité(s)


Résumé

Dans un parc informatique de plusieurs dizaines de milliers de postes, détecter, chercher et récupérer des artefacts à distance est un travail difficile. Les outils de live-forensics et EDR sont les solutions généralement retenues pour ces usages, néanmoins leur mise en œuvre peut s’avérer complexe sur des systèmes d’information modernes et des zones géographiques étendues. Cet article aborde les capacités de déploiement d’outils de live-forensics au travers des antivirus pour permettre la mise en œuvre des outils de référence, comme DFIR-ORC, lorsque c’est nécessaire.


Body

Introduction & contexte

Le contexte de la réponse à incident sur l’environnement poste de travail

Le live-forensics et la live-response sont des sujets dont nous trouvons des traces depuis plus de 10 ans [1] [2] [3] dans la littérature. En effet, lorsque l’on regarde l’activité des CSIRT, SOC et CERT, nous nous apercevons rapidement qu’il est presque impossible pour un SIEM de collecter les journaux d’événements permettant une couverture à 100 % des différents types d’IoC sans rencontrer rapidement des problèmes de dimensionnement ou de coûts et cela dès lors que l’on surveille des périmètres importants. Il suffit de regarder la verbosité d’une configuration sysmon par rapport à la simple collecte des journaux d’événements par défaut pour s’en rendre compte. Il est donc nécessaire d’avoir une approche itérative dans ces techniques de surveillance et de détection, mais également sur le plan des capacités de réponse.

Si les solutions EDR (Endpoint Detection & Response) [4] commerciales permettent d’adresser ces difficultés, notre expérience montre néanmoins des limitations sur certains aspects. Par exemple, des fonctionnalités absentes comme la collecte d’images mémoire, la recherche de formats d’IoC peu courants, l’impossibilité de définir des règles de détection personnalisées ou encore l’absence de capacité d’industrialisation des actions de remédiation sont des éléments parfois manquants dans ces produits.

Par ailleurs, les solutions libres telles que GRR Rapid Response ou DFIR-ORC permettent bien d’investiguer voire de compléter les fonctionnalités des EDR lorsque c’est nécessaire. Leur approche libre de droits permet de limiter les coûts associés et d’améliorer la confiance dans le code du logiciel, en contrepartie de l’absence de support éditeur et d’un report partiel des coûts vers la ressource humaine nécessaire. Mais dans tous les cas, ces 2 solutions ne répondent pas à la question des actions de remédiation sur les postes de travail, qui s’avère être une mission difficile sur de grands parcs informatiques.

Acquisition, ordonnancement, ciblage, collecte et lancement de tâches forensiques massives

Nous commencerons ici par rappeler les grandes problématiques qui sont censées être adressées par un outil de live-forensics, à savoir :

  • la prévention ;
  • la détection ;
  • l’investigation ;
  • la remédiation.

Il ne faut pas oublier que les capacités de détection automatisées des EDR ne couvrent souvent que les menaces ou techniques « connues » et que les capacités futures à base d’IA restent à éprouver. Au-delà de la recherche d’IoC la réalité du travail d’un SOC consiste aussi à rechercher de nouvelles menaces dans son parc supervisé. Posséder la bonne information, actionnable au bon moment, durant un incident est un des enjeux majeurs de la supervision de sécurité.

Dans le cadre d’investigations numériques, ce fait est d’autant plus marqué par la complexité d’acquisition d’informations qui est proportionnelle à la dispersion géographique des systèmes ainsi qu’à leur nombre (notamment quand le périmètre porte sur des centaines de milliers de postes). Dans ce sens, toute solution qui permet d’éviter le rapatriement physique des postes jusqu’au laboratoire de forensics et de limiter le nombre d’analyses complètes au strict nécessaire est un gain de temps et d’argent conséquent pour un organisme. En conséquence, l’ordonnancement des moyens de réponse par rapport aux besoins d’analyses au cours d’un incident est donc primordial dans une organisation.

L’autre aspect à ne pas négliger concerne le déploiement de l’agent qui répond à ces besoins qui peut s’avérer pour le moins compliqué et long en dehors d’une période d’incident sur des parcs conséquents. Nous constatons régulièrement les doutes que les équipes en charge des postes de travail expriment à propos de l’ajout d’un agent supplémentaire sur des machines souvent déjà bien chargées.

De ce constat, nous dessinons un besoin intermédiaire en live-forensics que l’on qualifiera ici de « léger » et qui doit permettre de compléter les recherches lorsque les SIEM ne collectent pas les traces nécessaires et que les EDR ne possèdent pas la fonctionnalité (ou sont simplement absents du périmètre), mais aussi de déployer efficacement des outils plus lourds comme DFIR-ORC le cas échéant.

1. Antivirus : point d’entrée de l’environnement bureautique

Comme nous l’avons évoqué plus haut, le déploiement d’un outil de live-forensics sur le parc peut s’avérer difficile selon les contextes. Il est donc intéressant de s’appuyer sur des solutions existantes qui, malgré certaines limitations par rapport à des solutions dédiées, sont déjà en place et largement déployées. Les antivirus restent une première barrière active et fiable et sont déjà largement présents dans nos parcs informatiques, ce qui répond à ces critères.

Certains éditeurs de ces solutions proposent dans leur produit une fonctionnalité permettant l’exécution de code par l’agent antivirus sur les clients. Par exemple, dans le produit Broadcom Symantec Endpoint Protection cette capacité est accessible via le module d’intégrité de l’hôte, au travers d’un contrôle personnalisé avec une action nommée « utilitaire : exécuter un script » [5]. Il est ensuite possible de paramétrer l’intervalle d’exécution du contrôle et donc du script.

1 SEP GetSpice-s

Fig. 1 : Exécuter un script de contrôle d’intégrité avec SEP.

Cette fonction initialement prévue pour du contrôle de conformité et d’éléments fixes (clé de registre, fichier) probablement en vue de faire du NAC et de la gestion de quarantaine des postes peut être détournée pour exécuter le code d’agents de live-forensics (ou par un attaquant qui mettrait la main sur votre console antivirus…). Si le mode de fonctionnement par exécution à intervalle régulier peut limiter certains usages, cela permet quand même aux équipes de défense de se doter rapidement et à moindres frais d’une capacité d’exécution de code PowerShell avec des privilèges système.

On peut se servir de cette fonction pour compléter les capacités manquantes des EDR, maximiser le nombre de routes possibles pour les interventions et donc également déployer des outils complémentaires par un effort de développement raisonnable d’un framework PowerShell modulaire.

2. Get-Spice : light live-forensics et ordonnancement de tâches

2.1 Un outil de forensique rapide et interopérable

Get-SPICE (pour Get Secure PowerShell Investigation & Control for Endpoint) est un projet open source initié par le SOC (Security Operations Center) du groupe EDF. C’est un outil conçu pour réaliser des investigations numériques simples, et permettre de déployer rapidement l’outillage nécessaire aux investigations complètes en cas de suspicion d’incident. Un module de réponse actif est également prévu pour permettre par exemple des actions de nettoyage scriptées.

Fonctionnellement, Get-Spice se compose de deux parties : un agent déployé sur les postes, et un serveur orchestrant les analyses à effectuer. Il s’agit d’un mode de transaction client-serveur assez classique.

Écrit en PowerShell, intégré nativement aux systèmes Windows depuis Windows XP, l’agent ne requiert pas l’installation d’autres logiciels tiers ; ce qui garantit une compatibilité avec une grande majorité des postes Windows du système d’information. Pareillement, le serveur est codé en Go, langage de programmation open source développé par Google, et peut aussi être compilé à destination des systèmes d’exploitation de type UNIX-like.

Get-Spice repose sur une architecture centralisée, les ordinateurs se connectent au serveur et récupèrent régulièrement la liste des tâches de collecte qui leur sont assignées pour ensuite les effectuer et retourner les informations récupérées au serveur. Ces actions effectuées localement sur les ordinateurs sont orchestrées par l’agent Get-Spice, exécuté en tâche de fond, qui communique avec le serveur par le biais de requêtes HTTP.

2 get spice-s

Fig. 2 : Exécuter un script de contrôle d’intégrité avec SEP.

2.2 Architecture et modules de recherche

Les différentes fonctionnalités de recherche et de collecte sont associées à l’agent de manière modulable. Aucune des fonctionnalités exécutées n’est inhérente à l’agent déployé sur les hôtes, elles sont toutes issues de modules.

Ces modules sont tout simplement des scripts PowerShell, décrivant une ou plusieurs fonctionnalités d’investigation bien distinctes des autres, comme contrôler une clé de registre ou vérifier la présence d’un fichier via un hash.

Avant d’exécuter un contrôle, l’agent vérifie si le module correspondant a déjà été téléchargé, s’il est inexistant sur l’hôte, l’agent demandera au serveur d’identifier le module contenant ladite fonctionnalité et de le mettre à disposition pour qu’il puisse être téléchargé. Une fois le module téléchargé, il est placé dans un répertoire local servant de cache.

À l’exécution, les fichiers PowerShell constituant le module d’origine, sont chargés par l’agent, en cours d’exécution, en tant que blocs de script puis exécutés.

# Paramètres de recherche associés à la tâche
 
param (
  [string] $registryPath,
  [string] $propertyName
);
 
$result = Get-ItemProperty -Path "Registry::$registryPath";
if ($propertName.Length -ne 0) {
    $result = $result | Select-Object -ExpandProperty $propertyName;
}
 
$infos = @{};
$result.psobject.properties | Foreach { $infos[$_.Name] = $_.Value };
 
$infos = HashTo-String -Hashtable $infos;
return New-Syslog -Facility 5 -Severity 4 -Content "$infos";
 
# Renvoi des résultats au format Syslog

Ci-dessus le module Inspect-Register permet de lire la valeur d’une clef de registre qui a été spécifiée en paramètre. Les résultats sont renvoyés au format Syslog à l’aide d’une fonction utilitaire pour permettre un traitement des résultats dans un SIEM.

Get-Spice est une solution rapide à installer et à utiliser, pour collecter des informations ciblées en temps réduit. Cependant, les fonctionnalités doivent être codées au préalable, ce qui peut s’avérer chronophage. Certaines menaces requièrent une vue d’ensemble pour être détectées, nécessitant la collecte de centaines d’artefacts à des emplacements différents. Dans l’urgence, si ce scénario complexe n’a pas été préparé, Get-Spice s’avérera inadapté. C’est ainsi que Get-Spice a notamment été conçu pour permettre de déployer des outils bien plus complets tels que DFIR ORC.

3. ORC : un PE32 pour les gouverner tous et dans Get-Spice les lier

L’Outil de Recherche de Compromission (ou tout simplement ORC) est un logiciel d’acquisition de données forensiques en environnement Windows publié par l’ANSSI en 2019 sur GitHub. L’agence a créé cet outil en 2011 dans le but de s’adapter aux nouvelles menaces de type APT. Il se devait donc d’être suffisamment pointu pour récupérer uniquement la donnée nécessaire lors d’une investigation numérique, tout en restant souple afin de s’adapter aux changements de contexte de cette dernière.

Pour définir ORC de manière synthétique, nous le qualifierons d’ordonnanceur de tâches de collectes forensiques, modulaire et autonome, se présentant une fois configuré sous forme d’un unique exécutable Windows. Il est fourni avec une suite d’outils de collecte assez complète embarquée de base [6], mais ses capacités peuvent être étendues par l’ajout d’autres outils externes à travers un mécanisme nommé ToolEmbed [7].

Selon nous, cet outil présente plusieurs atouts majeurs : maximiser le travail de préparation avant un événement de sécurité en offrant aux équipes de réponse à incident la possibilité de paramétrer des collectes d’informations spécifiques (configuration WolfLauncher [8]), d’y ajouter des conditions de lancement (ex. version et type de système d’exploitation Windows) et de les centraliser au sein d’un kit d’intervention numérique.

Mais sa force réside dans le détail des types de paramétrages possibles liés aux collectes. Il est notamment possible d’imposer une priorité au processus ORC s’exécutant sur un système, de paramétrer sa consommation de mémoire vive et/ou de temps processeur, ceci dans le but d’adapter son impact sur chaque cible. Enfin, les sorties des outils de collecte peuvent être configurées pour être réparties dans des archives puis déposées dans un répertoire ou bien transférées sur un serveur distant via le composant Windows BITS. Il est à noter que ce choix de mode de transfert n’a pas été fait au hasard : comme décrit précédemment, ce composant réduit grandement la charge réseau générée par les transferts de fichiers.

3.1 Système d’héritage des configurations

ORC permet de paramétrer sa configuration de trois manières différentes. La première manière correspond à la configuration de base du précieux binaire unique illustrée par le schéma ci-dessous :

3 Schema configuration initiale ORC-s

Fig. 3 : Schéma de configuration initiale de l’exécutable DFIR-ORC.

Un script MS-DOS ainsi que des fichiers de configuration XML permettant d’effectuer cette configuration sont mis à disposition dans un des dépôts de code de l’ANSSI [9]. Cette phase correspond à la construction du socle d’outils sur lequel nous allons configurer nos profils de recherches. L’objectif étant d’embarquer tout ce qui est susceptible d’être utilisé pendant une intervention. En l’état, l’exécutable effectuera donc toutes les collectes possibles, ce qui en matière de temps d’exécution et d’impact sur un système est loin d’être optimal.

Il est possible d’affiner les recherches en utilisant en complément la seconde méthode proposée par l’outil : les fichiers de configuration locaux. Ces fichiers, une fois placés dans le même répertoire que le binaire configuré, permettent de réécrire des paramètres à la volée, notamment les collectes à enclencher ou encore la méthode de transfert des archives résultant des sorties d’outils comme nous le montrerons plus loin.

Enfin, en cas de dernier recours, il est possible de lancer des collectes directement depuis la ligne de commandes d’ORC. Cette dernière méthode est utile pour les besoins de dernière minute, par exemple lors d’une intervention sur site. Sans avoir à reconfigurer totalement l’outil, il suffit pour un opérateur de taper quelques commandes pour le paramétrer à nouveau [10] ou même, pour des besoins très succincts, une simple commande permet de lancer une collecte d’artefact bien précise :

DFIR-Orc.exe GetThis /sample="*.pf" /out=prefetch.7z C:\Windows\Prefetch\ /nolimits

Ce mécanisme de réécriture de configuration est d’ailleurs très bien décrit dans le tutoriel mis en ligne par l’ANSSI [11]. Il vous permettra notamment d’adapter l’outil en fonction de vos besoins lors d’une intervention (ex. matériel disponible et contexte de l’opération) et de la maturité de votre SI (ex. déploiement automatisé par SCCM/Active Directory et rapatriement des données par BITS/SMB).

3.2 Profils de recherche

Lors d’une intervention sur un ou plusieurs systèmes, un plan de recherche (qu’il soit informel ou explicitement rédigé) listant les questions auxquelles un analyste doit répondre pour clore un incident est souvent de mise. Le but de ce plan est de sélectionner la donnée à collecter pour répondre à ces questions. Or, juste après sa configuration initiale, ORC effectue toutes les collectes possibles. Ceci engendre une perte de temps sur deux étapes : lors de la collecte et de l’analyse. Il est donc souhaitable de sélectionner uniquement la donnée en fonction du contexte de l’investigation.

Ainsi, il est possible d’associer les fichiers de configuration locaux DFIR-Orc.xml à ce besoin. Ils sont la traduction des problématiques soulevées dans un plan de recherche qui pour être résolues nécessitent la collecte d’artefacts bien précis. Nous avons donc classé un certain nombre de ces configurations par grande famille d’artefacts dont voici un exemple :

<ntfs_find path_match="\Users\*\AppData\Local\Packages\Microsoft.MicrosoftEdge_*\AC\MicrosoftEdge\User\Default\DataStore\Data\nouser1\*\DBStore\*.edb"/>
<ntfs_find path_match="\Users\*\AppData\Local\Packages\Microsoft.MicrosoftEdge_*\AC\MicrosoftEdge\User\Default\Recovery\Active\*.dat"/>
<ntfs_find path_match="\Users\*\AppData\Local\Packages\Microsoft.MicrosoftEdge_*\AC\#!001\MicrosoftEdge\*"/>

Cette manière de procéder présente deux intérêts :

  1. le gain de temps : il suffit pour un opérateur de sélectionner le bon fichier de configuration en fonction du plan de recherche, c’est tout.
  2. la simplicité d’utilisation : par les fichiers de configuration, n’importe qui est en capacité de lancer une collecte.

En supplément de la programmation des collectes, il est possible de définir dans ces fichiers le mode de rapatriement des archives de collectes ORC :

<upload job="DFIR-ORC" method="BITS"
  server="[URL]"
  path="[NOM_REPERTOIRE_VIRTUEL_IIS]"
  user="[UTILISATEUR_IIS_RV]" password="[MOT_DE_PASSE_IIS_RV]"
  operation="move"
  include="*" />

Grâce à cela, ORC transférera les archives de fin de collecte sur un serveur IIS. Les équipes de réponse à incident pourront en se connectant à ce serveur procéder à l’analyse des résultats. Néanmoins, il est à noter que le nombre d’archives s’accumule très vite et les examiner au cas par cas peut s’avérer assez laborieux.

Le but final étant bien évidemment de pouvoir déployer massivement ORC sur un ensemble (utilisation d’un mécanisme de ciblage type WQL) d’un parc Windows. En ce sens, Get-SPICE offre à notre intégration ORC un canal de déploiement simple, efficace, stable et évolutif. Des modifications mineures seront nécessaires pour l’adapter à un potentiel changement de solution antivirus, garantissant toujours un moyen de déploiement massif d’ORC.

3.3 Ciblage fin des artefacts

Pour entrer un peu plus dans le détail de la collecte, penchons-nous sur un des outils de collecte de la suite interne ORC : RegInfo. Comme son nom l’indique si bien, cet outil permet de collecter sur la base de critères de ciblage [12] assez précis des informations contenues dans les clés de registres des ruches Windows.

<registry_find key_path_regex="\\Microsoft\\Windows NT\\CurrentVersion\\NetworkList\\Signatures\\Unmanaged\\.*" value_regex=".*"/>
<registry_find key_path_regex="\\Microsoft\\Windows NT\\CurrentVersion\\NetworkList\\Signatures\\Managed\\.*" value_regex=".*"/>
<registry_find key_path_regex="\\Microsoft\\Windows NT\\CurrentVersion\\NetworkList\\Nla\\Cache\\.*" value_regex=".*"/>

Le fichier de configuration ci-dessus reste relativement simple, il n’en reste que les critères vont assez loin dans les possibilités de ciblage :

  • type de valeur contenue dans la clé de registre ;
  • valeur absolue ou partielle contenue dans la clé de registre (en hexadécimal, chaîne de caractères brute ou même expression régulière) ;
  • taille de la valeur contenue (intervalle ou simple seuil).

À l’image de la majorité des outils intégrés à ORC, plus il y a de critères, plus la collecte ira vite constituant ainsi un double avantage : traquer les anomalies ayant des caractéristiques dérivant du comportement nominal du système et récupérer rapidement de la donnée.

3.4 Un exemple (clé USB)

Le lancement par clé USB d’ORC, à condition de disposer de l’outil bien configuré et un fichier de configuration local reste relativement simple. Il suffit de déposer le binaire et le fichier XML sur une clé, de la brancher sur le système cible, et de lancer l’exécutable avec les privilèges nécessaires.

4 Lancement collecte ORC USB-s

Fig. 4 : Lancement d’une collecte ORC d’artefacts de navigation web depuis une clé USB.

Attention, si vous avez prévu un rapatriement BITS en fin de collecte, l’authentification au service associé du fait de l’élévation de privilèges risque de vous poser problème [13].

Hormis quelques complexités de mise en place, le transfert des collectes par BITS reste indéniablement le plus avantageux. Il rend possible une collecte massive d’artefacts là où une acquisition manuelle massive semble peu envisageable. À l’instar de Get-SPICE, sa seule contrainte reste l’accès au réseau. Il est impossible de transférer des archives sans un moyen d’atteindre le serveur de rapatriement. Dans ces cas-là, l’option d’exécuter ORC au travers d’une clé USB reste une solution, à condition que le nombre de systèmes sur lesquels doit s’effectuer la collecte soit proportionnel aux capacités de personnel sur place ainsi qu’au nombre de clés disponibles. Cela reste néanmoins un moyen très efficace sur un nombre réduit de systèmes hors réseau.

3.5 ORC en tant que module Get-Spice

DFIR ORC peut être déployé sur l'intégralité des postes en tant que module de Get-Spice, il suffit de planifier son téléchargement comme un module classique, suivi de son exécution une fois celui-ci téléchargé par le client.

Les configurations de DFIR ORC ainsi que l’exécutable doivent être rassemblés dans une archive ZIP puis téléversés sur un serveur IIS (Internet Information Services, un serveur web de Microsoft disponible dans toutes les versions de Windows NT). L’agent Get-Spice télécharge cette archive depuis le serveur IIS pour en extraire le contenu dans un répertoire temporaire afin de pouvoir lancer DFIR ORC en tâche de fond.

5 Lancement  rapatriement des donnees-s

Fig. 5 : DFIR ORC, GET-SPICE et SEP.

Le téléchargement de DFIR ORC peut aussi se faire par le biais de BITS (Background Intelligent Transfer Service) au travers de la cmdlet Start-BitsTransfer. BITS est un composant Windows qui permet le transfert de fichiers asynchrones utilisant la bande passante lorsqu’elle est inoccupée. Il assure notamment une reprise du transfert en cas d’interruption.

Chaque téléchargement effectué par BITS est défini comme « job » auquel il est possible d’associer des propriétés de téléchargement (priorité, utilisation d’un proxy, authentification…), ce qui permet aussi l’exécution d’un programme à la fin d’un téléchargement si spécifié.

Le déploiement par Get-Spice, permet aux investigateurs de s’affranchir de l’installation de DFIR-ORC, mais aussi de la suppression des fichiers nécessaires à son lancement.

Conclusion

Si les politiques d’intégrités SEP ont pour objectif de garantir ou de contrôler l’intégrité des postes clients, elles peuvent aussi planifier, sur un ensemble d’ordinateurs l’exécution d’un script de live-forensics à intervalles réguliers. Ce détournement permet l’exécution de l’agent Get-Spice par l’antivirus et de s’appuyer sur une infrastructure de sécurité existante pour ajouter ou compléter à moindres frais les capacités de live-forensics lorsque cela devient nécessaire.

Même si le développement de Get-Spice est encore à l’état de preuve de concept et présente certaines limitations comme l’absence de support des environnements Linux ou l’utilisation du module de l’antivirus qui ne permet pas de contacter l’agent sur demande, le projet reste open source et basé sur un fonctionnement par API. Il pourra donc être adapté à l’avenir pour couvrir ces besoins tout comme le passage à grande échelle qui n’a pas encore été adressé.

De même, malgré un certain regret de ne pouvoir admirer l’ORC gambader avec ses camarades ELF et DWARF sur les terres d’UNIX-like, il faut admettre que sur le domaine Microsoft il offre un grand nombre de possibilités d’acquisition de données qui en font un réel outil de référence. Le fait de tout réunir au sein d’un seul exécutable offre un réel confort lors d’une collecte manuelle et lui permet par la même occasion de s’intégrer facilement avec d’autres outils.

La synergie possible entre un agent léger comme Get-Spice et un outil complet comme ORC nous semble prometteuse dans une optique de Live-Forensics. Elle permet d’effectuer des contrôles simples et évolutifs dans une approche DevOps et de distribuer ensuite les outils complets comme ORC lorsque c’est nécessaire, ce qui permet une approche à la fois minimaliste et ajustable au besoin de l’outillage requis sur les postes pour le live-forensics.

Remerciements

Les auteurs tiennent à remercier particulièrement Marion, Amadou, Thomas et Frédéric pour leurs relectures attentives ainsi que l’ensemble de l’équipe SOC d’EDF pour avoir rendu possible cet article.

Références

[1] MISC n°56 – Les « live forensics » et l’enquête judiciaire, Eric Freyssinet :
https://connect.ed-diamond.com/MISC/MISC-056/Les-live-forensics-et-l-enquete-judiciaire

[2] MISC n°87 – Arrêtez de grogner avec GRR Rapid Response !, Étienne Ladent :
https://connect.ed-diamond.com/MISC/MISC-087/Arretez-de-grogner-avec-GRR-Rapid-Response

[3] MISC n°94 – Threat hunting 101, Chopitea Thomas :
https://connect.ed-diamond.com/MISC/MISC-094/Threat-hunting-101

[4] Wikipédia – Endpoint detection and response : https://fr.wikipedia.org/wiki/Endpoint_detection_and_response

[5] Using Endpoint Protection's Host Integrity feature to check if a Microsoft patch is installed : https://knowledge.broadcom.com/external/article/179348/using-endpoint-protections-host-integrit.html

[6] DFIR ORC Documentation – Embedded Tool Suite : https://dfir-orc.github.io/embedded_tool_suite.html

[7] DFIR ORC Documentation – ToolEmbed : https://dfir-orc.github.io/ToolEmbed.html

[8] DFIR ORC Documentation – WolfLauncher Configuration File : https://dfir-orc.github.io/wolf_config.html

[9] GitHub – DFIR ORC Configuration : https://github.com/DFIR-ORC/dfir-orc-config

[10] DFIR ORC Documentation – Architecture :
https://dfir-orc.github.io/tuto.html#edit-embedded-configurations

[11] DFIR ORC Documentation – Tutorial :
https://dfir-orc.github.io/architecture.html#deployment-specific-configuration

[12] DFIR ORC Documentation – RegInfo : https://dfir-orc.github.io/RegInfo.html

[13] Documentations Microsoft – Issues with BITS :
https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127392



Article rédigé par

Par le(s) même(s) auteur(s)

CTF : un outil pour la sensibilisation large à distance

Magazine
Marque
MISC
Numéro
118
Mois de parution
novembre 2021
Spécialité(s)
Résumé

Dans ce contexte morose de confinement et de télétravail généralisé que notre pays a traversé en 2020, maintenir des événements de cohésion d’équipes peut être une gageure. Dans ce sens, la création d’un CTF interne (Capture the flag ou capture du drapeau) permet d’occuper le terrain de l’animation tout en réalisant de la sensibilisation « cyber » auprès de ses équipes. Remplacer la machine à café par un CTF, c’est sur cette approche que notre unité du Groupe EDF a décidé de miser. Cet article fera le retour d’expérience de la mise en œuvre d’un défi de ce type, de la création à son bilan en passant par sa réalisation.

Covid-19, télétravail : mise en œuvre d’accès distants sécurisés pour se rapprocher du SI

Magazine
Marque
MISC
Numéro
111
Mois de parution
septembre 2020
Spécialité(s)
Résumé

Les mesures de confinement prises par le gouvernement mi-mars 2020 pour contrer la propagation du Covid-19 ont poussé les entreprises et administrations de toutes tailles à promouvoir le télétravail. Cet article présente le retour d’expérience d’une partie de l’équipe EDF en charge des « accès distants sécurisés » pendant cette période.

Zero Trust : anti-SOC, tu perds ton sang froid ?

Magazine
Marque
MISC
Numéro
110
Mois de parution
juillet 2020
Spécialité(s)
Résumé

Les security operation centers, au sens large, sont aujourd’hui au cœur des systèmes d’information des entreprises. En revanche, beaucoup adoptent encore et toujours une approche traditionnelle de la sécurité du SI. Comment le paradigme Zero Trust va-t-il impacter nos supervisions ? Repensons un peu à toutes ces années de service pour voir ce que Zero Trust peut apporter au SOC, et réciproquement comment ces derniers peuvent accompagner la transition.

Les derniers articles Premiums

Les derniers articles Premium

Quarkus : applications Java pour conteneurs

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous