**Cette note contient :**
1. **[Component](#Component)**
2. **[Architecture visualization](#Architecture-visualization)**
3. **[Activation des différents modules de wazuh](#Activation-des-différent-modules-de-wazuh)**
4. **[Test des alertes](#Test-des-alertes)**
5. **[Wazuh agent linux vs windows](#Wazuh-agent-linux-vs-windows)**
# Component
**Security Information and Event Management (SIEM) & Extended Detection and Response (XDR)**
* **Wazuh server**
Wazuh indexer, manager and dashboard are installed on the same host.
* **Wazuh indexer**
*The Wazuh indexer is a highly scalable, full-text search and analytics engine. This Wazuh central component indexes and stores alerts generated by the Wazuh server and provides near real-time data search and analytics capabilities.*
* **Wazuh manager**
*The Wazuh manager is the system that analyzes the data received from all registered agents and triggers alerts when an event coincides with a rule. For example, intrusion detected, file modified, configuration not in accordance with the policy, possible rootkit, among others.*
* **Wazuh dashboard**
*The Wazuh dashboard provides a user interface dedicated to manage your Wazuh deployment. This includes monitoring the status, logs, and statistics of the different Wazuh components. It also includes configuring the Wazuh server, and creating custom rules and decoders for log analysis and threat detection.*
* **Wazuh agent**
*The Wazuh agent is multi-platform and runs on the endpoints that the user wants to monitor. It communicates with the Wazuh server, sending data in near real-time through an encrypted and authenticated channel.*
**Network-based Intrusion Detection System (NIDS)**
* **Suricata NIDS**
* **Suricata**
*Suricata is an open-source intrusion detection system (IDS) and intrusion prevention system (IPS) that can be used to detect and prevent a wide range of network threats. Suricata is a high-performance engine that can be used to monitor both wired and wireless networks.*
> **We did an install on an ubuntu 22 and set it up successfully**
* **Rules auto updates**
**suricata-update** is the official way to update and manage rules for Suricata.
we made rules update automated by a root cronjob.
* **Network interface on promisc mode**
we set up a service that turn our network interface to promisc mode automaticaly.
# Architecture visualization
> ***From official wazuh's documentation :***
# Activation des différent modules de wazuh
## Security Configuration Assessment
### Comment ça marche ?
Chaque agent Wazuh possède sa propre base de données locale dans laquelle il stocke l'état actuel de chaque vérification SCA. Le serveur Wazuh maintient une base de données SCA pour tous les agents qui y sont inscrits. Les agents Wazuh envoient uniquement les différences détectées entre les scans au serveur Wazuh. S'il n'y a pas eu de changement, seul un résumé de l'analyse SCA est envoyé, évitant ainsi un trafic réseau inutile tout en maintenant à jour la base de données SCA sur le serveur Wazuh. Le serveur Wazuh utilise ensuite ces mises à jour pour émettre des alertes qui sont affichées dans le tableau de bord Wazuh.
### Cas d'utilisation
#### Détecter un processus en cours d'exécution
Netcat est un utilitaire qui utilise TCP et UDP pour lire et écrire des données sur un réseau IP. Netcat peut ouvrir des connexions, envoyer des paquets ou écouter sur les ports TCP et UDP. Les acteurs de la menace utilisent netcat à des fins malveillantes telles que la création d'un accès par porte dérobée.
Créez un répertoire pour enregistrer vos fichiers de stratégie personnalisés :
```bash
mkdir /var/ossec/etc/custom-sca-files/
```
Créez un nouveau fichier de stratégie SCA `/var/ossec/etc/custom-sca-files/processcheck.yml` et ajoutez-y le contenu suivant :
```yaml
policy:
id: "process_check"
file: "processcheck.yml"
name: "SCA use case to detect running processes"
description: "Guidance for checking running processes on Linux endpoints."
references:
- https://documentation.wazuh.com/current/user-manual/capabilities/sec-config-assessment/index.html
- https://documentation.wazuh.com/current/user-manual/capabilities/sec-config-assessment/creating-custom-policies.html
requirements:
title: "Check that the SSH service and password-related files are present on the system"
description: "Requirements for running the SCA scan against the Unix based systems policy."
condition: any
rules:
- "f:$sshd_file"
- "f:/etc/passwd"
- "f:/etc/shadow"
variables:
$sshd_file: /etc/ssh/sshd_config
checks:
- id: 10003
title: "Ensure that netcat is not running on your endpoint"
description: "Netcat is running on your endpoint."
rationale: "Threat actors can use netcat to open ports on your endpoints or to connect to remote servers."
remediation: "Kill the netcat process if confirmed to be malicious after further investigation."
condition: none
rules:
- 'p:nc'
- 'p:netcat'
```
Puis :
```bash
chown wazuh:wazuh /var/ossec/etc/custom-sca-files/processcheck.yml
```
Activez le fichier de stratégie en ajoutant les lignes suivantes au bloc `<ossec_config>` du fichier de configuration de l'agent Wazuh dans `/var/ossec/etc/ossec.conf` :
```xml
<sca>
<policies>
<policy enabled="yes">/var/ossec/etc/custom-sca-files/processcheck.yml</policy>
</policies>
</sca>
```
Finalement redémarrer wazuh agent :
```bash
systemctl restart wazuh-agent.service
```
## File integrity monitoring
### Comment ça marche ?
Le module FIM effectue des analyses périodiques sur des chemins spécifiques et surveille en temps réel des répertoires spécifiques pour détecter les changements.
FIM stocke les empreintes et autres attributs des fichiers dans une base de données locale FIM. Lors d'une analyse, l'agent Wazuh signale tout changement détecté par le module FIM dans les chemins surveillés au serveur Wazuh. Le module FIM recherche les modifications de fichiers en comparant les empreintes des fichiers avec leurs empreintes et valeurs d'attributs stockées. Il génère une alerte s'il trouve des divergences.
Le module FIM de Wazuh utilise deux bases de données pour collecter les données d'événements FIM, telles que la création, la modification et la suppression de fichiers. L'une est une base de données locale basée sur SQLite sur l'endpoint surveillé qui stocke les données dans :
`C:\Program Files (x86)\ossec-agent\queue\fim\db` sur Windows.
`/var/ossec/queue/fim/db` sur Linux.
`/Library/Ossec/queue/fim/db` sur macOS.
L'autre est une base de données d'agent sur le serveur Wazuh. Le démon wazuh-db crée et gère une base de données pour chaque agent sur le serveur Wazuh. Il utilise l'ID de l'agent pour identifier la base de données. Ce service stocke les bases de données dans `/var/ossec/queue/db`.
Surveillance de l'intégrité des fichiers
Le module FIM maintient les bases de données de l'agent Wazuh et du serveur Wazuh synchronisées entre elles. Il met toujours à jour l'inventaire des fichiers dans le serveur Wazuh avec les données disponibles pour l'agent Wazuh. Une base de données de serveur Wazuh à jour permet de répondre aux requêtes API liées à FIM. Le mécanisme de synchronisation ne met à jour le serveur Wazuh qu'avec les informations des agents Wazuh telles que les empreintes et les attributs de fichiers qui ont changé.
### Configuration générale
#### Au niveau de wazuh server
```xml
<syscheck>
<disabled>no</disabled>
</syscheck>
```
#### Au niveau de wazuh agent
```xml
<syscheck>
<directories>FILEPATH/OF/MONITORED/FILE</directories>
<directories>FILEPATH/OF/MONITORED/DIRECTORY</directories>
</syscheck>
```
### Cas d'utilisation
#### 1. Détection de la technique de persistance des logiciels malveillants sur Windows [not implemented yet]
Wazuh surveille automatiquement le dossier de démarrage sans nécessiter aucune action de l'utilisateur. Par défaut, le fichier de configuration Wazuh sur `C:\Program Files (x86)\ossec-agent\ossec.conf` utilise le paramètre suivant pour surveiller le dossier de démarrage :
```xml
<syscheck>
<directories realtime="yes">%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup</directories>
</syscheck>
```
#### 2. Détecter la manipulation de compte sur linux [done]
La manipulation de compte fait référence à la création, la modification ou la suppression de comptes d'utilisateurs ou d'autres informations d'identification au sein de l'infrastructure informatique d'une organisation. La surveillance de cette activité est essentielle à la cybersécurité d'une organisation. Des manipulations de compte non autorisées peuvent permettre à un attaquant d'accéder à des systèmes et des données sensibles.
Au niveau de wazuh agent sur `/var/ossec/etc/ossec.conf` :
```xml
<syscheck>
<directories whodata="yes">/home/*/.ssh/authorized_keys</directories>
</syscheck>
```
> **NOTE :** *La fonctionnalité who-data permet au module FIM d'obtenir des informations sur qui a apporté des modifications à un fichier surveillé. Ces informations contiennent l'utilisateur qui a apporté les modifications aux fichiers surveillés et le nom du programme ou le processus utilisé.*
#### 3. Modifications de fichiers sur linux [not implemented yet]
La fonctionnalité permettant de signaler les modifications apportées à un fichier vous permet de confirmer la mise en œuvre des modifications apportées à une application ou à un système. Par exemple, si vous modifiez un fichier de configuration d'application, la fonctionnalité FIM signale les modifications spécifiques apportées au fichier et affiche l'état avant et après la modification.
Avoir un enregistrement des modifications de fichiers peut être utile pour résoudre les problèmes ou à des fins d'audit. En offrant une visibilité sur les modifications de fichiers, la fonctionnalité FIM joue un rôle crucial dans une gestion efficace des modifications.
Au niveau de wazuh agent sur `/var/ossec/etc/ossec.conf` :
```xml
<syscheck>
<directories realtime="yes" report_changes="yes">/appfolder</directories>
<nodiff>/appfolder/private-file.conf</nodiff>
</syscheck>
```
> **NOTE :** in our case we can use `/var/ossec` and ignore `/var/ossec/etc/ossec.conf`, also `/var/www/html` and ignore `/var/www/html/site-map.xml`
#### 4. Surveillance des changements de configuration sur linux [done]
La surveillance des modifications de configuration permet d'établir la responsabilité des modifications apportées aux systèmes et aux applications. Les organisations peuvent identifier les parties responsables et s'assurer que les modifications sont correctement autorisées et documentées en conservant un enregistrement des modifications et de leurs auteurs.
Le module Wazuh FIM utilise les attributs **whodata** et **report_changes** pour enregistrer les informations suivantes sur ces modifications :
* L'utilisateur de connexion qui a apporté les modifications.
* Le temps des changements.
* Processus exécuté par l'utilisateur.
* Les modifications apportées au fichier.
Au niveau de wazuh agent sur `/var/ossec/etc/ossec.conf` :
```xml
<syscheck>
<directories check_all="yes" report_changes="yes" whodata="yes">/etc/app.conf</directories>
</syscheck>
```
> **NOTE :** nous pouvons changer /etc/app.conf avec n'importe quel fichier de configuration pour notre cas nous spécifierons les fichiers de configuration généraux de linux.
> * **`/etc/passwd`** : Ce fichier contient les informations des utilisateurs du système, comme leur nom d'utilisateur, identifiant utilisateur (UID), groupe principal, répertoire personnel, et le shell par défaut.
> * **`/etc/group`** : Ce fichier contient les informations sur les groupes du système, notamment leur nom de groupe, identifiant de groupe (GID) et les utilisateurs appartenant à chaque groupe.
> * **`/etc/hosts`** : Ce fichier mappe les noms d'hôtes (adresses) IP à des noms d'hôtes. Il est utilisé pour la résolution de noms locaux avant de consulter les serveurs DNS externes.
> * **`/etc/resolv.conf`** : Ce fichier contient les paramètres de configuration pour la résolution des noms de domaine (DNS) et spécifie les serveurs DNS à consulter.
> * **`/etc/fstab`** : Ce fichier contient les informations sur les systèmes de fichiers qui doivent être montés au démarrage du système, y compris les options de montage.
> * **`/etc/ssh/sshd_config`** : Ce fichier configure le serveur SSH (Secure Shell) et permet de spécifier les paramètres de connexion et de sécurité pour les connexions SSH.
> * **`/etc/sudoers`** : Ce fichier spécifie les autorisations et les privilèges des utilisateurs ou groupes pour utiliser la commande sudo et exécuter des commandes en tant qu'administrateur.
> * **`/etc/sysctl.conf`** : Ce fichier permet de configurer les paramètres du noyau Linux à l'aide de la commande sysctl, tels que les paramètres réseau ou de mémoire.
> * **`/etc/network/interfaces`** (ou **`/etc/netplan/*`** sur certaines distributions) : Ce fichier configure les interfaces réseau du système, y compris les adresses IP, les masques de sous-réseau et les passerelles par défaut.
> * **`/etc/apt/sources.list`** : Ce fichier contient la liste des sources de logiciels pour le gestionnaire de paquets APT, spécifiant les dépôts à utiliser pour les mises à jour et les installations de logiciels.
> * **`/etc/logrotate.conf`** : Ce fichier configure le système de rotation des journaux (logs) du système pour éviter leur surcroissance et permettre une gestion optimisée des logs.
> * **`/etc/environment`** : Ce fichier définit les variables d'environnement globales pour le système.
## Active response
La plate-forme Wazuh SIEM et XDR améliore la réponse aux incidents en offrant une visibilité en temps réel sur les événements de sécurité, en réduisant la fatigue des alertes et en automatisant les actions de réponse aux menaces. La plate-forme comprend un module de réponse actif avec des scripts de réponse prêts à l'emploi, permettant aux équipes de sécurité d'automatiser les actions en fonction de déclencheurs spécifiques. Cela permet de traiter rapidement et de manière cohérente les incidents hautement prioritaires, même dans des environnements aux ressources limitées. Cependant, une attention particulière est requise lors de la définition des scripts de réponse pour éviter les vulnérabilités potentielles sur les terminaux.
### Configuration générale
#### Au niveau de wazuh server
Vérifiez la configuration du bloc `<command>` dans le fichier de configuration `/var/ossec/etc/ossec.conf` du serveur Wazuh. Ajoutez-en un s'il n'existe pas déjà.
Le bloc `<command>` définit le script à exécuter en réponse à un déclencheur. Lorsque vous utilisez des scripts de réponse actifs prêts à l'emploi, les blocs `<command>` correspondants sont présents dans le serveur Wazuh `/var/ossec/etc/ossec.conf` par défaut, et vous n'avez pas besoin de les ajouter. Mais lorsque vous utilisez des scripts de réponse actifs personnalisés, vous devez leur ajouter les blocs `<command>` requis entre les balises `<ossec_config>` du fichier de configuration du serveur Wazuh. Par exemple:
```xml
<command>
<name>host-deny</name>
<executable>host-deny</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
```
#### Au niveau de wazuh agent[done]
La configuration par défaut autorise le module active response mais vous pouvez vous assurer en verifiant si la configuration au niveau de `/var/ossec/etc/ossec.conf` est comme ceci :
```xml
<active-response>
<disabled>no</disabled>
<ca_store>/etc/wpk_root.pem</ca_store>
<ca_verification>yes</ca_verification>
</active-response>
```
### Cas d'utilisation
#### 1. Blocage des attaques par force brute SSH avec réponse active sur linux [done]
Verifier si le bloc `<command>` de ***firewall-drop*** est présent au niveau de `ossec.conf`.
Au niveau de wazuh server sur `/var/ossec/etc/ossec.conf` :
```xml
<ossec_config>
<active-response>
<command>firewall-drop</command>
<location>local</location>
<!-- <rules_id><RULE_ID></rules_id> -->
<rules_group>sshd</rules_group>
<level>5</level>
<timeout>300</timeout>
</active-response>
</ossec_config>
```
#### 2. Désactivation d'un compte utilisateur Linux avec réponse active [done]
* **AU NIVEAU DE WAZUH SERVER :**
1. Ajoutez la règle ci-dessous au fichier `/var/ossec/etc/rules/local_rules.xml` du serveur Wazuh :
```xml
<group name="pam,syslog,">
<rule id="100100" level="10" frequency="3" timeframe="120">
<if_matched_sid>5503</if_matched_sid>
<description>Possible password guess on $(dstuser): 3 failed logins in a short period of time</description>
<mitre>
<id>T1110</id>
</mitre>
</rule>
</group>
```
2. Verifier si le bloc `<command>` de ***disable-account*** est présent au niveau de `ossec.conf`.
3. Ajoutez le bloc `<active-response>` ci-dessous au fichier de configuration `/var/ossec/etc/ossec.conf` du Wazuh server:
```xml
<ossec_config>
<active-response>
<command>disable-account</command>
<location>local</location>
<rules_id>100100</rules_id>
<timeout>300</timeout>
</active-response>
</ossec_config>
```
## Vulnerability detection
Les vulnérabilités sont des failles de sécurité que les pirates peuvent exploiter pour obtenir un accès non autorisé aux systèmes informatiques. La détection et la correction rapides des vulnérabilités sont essentielles pour renforcer la sécurité globale. Le module Wazuh Vulnerability Detector aide à découvrir les vulnérabilités du système d'exploitation et des applications en s'intégrant à des flux de vulnérabilités externes provenant de diverses sources.
### Configuration générale [done]
* **AU NIVEAU DE WAZUH AGENT:**
il faudra activer le bloc `<wodle>` pour autoriser le serveur wazuh à effectuer le scan nécessaire, sur `/var/ossec/etc/ossec.conf` :
```xml
<wodle name="syscollector">
<disabled>no</disabled>
<interval>1h</interval>
<os>yes</os>
<packages>yes</packages>
<hotfixes>yes</hotfixes>
</wodle>
```
* **AU NIVEAU DE WAZUH SERVER :**
Activez le module Vulnerability Detector dans le fichier de configuration du serveur Wazuh à `/var/ossec/etc/ossec.conf`. Définissez la valeur de la balise `<enabled>` sur `yes` pour le module Vulnerability Detector et chaque système d'exploitation que vous avez l'intention d'analyser. pour notre cas voici la partie du code de configuration :
```xml
<vulnerability-detector>
<enabled>yes</enabled>
<interval>5m</interval>
<min_full_scan_interval>6h</min_full_scan_interval>
<run_on_start>yes</run_on_start>
<!-- Ubuntu OS vulnerabilities -->
<provider name="canonical">
<enabled>yes</enabled>
<os>trusty</os>
<os>xenial</os>
<os>bionic</os>
<os>focal</os>
<os>jammy</os>
<update_interval>1h</update_interval>
</provider>
<!-- Debian OS vulnerabilities -->
<provider name="debian">
<enabled>yes</enabled>
<os>buster</os>
<os>bullseye</os>
<update_interval>1h</update_interval>
</provider>
<!-- Windows OS vulnerabilities -->
<provider name="msu">
<enabled>yes</enabled>
<update_interval>1h</update_interval>
</provider>
<!-- Aggregate vulnerabilities -->
<provider name="nvd">
<enabled>yes</enabled>
<update_from_year>2010</update_from_year>
<update_interval>1h</update_interval>
</provider>
</vulnerability-detector>
```
## Monitoring system calls
Wazuh surveille les appels système sur les terminaux Linux pour l'audit de sécurité. Le système d'audit Linux collecte les événements de sécurité et non liés à la sécurité, mais son volume de données peut rendre difficile l'identification des menaces. Wazuh utilise Linux Audit pour surveiller les appels système, installer et configurer des règles d'audit sur les terminaux. Il capture les événements liés à la sécurité et les envoie au serveur Wazuh pour analyse. Wazuh propose des règles de détection préconfigurées pour des activités telles que l'accès aux fichiers, l'exécution de commandes et la détection de logiciels malveillants, qui peuvent être personnalisées. En centralisant les événements d'audit, Wazuh simplifie la surveillance et facilite la conformité aux réglementations, en fournissant une solution complète de surveillance de la sécurité pour les systèmes Linux, en améliorant la sécurité et en se protégeant contre les cybermenaces.
### Configuration générale
Le système d'audit Linux génère une multitude d'événements, y compris ceux liés à l'accès en écriture, à l'accès en lecture, à l'accès en exécution, au changement d'attribut et aux règles d'appel système. Pour différencier et identifier efficacement ces événements d'audit, Wazuh utilise l'argument "`<KEY_NAME>`" dans les règles d'audit. Cette approche permet d'ajouter des valeurs clés descriptives à chaque entrée du journal d'audit, ce qui permet de discerner plus facilement la règle spécifique responsable de la génération de l'événement. Wazuh utilise une liste CDB avec une syntaxe comme "`<KEY_NAME>:<VALUE>`", où `<KEY_NAME>` représente l'argument utilisé dans le système de fichiers ou les règles d'appel système avec l'option "-k", et `<VALUE>` correspond à un événement différent types tels que l'écriture, la lecture, l'exécution, la modification d'attribut ou la commande.
* **AU NIVEAU DE WAZUH SERVER :**
Par défaut, Wazuh inclut une liste CDB d'audit. Cette liste CDB contient des clés d'audit qui correspondent aux événements d'écriture, de lecture, de modification d'attribut, d'exécution et de commande.
`# cat /var/ossec/etc/lists/audit-keys`
>**Output :**
> ```
> audit-wazuh-w:write
> audit-wazuh-r:read
> audit-wazuh-a:attribute
> audit-wazuh-x:execute
> audit-wazuh-c:command
> ```
Vous pouvez ajouter votre clé personnalisée avec sa valeur à la liste comme ceci (root):
```bash
echo "<YOUR_KEY>:<VALUE>" >> /var/ossec/etc/lists/audit-keys
```
* **AU NIVEAU DE WAZUH AGENT :**
1. installer le package d'audit (root).
```bash
apt install -y auditd
```
2. Au niveau de wazuh server sur `/var/ossec/etc/ossec.conf` :
```xml
<localfile>
<log_format>audit</log_format>
<location>/var/log/audit/audit.log</location>
</localfile>
```
### Cas d'utilisation
#### 1. Surveillance de l'accès aux fichiers et aux répertoires [done]
> **NOTE :** Dans cet exemple, nous surveillons différents types d'accès au répertoire `/home` du point de terminaison surveillé. Cela inclut l'écriture, la lecture, l'accès à l'exécution et les modifications des attributs du répertoire.
* **AU NIVEAU DE WAZUH AGENT :**
```bash
echo "-w /home -p w -k audit-wazuh-w" >> /etc/audit/audit.rules
echo "-w /home -p a -k audit-wazuh-a" >> /etc/audit/audit.rules
echo "-w /home -p r -k audit-wazuh-r" >> /etc/audit/audit.rules
echo "-w /home -p x -k audit-wazuh-x" >> /etc/audit/audit.rules
```
```bash
auditctl -R /etc/audit/audit.rules
auditctl -l
```
Output :
```
-w /home -p w -k audit-wazuh-w
-w /home -p a -k audit-wazuh-a
-w /home -p r -k audit-wazuh-r
-w /home -p x -k audit-wazuh-x
```
#### 2. Surveillance des commandes exécutées en tant que root [done | not tested]
* **AU NIVEAU DE WAZUH AGENT :**
ajoutez les règles ci-dessous dans le fichier de règles d'audit `/etc/audit/audit.rules` :
```bash
echo "-a exit,always -F euid=0 -F arch=b64 -S execve -k audit-wazuh-c" >> /etc/audit/audit.rules
echo "-a exit,always -F euid=0 -F arch=b32 -S execve -k audit-wazuh-c" >> /etc/audit/audit.rules
```
```bash
auditctl -R /etc/audit/audit.rules
auditctl -l
```
Output :
```
-w /home -p w -k audit-wazuh-w
-w /home -p a -k audit-wazuh-a
-w /home -p r -k audit-wazuh-r
-w /home -p x -k audit-wazuh-x
-a always,exit -F arch=b64 -S execve -F euid=0 -F key=audit-wazuh-c
-a always,exit -F arch=b32 -S execve -F euid=0 -F key=audit-wazuh-c
```
# Test des alertes
## ICMP flood Attack (Denial Of Service DOS)
Flooding our **Ubuntu NIDS** host with :
We can see that **Suricata** (N-IDS) can generate an alert and wazuh visualize it successfully :
## SSH brute force attack (active response)
**After trying to brute force a host by ssh (using hydra) wazuh detects it and generates a firewall rule to Block the attacker's IP address for 5 minutes:**
**5 minutes later the firewall rule is disabled:**
**Disabling active response on our linux enpoint :**
**Running hydra on our kali linux over this endpoint :**
**CONCLUSION :** Active response prevented this brute force attack.
## Password guessing attack (horizontal privesc)(active response)
On our N-IDS we try to switch user (su) to www-data and guessing password:
after trying 3 times wazuh lock the user and wait 5 minutes (300 secondes) to unlock this user again :
## File integrity monitoring
The FIM module runs periodic scans on specific paths and monitors specific directories for changes in real time.
FIM stores the files checksums and other attributes in a local FIM database. Upon a scan, the Wazuh agent reports any changes the FIM module finds in the monitored paths to the Wazuh server. The FIM module looks for file modifications by comparing the checksums of a file to its stored checksums and attribute values. It generates an alert if it finds discrepancies.
### Deleting ssh service
After removing the OpenSSH-server service, the file integrity monitoring module generates an alert that a file has been deleted (/etc/sshd_config) and a file has been modified (/etc/passwd) :
So the **FIM module** is working proprely.
> **NOTE :** The files monitored by the **FIM module** depends on the configuration implemented ***(see section : configuration of FIM module)***
### Detecting account manipulation
We will generate an SSH key-pair for user authentication and save it as `.ssh/test_key` using the following command:
```bash
ssh-keygen -f .ssh/test_key
```
We will run the following command to copy the content of the generated SSH public key `test_key.pub` and we'll add it to the authorized_keys file in the target Ubuntu user `.ssh` directory:
```bash
cat ~/.ssh/test_key.pub | ssh <UBUNTU_USER>@<UBUNTU_IP> "sudo tee -a /home/<UBUNTU_USER>/.ssh/authorized_keys"
```
**As we can see wazuh can detect properly the ssh file manipulation and generate an alert :**
### File integrity monitoring on a windows endpoint
We Configured our wazuh agent to verify this directory :`C:\Users\*\Documents` and generate a real time alert if any change happen on it.
So we create an empty file named by default `nouveau document texte.txt`, we changed it name to `hey.txt` and we add content on it :
Now on the wazuh dashboard we can see that all this action were shown successfully :
> **Notes :** We can also see those informations :
> **process name, user_id, user name, difference, event type ...**
> 
## Vulnerability detection
1. **Visualization :**
After enabling and configuring the vulnerability detection module on our wazuh agent and server we can now see the dashboard results after the full scan:
On this part, we can identify the number of problems we are facing and we can see their severity: critical, high, medium and low, as well as the last full scan and the last partial scan, and finally some programs/applications that may be vulnerable or have a CVE-related issue and need to be fixed.
2. **More informations :**
On this part, we can identify each vulnerability, its package name, the CVE associated with it and its severity, which allows us to solve the problems quickly.
## Monitoring file and directory access
*After enabling the monitoring file and directory access to `/home` with auditd service, we will simulate a file access manipulation :*
*We can see that WAZUH is able to detect and alert those suspicious behaviour runing on the host :*
## Monitoring commands run as root
After enabling the sub-module to monitor command run as root we will perform a test :
We can see that wazuh generate an alert :
## Detecting a running process
We are going to conduct a controlled simulation of an attack on our **NIDS** (*Network Intrusion Detection System*) hosted on Ubuntu. In this simulation, our SIEM (Security Information and Event Management) system, Wazuh, will act as the attacker host, listening for a reverse shell.
> **Please note that this simulation will be conducted in a secure and authorized environment for the sole purpose of assessing the effectiveness of our SOC and enhancing our cybersecurity defenses. All activities will be performed responsibly and ethically, and no harm will be caused to any external systems or networks.**
***
We intend to utilize this payload to execute a **reverse shell** on our NIDS (Network Intrusion Detection System) host:
We have configured a listener on our attack host, utilizing the same port. As a result, we successfully obtained our NIDS shell.
In our dashboard, it is evident that Wazuh has the capability to detect and trigger an alert for this particular event, marked with a high severity level (9):
## Simulating a pentest on our infrastructure
**Kali's IP ADDRESSE : 10.0.6.4**
Running Nmap over our windows 10 host and discovering open port and potential vulnerabilities :
Our N-IDS suricata generate alert after this scan and prompt it on wazuh dashboard :
And also more information about the scan (**nmap OS scan**) :
Now we will perform a scan on our windows server 2019 :
Our NIDS detect malicious activity and nmap scan scripting engine :
**Example of vulnerabilities detection :**
Wazuh vulnerabilities detector for our windows 10 host :
Wazuh vulnerabilities detector for our windows server 2019 :
Running a kerberos exploit (**WHITE BOX**) over our windows server 2019 :
## New service installation Detection on Windows Server 2019
We have successfully installed the Sysmon service on our Windows server with administrator privileges :
Wazuh has generated an alert associated with this event :
Additional details regarding this event are as follows :
## Infiltrating Windows Active Directory via an Internal Domain Post using Mimikatz
We have executed the installation of Mimikatz and proceeded to simulate a DCSync attack :
**We got the NTLM hash : f43cde5fb95d1b126790e18e4501906**
Utilizing this hash, we will proceed to simulate a Golden Ticket attack :
It is evident that Wazuh has identified this malicious activity and subsequently triggered an alert in response to this matter :
## Detecting a ftp brute force attack or password guessing on linux
We configured an FTP server on an Ubuntu host located at **[192.168.50.21]** :
We conducted an attempt to guess the password from our Windows host to the previously mentioned **FTP server** :
With kali linux brute-forcing the password :
It's evident that Wazuh successfully identified these malicious activities and produced an alert regarding this matter:
More details :
***
# Wazuh agent linux vs windows
## Collecte de journaux :
* **Wazuh Agent sur Windows :**
Le Wazuh agent Windows utilise l'API Windows Event Forwarding (WEF) pour collecter les journaux d'événements. Il peut être configuré pour collecter différents types d'événements, tels que les événements de sécurité, d'application, de système, de pare-feu, etc. Les événements sont collectés à partir des canaux de journaux Windows et envoyés au serveur Wazuh à l'aide de protocoles tels que WinRM (Windows Remote Management) pour les communications sécurisées.
* **Wazuh Agent sur Linux :**
Le Wazuh agent Linux collecte les journaux en parcourant les fichiers de journaux du système. Il examine les fichiers de journaux tels que `/var/log/auth.log`, `/var/log/syslog`, `/var/log/kernel.log`, et d'autres fichiers spécifiques à chaque distribution Linux. Ces fichiers contiennent des informations sur les activités système, l'authentification, les erreurs, les processus en cours d'exécution, etc.
## Modules spécifiques :
* **Wazuh Agent sur Windows :**
Le Wazuh agent Windows peut inclure des modules spécifiques pour surveiller les fonctionnalités uniques à Windows. Par exemple :
* Le module "windows-firewall" surveille les événements de pare-feu Windows pour détecter les règles de pare-feu modifiées, les tentatives de connexion bloquées, etc.
* Le module "windows-registry" surveille les modifications du registre Windows, telles que les changements de clés, de valeurs et d'autorisations.
* Le module "windows-account" détecte les activités liées aux comptes d'utilisateur, telles que les changements de mot de passe, les comptes verrouillés, etc.
* **Wazuh Agent sur Linux :**
Le Wazuh agent Linux propose des modules spécifiques pour surveiller les activités propres à Linux :
* Le module "syslog" analyse les fichiers de journal syslog pour détecter des événements tels que les connexions SSH **réussies/échouées**, les erreurs du noyau, etc.
* Le module "openvpn" surveille les journaux OpenVPN pour détecter les connexions VPN et les tentatives suspectes.
* Le module "apache" surveille les journaux Apache pour identifier les activités anormales sur un serveur Web Apache.
> **NOTE :** *Ces modules spécifiques exploitent les caractéristiques et les comportements distincts de chaque système d'exploitation pour détecter des activités malveillantes ou suspectes. Chaque module utilise des règles spécifiques qui sont conçues pour générer des alertes lorsque des conditions prédéfinies sont remplies.*
Sign in with Wallet
Connect another wallet