Network and Cloud Monitoring and Documenting – 15421

Assignment #3 –SIEM
Supervised By: Prof. Mohammad Al-Nabhan
Done By:
Ayat Hafez 20200815
Assim Kanaan 20200274
Zaid Massoud 20200497
Yousef Al-Karnawi 20200845
Rand Abu-Ghazaleh 20200023
Table of Contents
Setup..............................................................................................................................................................3
Wazuh Server...........................................................................................................................................3
Wazuh Agent............................................................................................................................................4
Attacker machine.....................................................................................................................................6
Challenge 1: Implement a Brute Force Attack and Monitor using the Wazuh SEIM Solution..........7
Task 1: Perform a Brute force attack on the root user of the Agent machine..........................................7
Task2: Create a new User, and try to switch to the root user and enter the wrong...............................13
password on the Agent machine............................................................................................................13
Challenge 2: Perform a port scanning Attack.........................................................................................16
Challenge 3: A user file integrity monitoring use case..........................................................................17
Setup
The setup branches into 3 parts: Wazuh server, Wazuh Agent, and Attacker.

Wazuh Server
Wazuh is a free, open-source security platform acting as a vigilant security guard for your
systems. The Wazuh Server, its central hub, collects data from all agents deployed across your
network. It analyzes this data, identifying threats and triggering alerts for swift incident response.
Additionally, Wazuh assists in maintaining security standards by monitoring configurations and
checking for vulnerabilities.
To log into the Wazuh server, you should pass its credentials:
User: admin
Pass: i6NI791Nnl+A6VPRGLTu+JAyJF6ElzdP

After successful login to the server, the Wazuh interface shown:

Wazuh Agent
We chose Ubuntu as a Wazuh agent and installed and set it up.
Step 1: Go to Wazuh server Agents Deploying new agent. The following fields should be
answered as the following:

Ip of the Wazuh server

Name of our agent

Step 2: Installing the Agent on Ubuntu

Step 3: Accessing our machine after successfully adding it, and navigating to ‘security events’:
Step 4: Enabling, starting, and verifying status for SSH from Ubuntu (agent):

Attacker machine
We choose Kali-Linux to be the attacker.
Challenge 1: Implement a Brute Force Attack and Monitor
using the Wazuh SEIM Solution

Task 1: Perform a Brute force attack on the root user of the Agent machine
Step 1: We chose to use a dictionary attack that is a branch of brute force for its speed; we save
a list of passwords into a password file. text.

Step2: We use the Hydra tool to implement a dictionary attack:

 hydra is a popular password-cracking tool.

 -l root specifies the login username to use.
 -P passwords.txt specifies the file containing the list of passwords to try.
 ssh://192.168.1.23 is the target SSH server's IP address.

Note: The correct password of Ubuntu is not stored on the password file; it is just to view the
Failed login Alerts.
Step 3: Monitoring Using Wazuh
Wazuh has a dashboard that shows security monitoring and provides an overview of
authentication events and alerts in a system.
Additional information regarding the Wazuh dashboard is provided below:

 Total: The total number of authentication events or alerts logged, which is 14654
 Level 12 or above alerts: Indicates the number of high-severity alerts (level 12 or above),
which is 0
 Authentication failure: The number of failed authentication attempts is 14654.
 Authentication success: The number of successful authentication attempts, which is 0

 Alert groups evolution: A time series graph showing the count of different alert groups
over time (in 30-minute intervals). Different colored areas represent different alert types,
such as Syslog, authentication_failed, sshd, pam, invalid_login, and access_control.
 Alerts: Another time-series graph showing the count of alerts over time, with different
alert severity levels indicated by colors.
 The Pie charts branch into 3 categories as the following:
 Top 5 alerts: A pie chart displaying the distribution of the top 5 alerts by type. The
segments represent different types of alerts, such as sshd: Attempt to log in, PAM:
User login failed, sshd: authentication_failed, unix_chkpwd: Pass..., syslog: User
missed...
 Top 5 rule groups: A pie chart showing the distribution of the top 5 rule groups that
generated the alerts. Different segments represent rule groups such as syslog,
authentication_failed, sshd, invalid_login, and pam.
 Top 5 PCI DSS Requirements: A pie chart representing the distribution of the top 5
Payment Card Industry Data Security Standard (PCI DSS) requirements related to the
alerts. The segments correspond to requirements like 10.2.4, 10.2.5, 10.6.1, 11.4.
As we can see in the image below, the top 5 alerts and top 5 rule groups consist of SSH failed
logins, invalid logins, failed authentication attempts, and password-related events.
In the alerts group evolution, we can see the huge count of invalid_logins:

This is the legend for the types of alerts to make the chart readable:
Step 4: for further Analysis, we scroll down to view the alerts:
we can observe the timestamp, agent IP, targeted user, source IP (confirmed as our Kali
machine's IP), rule description (confirmed as SSH authentication failure), and additional details.

This log entry details a failed SSH login attempt for the root user from the IP address
192.168.1.24 on port 57398. The attempt was logged by the agent AYZ_RandAyat with IP
192.168.1.23 and recorded in the /var/log/auth.log file. The rule that triggered this alert describes
a failed SSH authentication, and it has been triggered 92 times. The log entry also includes
references to compliance guidelines such as GDPR

We can also see and manage predefined rules/add custom rules to Wazuh:
We can also see the rules that were triggered by credential access issues, which were a result of a
Dictionary attack attempt:

 MITRE: Refers to the MITRE ATT&CK framework, a globally accessible knowledge

base of adversary tactics and techniques based on real-world observations. It is used for
understanding security threats and improving defense measures.
 Credential Access: This is a category within the MITRE ATT&CK framework that
covers techniques attackers use to steal credentials like account names and passwords:
 T1110.001 specifically refers to "Password Guessing" under the broader "Brute
Force" technique. The number 10 next to it indicates 10 detected instances of this
technique.

 T1021.004: This is another technique identifier, referring to "Remote Services:

SSH" under the broader "Remote Services" technique. The number 5 next to it
indicates 5 detected instances of this technique.
Task2: Create a new User, and try to switch to the root user and enter the wrong
password on the Agent machine

Step1: Adding new user named zaid with password massoud123

Step2: Logging in as zaid's account

Step3: After attempting to log in as root from Zaid's user account, we receive new alerts
Step 4: for further Analysis, we scroll down to view the alerts

This log entry details a failed attempt by the user zaid to switch to the user assim using the su
command on a virtual terminal. The event was recorded by the agent AYZ_RandAyat with IP
192.168.1.23 and logged in the /var/log/auth.log file. The rule that triggered this alert describes a
failure due to an incorrect password, and it has been triggered twice. The log entry also includes
references to compliance guidelines such as GDPR, GPG13, and HIPAA.
To illustrate the differences between the two tasks, refer to the following table. The first entry
represents a dictionary attack, while the second involves a user change attempt.
Field Dictionary Attack User Change Attempt
Time May 15, 2024 @ Not provided
20:35:18.263
@timestamp 2024-05-15T17:53:16.263Z 2024-05-15T18:11:59.355Z
_id 8dFfY8BSNhP4pxGHUJn S9V0Y8BShNp4pxGQEjF
id 1715795596.6933185 1715796719.6963624
agent.name AYZ_RandAyat AYZ_RandAyat
agent.id 008 008
agent.ip 192.168.1.23 192.168.1.23
data.dstuser root Not provided
data.srcip 192.168.1.24 Not provided
data.srcport 57398 Not provided
decoder.name sshd su
decoder.parent sshd su
full_log Failed password for root from FAILED SU (to assim) zaid
192.168.1.24 port 57398 ssh2 on pts/0
predecoder.program_name sshd su
location /var/log/auth.log /var/log/auth.log
manager.name rocky-vps.local rocky-vps.local
predecoder.timestamp 2024-05- 2024-05-
15T19:59:37.257689+02:00 15T20:18:19.325154+02:00
rule.description sshd: authentication failed. User missed the password to
change UID (user id).
rule.firedtimes 92 2
rule.id 5760 5301
rule.gdpr IV_35.7.d, IV_32.2 IV_35.7.d, IV_32.2
rule.groups Not provided syslog, su,
authentication_failed
rule.hipaa Not provided 164.312.b
Challenge 2: Perform a port scanning Attack

Step1: using Nmap to perform port scanning from kali to ubuntu

Step2 : for further analysis using Wazuh

This log entry details multiple failed SSH login attempts from the IP address 192.168.1.24, each
resulting in a timeout before authentication. The log suggests a possible scan or break-in attempt
due to the many login timeouts. The rule associated with this alert has been triggered twice and
has a high severity level of 10. The log entry includes references to compliance guidelines such
as GDPR and GPG13 and maps to MITRE ATT&CK techniques T1190 and T1110.

Challenge 3: A user file integrity monitoring use case

Step 1: Open the configuration of a Wazuh agent on a Ubuntu system. And display its
information:

Step 2: Add this script to the configuration file to use the sys check module for file integrity
monitoring.
 Element/Tag Description
<ossec_config> This is the root element for the Wazuh configuration
file. It encloses all configuration settings.
<syscheck> This section is dedicated to the File Integrity
Monitoring (FIM) configuration.
<disabled>no</disabled> Ensures that the FIM feature is enabled. Setting it to
"no" means the feature is active.
<frequency>43200</frequency> Sets how often the syscheck (FIM scan) is executed.
The value is in seconds (43200 seconds equals 12
hours).
<scan_on_start>yes</scan_on_start> Ensures that a scan is performed immediately when the
Wazuh agent starts.
<directories check_all="yes" Specifies directories to be monitored, with
realtime="yes">...</directories> check_all="yes" for all verifications and
realtime="yes" for real-time monitoring.
<ignore>...</ignore> Specifies files or directories to exclude from
monitoring to avoid unnecessary alerts for non-critical
changes.

Step 3: Write an Automatic script to connect to Ubuntu using SSH with user assim and password
assim123; create a new user name and newuser, and set password hamada123.

Grant the execute to the file

Step4: Install sshpass
Step 5: Execute the script

Step 6: For further analysis view Wazuh dashboard

The first alert:
Field First Alert Second Alert Third Alert
@timestamp 2024-05- 2024-05- 2024-05-
15T22:55:59.618Z 15T22:55:59.653Z 15T22:55:59.653Z
_id 8cvf0b8ShNp4pxGy 8cvf0b8ShNp4pxGy 8cvf0b8ShNp4pxGy
Uz Uz Uz
agent.id 008 008 008
agent.ip 192.168.1.23 192.168.1.23 192.168.1.23
agent.name AYZ_RandAyat AYZ_RandAyat AYZ_RandAyat
data.command /usr/bin/bash -c "echo Not applicable Not applicable
'newuser:hamada123'
| chpasswd"
data.dstuser root newuser assim
data.pwd /home/assim Not applicable Not applicable
data.srcuser assim Not applicable Not applicable
decoder.ftsscomment First time user Not applicable Not applicable
executed the sudo
command
decoder.name sudo pam pam
decoder.parent sudo pam pam
full_log 2024-05- 2024-05- 2024-05-
16T00:32:21.218129 16T00:32:21.208054 16T00:32:21.298229
+02:00 assim- +02:00 assim- +02:00 assim-
VirtualBox sudo: VirtualBox VirtualBox
assim : chpasswd[2835]: sshd[6229]:
PWD=/home/assim ; pam_unix(chpasswd: pam_unix(sshd:sessi
USER=root ; auth): password on): session closed
COMMAND=/usr/bi changed for newuser for user assim
n/bash -c "echo
'newuser:hamada123'
| chpasswd"
id 1715811959.20571 1715811959.20209 1715811959.22558
input.type log log log
location /var/log/auth.log /var/log/auth.log /var/log/auth.log
manager.name rocky-vps.local rocky-vps.local rocky-vps.local
predecoder.program sudo chpasswd sshd
_name
predecoder.timestam 2024-05- 2024-05- 2024-05-
p 16T00:32:21.218129 16T00:32:21.208054 16T00:32:21.298229
+02:00 +02:00 +02:00
rule.description Successful sudo to PAM: User changed PAM: Login session
ROOT executed. password. closed.
rule.firedtimes 5 2 10
rule.gdpr IV_32.2 IV_35.7.d, IV_32.2 IV_32.2
rule.gpg13 7.6, 7.8, 7.13 4.13, 7.10 7.8, 7.9
rule.groups syslog, sudo pam, syslog pam, syslog
 rule.hipaa 164.312.b 164.312.b, 164.312.c 164.312.b
rule.id 5402 5555 5502
rule.level 3 3 3
rule.mail Not applicable false false

Summary of Differences:
First Alert: indicates that the user assim executed a sudo command to create a new user newuser
and set its password to hamada123. This is the first time the user assim executed a sudo
command.
Second Alert: indicates that the password for the new user newuser was changed. The chpasswd
command was used to perform this change, and the PAM (Pluggable Authentication Modules)
system logged the event.
Third Alert: indicates that the login session for the user assim was closed. The session closure
was managed by the sshd service and logged by PAM.