L’EDR Crowdstrike integre bien sur une fonction de scan de machines cibles, a la demande ou planifiés.

Aller sur le lien Endpoint security/On-demand scans

Cliquer Create a scan

Sélectionner Now ou In the future pour planifier un scan

Laisser coché l’option «Limit how long this scan runs» pour limiter la durée du scan. NB : La durée de 2 heures par défaut pourra être adapté au vu de la durée observée en moyenne dans le résultat final du/des scans.

Sélectionner une ou plusieurs et/ou des groupes de machines (la selection dans le champs affiche automatiquement les éléments)

Inscrire un ou plusieurs chemin a scanner (1 par ligne)

Inscrire éventuellement un ou plusieurs chemin a exclure

Le champ «Exclusions to test against above pattern» peut être utilisé pour tester les exclusions.

Dans l’exemple ci-dessus, on veut scanner le lecteur D:\, en excluant tout le contenu (*) de D:\App1

(la coche et la couleur du test effectué  valide le fait que la syntaxe de l’exclusion est correcte. Au contraire, par exemple  ne sera pas exclu)

Le bouton  peut être utilisé pour charger une liste d’exclusion en respectant une ligne par exclusion.

Renseigner une description explicite

Laisser par défaut la niveau de détection et de prévention a Moderate

Pour information la description des niveau de détection est la suivante :

Selectionner un niveau maximum de consommation CPU a utiliser (par defaut Low up to 25%)

Décocher Show notifications to end user si vous ne voulez pas que l’utilisateur connecté sur la machine reçoive une notification de Scan (le paramètre Pause duration permet d’autoriser l’utilisateur connecté à reporter le scan pour une durée donnée)

Cliquer Create Scan

Le scan apparait dans la liste et passez en état Completed lorsque le scan est fini.

Un clic sur le scan permet d’avoir le détail

Cliquer sur See full details pour afficher les détails complets

Dans notre exemple, la machine cible est bien dans les «Hosts without detection»

Le lien  permet d’accéder si besoin a des éléments de diagnostique/remédiation, dans le cas d’une machine ou des détections ont été remontées :

Problématique:  Récuperer et rendre lisible un timestamp représentant la date de modification du password d'un compte AD, renvoyé par l'outil Dsquery (https://ss64.com/nt/dsquery.html)

$user = "johndoe"
$domain = "mydomain.com"

# Executer la commande dsquery pour recuperer l'attribut pwdLastSet
$obj = dsquery * -filter "samaccountname=$user" -attr displayName pwdLastSet -d $domain

# Decouper $obj pour ne recuperer que la chaine correspondant au timestamp
$TimeStamp = $($obj[1] -split " ") | Where-Object {$_ -match '^\d+$'}

# Convertir le timestamp en date avec l'outil w32tm.exe
w32tm.exe /ntte $TimeStamp

Un environnement homogène avec des OS installé en Anglais, c'est la vision de notre éditeur préféré (je parle bien sur de Microsoft).

Dans la pratique on a pas toujours l'opportunité d'avoir tous les OS dans la même version et pire encore dans la même langue d'installation.

Quel impact ?

Même si pour certain, installer un OS en Français est plus "Confortable / facile d'administration", en terme de "recherche / résolution" d'incident on est quand même nettement moins bien aidé (entre les messages d'erreur qui ne veulent rien dire ou les commandes qui diffèrent, avoir un langage différent de l'anglais peut vous faire perdre quelques heures).

Des Exemples :

Prenons un exemple simple l'activation ou la désactivation du "SID Filtering" dans un "Trust" entre deux domaines.

OS Anglais :

Si les OS des serveurs contrôleur de domaine sont en Anglais les commandes sont simples :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:No  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Yes

 Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

OS Français :

Lorsque les OS sont en Français il y a une petite subtilité :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Non  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Oui

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Vous l'avez ?

Et oui la commande est quasi identique puisqu'elle est en Anglais, mais les arguments eux sont en Français et le pire dans tout ça c'est que si vous passez la commande en Anglais avec les arguments en Anglais, l'OS vous dira que la commande s'est terminée avec succès même si ce n'est pas le cas; mais dans la pratique cette dernière aura échouée.

Alors de grâce ayez le réflex lors d'une installation serveur de sélectionner un Iso en Anglais et de l'installer en Anglais (rassurez vous pour le clavier et le fuseau horaire le Français est autorisé ^^ ).

ATA

Advanced Threat Analytics (ATA) est une plateforme OnPremise qui permet d’analyser l’ensemble des actions effectuées (accès à des ressources, verrouillage de compte, déplacement latéral…) avec des comptes Active Directory.

ATA fonctionne avec un serveur central qui récupère l’ensemble des logs des contrôleurs de domaines.

Ces logs peuvent être récupérés de deux façons :

• Via un agent installé sur les DC (nommé Lightweight Gateway)
• Via du port mirroring (nommé Full Gateway)

Ce billet s’intéressera uniquement à la configuration d’ATA avec des Lightweight Gateway.

Mise en place

Prérequis pour les Lightweight Gateway

Pour qu’ATA soit efficace il est impératif d’installer l’agent sur l’ensemble des DC du domaine Active Directory.

Pour la mise en place il faut

• l’ouverture du port TCP 443 entre les DC et le serveur ATA
• un compte de service (sans droit d’administration) présent dans l’AD
• un certificat SSL (optionnel, il est possible d’utiliser un certificat auto-signé pour la console d’administration)

Installation du serveur ATA

L’installation du serveur d’administration est très simple et se fait via l’assistant d’installation.

Il est possible de paramétrer le chemin d’installation, le chemin des logs et le certificat qui sera utiliser pour la console web.

La fin de l’installation s’effectue depuis l’interface d’administration web (https://localhost depuis le serveur ATA).

Le compte de service est nécessaire à ce moment pour lire l’AD.

L’étape suivante consiste à télécharger le setup pour les DC.

Installation des Lightweight gateways

L’installation de l’agent sur les DC se fait à travers l’assistant d’installation. Il est possible de paramétrer le chemin d’installation.

Une fois l’agent installé, celui-ci démarre automatiquement et le DC est visible dans l’interface d’administration.

Il est nécessaire de modifier la configuration d’un des DC dans l’interface d’administration pour le désigner comme Domain synchronizer candidate.

Tout DC défini comme Domain synchronizer candidat peut être responsable de la synchronisation entre ATA et le domaine Active Directory.

Analyse

Depuis l’interface d’administration les différentes alertes remontent automatiquement. Celles-ci sont classées par niveau de criticité : High, Medium et Low.

Il est possible de configurer des alertes mail et/ou d’envoyer l’ensemble de ces logs dans un SIEM.

Réinitialisation du mot de passe :

Avec un compte faisant partie de "Read_Laps"

Normalement lorsqu'un compte ne fait pas partie du groupe "Reset_Laps", il ne bénéficie pas du droit de réinitialiser le mot de passe, vérifions cela.

Avec le client lourd  :

En effet nous pouvons constater que lorsque l'on essaie de réinitialiser le mot de passe le client affiche au bas de la fenêtre un message "Failed to request password reset"

Avec Powershell :

Avec Powershell le résultat est le même (voir plus explicite), l'utilisateur ne possède pas les droits.

Avec un compte faisant partie de "Reset_Laps"

Maintenant nous allons utiliser un compte qui se trouve dans le groupe "Reset_Laps" mais pas dans le groupe "Read_Laps", par conséquent il n'est pas possible de lire le mot de passe mais je devrais pouvoir le réinitialiser. 

Avec le client lourd  :

Cette fois-ci nous pouvons constater que le mot de passe n'est pas lisible, et au bas du client lourd le message "Password reset request was successful".

Avec Powershell :

Conclusion :

Grâce à cette solution gratuite de Microsoft vous pouvez améliorer la sécurité de votre parc informatique en réduisant la portée d'attaque d'une intrusion à l'aide du compte administrateur local.

https://www.microsoft.com/en-us/download/details.aspx?id=46899&wt.mc_id=fy16techdays

https://technet.microsoft.com/en-us/library/security/3062591?wt.mc_id=fy16techdays

https://blogs.msdn.microsoft.com/laps/

https://support.microsoft.com/en-us/kb/3062591

Voici quelques commandes Powershell pour trouver les OU dont l'héritage est bloqué:

$GPOBlocked = Get-ADOrganizationalUnit -SearchBase "DC=LAB,DC=Org" -Filter * | Get-GPInheritance | Where-Object {$_.GpoInheritanceBlocked}
$GPOBlocked.count
$GPOBlocked | Select Name,Path

Le DistinguishedName (Path) n'est pas toujours agréable à lire je fais donc une conversion en CanonicalName, ensuite vous pouvez afficher les données à l'écran ou les écrire dans un fichier:

$GPOBlocked | ForEach-Object {
        $Name = $_."Name"
        $Path = $_."Path"
        $CanonicalName = Get-ADOrganizationalUnit -Filter {DistinguishedName -like $Path} -Properties CanonicalName | Select-Object -ExpandProperty CanonicalName
        Write-Output "$Name; $CanonicalName" | Add-Content C:\Temp\GpoInheritanceBlocked.txt
    }

Vérifications Serveur / Clients

Depuis le serveur

Vérifions l'état du mot de passe du compte Administrateur Local d'une machine cible.

Avec le client lourd  :

Avec Powershell :

Depuis l'Active Directory dans l'onglet éditeur d'attribut 

Depuis le poste Client

Avec un compte faisant partie de "Read_Laps"

Réalisons donc une mise à jour de la stratégie de groupe 

Nous allons pouvoir vérifier l'état du mot de passe du compte admin local.

Avec le client lourd  :

Avec Powershell :

Avec un compte faisant partie de "Reset_Laps"

Avec le client lourd  :

Avec Powershell :

Test de connexion

Nous testerons donc de nous connecter à la machine avec le nouveau mot de passe

C'est fonctionnel.

Mise en Oeuvre :

Installation sur l'infrastructure :

Pour réaliser l'installation de LAPS sur un serveur membre nous aurons besoin dans un premier temps d'un compte avec les droit Administrateur Local sur le serveur, puis de bénéficier des droits Admin du Schéma puis Admin du domaine ou Admin de ou des Unités d'Organisation en fonction de l'étendue sur laquelle vous souhaiter déployer LAPS. (Pour ma part je l'ai fait avec un compte "Admin du Domaine" sur lequel j'ai accordé les droits "Admin du schéma" le temps de l'installation).

L'installation se fait en suivant les étapes ci-dessous :

1. Installation de LAPS avec les composants Serveur.
2. Extension du schéma.
3. Attribution des droits.
   1. Droits pour les computers .
   2. Création des groupes de sécurité.
   3. Délégation des droits aux groupes de sécurité sur les OU.
4. Paramétrage des GPO
   1. Import des fichiers ADMX et ADML.
   2. Création et paramétrage de GPO.

Etape 1 : Installation de LAPS avec les composant serveur :

Le fichier msi fournit par LAPS permet d'installer les composants clients et serveurs, par défaut seul les composants clients sont installés, dans notre cas nous souhaitons déployer les composant serveurs nous sélectionnerons donc les "Management Tools".

Vous remarquerez la présence de 3 modules pour les "Management Tools" :

1. Fat Client UI : Soit l'interface utilisateur client lourd permettant de récupérer les mot de passe en clair dans l'AD
2. Powershell module : L'interface Powershell
3. GPO Editor Templates : Les ADMX

Etape 2 : Extension du schéma

Exécuter Powershell en tant qu'Administrateur.

# Import du module
Import-module AdmPwd.PS
# Update du schéma
Update-AdmPwdADSchema

Etape 3 : Attribution des droits.

Pour attribuer aux machines le droit de modifier leurs attributs exécutez :

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Machines,DC=LAB,DC=INFO"

Pour créer les Groupes de sécurité afin de déléguer les droits (Lecture et Réinitialisation), vous avez deux options (en graphique via ADAC ou User & computers AD, ou avec Powershell, pour ma part ce sera Powershell).

# Création du Groupe Read_Laps
New-AdGroup -Name "Read_Laps" -SamAccountName "Read_Laps" -Description "Group For Read Permission" -GroupCategory Security -GroupScope Global -Path "OU=Groups,OU=IT,OU=Main,DC=LAB,DC=ORG"

# Création du Groupe Reset_Laps
New-AdGroup -Name "Read_Laps" -SamAccountName "Reset_Laps" -Description "Group For Reset Permission" -GroupCategory Security -GroupScope Global -Path "OU=Groups,OU=IT,OU=Main,DC=LAB,DC=ORG"

Nb: Le nom des groupes est un choix personnel, libre à vous de mettre autres choses.

Nous allons maintenant déléguer les droits sur une OU à l'aide des commandes suivantes :

# Permet d'attribuer le droit de lecture du mot de passe au Groupe "Read_Laps" sur l'OU "Main/IT/Computers"
Set-AdmPwdReadPasswordPermission -Identity "OU=COMPUTERS,OU=Main,DC=LAB,DC=ORG" -AllowedPrincipals Read_Laps –Verbose

# Permet d'attribuer le droit de changement du mot de passe au Groupe "Reset_Laps" sur l'OU "Main/IT/Computers"
Set-AdmPwdResetPasswordPermission –Identity "OU=COMPUTERS,OU=IT,OU=Main,DC=LAB,DC=ORG" –AllowedPrincipals Reset_Laps –Verbose

Nb : Le droit peut être déléguer sur l'ensemble du domaine, pour ma part seul les "Domain Admins" bénéficie de ce privilège.

Etape 4 : Paramétrage des GPO.

Par défaut, LAPS positionne les fichiers ADMX et ADML sur le poste local, si on veut les placer dans le SYSVOL de l’organisation, on ira donc récupérer :

• C:\Windows\PolicyDefinitions\AdmPwd.admx -> A copier dans le "%systemroot%\sysvol\domain\policies\PolicyDefinitions"
• C:\Windows\PolicyDefinitions\en-us\AdmPwd.adml -> A copier dans le "%systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US" (Option à répéter pour chaque langage de votre AD).

Nb: Si toutefois vous n'aviez pas les répertoires ci-dessus, il faudra les créer manuellement avec un compte ayant les droits.

Il ne nous reste plus qu'à déployer les stratégies de groupe pour définir le comportement de LAPS.

1. On ouvre donc "Group Policy Management" et on créé une nouvelle GPO (Dans cet Démo, on la nommera simplement "LAPS").
2. On accède aux nouveaux paramètres : Computer Configuration -> Policies -> Administrative Templates -> LAPS

C'est donc à partir de ces nouveaux paramètres que nous allons pouvoir activer ou inhiber LAPS et pouvoir agir sur les différentes politiques de sécurité :

• Intervalle de changement de mot de passe.
• Longueur et complexité du mot de passe.
• Définir le nom du compte Administrateur (Seulement si ce dernier à été renommé).

Activation de LAPS

Paramètre du nom de compte Administrateur : Ne pas configurer si le compte est celui par défaut.

Spécifications de longueur et complexité du mot de passe.

La configuration serveur est maintenant terminée.

Installation sur le client :

Comme par défaut le fichier msi n'installe que les composants client, il vous sera possible de scripter l'installation à l'aide de le commande : msiexec /i <emplacement>\LAPS.x64.msi /quiet

La partie client de LAPS est un CSE (Client Side Extension), soit une extension qui vient s’enregister auprès du service client de stratégies de groupe de Windows. Il s'agit donc bien d'une installation d'un composant de l'OS et non un nouveau service, que vous pourrez retrouver par défaut sous %programfiles%\LAPS\CSE\AdmPwd.dll

A chaque déclenchement du CSE, ce dernier :

• vérifie si le mot de passe est expiré à l'aide du dernier changement stocké dans l'attribut ms-Mcs-AdmPwdExpirationTime.
• S'il l'est, en génère un de manière aléatoire basé sur les politiques de sécurité définies par la GPO.
• Met à jour le mot de passe et l'inscrit en clair dans l'attribut ms-Mcs-AdmPwd et modifie l'attribut ms-Mcs-AdmPwdExpirationTime de l'objet Ordinateur dans l'Active Directory.

Voila la configuration est maintenant terminée, mappons la GPO et vérifions.

Vous êtes vous déjà posé la question "Mon parc informatique est il vulnérable?".

En terme de sécurité dans une grande majorité des cas la réponse est "Oui", mais alors pourquoi?

Grand nombre de personnes justifierons que le parc est à jour (Update, antivirus, firewall...), à cela je ne vous poserais que deux questions :

1. Le compte Admin Local est il désactivé sur toutes vos machines comme préconisé par Microsoft ? Si la réponse est non on peut déjà douter.
2. Le mot de passe du compte Admin Local des postes et/ou des serveurs est il différent sur chaque machine ? Si la réponse est non on à une faille de sécurité.

Envisageons simplement que  le mot de passe sur une de vos machines vient à être compromis, d'un coup, c'est l'ensemble de votre parc qui l'est et cela sans avoir besoin d'utiliser le compte Admin du domaine.

Une fois la première machine compromise il n'y a plus qu'a rebondir sur les autres pour pouvoir compromettre l'intégralité du parc.

Et si je vous disais qu'on pouvait gérer ce problème avec un outil développé par "Microsoft Consulting Services" et fournit gratuitement par Microsoft, laissez moi vous présenter LAPS.

Introduction à LAPS :

LAPS, qu'est ce que c'est?

LAPS pour "Local Admin Password Solution" est un outils permettant la gestion et le stockage du mot de passe Administrateur Local des machines du domaine : Postes clients et Serveurs membres.

Cette solution permet:

• De mettre à jour le mot de passe dans le contexte système et de l'envoyer au contrôleur de domaine à l'aide d'un composant client. Création aléatoire du mot de passe et transmission au contrôleur de domaine de manière crypté à l'aide de kerberos version 5 et Advanced Encryption Standard (AES).
• De stocker le mot de passe et sa durée de validité comme attribut de l'objet machine de l'Active Directory. ms-Mcs-AdmPwd et ms-Mcs-AdmPwdExpirationTime.
• Gérer le déploiement des paramètres de manière centraliser via les Stratégie de Groupes. Nom du compte, fréquence de changement, longueur et complexité.
• La récupération des mots de passe pour les utilisateurs habilités via une interface graphique ou Powershell. Par défaut seuls les "Admins du domaine" sont autorisés à accéder à ces informations mais il est possible de déléguer les droits sur un groupe.

Illustration à l'aide d'un schéma d'architecture de la solution :

Jusque là c'est sympa mais comment ça fonctionne?

Le coeur  de la solution LAPS est une extension d'un composant du client Stratégie de Groupe (CSE - Client Side Extension) qui pendant la mise à jour des Objets de Stratégies de Groupe, effectue et peut forcer les actions suivantes  :

1. Vérifier si le mot de passe Administrateur Local est expiré (Contrôle de la date de validité et de la configuration de la GPO).
2. Générer un nouveau mot de passe si l'ancien a expiré ou nécessite d'être changé avant expiration.
3. Valider que le nouveau mot de passe répond aux politiques de sécurité.
4. Envoyer le nouveau mot de passe à Active Directory et le stocker avec un attribut confidentiel dans l'objet ordinateur dans l'Active Directory.
5. Envoyer la prochaine date d'expiration du mot de passe à Active Directory et le stocker en tant qu'attribut dans l'objet ordinateur dans l'Active Directory.
6. Modifie le mot de passe du compte Administrateur local.

Il est possible de déléguer les droits suivants:

• Read Permission : Permet de lire le mot de passe depuis l'Active Directory, le client lourd LAPS ou avec Powershell par les utilisateurs autorisés. L'autorisation se fait par délégation de droits à des Groupes de sécurités (par défaut les "Admins du domaine").
• Reset Permission : Permet de soumettre une demande de changement de mot de passe depuis le client lourd LAPS ou avec Powershell.

Prérequis et OS supportés :

Prérequis :

Infrastructure :

• Active Directory : Windows Server 2003 SP1 ou ultérieur (L'attribut confidentiel n'est supporté qu'à partir du 2003 SP1 dans Active Directory)
• Ajout des attributs ms-Mcs-AdmPwd et ms-Mcs-AdmPwdExpirationTime (Action réalisé lors de l'installation).
• Restriction aux utilisateurs qui ne doivent pas accéder à l'attribut (retrait du All Extended Rights pour les groupes sensibles).
• Installation & paramétrage d'un ADMX.

•  Être Admin du Schéma le temps de l'installation (une Extension de Schéma est requise lors de l'installation)

Outils d'administrations :

• .NET Framework 4.0.
• Windows PowerShell 2.0 or ultérieur.

OS Supportés :

Clients : Windows 10 , Windows 8.1, Windows 8, Windows 7, Windows Vista avec le dernier Service Pack

Serveurs : Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008,  Windows Server 2003 avec le Service Pack 2 (mais plus supporté)

Note : Les machines Itanium ne sont pas supportées.

Contexte

Il arrive souvent qu’un compte utilisateur soit utilisé pour l’exécution d’un job SQL, il s’agit d’une mauvaise pratique car le compte utilisateur peut être amené à changer de mot de passe ce qui provoqueras une erreur d’exécution des jobs en question.

Ce post explique comment détecter puis modifier les comptes utilisés.

Analyse

Le script suivant permet de détecter les jobs exécuté via un compte user (DOMAIN\USER-%) tout en ne remontant pas les jobs lancés par un compte de service (DOMAIN\SERVICE-%).

Les variables “DOMAIN\USER-%” et “DOMAIN\SERVICE-%” sont à modifier en fonction de la nomenclature utilisée pour nommer les comptes. Le “%” correspond à toute chaîne de zéro caractères ou plus Ce caractère générique peut être utilisé comme préfixe ou comme suffixe.

select s.name,l.name
from  msdb..sysjobs s
  left join master.sys.syslogins l on s.owner_sid = l.sid
where l.name like 'DOMAIN\USER-%' and  l.name not like 'DOMAIN\SERVICE-%'

Résolution

Il faut ensuite récupérer le SID du compte utilisateur à changer depuis l’active directory, ainsi que le SID du compte à utiliser, par exemple, SA.

Pour récupérer le SID d’un utilisateur SQL, executer la commande suivante “select sid,name,denylogin from MASTER..syslogins where name='SQLUser'”

Le script suivant permet de modifier l’owner des jobs d’une instance SQL depuis le SID “0x02” vers le SID “0x01” :

UPDATE msdb..sysjobs
SET owner_sid = CONVERT(varbinary(max), '0x01', 1)
where owner_sid = CONVERT(varbinary(max), '0x02', 1)