mdsecactivebreach/sitrepOutil extensible de triage hôte pour les équipes rouges, chargeant dynamiquement des vérifications conscientes de l'OpSec pour recueillir des informations sur les utilisateurs, les domaines, les privilèges et les identifiants à partir de terminaux Windows via execute-assembly.
Triage hôte extensible et configurable.
SitRep est conçu pour fournir une alternative légère et extensible au triage d’hôtes. Les vérifications sont chargées dynamiquement à l’exécution à partir de fichiers autonomes. Cela permet aux opérateurs de modifier rapidement les vérifications existantes ou d’en ajouter de nouvelles selon les besoins.
Les vérifications sont regroupées par catégorie et peuvent être marquées comme sûres/dangereuses pour l’OpSec. Les vérifications dangereuses ne sont chargées que si l’indicateur /AllowUnsafe est fourni.
Les résultats intéressants sont mis en évidence avec un « [*] ».
Les vérifications sont réparties en catégories. Cela permet de les afficher dans des groupes appropriés. Les vérifications suivantes sont actuellement disponibles :
Environnement
Défenses
Permissions
Logiciels
Identifiants
Les vérifications suivantes sont actuellement marquées comme dangereuses pour l’OpSec :
Vous devez examiner cette configuration et mettre à jour les balises OpSec si nécessaire.
Toutes les vérifications sont activées par défaut. Cependant, comme les vérifications sont chargées dynamiquement, il est possible de les désactiver.
Désactiver une vérification
CheckBase inclut une propriété booléenne « Enabled », dont la valeur par défaut est true. Celle-ci peut être définie dans la classe dérivée en ajoutant un constructeur. L’exemple ci-dessous désactive la vérification CurrentUser (CurrentUser.cs) :
public CurrentUser()
{
base.Enabled = false;
}
Exclure des vérifications de la compilation
Comme les vérifications sont chargées dynamiquement, il est possible d’exclure une vérification de la compilation sans autres modifications. Le moyen le plus simple est de cliquer avec le bouton droit sur la classe de vérification dans Visual Studio et de sélectionner « Exclure du projet ». La vérification peut être rajoutée en sélectionnant « Inclure dans le projet » dans le même menu contextuel.
Cette approche présente l’avantage de supprimer le code de l’artefact compilé.
Exécuter toutes les vérifications
SitRep.exe /AllowUnsafe
Exécuter uniquement les vérifications OpSec sûres (par défaut)
SitRep.exe
SitRep est conçu pour être exécuté via execute-assembly (ou équivalent)
Les vérifications héritent de CheckBase et implémentent l’interface ICheck. Cela impose les modèles nécessaires au chargement dynamique des vérifications. D’autres méthodes et classes peuvent être ajoutées selon les besoins.
L’interface ICheck expose les propriétés et méthodes suivantes :
Les classes dérivées doivent redéfinir la méthode « ToString() » définie dans CheckBase. Cette méthode est appelée lors de l’affichage de la sortie de chaque vérification.
L’accès aux méthodes natives est fourni via des classes dans le dossier « NativeMethods ». Chaque classe est nommée d’après la DLL avec laquelle elle interagit.
Les vérifications sont responsables de leur propre gestion des erreurs. Les vérifications actuelles encapsulent l’ensemble de la méthode « check » dans un bloc try-catch ; l’utilisation de ce modèle est encouragée.
Un exemple de vérification vide est présenté ci-dessous :
using SitRep.Interfaces;
using System;
namespace SitRep.Checks.Software
{
class ExampleCheck : CheckBase, ICheck
{
public bool IsOpsecSafe => true;
public int DisplayOrder => 1;
public Enums.Enums.CheckType CheckType => Enums.Enums.CheckType.Credential;
public void Check()
{
try
{
throw new NotImplementedException();
}
catch
{
Message = "Check failed [*]";
}
}
public override string ToString()
{
throw new NotImplementedException();
}
}
}
Les PR sont les bienvenus. Veuillez vous assurer que les vérifications sont autonomes (c’est-à-dire qu’elles ne dépendent pas des résultats d’autres vérifications). Dans la mesure du possible, les vérifications doivent être auto-suffisantes, tout le code à usage unique étant présent dans la classe de vérification.
Avez-vous déjà essayé de simuler un point de terminaison Windows joint à un domaine ? Voilà pourquoi.
SitRep utilise du code provenant de Seatbelt, SharpUp et de diverses publications StackOverflow. Les crédits ont été ajoutés le cas échéant.