dimanche 13 juillet 2014

De l'intérêt des Metadata de Réplication lors d'audit Forensic Active Directory, Partie 2

Bonjour à tous.

Cet article fait suite à l'article De l'intérêt des Metadata de Réplication lors d'audit Forensic Active Directory, Partie 1

Nous avons vu très rapidement dans la première partie qu'il pouvait être intéressant d'analyser les Metadata de Réplication dans le cadre d'un audit Forensic Active Directory.

Avant d'entrer dans le détails de l'audit, nous allons aborder aujourd'hui les différentes méthodes pour récupérer les Metadata de Réplication. L'objectif étant bien évidemment d'automatiser au maximum la récupération de ces données.


Nous avons vu dans le 1er article que l'on peut utiliser l'outil Repadmin et plus particulièrement avec le paramètre Repadmin /Showobjmeta

Un exemple avec les metadata d'une OU :


Repadmin nous permet de récupérer très facilement les metadata pour un objet donné.

Par contre il est difficile à utiliser pour récupérer les metadata d'un nombre important d'objets.
De plus le format de sortie  impose un traitement assez conséquent pour avoir des informations exploitables.

On l'utilisera donc plutôt pour avoir les metadata d'un objet unique. On pourra s'en servir par exemple pour récupérer le timestamp et le DC d'origine d'une modification d'un attribut pour ensuite consulter les logs.


Nous allons voir maintenant un autre outil qui va nous permettre de récupérer les metadata de réplication.
C'est un outil généralement peu utilisé mais qui peut rendre bien des services, LDP.

Pour récupérer les metadata de réplication il suffit de se positionner sur l'objet et de faire un clic-droit puis Advanced et Replication Metadata


Et on affiche les metadata :


Le problème c'est que comme pour Repadmin, ce n'est pas facilement exploitable d'autant plus qu'avec ldp nous n'avons pas le nom des attributs...
On peut toutefois récupérer les informations sous une forme plus exploitable.
Pour ceci on peut effectuer une recherche sur l'objet et en spécifiant l'attribut msDS-ReplAttributeMetaData



Le format de sortie est de type DS_REPL_VALUE_META_DATA qui a une structure de type XML.

On peut de plus effectuer la recherche sur plusieurs objet.

Par exemple, en effectuant une recherche sur le conteneur Users pour tous les groupes.
Vous remarquerez que j'utilise ici l'attribut msDS-ReplValueMetaData et non msDS-ReplAttributeMetaData. C'est uniquement pour vous montrer que l'on peut récupérer les metadata de plusieurs objets. Je reviendrais en revanche en détail sur cet attribut dans un autre article puisqu'il est très intéressant pour l'audit des groupes.



On arrive donc a récupérer les informations de plusieurs objets dans un format plus exploitable (XML).
On a toutefois toujours besoin de retraitement pour exploiter les données.


On va désormais passer aux méthodes permettant de récupérer les metadata dans un format exploitable

On va commencer par utiliser la méthode GetReplicationMetadata de la classe DomainController


Voici le code utilisé:

$DomainName = "metadata.adds"
$ObjectDistinguishedName = ""
$DirectoryContext = new-object System.DirectoryServices.ActiveDirectory.DirectoryContext("Domain",$DomainName)
$DomainController = [System.DirectoryServices.ActiveDirectory.DomainController]::findOne($DirectoryContext)
$MetaData = $DomainController.GetReplicationMetadata($ObjectDistinguishedName)


On peut donc récupérer facilement les informations dans un format exploitable.
L'intérêt de cette méthode est qu'elle est simple à utiliser et ne nécessite pas l'utilisation du module Powershell ActiveDirectory.


On va maintenant voir une solution utilisant l'attribut msDS-ReplAttributeMetaData et le module Powershell ActiveDirectory.

J'ai fait une fonction relativement simple qui permet de récupérer ces informations en fournissant le DistinguishedName d'un objet  :



Voici le code de la fonction :

Function Get-ADObjectMetadata {
 Param(
        [Parameter(Mandatory=$true,Position=1)]
        [String] $ObjectDN
        )

    ### Chargement du module ActiveDirectory
    try { Import-Module ActiveDirectory |Out-Null}
    catch { Write-Warning "Cannot load ActiveDirectory module."; Break }

    $ADObject = Get-ADObject $ObjectDN -Properties "msDS-ReplAttributeMetaData"

    $ReplAttributeMetaData = $ADObject."msDS-ReplAttributeMetaData"
    $ReplAttributeMetaData = "<root>" + $ReplAttributeMetaData + "</root>"
    $ReplAttributeMetaData = $ReplAttributeMetaData.Replace([char]0," ")
    $ReplAttributeMetaData = [XML]$ReplAttributeMetaData
    $ReplAttributeMetaData = $ReplAttributeMetaData.root.DS_REPL_ATTR_META_DATA

    $TabObjectMetadata = @()

    $ReplAttributeMetaData | Foreach {
        $obj = New-Object psobject
        $obj |Add-Member -type NoteProperty -name AttributeName -value $_.pszAttributeName
        $obj |Add-Member -type NoteProperty -name Version -value $_.dwVersion
        $obj |Add-Member -type NoteProperty -name TimeLastOriginatingChange -value $_.ftimeLastOriginatingChange
        $obj |Add-Member -type NoteProperty -name usnOriginatingChange -value $_.usnOriginatingChange
        $obj |Add-Member -type NoteProperty -name usnLocalChange -value $_.usnLocalChange
        $obj |Add-Member -type NoteProperty -name LastOriginatingDsaDN -value $_.pszLastOriginatingDsaDN

        $TabObjectMetadata += $obj
        }

    return $TabObjectMetadata
    }

Encore une fois les données sont facilement exploitables.


Pour finir, Windows Server 2012 R2 (et Powershell 4.0) apporte de nombreuses Cmdlets.
Get-ADReplicationAttributeMetadata répond parfaitement à notre besoin en toute simplicité.



Je vais m’arrêter ici pour les différentes méthodes permettant de récupérer les metadata de réplication.
Nous verrons dans la suite l'attribut msDS-ReplValueMetaData et l'intérêt qu'il peut avoir dans un audit Forensic Active Directory.

Merci de m'avoir lu.
A la prochaine.

mercredi 9 juillet 2014

De l'intérêt des Metadata de Réplication lors d'audit Forensic Active Directory, Partie 1

Bonjour à tous,

Je vous propose aujourd'hui un sujet autour des audits Forensic d'environnement Active Directory.
Sujet malheureusement d'actualité auquel il faut se préparer car aujourd'hui nul n'est à l'abri d'une compromission de son environnement Active Directory.

On va voir ici l'intérêt d'utiliser les Metadata de réplication pour avoir rapidement un aperçu des modifications qui ont pu être effectuées dans un environnement Active Directory.

Vous allez me dire : Pas besoin, je fais déjà de l'audit sur mon environnement AD, je vais voir toutes les modifications qui sont effectuées. Et vu que je fais les choses bien, c'est même centralisé avec l'Event Forwarding.

Oui mais ... Faisons un petit test.

J'ai un environnement AD avec l'audit des modifications AD activé sur mon DC.


 Dans mon environnement j'ai une OU nommée TEST-METADATA


Sur cette OU j'ai configuré un audit pour toutes les modifications effectuées par tous le monde.


L'audit est donc bien configuré sur le DC et sur l'objet au travers des SACL.

Faisons un test en modifiant la description de l'OU.

Effectivement l'audit fonctionne bien. J'ai bien un event qui est généré pour la modification.

Maintenant, modifions les permissions sur cette OU. Pour simplifier les choses je vais juste modifier la protection contre la suppression accidentelle qui modifie les ACL sur l'objet.


Mon attribut a bien été modifié (les ACL de l'OU en fait) mais pourtant je n'ai pas d'event généré ...
Si je modifie à nouveau la description, les events sont bien générés (2 events, un pour la suppression de l'ancienne valeur, un pour l'ajout de la nouvelle)


Les modifications sur les objets audités ne génèrent donc pas toutes des events ...

Et si il était possible de masquer des actions de modification malveillantes sans qu'elles soient remontées par l'audit ?

Je ne vais pas rentrer dans le détails dans cet article mais je vais juste vous dire ce que j'ai fait pour empêcher l'audit des modifications des ACL.
Vous le savez sûrement, les permissions sont "stockés" dans l'attribut ntSecurityDescriptor

J'ai modifié l'attribut searchFlags de l'objet du schéma nt-security-descriptor.
Et j'ai spécifié de ne pas auditer cet attribut.


Le problème c'est que la modification de cet attribut n'est pas auditée ...
Et donc si une personne malveillante a eu accès a des droits de type "Schema Admins" sur votre environnement, il est possible que qu'elle est effectuée des modifications de ce type pour masquer ses prochaines actions sans que vous vous en rendiez compte ...

Alors on fait toujours confiance aux audits AD ?

Maintenant que l'on est complètement parano, voyons comment détecter ce type de modification.

Encore une fois je ne vais pas rentrer dans le détail, mais la solution c'est les metadata de réplication.
Un simple Repadmin nous donne l'information, l'attribut searchFlags a été modifié 2 fois.


Et si on regarde les metadata de notre OU on voit bien les modifications de la descripption et des ACL (DACL et SACL) :


Je vais m'arrêter ici pour ce premier article. Bien évidement l'attribut searchFlags n'est pas le seul attribut qu'il faut vérifier. Le next step est d'automatiser au maximum ces vérifications sans utiliser repadmin. Nous verrons ce point dans un autre article où je vous proposerai un outil pour effectuer ces vérifications.

A bientôt.

mardi 8 juillet 2014

Mise à jour du livre blanc Microsoft sur les attaques du type Pass-The-Hash

Bonjour à tous,

Microsoft vient de mettre à jour son livre blanc sur les attaques de type Pass-The-Hash.

Pour plus d'informations : Pass The Hash
Pour télécharger directement le livre blanc : Mitigating Pass-the-Hash and Other Credential Theft v2


Edit : L'article sur le blog sécurité de Microsoft : New Strategies and Features to Help Organizations Better Protect Against Pass-the-Hash Attacks



Bonne lecture.

samedi 28 juin 2014

Présentations de l’ANSSI au SSTIC 2014

Bonjour à tous,

L'ANSSI a mis à disposition les présentations effectuées par ses experts lors du SSTIC 2014.

Les présentation sont disponibles via le lien suivant : Retrouvez les présentations de l’ANSSI au SSTIC 2014

2 des présentations attirent particulièrement mon attention, à lire absolument si vous faites de l'AD et/ou de la sécurité.


Chemins de contrôle en environnement Active Directory

 L’audit d’un domaine Active Directory est un sujet complexe : les relations entre objets à inspecter dépassent largement l’appartenance aux groupes de sécurité ou aux unités organisationnelles. Le bureau Audit et Inspection de l’ANSSI a développé une méthodologie et un outillage permettant de prendre en compte et d’agréger de nombreuses relations afin de les représenter sous forme de graphes appelés graphes des chemins de contrôle. Les réponses à des questions comme « Qui peut obtenir les privilèges d’administration du domaine ? » ou bien « Quelles ressources un utilisateur peut-il contrôler ? » peuvent alors être obtenues de façon graphique

Cette présentation est directement disponible dans le lien suivant : Chemins de contrôle en environnement Active Directory - Chacun son root, chacun son chemin


Secrets d’authentification épisode II - Kerberos contre-attaque

Cet article présenté lors de la conférence SSTIC 2014 a deux objectifs.

Le premier est d’étudier quelques spécificités du protocole Kerberos dans les environnements Active Directory (délégation, relation inter-domaines, autorisation, etc.) et les impacts en matière de sécurité.

Le second est de démontrer qu’en cas de compromission d’une base de comptes Active Directory (récupération par un attaquant de toutes les empreintes des mots de passe), les conséquences sont graves et que la remédiation est bien plus lourde qu’un simple changement des mots de passe de quelques utilisateurs.

 Cette présentation est directement disponible dans le lien suivant : Secrets d’authentification épisode II - Kerberos contre-attaque


mercredi 9 avril 2014

Disponibilité des baselines SCM pour : Windows 8.1, 2012 R2, IE 11 et Beta Office 2013

Bonjour à tous,

Les baselines SCM pour Windows 8.1, Windows Server 2012 R2 et Internet Explorer 11 sont disponibles depuis hier.

Elles ne sont toutefois pas encore disponibles au format SCM mais l'archive fournie contient les éléments suivants :
  • Administrative Template:  an ADMX and (US English) ADML file surfacing some "pass the hash"-relevant settings through the Group Policy editor.  (Note: the Local_Script folder contains scripts that install these files to the appropriate location.)
  • Documentation:  "Recommended Security Baseline Settings.docx" is a Word doc that categorizes and describes all the new and updated settings (you should probably start here); this folder also contains "SCM Windows 8.1 and 2012 R2 Settings.xlsx", an Excel spreadsheet that describes the full set of recommended settings.
  • GP Reports:  Group Policy reports formatted as HTML files (for those who prefer that format over Excel spreadsheets).
  • GPOs:  Group Policy Object backups for the four separate sets of baselines described earlier.
  • Local_Script:  This directory contains three batch files that apply appropriate settings to the current machine:  81_Client_Install.cmd, 2012R2_DomainController_Install.cmd, and 2012R2_MemberServer_Install.cmd.
  • WMI Filters:  This directory contains .MOF files that you can import into your Group Policy configuration to ensure that GPOs are applied only to the appropriate systems.

Les principaux changement sont les suivants:
  • Use of new and existing settings to help block some Pass the Hash attack vectors
  • Blocking the use of web browsers on domain controllers
  • Incorporation of the Enhanced Mitigation Experience Toolkit (EMET) into the standard baselines
  • Removal of almost all service startup settings, and all server role baselines that contain only service startup settings
  • Removal of the recommendation to enable “FIPS mode”

L'annonce de la sortie sur le blog Microsoft Security Guidance : Security baselines for Windows 8.1, Windows Server 2012 R2 and Internet Explorer 11

Le lien direct pour l'archive (encore taggé Beta) : Win81-WS2012R2-IE11-Baselines-BETA.zip  

En parallèle, la beta pour les baselines Office 2013 est ouverte : SCM Office 2013 Beta is now live!


jeudi 27 mars 2014

Disponibilité des baselines SCM pour SQL Server 2012

Bonjour à tous,

Les baselines SCM pour SQL Server 2012 sont disponibles depuis quelques jours.

Vous pouvez soit télécharger les fichiers cab puis les importer dans SCM, soit passer directement par SCM pour les télécharger et les importer.



L'annonce de la sortie sur le blog Microsoft Security Guidance : SQL Server 2012 Baselines are now live !

Les fichiers en téléchargement direct :
SQL Server 2012 Security Compliance Baseline
SQL Server 2012 Security Compliance Baseline Attachements


samedi 8 mars 2014

Délégation d'administration Active Directory et Powershell


Bonjour à tous.

Je vous propose aujourd'hui un article sur la délégation d'administration Active Directory et Powershell.

Bien évidemment on peut toujours utiliser l'assistant de délégation d'administration ou les commandes dsacls pour mettre en place la délégation d'administration mais il est plus intéressant d'utiliser les fonctionnalités apportées par Powershell.


Avant de commencer il faut déjà parler du lecteur AD:\ qui est créé lors de l'import du module ActiveDirectory.
Lorsque vous importez le module Powershell ActiveDirectory, un lecteur nommé AD est créé et est mappé à un des contrôleurs de domaine.
 


Vous pouvez vous déplacer dans ce lecteur comme dans une arborescence classique de fichier.

 


Par défaut le lecteur est mapper sur le domaine mais il est possible de créer un autre lecteur et de le mapper un autre domaine ou une autre forêt avec la Cmdlet New-PSDrive.



Pour faire notre délégation, on va se servir de ce lecteur et de la Cmdlet Get-ACL.
En effet, on peut récupérer les ACL d'objets Active Directory via notre lecteur.



On récupère un objet de classe ActiveDirectorySecurity.


On va s'intéresser de plus près maintenant aux méthodes proposées par cette classe.
La liste des méthodes la classe est disponible dans le lien suivant : Méthodes ActiveDirectorySecurity

La méthode qui nous intéresse principalement est la méthode AddAccessRule qui permet d'ajouter une règle d'accès à la liste DACL d'un objet.

Le paramètre de cette méthode est un objet de classe ActiveDirectoryAccessRule qui représente une entrée de contrôle d'accès (ACE) dans la liste de contrôle d'accès discrétionnaire (DACL).

Nous allons donc voir comment construire des objets de classe ActiveDirectoryAccessRule.

Il existe différents constructeurs pour initialiser une nouvel objet de classe ActiveDirectoryAccessRule : Constructeurs ActiveDirectoryAccessRule

On utilisera ces différents constructeurs en fonction du besoin.


Prenons un exemple, j'ai une OU nommée Utilisateurs sur laquelle je veux déléguer la création de compte utilisateurs à un groupe nommé "Create User Accounts".

Je commence par récupérer les ACL de l'OU



Maintenant je dois construire mon ACE. J'ai d'abord besoin du SID de mon groupe.



Ensuite j'ai besoin du droit que je souhaite autoriser, à savoir la création d'objet enfant (de type utilisateur). La liste des droits est disponible ici : ActiveDirectoryRights


 Puis du type de contrôle d'accès qui est autoriser : AccessControlType


Et enfin le GUID du type d'objet auquel la règle d'accès doit s'appliquer, les objets de type utilisateur. Les GUID des classes d'objets sont disponibles ici : All Classes



On peut maintenant créer notre ACE.


Puis l'ajouter aux ACL de notre OU.


Et c'est terminé. On peut vérifier que la délégation a bien été faite.



Je n'irai pas plus loin dans la démonstration, ça peut paraitre au premier abord assez laborieux.
Une fois qu'on a jonglé avec les différents constructeurs ça devient vite compréhensible.

Voici le code que j'ai utilisé :

$ACL = Get-Acl "AD:\OU=Utilisateurs,DC=ROOT,DC=ADDS"

$Group = Get-ADGroup "Create User Accounts"

[System.Security.Principal.SecurityIdentifier] $SID = $Group.SID
[System.DirectoryServices.ActiveDirectoryRights] $ADRights = "CreateChild"
[System.Security.AccessControl.AccessControlType] $AccCtrlType = "Allow"
[System.guid] $GUID = "bf967aba-0de6-11d0-a285-00aa003049e2"

$ACE = New-Object -TypeName System.DirectoryServices.ActiveDirectoryAccessRule -ArgumentList $SID,$ADRights,$AccCtrlType,$GUID

$ACL.AddAccessRule($ACE)
$ACL|Set-ACL


L'intérêt est bien évidemment de pouvoir scripter un déploiement complet du modèle de délégation en utilisant les autres fonctionnalités de Powershell.

Je travaille en ce moment sur une autre série d'articles sur la délégation d'administration, je fournirai à chaque fois le code Powershell correspondant.

J'espère que cet article vous aura intéressé.

A bientôt et bon scripting