Introduction
With the ever-growing number of cybersecurity threats — especially those amplified by AI — MSPs are taking on a much larger role in protecting their clients' networks. Many organizations are simply unaware of how vulnerable their environments truly are. The rapid advancement of AI has only widened that gap, empowering attackers just as much as defenders.
To get ahead of this, the company I work for began offering penetration testing as part of our service catalog. After telling my boss that I wanted to broaden my experience in cybersecurity, he made sure I got exactly that... and then some.
We accomplish penetration testing using a Vonahi agent, deployed on a Raspberry Pi 5 running Ubuntu Desktop. From the Vonahi portal, I could define scan schedules, scope internal IP ranges, select report types, and even coordinate multiple scans using the same agent. This gave me full control over when, where, and how tests were executed.
One of our largest customers — a medical provider with multiple geographically distributed sites and a large number of internal subnets — was the first to request this service. In hindsight, they were the perfect environment to truly see what Vonahi was capable of.
Preparation
The preparation phase was relatively straightforward, but undeniably tedious. I worked closely with site representatives and leveraged existing network documentation to build an accurate list of private IP ranges. Instead of defining individual IP addresses, I summarized each site's subnets using CIDR notation to keep the scope manageable.
I also coordinated with the EDR vendors in use to ensure they were aware of the upcoming penetration test — it was almost guaranteed that alerts would be triggered.
To streamline deployment, I pre-configured the Raspberry Pi's wireless adapter with the correct SSID and credentials. Once powered on, the agent would automatically connect and gain visibility across the internal network, including traffic traversing site-to-site VPNs.
The Penetration Test
Once everything was prepped, it was time to run the test. I kicked off the scan and let it do its thing. The next morning, I logged into the portal and immediately ran into my first real obstacle.
With over 20,000 IPs in scope, the agent was simply overwhelmed. At that scale, the host discovery phase alone would have taken weeks. So I pivoted and asked a more important question: How many IPs is too many?
After some trial and error, I found the sweet spot: breaking the scope into three separate scans. The largest of those scans took roughly 7–9 days to complete, including information gathering, host discovery, enumeration, exploitation, post-exploitation, quality assurance, and reporting.
I was genuinely impressed by how much work that little Pi agent could handle and how cleanly the results were presented. Ultimately, the customer agreed that as long as all internal subnets were tested and remediated within a quarter, the approach was acceptable. This allowed me to stagger scans every two weeks, ensuring full quarterly coverage while leaving time for remediation.
Post-Testing: Where the Real Work Began
When I received the reports, I'd be lying if I said I wasn't overwhelmed.
Across all scans, there were 13 distinct vulnerabilities affecting 987 IPs — and remediation was entirely on me.
To get control of the chaos, I leaned heavily on documentation. I needed a way to brief the customer clearly and track progress without losing my sanity. So I built a detailed remediation tracker in Microsoft Excel.
Remediation Tracker Features
- A front-page progress dashboard
- Individual worksheets per vulnerability
- Lists of affected IPs per issue
- Formulas and conditional formatting for automatic progress updates
Using formulas and conditional formatting, every IP marked as "Completed" automatically updated progress percentages — both per vulnerability and overall. The customer could open the file and instantly see how remediation was progressing without digging through raw data.
Understanding the Vulnerabilities
Before moving forward, I had to ask myself a tough question: What do these vulnerabilities actually mean?
Some findings were straightforward: default credentials, insecure protocols, and similar low-hanging fruit. Others were far more intimidating.
Major Findings Across Hundreds of Systems
- SMB signing not being required — allows man-in-the-middle attacks
- SMB NULL authentication — permits anonymous enumeration
- Default SNMP community strings — exposes network device configs
I had to research not only what these vulnerabilities meant, but how to remediate them at scale.
Windows Remediation via Group Policy
For Windows systems, Group Policy helped immensely by enforcing SMB signing, blocking insecure protocols via firewall rules, and tightening authentication requirements.
The SNMP Monster
SNMP remediation, however, was a monster.
Community strings were spread across switches, printers, label makers, and countless other IP-based devices. Every vendor had a different configuration method — some via CLI, others through web interfaces.
My goal was always to enable SNMPv3 and disable v1/v2c where supported. If a device didn't support v3, I ensured the community string was changed to something non-default and unique.
Some interfaces made this painless. Others required serious digging. Either way, I became very familiar with a wide range of device management consoles.
Over the following months, I worked through the list methodically. From an admin jump box, I spent countless hours testing, remediating, validating, and documenting. There truly is more than one way to skin a cat, and I learned most of them.
Results
The initial phase of this customer's vulnerability testing plan was a long road. But because of the time I invested upfront in preparation, documentation, and remediation, future cycles are now far more efficient.
I understand the environment deeply. I understand the vulnerabilities. I understand the solutions.
What This Project Delivered
- Complete quarterly penetration testing coverage across all internal subnets
- A repeatable remediation workflow with clear progress tracking
- Hardened Windows systems with enforced SMB signing and secure protocols
- SNMP configurations upgraded to v3 or secured community strings across all devices
- Deep familiarity with a complex, multi-site medical provider network
- Customer confidence in their network security posture
This has been, without question, one of the largest and most rewarding professional undertakings I've ever experienced. The customer is confident in the security of their network. My leadership has seen the ownership and discipline I bring to complex problems. And I've gained a level of confidence in my ability to learn, adapt, and overcome challenges at scale.
Conclusion
This was only the beginning of a new service offering, but I'm incredibly glad I committed fully to the preparation, documentation, communication, and execution phases. Those habits have already paid dividends in the quarterly penetration tests that followed.
Penetration testing has been a goal of mine since I first learned about it years ago. The idea of ethically breaking into a network, identifying weaknesses, and helping organizations defend themselves — all while being paid to do it — is about as cool as it gets.
I'm hopeful that the work I'm doing now, combined with the projects I pursue on my own time, will eventually put me in a position to do this kind of work full-time.