Cybersecurity Homelab

Transforming OpenVAS Vulnerability Data in Power BI

In this section, I took the vulnerability results from OpenVAS and transformed the data in Power BI to create meaningful visualizations. This involved exporting the data from OpenVAS, cleaning and transforming it in Power BI, and creating interactive charts and tables to analyze the vulnerabilities.

Objective

The goal was to:

• Export the OpenVAS scan results in XML format.
• Import and transform the data in Power BI to make it usable for analysis.
• Create visualizations, including a pie chart and tables, to highlight key vulnerability metrics.

Tools Used

• OpenVAS: For exporting the vulnerability scan results in XML format.
• Power BI: For data transformation, analysis, and visualization.

Steps Performed

1. Exporting Data from OpenVAS

   I exported the vulnerability scan results from OpenVAS in XML format using the web interface. Below is a screenshot of the export process:

   
2. Importing Data into Power BI

   I imported the XML file into Power BI. Initially, the data appeared as a single row, so I used the Drill Down feature to expand the nested tables. Below is a screenshot of the initial data import:

   
3. Transforming the Data

   I navigated through each table, expanded the necessary columns, and removed irrelevant ones to clean the data. This included:

   • Expanding the results table to access individual vulnerability details.
   • Removing unnecessary columns like timestamp and host that were not relevant to the analysis.
   • Renaming columns for clarity, such as threat_level, cvss_base, and nvt.family.

   Below is a screenshot of the Power Query Editor showing the transformed data:

   
4. Creating Visualizations

   After transforming the data, I created the following visualizations:

   • Pie Chart: A pie chart showing the distribution of vulnerabilities by threat level (e.g., High, Medium, Low). This helps quickly identify the most critical issues.
   • Vulnerability Table: A table displaying key details about each vulnerability, including:
     • Name of Threat: The name of the vulnerability.
     • Threat Level: The severity level (e.g., High, Medium, Low).
     • CVSS Base Score: The Common Vulnerability Scoring System (CVSS) score.
     • NVT Family: The category or family of the vulnerability.
     • Description: A brief description of the vulnerability.
     • Attribute ID: A unique identifier for the vulnerability.
   • Port and Solution Table: A table to the right of the pie chart showing additional details, including:
     • Name of Threat: The name of the vulnerability.
     • Port: The port associated with the vulnerability.
     • Solution Text: Recommended steps to remediate the vulnerability.
     • Reference ID: A reference to a CVE or CB (Common Vulnerabilities and Exposures or Common Bug) identifier.
     

     View the full Power BI project here.

Key Findings

• Successfully transformed raw OpenVAS XML data into a structured format for analysis in Power BI.
• Created a pie chart to visualize the distribution of vulnerabilities by threat level, highlighting the most critical issues.
• Developed detailed tables to provide actionable insights, including vulnerability descriptions, CVSS scores, and remediation steps.

What’s Next?

Based on the analysis, here’s what I plan to do next:

1. Remediate Vulnerabilities:
   • Prioritize and address high-severity vulnerabilities identified in the pie chart.
   • Use the solution text and reference IDs to implement fixes.
2. Enhance Visualizations:
   • Add filters and slicers to make the Power BI dashboard more interactive.
   • Include additional metrics, such as trends over time or vulnerability distribution by host.
3. Automate the Process:
   • Set up automated data refreshes in Power BI to keep the dashboard up to date with new scan results.

Conclusion

This exercise demonstrated the power of combining OpenVAS and Power BI for vulnerability analysis. By transforming raw scan data into actionable visualizations, I was able to quickly identify and prioritize critical vulnerabilities. Moving forward, I will focus on remediation and enhancing the dashboard to support ongoing security monitoring.

OpenVAS Vulnerability Scanning

In this section, I used OpenVAS, a comprehensive vulnerability scanning tool, to identify security issues within my internal network. The process involved discovering live hosts using Nmap, creating a scan task in OpenVAS, and analyzing the results for critical vulnerabilities.

Objective

The goal was to:

• Discover live hosts on the internal network using Nmap.
• Perform a Full and Fast vulnerability scan using OpenVAS.
• Identify and document high-severity vulnerabilities, such as default admin credentials on pfSense devices.

Tools Used

• Nmap: Used for network discovery and live host identification.
• OpenVAS: A vulnerability scanner for identifying security issues.

Steps Performed

1. Network Discovery with Nmap

   I started by performing a discovery scan on my internal network to identify live hosts. The following command was used:

   nmap -oG nmap_output.txt 192.168.2-4.0/24

   This scan generated a list of live hosts, which I filtered and saved into a file named targets.txt:

   grep "Up" nmap_output.txt | awk '{print $2}' > targets.txt

   Below is a screenshot of the Nmap scan results:

   
2. Creating a Scan Task in OpenVAS

   Using the targets.txt file, I created a scan task in OpenVAS with the Full and Fast scan mode. Below is a screenshot of the scan task configuration:

   
3. Parsing Targets in OpenVAS

   I imported the targets.txt file into OpenVAS and configured it as a target list. Below is a screenshot of the parsed targets in OpenVAS:

   
4. Analyzing Scan Results

   After the scan completed, I reviewed the results and identified high-severity vulnerabilities. Specifically, I found default admin credentials for pfSense devices on the following IPs:

   • 192.168.2.1
   • 192.168.3.1
   • 192.168.4.1

   Below is a screenshot of the OpenVAS scan results highlighting these vulnerabilities:

   

Key Findings

• Discovered live hosts on the internal network using Nmap.
• Identified high-severity vulnerabilities, including default admin credentials on pfSense devices.

What’s Next?

Based on the findings, here’s what I plan to do next:

1. Remediate Vulnerabilities:
   • Change default credentials on pfSense devices.
   • Apply patches and updates to vulnerable systems.
2. Expand the Scope:
   • Include additional vulnerability checks in the OpenVAS scan configuration.
3. Transform Data for Analysis:
   • In the next section, I will transform the scan data for further analysis and visualization.

Conclusion

This exercise demonstrated the effectiveness of OpenVAS for identifying vulnerabilities in a network. By combining Nmap for discovery and OpenVAS for scanning, I was able to uncover critical security issues. Moving forward, I will focus on remediation and expanding the scope of the scans to ensure comprehensive coverage.

Getting Started with Metasploit

In this section, I explored Metasploit, a powerful penetration testing framework, to identify and exploit vulnerabilities in my lab environment. My target was the domain controller at 192.168.2.10, and I focused on using Metasploit to test for known vulnerabilities like EternalBlue and DoublePulsar.

Objective

The goal was to use Metasploit to:

• Scan for vulnerabilities on the domain controller.
• Search for and test exploits related to open services.
• Attempt to exploit the target system to gain access.

Tools Used

• Metasploit: A penetration testing framework for exploiting vulnerabilities.
• nmap: Used to scan for open ports and services.
• searchsploit: A command-line tool for searching the Exploit Database.

Steps Performed

1. Starting Metasploit

   I launched Metasploit and was greeted with its iconic ASCII art interface. Below is a screenshot of the Metasploit startup screen:

   
2. Scanning for Vulnerabilities

   I used nmap with the --script vuln flag to scan the domain controller for vulnerabilities:

   nmap --script vuln 192.168.2.10

   This scan revealed several open ports and services. Below is a screenshot of the results:

   
3. Searching for Exploits

   Using searchsploit, I searched for exploits related to the open services. I found many results, but I narrowed my focus to EternalBlue, a well-known exploit for SMB vulnerabilities:

   searchsploit eternalblue

   Below is a screenshot of the search results:

   
4. Exploring the DoublePulsar Exploit

   In Metasploit, I searched for the DoublePulsar exploit, which is related to EternalBlue:

   msf6 > search eternalblue

   I found the SMB DOUBLEPULSAR Remote Code Execution exploit (ID 27). Below is a screenshot of the exploit details:

   
5. Attempting the Exploit

   I set up the exploit and targeted the domain controller:

   msf6 > use exploit/windows/smb/smb_doublepulsar_rce
   msf6 exploit(windows/smb/smb_doublepulsar_rce) > set RHOSTS 192.168.2.10
   msf6 exploit(windows/smb/smb_doublepulsar_rce) > exploit

   Unfortunately, the exploit failed because the target system is likely patched against the vulnerability. Below is a screenshot of the attempt:

   

Security Onion IDS Alerts

While performing these activities, my Security Onion IDS detected several alerts. Below is a summary of the alerts:

Key Alerts:

• 28 Alerts - ET POLICY LDAPSv3 LDAPS_START_TLS Request Outbound: These alerts indicate that the Kali machine (192.168.1.128) was sending LDAP START_TLS requests to the domain controller (192.168.2.10). This is normal behavior for LDAP traffic and is not directly related to the DoublePulsar exploit.
• Other Alerts: Additional alerts were triggered for suspicious inbound traffic to database ports (e.g., Oracle SQL, MySQL, PostgreSQL, MSSQL) and a potential VNC scan. These are likely false positives or unrelated to the DoublePulsar exploit.

Analysis: The LDAP alerts suggest that the Kali machine was interacting with the domain controller’s LDAP service, which is expected during enumeration or exploitation attempts. However, these alerts do not indicate a successful exploit or compromise.

Key Findings

• Discovered open ports and services on the domain controller, including SMB, LDAP, and Kerberos.
• Identified the EternalBlue and DoublePulsar exploits as potential attack vectors.
• Confirmed that the target system is likely patched against these vulnerabilities, as the exploit attempt failed.

What’s Next?

Since the DoublePulsar exploit didn’t work, here’s what I’ll do next:

1. Verify Vulnerability:
   • Use the smb_ms17_010 scanner in Metasploit to confirm if the target is vulnerable to EternalBlue.
2. Explore Other Exploits:
   • Search for other exploits related to SMB, LDAP, or Kerberos.
3. Enumerate the Target:
   • Use tools like enum4linux or ldapsearch to gather more information about the domain controller.
4. Brute Force Credentials:
   • If no exploits are available, attempt to brute-force credentials for SMB or LDAP.

Conclusion

This exercise was a great introduction to using Metasploit for vulnerability scanning and exploitation. While the DoublePulsar exploit didn’t work, it highlighted the importance of keeping systems patched and up to date. Moving forward, I’ll focus on enumerating the target further and exploring other attack vectors.

Network Enumeration and Scanning

In this section, I performed network enumeration and scanning to identify live hosts, open ports, and services running on the lab network. This activity is critical for understanding the network's attack surface and ensuring that all devices are properly secured and monitored.

Objective

The goal was to map out the network, identify active devices, and gather information about the services running on those devices. This helps in identifying potential vulnerabilities, misconfigurations, and unauthorized devices that could pose a security risk.

Tools Used

• nmap: A powerful network scanning tool for discovering hosts and services.
• netdiscover: A tool for ARP-based host discovery, useful for identifying devices on the local network.
• Security Onion: A network security monitoring (NSM) platform used for intrusion detection and log analysis.

Steps Performed

1. Scanning for Live Hosts

   I started by using nmap to scan the entire subnet for live hosts. This helps in identifying all active devices on the network.

   nmap -sn 192.168.1-4.0/24

   This command performed a ping scan, which quickly identified all devices responding to ICMP requests. Below is a screenshot of the results:

   
2. Detailed Scan on Specific Hosts

   Next, I performed a detailed scan on specific hosts to identify open ports and services. This step provides deeper insights into the services running on each device.

   nmap -sV -O 192.168.1.1

   nmap -sV -O 192.168.2.10

   The -sV flag enabled version detection, while -O enabled OS detection. This revealed the operating system and service versions running on the target host. Here’s a screenshot of the output:

   
   
3. ARP-Based Host Discovery

   Finally, I used netdiscover to perform ARP-based host discovery. This tool is particularly useful for identifying devices that might not respond to ICMP requests.

   netdiscover -i eth0 -r 192.168.1.0/24

   This command scanned the network using ARP requests. Below is a screenshot of the results:

   

Key Findings

• Discovered 6 live hosts on the network, including the pfSense firewall, Security Onion, and Windows Server.
• Identified open ports such as HTTP (80), HTTPS (443), and DNS (53) on various devices.
• Detected the operating systems and service versions running on each host, which will be useful for vulnerability assessment.

Security Onion IDS Alerts

During the ping scan and subsequent network enumeration, my Security Onion IDS detected several suspicious activities. Below are the key alerts generated:

Analysis: The alerts from Security Onion show some unusual activity happening between two devices on the network:

• Source: The Kali machine (192.168.1.128) is sending traffic to the Windows Server (192.168.2.10).
• What’s Happening: The traffic is going to non-standard ports (ports not normally used for MSSQL or Terminal Server), which could mean someone is trying to steal data or run malware.
• Why It’s a Problem: High-severity alerts mean this activity could be dangerous. It might be an attempt to break into the Windows Server or send sensitive information outside the network.

As part of the Blue Team, my job is to figure out what’s going on and stop it. Here’s what I’ll do:

• Find the Source: Check if the Kali machine is doing this on purpose or if it’s been hacked. Maybe someone is using it to test the network, or maybe it’s been compromised.
• Stop the Threat: Disconnect the Kali machine from the network so it can’t cause any more problems while I investigate.
• Check for Damage: Look at the Windows Server to see if any sensitive data was accessed or stolen.

What’s Next?

Here’s the plan to fix the issue and make sure it doesn’t happen again:

1. Incident Response:
   • Disconnect the Kali machine from the network to stop any more suspicious activity.
   • Investigate the Kali machine to see if it’s been hacked or if someone is misusing it.
2. Update Firewall Rules:
   • Change the firewall settings to block traffic to unusual ports, especially for services like MSSQL and Terminal Server.
   • Only allow the Kali machine to send traffic to necessary services and ports.
3. Protect Devices:
   • Make sure all computers on the network, including the Windows Server, have antivirus software installed and up to date.
   • Run a malware scan on the Windows Server to check for infections.
4. Improve Monitoring:
   • Turn on detailed logging for all important devices and services so we can catch suspicious activity in the future.
   • Adjust Security Onion’s rules to reduce false alarms and make it better at detecting real threats.
5. Train Users:
   • If someone on the team is using the Kali machine, make sure they know how to use it safely and follow security rules.
   • Teach everyone on the network about the risks of connecting to unusual ports or running unauthorized services.

Conclusion

This exercise showed how important it is to keep an eye on the network and take action when something looks wrong. By using tools like Security Onion and pfSense, the Blue Team can spot and stop threats before they cause serious damage.

Step-by-Step Setup

1. Prepare the Host Machine:
   • Ensure hardware meets requirements: 8 CPU cores, 32 GB RAM, 1 TB SSD.
   • Install VMware Workstation Pro 16 or VirtualBox.
   • Download ISOs for pfSense, Security Onion, Kali Linux, Windows Server, Windows 10, Ubuntu Server, and additional Linux machines.
2. Configure pfSense Firewall:
   • Create a VM with 1 CPU core, 2 GB RAM, and 20 GB storage.
   • Add 5 network adapters for segmentation.
   • Install pfSense Community Edition and configure interfaces (LAN, OPT1, OPT2, OPT3).
   • Complete the setup wizard and configure firewall rules.
3. Set Up Security Onion:
   • Create a VM with 2-4 CPU cores, 4-32 GB RAM, and 200 GB storage.
   • Add 2 network adapters (management and monitoring).
   • Install Security Onion and configure interfaces (management: DHCP, monitor: span port).
   • Access the web interface from an Ubuntu Desktop machine.
4. Configure Kali Linux:
   • Create a VM with 2 CPU cores, 4 GB RAM, and 20 GB storage.
   • Set the network adapter to Vmnet2.
   • Install Kali Linux and change the default password using passwd.
   • Use Kali for penetration testing and accessing the pfSense WebGUI.
5. Set Up Windows Server (Domain Controller):
   • Create a VM with 2 CPU cores, 4 GB RAM, and 40 GB storage.
   • Set the network adapter to Vmnet3.
   • Install Windows Server 2019 and promote it to a Domain Controller.
   • Configure Active Directory and create user accounts.
   • Disable the firewall for lab purposes.
6. Configure Windows 10 Desktops:
   • Create 2 VMs with 2 CPU cores, 4 GB RAM, and 40 GB storage each.
   • Set the network adapter to Vmnet3.
   • Install Windows 10 and join the machines to the AD domain.
   • Configure IP settings and test domain connectivity.
7. Install Splunk on Ubuntu Server:
   • Create a VM with 2-4 CPU cores, 4-8 GB RAM, and 100 GB storage.
   • Set the network adapter to Vmnet6.
   • Install Ubuntu Server and optionally add a GUI for easier management.
   • Download and install Splunk Enterprise.
   • Start Splunk and configure it to receive logs from the Windows Server using the Universal Forwarder.
8. Add Additional Linux Machines:
   • Examples: Ubuntu, CentOS, Metasploitable, DVWA, Vulnhub.
   • Create VMs with 1-2 CPU cores, 2-4 GB RAM, and 20-40 GB storage.
   • Use these machines for exploitation, detection, or monitoring.
9. Configure Ubuntu Desktop (Analyst Machine):
   • Create a VM with 2 CPU cores, 4 GB RAM, and 20 GB storage.
   • Install Ubuntu Desktop.
   • Use this machine to access the Security Onion and Splunk web interfaces.
10. Finalize Network Configuration:
    • Segment the network:
      • LAN: Kali Linux and pfSense management.
      • OPT1/OPT2: Internal networks for Windows and other services.
      • OPT3: Span port for Security Onion.
      • OPT4: Splunk communication.
    • Set IP addressing:
      • pfSense LAN: 192.168.1.1.
      • Windows Server: 192.168.2.10.
      • Windows Desktops: 192.168.2.21 and 192.168.2.22.