Category Archives: Labs

Nessus and Chill: First Hands on with Nessus Essentials

Posted on by
Reply

One of the tools I’ve heard mentioned a lot in cybersecurity spaces, particularly when it comes to vulnerability management is Nessus.  Nessus is a vulnerability scanner, with Nessus Essentials being their free version.  It scans systems, networks, and applications to help organisations identify vulnerabilities that pose potential security risks.  It’s widely used by businesses and cybersecurity professionals to ensure the security and compliance of their IT infrastructure.  It’s a powerful tool, and something I’m keen to get some experience with.  This tutorial I found by Josh Madakor is a perfect start, guiding viewers through a beginner level lab to using Nessus and facilitating that first hands on experience with the tool.  That is what I’m going to be working through today in this post, so follow along and hope you enjoy hearing about how I went about it.

To get started, we’re going to need to download Nessus Essentials.  This can be done through their website, linked here.  Simple register for an activation code, follow along and it’ll download.  Nessus runs on our own local machine using port 8834 by default, so we connect to the web interface by going to the URL https://localhost:8834.  Simply select Nessus Essentials, punch in the activation code and it’ll download and compile the required plug-ins.  We’ll be running our scans on a basic Windows 10 Virtual Machine, the ISO file for which can be found at Microsoft’s website here.  I’ll be running this VM on VMware Workstation, but any alternative such as VirtualBox will do the trick as well.  Download the file and create a new VM with it.  We’ll be using the Windows 10 Pro operating system in this lab.

Once the VM is all set up, the first thing we’ll want to do is get the IPv4 address of the machine.  We use this address to connect to the VM through Nessus Essentials that’s running on our machine.  This can be done by opening the command line and typing the command ‘ipconfig’, like so:

We can then ping that IP address on our PC to make sure we can reach the VM.  We do this by running the command ‘ping <IPv4 address>’ on the command line.  Adding the ‘-t’ flag will continue to ping the machine until we cancel it, which may be useful as our PC is most likely not going to be able to detect the VM on the first go, as the ping requests will time out.  To fix this, we can just disable the firewall on the VM.  When working with a proper host, this is not ideal and creates unnecessary risk.  However,  we’re only using this VM for this simple lab, so we don’t mind as much if we turn the firewall off.  To do so, we follow the same process I did in my previous post linked here, turning the firewall state of the domain, private and public profiles off.

Even after disabling the firewall, I continued to not be able to ping the VM from my PC.  I figured out that this was because my VM was configured to use a NAT network connection, which shared the host’s IP address.  This was causing me to be unable to ping the machine, as it was on the LAN on the host.  Switching the network connection to a bridged connection allowed the VM to get its own IP within the network, and made it discoverable by my PC.  This can be changes in the Network Adapter tab, under Virtual Machine Settings of VMware

Now that we can access the VM from our PC, we can get to scanning our machine.  Navigate back to our Nessus Essentials web app and create a new scan.  There’s lots of different types of scans that check for a range of vulnerabilities, but we’re only going to be running a Basic Network Scan today.  Click on that one and fill out the details, filling in the targets box with the IPv4 address of the VM.

The first scan we’ll be running is just a basic, non-credentialled scan.  With this kind of scan, Nessus will scan the machine for any obvious vulnerabilities, reporting them back to the user along with any notable bits of information it finds about the VM.  Non-credentialled scans aren’t very thorough though, as they don’t get into the machine and scan places such as the file system and registry, providing a greater assessment of the state of the machine.  After our non-credentialled scan, we’ll revisit the credentials tab to run our own credentialled scan.  In the meantime, we can hit save, then the launch button on the right to get the scan started.

Once completed, we can click on the scan to view its results:

Further clicking on the scan brings up a list of all the reported vulnerabilities and information, as seen below:

So the first scan had a couple vulnerabilities it detected but was mainly full of information about the machine.  Each one of those vulnerabilities can be clicked on and expanded, to see the information reported, as well as an overview of the vulnerability detected and how to patch it.  However, this scan wasn’t extensive enough for my liking, so we’re going to run a credentialed scan to identify vulnerabilities within the VM.

To do so, we need to configure the VM for a credentialled scan. An full walkthrough of enabling a credentialled check on Windows can be found here, which goes into better detail than I can.  Essentially, we enable the remote registry, enable printer and file sharing, and disable user account control.  Then we added a registry entry called LocalAccountTokenFilterPolicy, settings its value to 1.  Once that is all done, reboot the VM, and we can run our credentialled scan.  Return to Nessus, select the scan, and click on configure which is under the more tab in the top right of the screen.  There, we add a new set of windows credentials under the credentials tab, inputting our username and password. 

Save it and we can run the scan one more time.  Once it’s complete, it should be looking something like this:

That’s a lot better.  Now we can see that even as a default  Windows 10 machine, there’s multiple vulnerabilities present right off the bat.  To simulate a machine with applications that may be out of date, I’ll install an old version of Firefox on the VM, which can be found here.  Let that finish installing, run another credentialled scan and we’ll compare the number of vulnerabilities present.

That’s a hell of a lot more red with just one out of date application.  More than half of the findings are either critical or high severity vulnerabilities.  Diving into the list of vulnerabilities, most of them seem to be concerned with out of date software, requiring different updates to get it up to speed and secure.  Obviously, the Firefox version is extremely out of date, but even the operating system is missing updates and patches to some of its software and applications.  The best thing to do here is return to the VM and update Firefox to the latest version.  I also need to check for the missing Windows updates and apply them to reduce the number of vulnerabilities.  After doing so, and working through some of the other vulnerabilities Nessus found, my final scan is looking something like this:

Only the 1 vulnerability! How good!  I couldn’t seem to patch the last one following the instructions Nessus provided to patch it, but potentially its due to me disabling the firewall on the VM.  Either way, the VM is significantly more secure now compared to its previous, default state.  With most of the vulnerabilities being patched downloading and installing updates, this lab has reinforced how important it is to regularly update your systems and applications.  Keeping them out of date, even more a seemingly minor update, can leave multiple vulnerabilities present and exploitable.

Like many of the other labs I’ve done so far, this is only scratching the surface with Nessus.  Even by looking at the list of other types of scans outside a basic network scan demonstrate how powerful and comprehensive this tool can be.  I can say I’ve got a good understanding of the basics however, and that’s a good place to start as I explore the field of vulnerability management.  I’m sure the process of scanning and remediating vulnerabilities in a large organisation would be very different to me just scanning a VM, so learning about that is my next step.  Till then, I hope you all enjoyed following along with me!

SIEMple Enough!

Posted on by
1

In my studies for the CompTIA Security+ exam, I came across the concept of a SIEM, a device capable of combining log data from multiple different sources into a centralised device.  I then came across this tutorial created by Josh Madakor, facilitating hands on experience learning what a SIEM can do.  Having completed the tutorial myself, I was inspired to write about my experience and some of the key takeaways I gained from the project.

The main purpose of this project is to gain exposure working with a SIEM, as well as getting some hands on experience with Microsoft Azure.  Cloud computing has been a booming section of the IT industry, so having a basic knowledge of how to configure and set up different cloud-based applications is an important skill.  Importantly, being able to visually represent where attacks are coming from is very cool, and something that I was excited to see pan out.

The basic idea is to create a virtual machine (VM) with severely reduced defences to act as our honeypot.  Attackers who try to log into the VM will be recorded in the Event Viewer, which contains their IP address.  With the help of a PowerShell script, the IP address will be obtained from these failed log ins and sent to an API which will allow us to create custom logs with geographic data to discover where the attacks are coming from.  These logs will be exported to a Log Analytics Workspace where they can be accessed by Sentinel – Microsoft’s cloud native SIEM – and then analysed, plotting where the attacks are originating from on a global map. Jumping into things, one of the most important considerations when setting up the VM for this project is making sure it’s highly exposed on the internet.  This means disabling all the security protocols and opening all the ports on the machine to make the honeypot extra sweet and noticeable for attackers out on the internet.  One of the main ways we go about doing this is through creating a custom NIC network security group when creating the VM.  This network security group typically determines what network traffic is allowed to and from the VM, but in our case, we create a new inbound rule that essentially allows all traffic from the internet into our machine.  Simply fill in the Destination port ranges field with an asterisk to allow all and our VM is on the way to looking very attractive to attacks now!

Another way we really try to attract attackers to the VM is by disabling the firewalls on the operating system.  This was my first time changing the settings on a firewall, good experience of what not to do.  Simply connect to the VM with a remote desktop, open Windows Defender Firewall with Advanced Security, and change the firewall state to off in the domain, private and public profile.

As all the attackers start to find this machine on the internet and try to log into it, their failed attempts will be logged in the security section of the Event Viewer.  Failed logon attempts are recorded as ‘Audit Failure’, with the event ID of 4625. 

Even when I was first looking at the event viewer and checking it out, there were multiple audit failures present that were from attackers already trying to access the VM.  Highlights just how easy it is to locate exposed machines on the internet when the correct security protocols are turned off.

The Event Viewer collects a lot of information beyond just audit failures.  Luckily, we’re able to use the event ID to extract just the information we need with some PowerShell scripting!  Full credit to Josh Madakor once more, who created this script which is included with his tutorial.  In essence, the script extracts the logs using the event ID, uses this API to gain the locational data of the IP address, then packages them up into a log file containing all the information.  This forms the raw data that we then analyse to figure out where the attackers are trying to access the VM from, a sample of which is seen below.

All these processes have occurred inside the VM so far, but now we turn our attention to our next cloud application, the Log Analytics Workspace.  Log Analytics can collect information from many sources – such as our VM – and run queries on the data to gain insight into the logs.  Custom logs can also be created, which is the function used to understand the raw log data and discover where the attacks are coming from.  Simply connect the workspace to the VM, enter some sample logs and provide the collection path of the log file the script is writing to.  Following that, the workspace can now access our logs!

Being able to read the logs is a completely different story however, because with the log data being in one big text file, our workspace doesn’t know what to make of it.  Queue a bit of machine learning to help the workspace decipher our data.  While it was a bit monotonous to highlight out every field, it was interesting to see the workspace trying to match the same fields in the other log entries.  Training the data set to pick up correct results was simple and really highlighted how quick to learn some algorithms are.

Finally, with our Honeypot attracting attackers and our Log Analytics Workspace ingesting the logs using the PowerShell script, it was time to visualise the data.  This was as simple as creating a new instance of Sentinel and linking it to our workspace, allowing it access to our custom logs.  From there, creating a workbook and writing out a specific query was the final piece we needed.

Run this query, changing the visualisation setting to map, and voila:

The map here shows the attack data from the VM after running for just 12 hours.  As you can see, attacks from Belize were the main contributor, followed by other attacks from South Korea and the United States.  This doesn’t mean the attackers are from these regions however, as proxies and VPNs could’ve been used to protect attacker’s true IP addresses.  The attacks from Belize were especially interesting to see come through into the system.  It was clear some sort of script was being used to try brute force its way into the system, trying common names such as ‘Administrator’, ‘Support’ and ‘itsupport’.  Attacks like this highlight the importance of strong authentication processes, especially when a system has generic account names.

For those interested, I would highly recommend checking out Josh Madakor’s tutorial.  I learnt a lot from the experience, and it was good to put the theoretical learning into practice. I know I’m barely scratching the surface when it comes to SIEMs, logs and other security processes though, and I’m keen to have more of a play with some of the other things this tool can do.  Hopefully you enjoyed just as much as I did.