Vulnerability Management is an excellent way to kick-start a career in cybersecurity. This guide will help show you the way.

Jump to Section


Why Vulnerability Management?

Vulnerability Management (a.k.a. “VM”) is a less-considered, but in my opinion, ideal entry-level role for aspiring infosec professionals. For many who are looking to get into information security, finding that first job can be very difficult. Typical recommended paths into infosec include roles such as help desk, SIOC/SOC, system administration, network engineering or even software development. Though there is no one path that is universally best, I believe VM can be an optimal choice for a number of different reasons.

Why Start Your Infosec Career with Vulnerability Management
  • A lot of true infosec positions are not really considered “junior” or “entry-level” (e.g. penetration testing, threat hunting, reverse engineering, application security, etc…) This means it is difficult to jump directly into those roles without some prior experience in infosec. VM however, is considered junior and thus is more readily attainable by those with little-to-no prior infosec experience.
  • Unlike other recommended “starter” roles (i.e. help desk, system administration, etc…), VM is a true infosec role. What I mean by this is, having the title “Vulnerability Management” (or some derivation of this title) on your resume counts towards years of experience in cybersecurity whereas having help desk (for example) experience on your resume would likely not be considered infosec-relevant experience.
  • VM (in my opinion), is easier to learn the basics of as compared to other potential starter positions. Don’t get me wrong, you certainly need to have a breadth of knowledge in a number of different areas but you don’t (for example) need to be able to fully administer Linux/Windows, or engineer a network, or perform in-depth packet analysis, or be an expert coder to work in VM (though it wouldn’t hurt!). You need only have (at least starting out) a relatively foundational grasp of a handful of knowledge areas.
  • Those in VM roles are exposed to a wide variety of other infosec domains. For example, in performing the week-to-week responsibilities of a VM analyst/engineer, you will encounter vulnerabilities that a penetration tester would also encounter, you may be asked to assess the risk of scan findings similar to what a GRC analyst would be asked to do, you could also be asked how to patch or mitigate issues like a system administrator would need to do, etc… Collectively, these experiences are great for building a solid generalist base of knowledge and could also help you pivot into other areas of infosec if/when you are ready to do so.
  • Penetration testing is a very sought-after infosec position but can be out-of-reach for many entry-level professionals. This is for good reason as penetration testing requires skills and experience that are a bit more advanced. VM is a great stepping-stone to a career in penetration testing as you get a lot of hands-on experience with the vulnerabilities you will be exploiting as a penetration tester. (NOTE: This statement is not meant to discourage those looking to get into penetration testing early in their careers. It certainly can be done!)
  • VM analysts typically get a good bit of face-time across IT organizations. What I mean by this is that you will likely be asked to interface with a wide variety of groups within IT - server teams, desktop teams, development teams, IT leadership, etc… This exposure helps network you around the organization and also gives you the opportunity to learn from a diverse set of personalities and professionals.
  • VM is (or really should be) ubiquitous. Since VM is fundamental to all organizations, the need for qualified and/or knowledgeable VM professionals is abundant. In other words, there is a lot of opportunity in learning this particular craft. With that said, there is an increasing prevalence of out-sourced, managed VM which means this function may become more and more commoditized.
VM Compared to Other Infosec Starter-Roles

There are a number of different “starter” roles one could consider as they begin their journey into infosec. I personally believe VM is one of the better options as compared to these other roles. Some of the cons of these other roles are detailed below.

  • In help desk roles, learning (specifically infosec-related learning) tends to stagnate, your ability to perform actual “security” work is limited, pay tends to be lower and opportunities to pivot into more security-specific roles are often non-existent or overly hard-fought. There also tends to be a stigma attached to “help desk” which if you’re not careful, could hinder your ability to break out of that role and onto something more “advanced”.
  • In SIOC/SOC or other blue-team-analyst-type roles, you get great exposure to “real” security work, but this often comes at the expense of jobs that are high stress, have weird/long hours and/or are very scripted in nature with respect to operational responsibilities, limiting the ability to learn and grow. A lot of individuals in these positions suffer from burn-out or other stress-related issues.
  • In system administration roles, you learn a great deal about the OS (i.e. Windows, Linux, Mac) you are administering but do not necessarily get to perform any security-specific work. This experience certainly comes in handy later in an infosec career but might not help too much for breaking into the field initially.
  • In network engineering roles, you can easily find yourself siloed into only performing network engineering and never getting to break out and do any actual security work. I’ll add that this path requires quite a bit of technical depth on the networking side which makes this path particularly difficult for an entry-level individual. With that said, that knowledge could be of great use if/when you do ultimately move into a more security-specific position.
  • Software development is a common first step for those who ultimately would like to end up in an “Application Security” role. This makes sense considering knowing how to properly assess and secure applications likely means first having some understanding or experience writing/developing applications. With this said, it is a relatively serious commitment that must be made to become a software developer and is probably a bit over-kill if your goal is to quickly get into infosec-proper.

Vulnerability Management Day-to-Day

If you’re with me thus far, you’re likely somewhat interested in a getting a job in Vulnerability Management. You may however be wondering, “what exactly does someone in Vulnerability Management actually do?” This is of course a very relevant question for someone thinking of going down this path so I’d like to try and cover it here. Though it can certainly vary from place to place, VM professionals typically have responsibilities in three functional areas - operations, analysis and engineering. I’ll briefly explain VM responsibilities across each of these domains below…

VM Operations

Though there are elements of VM analysis or engineering that could be considered operational, what I really mean by “operations” is, the every day break-fix, tuning and troubleshooting that a VM professional needs to do to keep scans running on-time and without failure as well as ensuring reports/alerts are being generated and delivered as required. Consider the list of potential operational tasks below…

  • Scan failures: If a scan fails to kick-off, finish or otherwise does not complete, the VM team will need to troubleshoot what happened. A scan may fail for a number of different reasons: the scanner itself may be malfunctioning, a firewall or IPS may be blocking scan traffic or the target endpoint could have shut off. These are just a few examples.
  • False positives: Often, a system owner may contact the VM team because they believe a finding on a scan report is a false positive. It is then the VM team’s job to investigate this claim and determine whether it is indeed a false-positive or not. In my experience, especially when it comes to credentialed scans, it is very rarely a real false-positive. In any case, you will need to understand and be able to explain the scan plugin logic to the system owner that way there is a mutual understanding of why that plugin fired.
  • Scan causes system degradation: Network scans can be somewhat invasive - both on the network as well as against a target host. Though modern operating systems and enterprise networks are fairly robust and thus less likely to have a negative reaction as a result of a common vulnerability scan, it is certainly still possible that a scan could cause network/system degradation. When this happens, the VM team may be contacted to disable the scan.
  • Creating/maintaining scan jobs: One of the core tenets of VM is that of visibility. What this means is that to the best of our ability, we as the VM team would like to be scanning everything with the highest-fidelity (credentialed) scan type as possible. To achieve this, the VM team will often need to create additional scan jobs or modify existing ones as needed to further increase visibility.
  • Credential failure: The highest-fidelity scan type is an authenticated scan. To achieve an authenticated scan you need proper credentials which have sufficient privileges on the target host. The scan job must then be populated with these credentials. For any number of reasons, scans may fail to actually login to the host. When this occurs, the VM team will need to diagnose what has happened and fix the scan.
  • Report/alert tweaking: A key facet of VM is ensuring that appropriate stakeholders receive reports which detail the information and specific findings relevant to them. The VM team is therefore responsible for building and maintaining these reports, regularly auditing whether they are being sent and received properly and that they have the correct and comprehensive data contained within them.
VM Analysis

Much of the “analyst” work a VM professional does could be considered operational as it is something that might be performed on a day-to-day basis. However, I delineate between analysis work and operations based on the skillset needed to perform each. VM analysis is the process of reviewing scan results (and vulnerabilities in general) and performing analysis on these findings which leads to a better understanding of risk. This work stands in stark contrast to operations, which does not require having a deep understanding of threats, vulnerabilities and risk. Below are some examples of VM analysis work…

  • Creating dashboards/content: Enterprise scan tools have advanced dashboarding and other content-creation capabilities which allow VM analysts to quickly consume VM metrics, trends and other interesting data points related to organization-wide scan results. For example, the VM team may maintain a trend graph which shows the total high-risk vulnerabilities that have been present in the environment over the course of the year. Or, there may be a dashboard component which shows the number of outstanding vulnerabilities across each department within IT.
  • Risk assessments: A common ask for the VM team is to produce a “risk assessment” related to a certain vulnerability against a specific system or as it applies to the organization as a whole. These risk assessments help IT leadership determine how to prioritize work. If the risk is high, business leaders and IT leadership must make decisions on risk mitigation.
  • Triaging recently disclosed vulnerabilities: Often new vulnerabilities are disclosed and require speedy analysis from the VM team. In these cases network scan vendors will not have had time to write and publish detection plugins for their respective scanners. When this happens, the VM team will be asked to triage these new vulnerabilities to determine their applicability to the organization’s environment, calculate potential risk and even research/produce possible risk treatments related to that vulnerability.
  • Vulnerability validation: Network scanners are great at identifying vulnerabilities. What they can’t always do however is determine the “true risk” of a vulnerability based on the relevant network/host-based controls which may mitigate certain aspects of the respective issue. The VM team may be asked to analyze a vulnerability in the context of whether it is truly a risk to the system. In some cases this may mean trying to actively exploit that particular vulnerability to determine if the expected controls which may mitigate said issue actually do so. Though I wouldn’t call this “penetration testing”, it is similar in some ways.
  • Reviewing scan results: VM analysts may spend a good bit of time simply reviewing the results of scans and evaluating whether any vulnerabilities require special or immediate attention. For example, if a new class of high-risk vulnerability appears in a scan result which does not have automated alerting or reporting content, a VM analyst may want to quickly catch it so it can be triaged accordingly.
VM Engineering

Last but certainly not least, we have VM engineering. Engineering in this context is the design, build and maintenance of the architecture and infrastructure which support VM operations and analysis. Some examples of VM engineering tasks are detailed below…

  • Patching: VM is supported by scanners, databases, central-consoles and a lot of other infrastructure. This infrastructure must be kept up-to-date with the latest functional/security patches from their respective vendors. The VM team may be responsible for maintaining their own tools in this way. In many cases however, the responsibility of patching, even for VM infrastructure, is placed on an organization-wide patching team rather than resting on the system-owners themselves.
  • Archictecture: As advancements are made, or perhaps as the VM program is first being built, there is a need to design an architecture for the VM program itself - especially as it relates to scanning operations. The VM team is responsible for designing and deploying VM-related hardware, determining where scanners are placed on the network and much more.
  • Scan routing: In order to scan all corners of an enterprise network, the VM team must work with the network team to ensure proper rules are in place on the firewalls such that the scanners can traverse the network.
  • New tooling: As modern enterprises continue to make strides into new computing frontiers (e.g. cloud, microservices, serverless, etc..), the VM team must keep up with respect to maintaining scan comprehension and visibility. To do so, new tools will likely need to be evaluated. Typically, this is done through trial-based, proof-of-concept engagements. The VM team will acquire the tool(s) and a trial license and have a limited amount of time to evaluate a new product to determine if it meets the VM-needs of the organization.
  • *Scripting & Automation: This final task is something that I believe spans all three VM functional areas. In order to get the most out of the tools you have in your VM tool-kit and to best solve the “scaling” issue within infosec, VM professionals must be able to write scripts and automate against RESTful APIs. These scripts will likely perform operational tasks and therefore the maintenance and creation of these scripts could be considered operational. Similarly, these scripts may perform automated analysis and triage of VM findings. In this way, these scripts can also be considered “analyst” work. Collectively, I think they are also engineering in that they are somewhat one-time efforts (not counting maintenance and upgrades) which help add new functionality to the VM program.

As you can see! There is a lot of interesting work to be done in VM. Due to the breadth of responsibilties and the very nature of the work, I truly believe it is one of the best starter infosec roles out there. Now, let’s get into the bootcamp!


Bootcamp Intro

OK! So you’re excited to learn more about VM and are ready to dive in. This is great! I’d like to officially welcome you to the Shellsharks Vulnerability Management Bootcamp, I am happy to have you here. The primary goal of this bootcamp is to fully prepare someone to not only ace an entry-level Vulnerability Management interview and get offered the job, but to also prepare you to step in day 1 after being hired and immediately hit the ground running with respect to performing the responsibilities of a VM analyst. As such, the specific objectives for this bootcamp as well as what this bootcamp explicitly doesn’t cover are provided in the two separate lists below.

Bootcamp Objectives
  1. Prepare you to ace an entry-level/junior VM interview, the outcome of which is (hopefully) a job offer.
  2. Provide real-world, hands-on, practical, lab-based VM experience which will equip you with the confidence and skills needed to perform VM analyst responsibilities immediately after starting your new job.
What the Bootcamp Doesn’t Cover
  • There are purposefully-open-ended, scenario-based questions at the end of the bootcamp lab. “Answers” for these questions are not explicitly provided. In fact, these questions do not have one correct answer, rather they are designed to be more of an exploratory thought-exercise based on real-world challenges a VM analyst might be expected to solve. For more information on how best to approach solving these prompts, you are encouraged to contact me or start a discussion in the Shellsharks Discord.
  • Here lies the necessary disclaimer that this “bootcamp” does not guarantee that you will be given interview opportunities nor that by completing the bootcamp you will be 100% prepared for any and all questions/prompts you may encounter in a VM interview. I have, to the best of my ability, attempted to provide as much information, both purely academic as well as practical which aims to achieve the objectives set forth in the previous section.
  • The goal of this bootcamp is not to make one an expert in all things VM. As such, there are many facets of VM that are only superficially covered or not mentioned at all. Expertise is developed over time and through years of experience and personal research. Though the goal of this piece is merely to introduce VM and give someone enough understanding to ace an interview, I am working on a more comprehensive compendium of VM knowledge - so stay tuned for that!

Bootcamp Sections

The bootcamp is comprised of the following five sections…

Part 1: VM Knowledge Pre-Requisites

Vulnerability Management, though “entry-level” in many respects, still requires a level of foundational infosec knowledge. This section provides an accelerated course of study through these knowledge areas. This is delivered though both statically-defined tips as well as externally-sourced references. The expectation is to have a fundamental grasp of these concepts and be able to speak reasonably well about them in an interview.

Part 2: VM Bootcamp Lab

This is the main portion of the bootcamp which walks you through how to set up the lab environment and how to perform a variety of different processes and actions related to VM. In this section there are also provided exercises designed to test your knowledge and understanding along the way. These questions have answers provided. Ultimately, this section will help you demonstrate in an interview, your hands-on understanding of the tools and techniques of the VM trade.

Part 3: Scenario-Based Exercises

As described previously, the scenario-based questions are open-ended and designed to be exploratory topics rooted in real-world situations I have encountered in my years in the VM arena. I encourage those who have produced solutions to these questions to contact me or start a discussion in the Shellsharks Discord. By solving these challenges, you best prepare yourself for solving similar problems once “on-the-job”.

Part 4: Finding a Job in VM

After you learn the basics but before you actually get an interview, you must first find actual VM jobs to apply to. This isn’t always straight-forward. This section will share some tips on how to best pinpoint VM-related jobs to apply to.

Part 5: The Interview

Finally, I provide a list (that I will continue to contribute to) of likely interview questions you may encounter during an entry-level VM job interview. Accompanying each of these questions is one possible answer (or a reference which can help you understand the answer). These questions will cover a variety of topics but will mostly be sourced from the VM knowledge pre-reqs and the lab exercises.


VM Knowledge Pre-Requisites

To get started in VM, there are a handful of knowledge areas that are in my opinion critical to have a basis in. As it pertains to the objective of this bootcamp, understanding these fundamental areas will best equip you to succeed in a VM interview and execute from day one once accepting a VM job offer. This pre-requisite material is succinctly listed below, either as informational snippets or externally-linked references. Where possible, I summarize why or what specifically may be required for you to understand about a specific topic. The goal of which is to reduce the total amount of prep that is needed to simply ace an interview.

Networking
  • TCP “Three-Way Handshake”” - Understand SYN –> SYN/ACK –> ACK.
  • OSI model - Know the layers in order and generally what they are responsible for.
  • NMAP - Know what Nmap is and what some of the basic flags do.
  • Port Scan Techniques (e.g. SYN, connect, UDP, NULL, FIN, Xmas, ACK, Zombie, etc…) - Best to at least understand the SYN, connect and UDP scan types.
  • TCP Flags (i.e. SYN, ACK, FIN, RST, PSH, URG) - Know what each is used for.
  • Network Devices - Understand what the basic networking devices are and what they do.
  • TCP vs UDP - Understand the basic differences between TCP and UDP.
Ports & Protocols
  • ICMP - Understand how it’s used for the ping and Microsoft tracert utilities.
  • Ephemeral Ports - What are “ephemeral” ports and why are they different than system / “well-known” ports.
  • *For each of the protocols specified below, simply understand what they are and remember the associated port number. Other ports and protocols may be asked about during an interview but the ones below makeup a majority of the popular ports/protocols.
Protocol  TCP/UDP  Port #
FTPTCP20/21
SSHTCP22
TelnetTCP23
SMTPTCP25
DNSTCP & UDP 53
DHCPUDP67/68
HTTPTCP80
POP3TCP110
NTPTCP123
NetBIOSTCP137/138/139
SNMPUDP161
LDAPTCP389
HTTPSTCP443
SMBTCP445
MySQLTCP3306
RDPTCP3389


Operating Systems
  • Basic Windows CLI - Learn basic Windows CLI commands (e.g. ipconfig, netstat, ping, tracert, systeminfo, net use, regedit, net user, etc…) You may be asked about specific commands but more likely an interviewer will just ask you qualitatively, how “familiar” you are with Windows.
  • Basic Linux CLI - Learn basic Linux CLI commands (e.g. curl, ls, tail, cat, grep, ps, top, netstat, ifconfig, ip, df, du, id, chmod, nslookup, ping, etc…) You may be asked about specific commands but more likely an interviewer will just ask you qualitatively, how “familiar” you are with Linux.
  • Linux file directory structure (e.g. root, bin, cdrom, dev, etc, home, lib, media, mnt, opt, proc, run, sbin, tmp, etc…) - Understand what is typically found in each of these directories.
  • SSH - What is SSH used for? I also recommend having SSH’ed into something as practice.
  • Windows Firewall - Just be mildly familiar.
  • Linux Firewall / iptables - Just understand the basics.
  • Understand that when designing a network scanning architecture within an organization, the scanners themselves must be whitelisted on any firewalls in order that they can scan devices residing behind those firewalls.
Vulnerabilities
  • OWASP Top 10 - Have some familiarity with and be able to define some of the vulnerabilities on this list (especially XSS, CSRF and SQLi). It may help to understand the different types of XSS (i.e. stored, reflected and DOM-based.)
  • CWE Top 25 - Have some familiarity with the vulnerabilities on this list.
  • NVD - Know what NVD is and the general composition of a CVE/vulnerability.
  • CIA Triad - Understand what Confidentiality, Integrity and Availability mean and how they relate to vulnerabilities.
Vulnerability Management
VM Tools
Risk Analysis
Compliance/Regulatory Frameworks
  • *You need only have a high-level understanding of each of the following frameworks. Be able to describe what they are at a minimum.
  • NIST 800-53 - Be familiar with some of the controls and at a high-level what this document is.
  • NIST CSF - Identify, Protect, Detect, Respond, Recover.
  • PCI - Compliance standards for merchants who accept credit card payments.
  • ISO 27001 - Industry framework detailing security requirements for information security management systems (ISMS)
  • HIPAA - Framework for protecting sensitive patient health information (PHI).
REST APIs & Scripting
  • Python - Popular programming language. This is my recommended language for those getting into infosec.
  • Learn a little Python - I recommend being familiar enough with Python that you could comfortably list it on your resume. This goes a long way in terms of standing out in an interview.
  • REST - REST APIs are built into a lot of different security tools. Knowing what they are and how to use them is an invaluable skill and one that would really help you stand out in an interview.
  • Writing against REST APIs in Python - Some information on how exactly to programmatically use a REST API using Python.
  • Github - I recommend creating a Github account, writing a simple script or two (in Python for example) and making it publicly available on your Github. This will demonstrate to prospective employers your knowledge of scripting. An example of a possible script you could write will be covered in the bootcamp lab.
Regex
  • Regex Tutorial - Regex is used quite a bit in infosec. I recommend you know what it is so you can speak to it in an interview if necessary.
  • Regex Tester(s) - regexr, regex101, regextester are handy tools when testing out Regex queries you have built.

VM Bootcamp Lab

Alright! If you’ve made it this far, you’re comfortable enough with the recommended pre-reqs and are ready to get into the hands-on portion of the bootcamp. The goal of these exercises is to give you real-world, practical experience you can reference on a resume. This should give you the credit and confidence needed to show well in a VM interview. To get started, I’ve provided a list of what you will need to accomplish the bootcamp exercises. At the end of each lab exercise, there will be a series of questions designed to help test your knowledge and understanding.

What You’ll Need
Bootcamp Lab Exercises

Exercise 0: Lab Setup

First, let’s get our lab environment set up so we can proceed through the bootcamp exercises.

  • To start, we need to download a virtualization hypervisor such as VMware, VirtualBox, or Parallels. I will be using VMware Fusion during the exercises.

  • Once the virtualization tool is downloaded and installed, we need to acquire a VM which will host our scanning tool and effectively be the scanner host. For this, I recommend a Linux variant such as Kali Linux or Ubuntu. I will be using Kali (64-bit) throughout the exercises. Offensive Security actually maintains VMware and VirtualBox-specific Kali images which I recommend using.

  • *If you’ve downloaded the pre-configured .vmwarevm from Offensive Security, you can simply double-click the (un-zipped) file and it should open up in VMware with no other setup required.

  • Otherwise, once we have downloaded the VM, we need to unpack, install and perform the initial setup of the VM within our virtualization tool. Here is a guide for installing Kali inside VMware. When asked to name the VM, give it an appropriate name such as “Scanner”. I recommend giving it as much RAM and CPU as you can spare. Scanning can be somewhat resource-intensive so the more power the VM has the better. Keep in mind, you will also need to run a second VM simultaneously so don’t spend all your computer’s resources in one place! The pre-configured .vmwarevm image from Offensive Security has 2GB RAM, and 80GB virtual hard drive, I think this is sufficient for this exercise.

  • To start, have the VM configured in NAT mode (a.k.a. “Share with my Mac” on Mac devices). This is to ensure that the Kali VM is able to download updates and additional tools needed for the bootcamp exercises.

  • To initially get into our Kali instance, use the credentials kali / kali. I recommend immediately changing your kali user password. Here is a guide on how to change a Linux password. Once this is done, run sudo apt-get update and then sudo apt-get upgrade (typing “Y” to confirm the upgrade) to update your system tools to the latest versions. This may take a few minutes to complete.

  • Now that our scanner VM base image is set up and ready to go, we need to register for a Nessus Essentials activation code. Once submitting your registration, you should receive an email from no-reply@tenable.com with your License key and a button-link to download Nessus.

  • Within Kali, open the Nessus download link which will take you to the Nessus downloads page. Find the Nessus-[current.version]-debian[X]_amd64.deb Nessus binary (which is suited for Debian 9, 10 and a variety of Kali Linux versions). Click “I Agree” on the License Agreement and save the file directly to your Kali host.

  • To install Nessus, follow the appropriate guide Tenable has provided. If you are using Kali, use this guide. Navigate to the directory you downloaded the Nessus binary to and run the following command.

sudo dpkg -i Nessus-<version number>-debian6_amd64.deb
  • Once installed, start the Nessus scanner service nessusd by running…
sudo service nessusd start
  • …and then verify it is running using the following command…
sudo service nessusd status
  • Now, you can navigate to https://kali:8834/. You may need to click through a certificate-related security warning within the Kali browser.

  • Once on the Nessus web-server, you should see a wizard for installing a variety of different Nessus versions. Select “Nessus Essentials” and proceed with installing Nessus using this guide. The installation may take some time as it needs to download and compile a large database of Nessus plugins.

  • While Nessus initializes, let’s make sure we have all the other utilities needed for the lab exercises. We’ll need to ensure we have Nmap, tcpdump, hping3, ping and traceroute. Kali Linux comes with all of these tools so no additional setup is needed.

  • The target system we will be scanning with our Nessus-infused Kali machine will be a Metasploitable 2 VM. This VM can be downloaded here. Once downloaded and un-zipped, you can double-click on the Metasploitable.vmx file to have it open directly in VMware.

  • With Metasploitable running, login to the system (defaults creds are msfadmin / msfadmin) and run ifconfig to see what the IP address is. Similarly, get the IP address of your kali instance by running ipconfig locally on that machine. With both IPs in-hand, you can test connectivity between them using the following command. Be sure to test connectivity in both directions! You’ll know if the connection is working if you see “1 packets transmitted, 1 received…” in the output from the command below.

ping -c 1 TARGET_IP

Exercise 0 Questions

Question 0.1

What are the default credentials for Kali and Metasploitable 2? How would you change a user’s password on either of these systems? –> Answer

Question 0.2

How can you update Kali Linux? –> Answer

Question 0.3

What is Network Address Translation? –> Answer

Question 0.4

In what ways can you interact with (e.g. start, stop, restart, check status of) system services (such as nessusd) on Linux? –> Answer

Question 0.5

What is the default number of ICMP requests made by the Linux ping utility (e.g. ping 172.16.84.2)? –> Answer

*

OK! We have now finished the lab setup exercise. Let’s move on to the next step.


Exercise 1: Network Tools Primer

Before we proceed to the scanning sections of the lab, let’s take a quick sojourn into a few basic network utilities and how we would use them for basic VM engineering and troubleshooting.

Network Tools
tcpdump

Tcpdump is an excellent tool for network troubleshooting, something you may find yourself doing quite a bit as a VM analyst/engineer. I won’t cover Tcpdump in-depth but I think this guide by Daniel Miessler is worth reading. I recommend going through at least the first six sections of that writeup (up to “Show Traffic by Protocol”). Let’s go through a quick exercise to demonstrate the power of Tcpdump.

  • On your Kali instance, open two terminal windows side-by-side. In one terminal window, run the following tcpdump command. You will need to run it as root for it to work. Replace METASPLOITABLE_IP with the IP of your Metasploitable 2 instance.
sudo tcpdump -i eth0 -n host METASPLOITABLE_IP
  • …in the second terminal window, run the following hping3 command (we’ll cover hping3 in more detail shortly) What this command does is send a single TCP SYN to port 22 on the Metasploitable system.
sudo hping3 -p 22 -S -c 1 METASPLOITABLE_IP
  • What you’ll see as the immediate output of this command is shown below… Essentially, hping3 is letting us know that it sent the SYN (as denoted by the “-S” in the hping3 command) and received a SYN/ACK (as denoted by the “…flags=SA…”) from the Metasploitable box. Great!
HPING 172.16.84.3 (eth0 172.16.84.3): S set, 40 headers + 0 data bytes
len=46 ip=172.16.84.3 ttl=64 DF id=0 sport=22 flags=SA seq=0 win=5840 rtt=11.8 ms

--- 172.16.84.3 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 11.8/11.8/11.8 ms
  • Moving back to the tcpdump window we see the following output. From this output, we can see the initial SYN (as denoted by the “S” flag in Flags [S]), sent from our Kali instance to the Metasploitable system. Then, we see two records after that, one with the flags “[S.]” and another with the flags “[R]”. The second record is the response SYN/ACK from the SSH service listening on the Metasploitable system. The third record is hping3 gracefully closing out the connection with an RST.
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:44:11.987603 IP 172.16.84.2.1662 > 172.16.84.3.22: Flags [S], seq 2133837101, win 512, length 0
14:44:11.988190 IP 172.16.84.3.22 > 172.16.84.2.1662: Flags [S.], seq 1870315893, ack 2133837102, win 5840, options [mss 1460], length 0
14:44:11.988206 IP 172.16.84.2.1662 > 172.16.84.3.22: Flags [R], seq 2133837102, win 0, length 0

As you can see, there is more than meets the eye when it comes to network traffic and tool output. Tcpdump is a great way for us to see exactly what is happening “under the hood”. I highly encourage you to open up Tcpdump and capture traffic in a variety of different situations - troubleshooting, trying out a new tool, etc… You will learn a lot about how a tool works by inspecting the traffic it generates.

ping

There’s not much to discuss with ping but it is worth mentioning here in the event that you are unfamiliar with what it is and how to use it. ping is a routinely used tool for diagnosing network connections. It sends an ICMP echo request and expects an ICMP echo reply. If you get a reply, this means the target IP is routable (at least using ICMP) and if you don’t get the reply, it may not be routable. The command below demonstrates a ping from my Kali box to the Metasploitable box.

ping -c 1 172.16.84.3   
PING 172.16.84.3 (172.16.84.3) 56(84) bytes of data.
64 bytes from 172.16.84.3: icmp_seq=1 ttl=64 time=0.537 ms

--- 172.16.84.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.537/0.537/0.537/0.000 ms

ping is typically one of the first things I will try when troubleshooting network connectivity. Keep in mind! The absence of an ICMP echo reply though does not necessarily mean a machine is not routable.

hping3

hping3, similar to the classic ping utility is a network tool built for troubleshooting - but really has much more functionality. Using hping3 you can custom-build ICMP, UDP and TCP packets to an exact specification and then fire them off to test firewalls, perform port scanning, fingerprint OS’s and a lot more. hping3 is similar in some ways to Nmap but much lighter-weight which makes it particularly good for quick troubleshooting.

To get started, I recommend reviewing the hping3man page” to get a better idea of its capabilities and the flags required to invoke different functionality.

OK, now let’s get an idea of the listening services on the Metasploitable box. We can do so by running “netstat -tulpn” on the Metasploitable host.

netstat

From the output of the netstat command, we can see there are quite a few listening services. Moving over to the Kali scanner host, we can use the hping3 command below to verify whether services are reachable from our scan host. The command below demonstrates that TCP port 53 on the Metasploitable is responding to SYN packets from our scanner host.

sudo hping3 -S -c 1 -p 53 172.16.84.3   
HPING 172.16.84.3 (eth0 172.16.84.3): S set, 40 headers + 0 data bytes
len=46 ip=172.16.84.3 ttl=64 DF id=0 sport=53 flags=SA seq=0 win=5840 rtt=3.5 ms

--- 172.16.84.3 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 3.5/3.5/3.5 ms

I encourage you to explore other options and functionality of the hping3 tool and think of other ways you might be able to use it for basic scanning, troubleshooting, etc…

traceroute

traceroute (or tracert on Windows) is a simple network utility which tracks the route packets take on an IP network to a destination host. This handy tool is useful when diagnosing routing failures which may exist between a scan host and the target host.

This short exercise will demonstrate the route a network packet takes from your Kali system to your actual router/gateway. First, figure out the IP address of your router. An easy way to do this may be to just run ipconfig/ifconfig, figure out your parent host IP address and then change the fourth octet to a “1”. For example, if your parent host IP is 192.168.1.39, your router’s IP may likely be 192.168.1.1. OK, with your router IP address in-hand, go back to your Kali system and try the following traceroute command. Replace 192.168.1.1 with the IP address of your router.

traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
 1  172.16.84.1 (172.16.84.1)  0.311 ms  0.179 ms  0.110 ms
 2  192.168.1.1 (192.168.1.1)  1.359 ms  1.291 ms  1.241 ms

Here you will see that in order for the packet to reach its destination (the router IP), it had to traverse the IP 172.16.84.1 which is the internal gateway for your virtualized host. On my parent host machine, this is the bridge100 VMware interface (which can be seen by running ifconfig on the parent host).

bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
	options=3<RXCSUM,TXCSUM>
	ether 02:3e:e1:2c:ad:64
	inet 172.16.84.1 netmask 0xffffff00 broadcast 172.16.84.255

If I was unable to reach the router with traceroute, the culprit could very likely be this intermediary router. Don’t stop here though, think of some other things you can trace!

Nmap

Finally, let’s take quick peek at Nmap. Nmap is a very full-featured network exploration, scanning and security auditing tool. It can scan multiple hosts at a time, perform service fingerprinting and enumeration and even run custom-built scripts which can audit the security of target hosts and even perform exploitation of vulnerabilities. It is a powerful tool, but you need only have a limited understanding of it’s feature-set to aid you in every-day VM engineering/analyst responsibilities.

For this exercise, let’s just do a quick full-port-scan of the Metasploitable host from our Kali scan host. As usual, I first recommend reviewing the features and flags of Nmap by running “man Nmap”. Now, let’s run a simple, plain Nmap scan of the Metasploitable host using the command shown below.

sudo nmap 172.16.84.3
Starting Nmap 7.91 ( https://nmap.org ) at 2021-04-21 09:45 EDT
Nmap scan report for 172.16.84.3
Host is up (0.0027s latency).
Not shown: 977 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
23/tcp   open  telnet
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
512/tcp  open  exec
513/tcp  open  login
514/tcp  open  shell
1099/tcp open  rmiregistry
1524/tcp open  ingreslock
2049/tcp open  nfs
2121/tcp open  ccproxy-ftp
3306/tcp open  mysql
5432/tcp open  postgresql
5900/tcp open  vnc
6000/tcp open  X11
6667/tcp open  irc
8009/tcp open  ajp13
8180/tcp open  unknown
MAC Address: 00:0C:29:4B:79:E4 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds

From this scan, we can see there is a bevy of listening services. COOL! As a VM analyst you may use this to quickly diagnose whether a port is open. This is quicker than running a network scan from a traditional vulnerability scanner.

Exercise 1 Questions

Question 1.1

What protocol does Kali use when you run traceroute against your Metasploitable host? (TIP: Try using tcpdump to investigate.) –> Answer

Question 1.2

What port does ping use? –> Answer

Question 1.3

How can you send a UDP packet to port 69 (of the Metasploitable box) using hping3? What is returned from Metasploitable as a result of this packet? Why is this the response? –> Answer

Question 1.4

When using traceroute targeting your home router, what is the TTL of the first packet sent by traceroute? What is returned in response to this packet and from what device? –> Answer

Question 1.5

By default what ports does Nmap scan? How can you configure Nmap to scan all ports? –> Answer


Exercise 2: Discovery Scanning

Alright, so we have our lab setup and we have some familiarity with basic network utilties. Let’s begin the network scanning portion of the lab with the typical Step 1, Discovery Scanning. Typically, prior to performing deeper vulnerability scans you want to first gather an inventory of in-scope devices on your target network. For the lab, we are focusing most of our targeted efforts at the Metasploitable box, but for this exercise, we can (if you would like) expand the scope of our scanning to include other devices on your home network. Follow the steps below to get started…

  • On your Kali machine, log into the Nessus web interface. You can do this by opening up Firefox in Kali and navigating to the URL https://127.0.0.1:8834/.
  • Create a new scan by clicking the “New Scan” button in the top right corner of the Nessus interface.
  • Click the “Host Discovery” section of the “Scan Templates” menu.
  • Within the scan creation wizard, give the scan an appropriate name (such as “Discovery Scan”).
  • Populate the “Targets” section of the scan wizard with the IPs you wish to scan. For this, at a minimum, input the IP of your Metasploitable host. Optionally, you can choose to put in the class-C subnet that your home network uses (likely something similar to 192.168.1.0/24).
  • Click the “Save” button at the bottom of the scan creation wizard.
  • Click the “Play” button at the right hand side of the scan record on the main Nessus interface. This will run the scan.
  • Give the scan a few minutes to complete.
  • Once the scan completes, click anywhere on the record to open up the scan results.
  • Within this view, you can see the IPs found, and any vulnerabilities/plugins that were identified during the scan.

Discovery Scan Results

Congrats! You just performed a discovery scan with Nessus! One important thing to keep in mind with the free version of Nessus is that though there is no limit on the devices you can discover with Nessus, you will only be able to perform vulnerability scanning against a max of 16 target systems.

Exercise 2 Questions

Question 2.1

By default, what “ping methods” are used by a Nessus host discovery scan. –> Answer

Question 2.2

What are the two Nessus plugins triggered by the Nessus host discovery scan? –> Answer

Question 2.3

Does the host discovery scan perform “Credentialed checks”? How can you confirm this within Nessus? –> Answer

Question 2.4

What ping method was successful in identifying the live Metasploitable host? –> Answer


Exercise 3: Vulnerability Scanning

OK, now that we’ve discovered our target system(s), we now move into the actual vulnerability scanning portion of our VM lifecycle. Tools like Nessus are purpose built with an expansive set of detection plugins to find, classify and even risk-rank vulnerabilities. Network scanning tools have a number of different methods for detecting vulnerabilities, two of these methods are credentialed and uncredentialed scanning. Ideally, where possible, you want all scans to be credentialed. Credentialed scans have higher-fidelity results (less false-positives) and they also find more issues overall. With that said, you won’t always have credentials for a target so you may have to settle for an uncredentialed scan. These two types of scans also function a little differently. Credentialed scans will actually “physically” login to a target system and enumerate vulnerabilities by running commands directly on the system. Uncredentialed scans on the other hand, are unable to login to the target system and must instead rely on anonymous/remote fingerprinting mechanisms to detect potential vulnerabilities. Let’s run through a pair of exercises for configuring and running an uncredentialed and credentialed scan respectively.

Uncredentialed Scan
  • Create a new scan by clicking the “New Scan” button in the top right corner of the Nessus interface.
  • Click the “Basic Network Scan” section of the “Scan Templates” menu.
  • Within the scan creation wizard, give the scan an appropriate name (such as “Uncredentialed Scan”).
  • Populate the “Targets” section of the scan wizard with the IPs you wish to scan. For this, input the IP of your Metasploitable host.
  • Click the “Save” button at the bottom of the scan creation wizard.
  • Click the “Play” button at the right hand side of the scan record on the main Nessus interface. This will run the scan.
  • Give the scan a few minutes to complete. It will take a little longer than the host discovery scan.
  • Once the scan completes, click anywhere on the record to open up the scan results.
  • Within this view, click on the “Vulnerabilities” tab and you will be able to view all vulnerabilities/plugins that were identified during the scan.

As you can see, the uncredentialed scan yields A LOT more plugins being returned and plenty of vulnerabilities found. (Remember, there were only two plugins found during the discovery scan.)

uncred-results

Credentialed Scan
  • Create a new scan by clicking the “New Scan” button in the top right corner of the Nessus interface.
  • Click the “Basic Network Scan” section of the “Scan Templates” menu.
  • Within the scan creation wizard, give the scan an appropriate name (such as “Credentialed Scan”).
  • Populate the “Targets” section of the scan wizard with the IPs you wish to scan. For this, input the IP of your Metasploitable host.
  • Click on the “Credentials” tab of the scan creation wizard and then click “SSH”.
  • In the right-hand pane change the “Authentication method” drop-down to “password” and then set the “Username” and “Password” text-fields each to msfadmin.
  • Click the “Save” button at the bottom of the scan creation wizard.
  • Click the “Play” button at the right hand side of the scan record on the main Nessus interface. This will run the scan.
  • Give the scan a few minutes to complete.
  • Once the scan completes, click anywhere on the record to open up the scan results.
  • Within this view, click on the “Vulnerabilities” tab and you will be able to view all vulnerabilities/plugins that were identified during the scan.

As you can see from the image below, and as-predicted (compared to the screenshot of the uncredentialed scan results), there are far more findings with the credentialed scan.

cred-results

Well done! We should now have plenty of vulnerability data to work with for the rest of the exercises in the lab.

Exercise 3 Questions

Question 3.1

What different severities does Nessus report for vulnerabilities? –> Answer

Question 3.2

Given just the uncredentialed scan, what is the most severe vulnerability according to Nessus? Why has Nessus given this vulnerability this rating? –> Answer

Question 3.3

Now, according to the credentialed scan results, what is the most severe vulnerability according to Nessus? Why does this vulnerability have a higher VPR severity score than the previously identified vulnerability? –> Answer

Question 3.4

Using what plugin(s) can we validate that the credentialed scan was successful in logging into the target system. –> Answer

Question 3.5

The credentialed scan was successful in logging into the target Metasploitable system, but had some issue performing everything it was trying to accomplish. What happened here? –> Answer


Exercise 4: Scanning Enrichment

Setting up vulnerability scans is an important first step for a VM professional, but you shouldn’t stop there. There are always improvements and advancements that can be made within scanning operations or the VM program as a whole. These improvements can help alleviate time spent on manual tasks, reduce MTTR, improve the fidelity of reports or even increase the overall effectiveness of your scans. The challenge in VM is that of scale. How can we scan a lot of systems and triage/resolve an even greater number of vulnerability findings with limited resources? The answer is usually coupling automation with robust prioritization. Below are just a few quick exercises that demonstrate some improvements we can make just within Nessus itself. Keep in mind, when working in an enterprise VM program you will have tools that have VM enrichment capabilities far beyond what Nessus Essentials can offer.

For each of the sub-exercises below, first follow these steps.

  • Open your credentialed scan results by clicking on the record on the Nessus main page.
  • Click on the “Configure” button to edit the scan configuration.

Automation & Scheduling

  • Click on the “Schedule” side-tab under the “Basic” section within the configuration wizard.
  • Toggle “Enabled”. Here you can set a time for the scan to begin as well as an interval for that scan to run on.

Scheduled scans are ideal as you may not want to scan certain devices during business hours. Automated, recurring scans mean one less thing a VM professional has to perform manually. Combined, scheduled + recurring scans are an obvious advancement to be made to routine VM operations.

Notifications & Filters

  • Click on the “Notifications” side-tab under the “Basic” section within the configuration wizard.
  • In the “Email Recipient(s)” field you can provide email addresses for those who need to receive alerts on specific vulnerabilities.
  • In the “Result Filters” area, we can add filters such that notifications are sent only when certain criteria are met.
  • *For example, we may be interested in seeing alerts on all “Critical” risk vulnerabilities that are known to have an exploit available. We can create these two filters using the following filter-sets.
    • Match All of the following:
    • Exploit Available is equal to true
    • Severity is equal to Critical

Most vulnerabilities will likely be addressed through the standard patching process which is governed by SLAs created in coordination between the VM team and the respective IT organization. There are however, some vulnerabilities that may require more immediate analysis and mitigation. Using the notification/filter functionality, we can create alerts which will notify us the instant a vulnerability which meets this urgent criteria is discovered. At which point, we can immediately being to address that finding.

Reporting

  • Click on the “REPORT” section within the “Settings” tab.
  • Uncheck the box for “Show missing patches that have been superseded”

Toggling this setting will help us remove false-positives from our Nessus reports. This is somewhat self-explanatory. Basically, if a system has a patch which supersedes a missing patch, we don’t want any plugins to fire for the superseded patch. This will unnecessarily junk up the report with vulnerabilities that are not actually there.

Advanced

  • Click on the “ADVANCED” section within the “Settings” tab.
  • Change the “Scan Type” drop-down to “Custom”.
  • Click on the “General” section below the “Advanced” pane on the left-hand side.
  • Uncheck the “Enable safe checks” box within the “General Settings” pane.

This setting should only be disabled under great caution. Disabling “Enable safe checks” will mean the scan can use certain plugins that are considered highly invasive. This includes destructive attacks, denial of service (DoS) and other kinds of floods. Though this scan can have negative side-effects on a target system, it also adds additional tests that weren’t otherwise being run. In this way, more potential issues can be identified.

Exercise 4 Questions

Question 4.1

Vulnerability scans can by nature be somewhat network-intensive. In the event that a host being actively scanned becomes unresponsive, something like Nessus could DoS the system even further. What can be configured within the scan to prevent this from happening? –> Answer

Question 4.2

What is the default user-agent for Nessus web application scanning. –> Answer

Question 4.3

What type of port scanning does Nessus perform by default? –> Answer


Exercise 5: Reviewing/Analyzing Results

Now that we have our vulnerability scans completed, it’s time to review the results and analyze the findings. Metasploitable is a “purposefully-vulnerable” machine and as such, is rife with issues. Though you may not encounter a system that is this bad in the real world, you certainly could find yourself reviewing a box that has many vulnerabilities on it. So let’s take this system, how should we go about analyzing these vulnerabilities? Below is one sequence that could occur…

  • OK, so there are a lot of vulnerabilities. We need to start filtering down to just the ones that are of highest importance.
  • Are there any vulnerabilities that are of imminent danger of being exploited? If so, are any of these vulnerabilities mitigated in any way due to other controls within the environment?
  • We can add a filter to see only exploitable vulnerabilities. We are now down to 12 vulnerabilities (this is 12 groups of vulnerabilities as some as you can see, are bundled).

12 vulns

  • That’s still a lot of vulnerabilities to take on at one time. Let’s filter this down a little bit more. We can do so by adding some additional filters. Let’s add a filter for only Critical severity issues as well as a filter for only plugins which are in the “Plugin Family”, Gain a shell remotely. These filters are shown in the image below…

Filters

  • After these filters have been applied, we have only a few remaining issues (5 total).

Final vulns

As a VM analyst who is reviewing these results, I would likely filter down to these findings and proceed with prioritization, reporting and remediation. For each of these findings, I would want to open them up, understand the plugin logic and perform cursory checks to determine whether they we’re false-positives or not. With credentialed scans though, hoping a finding is a false-positive is often just wishful-thinking. I encourage you to open each of these and to the best of your ability, analyze them to determine the validity of the finding. Specifically, is the vulnerability really exploitable?

(COMING SOON: Steps for reproducing manual validation of a vulnerability. Wasn’t ready in the 1.0 release.)

Exercise 5 Questions

Question 5.1

What is the CVSS vector for the Shellshock vulnerability? What does “AC:L” mean within that CVSS vector? –> Answer

Question 5.2

How did Nessus determine that Metasploitable was vulnerable to Shellshock? –> Answer

Question 5.3

What is the highest risk finding? –> Answer

Question 5.4

According to Nessus, what action (mitigation/patch) should be taken to reduce the most risk on the system? –> Answer


Exercise 6: Reporting

Once we have performed analysis on the findings, we need to deliver something to the appropriate place in order that the finding be mitigated. What I mean by this is that there are stakeholders who need to receive reports which detail these findings so that they can address them. Nessus reports are one way to do this. Creating a report is easy. Inside a scan result, we can click on the “Report” drop-down in the top right which reveals a number of different report formats available (.pdf, .html and .csv). We can click on any of these to generate that report. Try creating a “Custom”, and an “Executive Summary” report and see what is contained within each.

report

The image above illustrates the wealth of settings available when creating a “Custom” report with Nessus. I recommend you check all boxes, generate the report and then review that report to see what each of those boxes adds to the final product.

Exercise 6 Questions

Question 6.1

If we’re interested in generating a report for just Critical vulnerabilites. How can this be done? –> Answer

Question 6.2

Who all might be interested in receiving a vulnerability report from Nessus? (HINT: Think individual groups, stakeholders or other personnel within an organization.) –> Answer


Exercise 7: Scripting & Automation

To take Nessus, and really VM, to the next level, we need to step up our game in terms of automation. The best way to do that is by leveraging the Nessus API. The API documentation is available locally within your Nessus instance at “https://127.0.0.1:8834/api#/overview”. The API represents boundless opportunity for VM analysts/engineers to automate all manner of operational tasks, thus reducing overhead. I recommend those interested in not only VM but infosec at large, to become very familiar with APIs such as this and learn to write against them programmatically using a scripting language such as Python. To aid you in this journey there are frameworks, built by others in the community that can help you interact with these APIs. For the Nessus API, there is PyNessus, a Nessus REST API client which is fully Apache 2 licensed and built specifically for security auditors, pentesters and VM analysts.

As I mentioned, there are countless potential automation ideas that one could think of. One possible project would be to create a script that could kick off a scan against a target system. The use-case for this project would be as follows… As a VM analyst you may be asked by a system owner to re-scan a system following patch application. The system owner is interested in whether the patch has been successfully applied and thus the vulnerability is mitigated. Rather than wait for the next scan window, the system owner would like to know as soon as possible whether the vulnerability has been eradicated. Typically, a VM analyst would kick off a targeted scan of this system manually. But instead, what if you wrote a script that took one argument (a target IP) and auto-ran a scan of that system.

This bootcamp is not designed to be a course in Python and as such, will not cover in-depth how to create the script I detailed above. I recommend researching how best to programmatically interact with REST APIs. One good resource would be Python & APIs: A Winning Combo for Reading Public Data. With that said, I would like to provide this script myself so others may have an example to build off of and reference as they create other useful scripts of their own.

Example script is currently being developed. Stay tuned!

Finally, I’d like to list a few other potential script ideas that someone could work on if they were interested!

  • Building off the previous idea - a script that could auto-run a scan against a provided target but also take as input a Plugin ID and return true or false if that plugin is found within the results of that scan. Ultimately, the system owner is interested if a plugin has “fallen off” the report so rather than go into the scan results and see manually, why not have the result returned programmatically.
  • A script that can take a list of plugins as input and return all the hosts that have one or more of those plugins. In the event of a large patch release by a vendor, we may want to quickly see all the hosts affected by a set of plugins.
  • A script that will take an IP as input and return the last time it was scanned, how long the scan was and whether it was successfully scanned with credentials. This is a common question in the VM world. Take this scenario as an example - there may be some issue (system degradation) with a system and the owner is wondering if the scan itself is the culprit. The system owner may provide logs indicating some malfunction during a certain time and would like to blame the scan for the degradation. You may be able to quickly diagnose this using this script which will tell you when the scan was last performed. If the scan timing overlaps with when the system was experiencing a degraded state, it may very well be the scanners fault. Otherwise, we can rule out the scanner as being the cause. Alternatively, you may find that the results of the scan look a little off, and you’d like to quickly troubleshoot whether the last scan was with credentials. As we know, non-credentialed scans can introduce false-positives into the scan results.

Thanks for taking the time to work your way through these exercises and happy scriptin’!


Lab Exercise Answers

Exercise 0 Answers

Answer 0.1

Kali credentials: kali / kali

Metasploitable 2 credentials: msfadmin / msfadmin

To change the password for the user you are logged in as, simply type passwd and go through the prompts. To change the password of another user, type sudo passwd OTHERACCOUNTNAME. This guide explains it very succintly.

Back to Question

Answer 0.2
sudo apt-get update && sudo apt-get upgrade

Back to Question

Answer 0.3

Network Address Translation, or “NAT”, is where local IP addresses are mapped to a single public IP address (and vice-versa) in order to provide Internet access to internally-situated hosts.

Back to Question

Answer 0.4

There are a number of different methods and utilities for interacting with system services on Linux. Some of these include the service command, []/etc/init.d/service](https://www.geeksforgeeks.org/what-is-init-d-in-linux-service-management/) and systemctl.

Back to Question

Answer 0.5

Somewhat of a trick question. Linux will endlessly send ping requests until it is stopped.

Back to Question

Exercise 1 Answers

Answer 1.1

UDP! You can determine this by running the tcpdump command shown below…

tcpdump -i eth0 -n host [METASPLOITABLE_IP]

…then running traceroute against your Metasploitable host. In the tcpdump output, you will see a number of UDP datagrams being sent to a variety of different ports (shown below). Interesting!

listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:13:55.430855 IP 172.16.84.2.33737 > 172.16.84.3.33434: UDP, length 32
11:13:55.430945 IP 172.16.84.2.57603 > 172.16.84.3.33435: UDP, length 32
11:13:55.430996 IP 172.16.84.2.57344 > 172.16.84.3.33436: UDP, length 32
11:13:55.431062 IP 172.16.84.2.44554 > 172.16.84.3.33437: UDP, length 32
11:13:55.431127 IP 172.16.84.2.43253 > 172.16.84.3.33438: UDP, length 32
11:13:55.431181 IP 172.16.84.2.39702 > 172.16.84.3.33439: UDP, length 32
11:13:55.431235 IP 172.16.84.2.49692 > 172.16.84.3.33440: UDP, length 32
11:13:55.431288 IP 172.16.84.2.48673 > 172.16.84.3.33441: UDP, length 32
11:13:55.431342 IP 172.16.84.2.37153 > 172.16.84.3.33442: UDP, length 32
11:13:55.431398 IP 172.16.84.2.47292 > 172.16.84.3.33443: UDP, length 32
11:13:55.431451 IP 172.16.84.2.55651 > 172.16.84.3.33444: UDP, length 32
11:13:55.431505 IP 172.16.84.2.34029 > 172.16.84.3.33445: UDP, length 32
11:13:55.431558 IP 172.16.84.2.57045 > 172.16.84.3.33446: UDP, length 32
11:13:55.431611 IP 172.16.84.2.40330 > 172.16.84.3.33447: UDP, length 32
11:13:55.431664 IP 172.16.84.2.34592 > 172.16.84.3.33448: UDP, length 32
11:13:55.431738 IP 172.16.84.2.50855 > 172.16.84.3.33449: UDP, length 32
11:13:55.433781 IP 172.16.84.3 > 172.16.84.2: ICMP 172.16.84.3 udp port 33437 unreachable, length 68
11:13:55.435107 IP 172.16.84.3 > 172.16.84.2: ICMP 172.16.84.3 udp port 33438 unreachable, length 68
11:13:55.435107 IP 172.16.84.3 > 172.16.84.2: ICMP 172.16.84.3 udp port 33439 unreachable, length 68

Back to Question

Answer 1.2

Another trick question! ping uses a layer 3 protocol “ICMP” which is neither TCP nor UDP (which are layer 4 protocols) and does not use ports. This can be seen by running a tcpdump capture at the same time as the ping and seeing no ports included. The tcpdump capture shown below shows no ports after the IP addresses.

listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:21:07.451104 IP 172.16.84.2 > 172.16.84.3: ICMP echo request, id 50276, seq 1, length 64
11:21:07.451781 IP 172.16.84.3 > 172.16.84.2: ICMP echo reply, id 50276, seq 1, length 64

Back to Question

Answer 1.3

The “-2” crafts a UDP datagram and the “-p 69” will send it to port 69.

hping3 -2 -p 69 METASPLOITABLE_IP -c 1

As you can see in the tcpdump output shown below, nothing is returned from the Metasploitable box.

listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:30:24.006909 IP 172.16.84.2.2758 > 172.16.84.3.tftp: TFTP, length 0 [|tftp]
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel

Nothing is returned because UDP is connectionless and therefore will not return responses for UDP services that are listening and receive data.

Back to Question

Answer 1.4

The TTL of the first packet sent is 1. Determine this by running the tcpdump packet capture shown below while executing the traceroute. In this ouput you can see it says “…ttl 1…” If you’d like to understand why the TTL is set this way, I recommend researching host traceroute works.

sudo tcpdump -i eth0 -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:33:05.006272 IP (tos 0x0, ttl 1, id 19407, offset 0, flags [none], proto UDP (17), length 60)

Further down in the packet capture, you will see a record with the same “id” as that first UDP packet described above. This is the ICMP packet returned from the “next-hop” router which is in fact your VMware bridge router.

172.16.84.1 > 172.16.84.2: ICMP time exceeded in-transit, length 36
        IP (tos 0x0, ttl 1, id 19407, offset 0, flags [none], proto UDP (17), length 60)

Back to Question

Answer 1.5

By default, Nmap only scans the top 1000 ports (this list is available on your Kali box at /usr/share/nmap/nmap-services). You can scan all ports using the command below. Essentially, you are just specifying all ports (using “-p0-65535”) in the command.

nmap -p0-65535 METASPLOITABLE_IP

Back to Question

Exercise 2 Answers

Answer 2.1

TCP, ARP, ICMP. This is determined by going to the “DISCOVERY” section within the “Settings” tab of the host discovery scan creation wizard. Within this pane you will see TCP, ARP and ICMP listed under “Ping hosts using:”

Back to Question

Answer 2.2

“Nessus Scan Information”, plugin 19506 and “Ping the remote host”, plugin 10180.

Back to Question

Answer 2.3

In the output of the 19506 plugin, there is a line which reads “Credentialed checks : no”.

Back to Question

Answer 2.4

Though it may vary, the likely answer is ARP. The successful method can be determined by reviewing the 10180 plugin’s output as shown below.

The remote host is up
The host replied to an ARP who-is query.
Hardware address : 00:0c:29:4b:79:e4

Back to Question

Exercise 3 Answers

Answer 3.1

Nessus uses a 5-tier severity scale - Critical, High, Medium, Low, Informational. Tenable has also recently introduced a new risk-scoring methodology known as VPR.

Back to Question

Answer 3.2

By opening up the uncredentialed scan results and clicking on the “VPR Top Threats” tab, you will see just one Critical vulnerability, “Apache Tomcat AJP Connector Request Injection (Ghostcat)” with a VPR score of 9.6. It’s been given this rating despite it’s CVSSv3 Impact Score being only a 5.9. This is due to the readily available exploit code and high Threat Intensity.

Back to Question

Answer 3.3

By opening up the credentialed scan results and clicking on the “VPR Top Threats” tab, you will see several Critical severity issues. The top issue is “Bash Remote Code Execution”, with a VPR severity score of 9.8. This is scored higher than the previously identified hihg-risk issue in the uncredentialed scan due to its Threat Intensity being “Very High” as opposed to just “High”. This intensity is calculated based on the number and frequency of recently observed threat events (by Tenable themselves presumably).

Back to Question

Answer 3.4

There are quite a few different ways to troubleshoot/validate credentialed scans. A few such options include the following plugins…

  • Plugin 19506 can be used by looking at the plugin output - specifically where it says “Credentialed checks : yes, as ‘msfadmin’ via ssh”.
  • The presence of plugin 117887, “Local Checks Enabled” is a good sign that the scan was successful in logging in and performing local checks.
  • Plugin 141118, “Target Credential Status by Authentication Protocol - Valid Credentials Provided” very explicitly claims that “valid credentials” have been provided. This would be another sure-fire way to claim that the scan was successfully performed with credentials.

Back to Question

Answer 3.5

The scan was performed with the credentials msfadmin / msfadmin. Though these are valid credentials for the Metasploitable system, the user msfadmin does not sufficient privileges on the system for all of Nessus’ checks. In fact, plugin 110385, “Target Credential Issues by Authentication Protocol - Insufficient Privilege” tells us this exact thing.

Back to Question

Exercise 4 Answers

Answer 4.1

There is a toggle in the “Advanced” settings within the scan configuration wizard which can “Stop scanning hosts that become unresponsive during scan”. Toggling this on can help with systems that are more sensitive in nature or that are experiencing responsiveness issues.

Back to Question

Answer 4.2

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0). You can find this by going to the scan configuraiton wizard settings, going to “Assessment –> Web Applications”, toggling “Scan web applications” and then looking at the default value in the “Use a customer User-Agent” field.

Back to Question

Answer 4.3

SYN. You can find this by going to the scan configuration wizard settings, going to “Discovery –> Port Scanning”, scrolling down to the “Network Port Scanners” section and then seeing that only the “SYN” check-box is checked (TCP and UDP are not checked by default).

Back to Question

Exercise 5 Answers

Answer 5.1

The CVSS v2.0 Vector for the Shellshock vulnerability is AV:N/AC:L/Au:N/C:C/I:C/A:C. “AC:L” means that the “Access Complexity” for successfully exploiting this vulnerability is Low. In other words, exploiting this issue is trivial, thus its Critical severity rating.

Back to Question

Answer 5.2

In this case, Nessus actually physically exploited the vulnerability. It did so as can be seen in the plugin output below…

Nessus was able to set the TERM environment variable used in an SSH
connection to :

() { :;}; /usr/bin/id > /tmp/nessus.1619029506

Back to Question

Answer 5.3

This is somewhat of a subjective question, but in my mind, the highest risk issue is the “Bind Shell Backdoor Detection” finding. This is not only immediately exploitable but also evidence of previous/current system compromise. In other words, an attacker is likely already on the system! In fact, Nessus was even able to exploit this vulnerability as shown in the output below.

Nessus was able to execute the command "id" using the
following request :

This produced the following truncated output (limited to 10 lines) :
------------------------------ snip ------------------------------
root@metasploitable:/# uid=0(root) gid=0(root) groups=0(root)
root@metasploitable:/#

Back to Question

Answer 5.4

By going to the “Remediations” tab within the credentialed scan results, we can see a list of “Actions”. Each action represents a patch or other mitigation that can be applied and how many vulns that patch will fix. The top “Action” is “Ubuntu 8.04 LTS : linux vulnerabilities (USN-1105-1): Update the affected packages.” which according to Nessus will fix 234 vulnerabilities. Though this may in fact reduce a lot of risk on the system, it still wouldn’t be the highest thing I would prioritize. This is why manual analysis is so important as opposed to relying on what Nessus tells you via it’s automated semi-prioritization methodology.

Back to Question

Exercise 6 Answers

Answer 6.1

A “Filter” can be created in the “Vulnerabilities” tab first. This filter should have the criteria “Severity is equal to Critical”. Once this filter has been applied, any report that is generated will just be for the filtered vulnerabilities.

Back to Question

Answer 6.2

There are a number of different parties that may be interested in receiving different kinds of reports from Nessus. Some of these groups are listed below.

  • IT Leadership may be interested in a report which has a high level breakdown of how many vulnerabilities are present within the organization’s overall environment.
  • VM Analysts may be interested in a report that has particularly high-risk vulnerabilities in it.
  • System Administrators may be interested only in vulnerabilities that affect systems they own. They may also be interested only in vulnerabilities which match particular SLA criteria (meaning which vulnerabilities do they need to address soon.)
  • IT Managers - May be interested in vulnerabilities which affect all the systems within their department. They may also just be interested in high level number of vulnerabilities.

Back to Question


Scenario-Based Exercises

At this point, you’ve learned the pre-requisite knowledge recommended to succeed in a VM role and you’ve acquired real hands-on experience doing VM tasks with Nessus. This section is the culmination of all the work you’ve put in throughout this bootcamp. Below is a progressive series of six exercises, each mapping to a different stage of the VM lifecycle. They are designed to test your knowledge and evaluate your thought process as it relates to real-world VM scenarios. They are all open-ended such that there are no “answers”, rather they are more abstract thought exercises. I recommend you go through each, writing up a quick paragraph or two on how you would solve each of the prompts. Optionally, I invite you to contact me (or start a discussion on the Discord) with your writeups and we can discuss your answers. At that time, I can give you my opinions and feedback on your answers. Again, there is not necessarily a single right answer to any of these prompts. You are also welcome to contact me if there are any other questions about these scenarios. With all that said, let’s introduce the scenario-based exercises. NOTE: These exercises require that you have completed all the exercises within the bootcamp!

Scenario 1: IDENTIFY

An automated Nessus scan identified the Ghostcat vulnerability (plugin 134862) on a host. An automated report was sent to the system owner detailing the finding. The system owner has contacted the VM team (you) and is claiming the finding is a false-positive. How would you go about addressing this claim?

Scenario 2: CLASSIFY

The CISO has asked the VM team (you) to provide a list of the top 10 highest-risk vulnerabilities present within the organization’s environment. Assume Metasploitable is the entirety of the environment. What would be the top 10 vulnerabilities and how did you come to this determination?

Scenario 3: ANALYZE

Upon receiving the scan report of the Metasploitable system, IT leadership has asked that the VM team (you) put together a risk assessment for the “NFS Exported Share Information Disclosure” (plugin 11356) finding. This finding has been identified on other systems within the network and leadership wants a more thorough understanding of the risk. Create this risk assessment, come up with a final risk determination and think of any additional questions you may need answered to accurately come up with this designation.

Scenario 4: PRIORITIZE

In Scenario 2, we came up with a list of the top 10 highest risk vulnerabilities. We now need to prioritize the remediation of all findings within the Metasploitable scan report. How would you suggest prioritizing these fixes? Would you recommend fixing them in the order you specified earlier? If so or if not, explain why. I would recommend making some assumptions on a few things…

  • What data is stored/processed by the Metasploitable system (in theory).
  • What resources are available for patching or implementing other defensive measures?
  • etc…
Scenario 5: REPORT

Nessus Essentials has limited reporting options. Given you had more flexibility in how you create reports and what content exactly they could contain, in what formats and with what content would you suggest for reports being sent to the following groups…

  • IT Leadership
  • Company Executives
  • IT System Owners
  • VM Staff
Scenario 6: REMEDIATE/MITIGATE

The Metasploitable system is overrun with vulnerabilities. Swift action must be taken to mitigate risk. What are the first 3 things you would recommend for mitigating this risk? HINT: Think beyond patches and consider alternative approaches to risk mitigation.


How to Find a VM Job

Congrats! Presumably, you are through the bootcamp and are now faced with the challenge of actually finding and applying to relevant positions within VM that you could be qualified for. Below is a quick list of tips for hunting down applicable positions.

  • Expand. Your. Search. Look and apply everywhere. Linkedin, Monster, SimplyHired, Reddit, Craigslist, Dice, Indeed, Company career pages, Glassdoor, etc… There may be a lot of overlap but widening the set of sources you use is a good start. I’ll also add that volume of applications can be your friend. Yes, it is definitely work, and yes, it is frustrating to be turned down (again and again), but perseverance is key and applying to a lot of places will statistically up the probability you get an opportunity.
  • Don’t be afraid to apply. What I mean is - yes, you want to avoid applying to places that you are completely unqualified for but don’t be too scared off by job reqs that ask for N years of experience. If it sounds like you can do what is being asked of you in the job req, or you at least have some or most of the qualifications, you need not worry that you don’t check every box.
  • Don’t embellish or lie on your resume. You don’t need to. This is an entry-level job and they don’t expect you to know everything. If you’ve never used a tool, don’t list it. If you’ve used it once or twice though, put it on your resume! Everything on your resume is fair game and you should be ready to, at a minimum, explain what a tool is, what it does and in what capacity you have used it.
  • “Vulnerability” is a good search term. A lot of VM jobs (unsurprisingly I guess) have titles which include “Vulnerability” in it in some fashion (e.g. “Senior Engineer, Vulnerability Management”, “Vulnerability Management Analyst”, “Vulnerability Engineer”, “Vulnerability Management Security Engineer - Security Operations”, etc…) There is no standard title for VM, these are job titles I pulled off of a job board today! Play around with these search terms to cast the best possible net.
  • Not every company has positions that are pure VM. In many cases, VM responsibilities fall within the “SIOC” or engineering teams and as such, these jobs require experience or skills far beyond what is covered in this bootcamp. I would recommend reading the job req and trying to determine what percentage of the daily responsibilities involve VM versus other engineering/SIOC-type-work. You may still be eligible for that position or the hiring manager may be willing to bring you in for your VM experience alone, as long as you are willing to learn the other facets of the role (and you should be eager to learn as much as possible!)

I will add additional tips here as I think of them. Now, let’s talk about the interview


VM Interview

So you’ve gone through the bootcamp, applied to some VM positions and now have an interview scheduled. Well done! It’s time to put it all together and knock it outta the park. Below, I have a few quick tips on your interview as well as a series of common interview questions (and some possible answers where appropriate).

Interview Tips
  • Don’t be afraid to admit you don’t know something. If you’re asked a question you don’t know, state that you don’t know or are not sure, but always offer to explain your thought process for answering the question. Interviewers want to know how you think moreso than necessarily if you have the “right” answer. In many cases there may be no right answer, so always offer up your thoughts. Try to keep them brief and to the point though - rambling on when you are very unsure can certainly be a turn-off for an interviewr.
  • Be enthusiastic. This is true of any interview but particularly potent for entry-level / junior interviews. Those in charge of hiring understand that junior applicants may not have any real experience (you do though!), and it can be really hard to truly gauge someones technical acumen. What’s not hard however, is to see if someone is truly interested in the role and passionate about infosec.
  • Have plenty of questions. Be ready to ask a lot of questions, this if nothing else will show interest in the role. Some example questions are…
    • What tools does the team use?
    • What is the makeup of the team now?
    • What are the biggest challenges that the team currently faces?
    • Where would you like the program to be in 1 year? What about 2 years?
    • What does success look like to you for someone coming into this role?
  • If you don’t know something or are otherwise stumped by a question, always return to being very interested and excited about learning more on that topic. Where it applies, you can even mention things you are learning currently that are related to that topic.
  • Be ready to explain the things you do at home / in-your-free-time to stay up-to-date on all things infosec. Podcasts, RSS feeds, Reddit, Twitter, infosec blogs, building a homelab, etc…
  • Be yourself (within reason).
Interview Questions
  • Q: What port is HTTPS typically on? · A: 443 but it is also commonly found on port 8443.
  • Q: What are some vulnerabilities you are familiar with? · A: Reference the Vulnerabilties section for some good ideas.
  • Q: What is the difference between TCP and UDP? · A: Reference the Networking section for some good ideas. But remember TCP is connection-oriented while UDP is not.
  • Q: Explain at a high-level how HTTPS works. · A: Check this out and be able to describe HTTPS at a high-level.
  • Q: How does traceroute work? · A: This guide does a good job explaining the basics.
  • Q: What are some interesting logs on Linux/Windows and where are they stored? · A: Linux logs and Windows logs.
  • Q: What are the different types of XSS? · A: Reflected, Stored and DOM-based. Check this guide out.

I’ll add additional tips and interview questions as I think of them. If you have any you think would be good to add, just let me know!


Help & Outro

For any questions, suggestions, feedback, corrections or anything else related to the VM Bootcamp, feel free to contact me anytime. For in-depth discussions on the scenario-based questions or anything else, I encourage you to join the Discord and we can chat!

If you’ve completed the bootcamp in it’s entirety, I’d like to first thank you for reading and I sincerely hope you found the content useful and somewhat mentally stimulating. Second, CONGRATS! - hopefully this can be the first (or at least one) of many steps you will take in a successful infosec career. Feel free to connect with me on Linkedin and if I can, I’ll do what I can to refer you or otherwise help you progress in your career.