How I Built a Business Network - So I Could Break Into It

Executive Summary

This project started with a simple question: how easy is it, really, to leave a small business network wide open to attackers?

The answer, it turns out, is embarrassingly easy.

I built a simulated small business network from scratch — a firewall, a server, a workstation, and a legacy machine — and deliberately configured it the way real small business networks tend to look: set up for convenience, never revisited for security, and running on the assumption that nobody would ever bother targeting them. Then I broke into it.

What I found wasn't surprising, from a technical standpoint. What was surprising was how little effort it took. Default passwords, open file shares, disabled antivirus, an unpatched machine that's been vulnerable since 2008 — none of it required exotic techniques or advanced skills to exploit. It required a free tool, a few commands, and about an hour.

The three most urgent things I found — things that would keep any small business owner up at night — were default and weak passwords on every system, remote access services exposed without proper protection, and unnecessary services running on machines nobody was watching. In this new installment of A Beginner's Guide to Learning Cybersecurity, we'll get into all of it. I hope you are prepared to learn something today. I know I did.

Methodology and Scope

Before we get into any of the finer details, I need to explain how I structured this assessment, because the framework matters. Knowing how findings are structured in the industry gave me a good idea of what to look for, and how to organize them. In an industry like cybersecurity, well organized information is a gold mine.

I used the NIST Cybersecurity Framework (CSF) as my organizational backbone. NIST CSF breaks security down into five functions that any organization — from a Fortune 500 to a three-person bakery — can apply to their situation:

Identify — Know what you have. Assets, systems, data, people. You can't protect what you don't know exists, and you won't notice when something goes missing if you never tracked it in the first place.

Protect — Put safeguards in place. Passwords, firewalls, access controls, encryption. This is the layer most people think of when they think "cybersecurity."

Detect — Know when something is wrong. Logging, monitoring, alerts. Protecting is great, but if an attacker gets through and nobody notices for six months, the protection didn't matter much.

Respond — Have a plan for when things go wrong. Because things will go wrong. The question is whether you're ready when they do.

Recover — Get back on your feet. Backups, restoration procedures, lessons learned. The goal isn't to be bulletproof — it's to survive when you get hit.

On the technical side, I mapped each vulnerability and exploitation technique to the MITRE ATT&CK framework—the industry-standard taxonomy for how attackers actually operate. Think of it like a playbook detailing an attacker's full process, from gathering information to leaving no trace. When I reference a technique ID like T1046 or TA0043, that's what I'm pointing to.

Tools Used

Like every good heist episode, this is the team that joins me on every mission:

• Nmap — the essential network mapper. Finds every device and service on a network. Every assessment starts with nmap.

• Metasploit — a database of known exploits with automated delivery. If a vulnerability is well-documented, Metasploit probably has a module for it.

• Hydra — a password-cracking tool that methodically tries credentials against login services. Fast, relentless, and effective against weak passwords.

• enum4linux — enumerates Samba/SMB services and finds shared directories. If a sensitive folder is accessible, they can find it.

• Nikto — web server scanner. Identifies misconfigurations, missing security headers, and version disclosures on HTTP services.

• smbclient — connects to SMB file shares. Think of them as a command-line file browser for network shares — including ones that shouldn't be open.

Network Topology

This simulation ran entirely on a single Dell Precision 5510 laptop using Proxmox virtualization — four separate virtual machines functioning as independent systems on their own isolated network segment: vmbr1. Small in scale, but representative of what you'd find walking into most small businesses.

Findings

With the background out of the way, I can finally share with you my findings, organized by the five functions of the NIST CSF framework, and labeled with the MITRE ATT&CK Framework identifiers:

Identify

• No formal asset inventory exists.

  Nobody had a list of which machines were on this network, what software was running on them, or where the data lived. This sounds terribly bureaucratic for a small business, until you realize that nobody would notice if a machine disappeared, a new unauthorized device appeared, or data was quietly copied and taken. You can't protect what you haven't counted.

  
  

  How we can fix it: Create a simple spreadsheet of every device on the network — name, IP address, OS, owner, purpose. Review it quarterly. Tools like Nmap can generate this automatically.

• The Windows XP Machine is an unsupported legacy OS present with no compensating controls (T1210).

  One machine on this network is a legacy workstation, running Windows XP. Microsoft stopped releasing security patches for XP in 2014. That means every vulnerability discovered since then — and there have been many — will never be fixed. It's a permanently broken window sitting open on your network.

  The specific vulnerability I exploited here is MS08-067, a notorious remote code execution flaw in Windows' Remote Procedure Call (RPC) service. It's been in Metasploit's library for years, requires minimal configuration to use, and gives me complete system-level access to the machine in a single command. No password required. No interaction from the user. Just a command and a shell. It's so easy to exploit that many in the community consider it a 'tutorial hack'.

  
  

  How we can fix it: No legacy machine should be exposed to the internet without compensating controls. Upgrade to the latest version of Windows immediately. Sometimes the legacy OS is the only way to maintain a certain asset, in which case we need to immediately isolate the machine from the main network and, if possible, the internet entirely.

• Network topology exposes all hosts to internal lateral movement (TA0043, T1046).

  A single Nmap scan across the network subnet revealed every host, every open port, and every running service. From one machine, I had a complete map of the entire network in minutes. No special access required — just being on the same network was enough.

  This is significant because it means that once an attacker gets a foothold anywhere on the network — through a phishing email, a compromised password, a malicious USB drive — they immediately have a roadmap to everything else: a technique called lateral movement.

  
  

  How we can fix it: Implement network segmentation. Different types of systems — servers, workstations, guest devices — should live on separate network segments that can't freely communicate with each other. This limits what an attacker can reach from any single point of compromise.

Protect

• Default credentials on the network firewall.

  The firewall — the device responsible for protecting the entire network — was accessible using its default username and password. These credentials are publicly documented by the manufacturer and are the first thing any attacker tries to exploit.

  Default credentials on a firewall aren't just a password problem. They're a "the front door is unlocked, and the key is under the mat" problem.

  
  

  How we can fix it: Change default credentials on every network device immediately upon installation. Password managers are a great way to create and store complex passwords without having to memorize them all.

• Unencrypted firewall management interface.

  The firewall's web management interface was accessible over HTTP rather than HTTPS. Every configuration change, every login, every setting — transmitted in plain text across the network. Anyone watching network traffic could capture administrator credentials without any hacking required.

  
  

  How we can fix it: Enforce HTTPS on all management interfaces. Disable HTTP access entirely if possible. This is usually a single checkbox in the firewall's settings.

• Weak authentication across all systems (TA0006, T1110).

  Every machine in this network was running with passwords that appeared in the rockyou.txt wordlist — a publicly available file containing over 14 million commonly used passwords compiled from real data breaches. Hydra found them quickly. All fell within minutes.

  Weak passwords aren't just a bad habit — they're an open invitation. Automated tools don't get tired, don't take lunch breaks, and will try millions of combinations without complaint.

  
  

  How we can fix it: Enforce strong, unique passwords across all systems. Enable multi-factor authentication wherever possible, particularly on email, remote access, and administrative accounts. Consider a business password manager to make compliance easy for employees.

• Disabled endpoint protection on the Windows 10 workstation.

  Windows Defender — Windows 10's built-in antivirus — and Windows Firewall were turned off entirely. No alerts, no scanning, no protection. The machine was essentially volunteering to be compromised.

  This happens more often than you'd think. Someone turns it off during troubleshooting and never turns it back on. A pop-up was annoying, so someone disabled it. Whatever the reason, a machine with no endpoint protection is a free pass for malware.

  
  

  How we can fix it: This is an easy fix; re-enable Windows Defender and verify that they are running regularly. Or better yet, if the business can afford it, consider a managed endpoint protection service that sends alerts if protection is disabled or a suspicious signature is detected.

• Unauthenticated SMB access on server and workstation (TA0009, T1039).

  Both the Ubuntu Server and the Windows 10 workstation had file shares accessible with no authentication required. No username, no password — just connect and browse. I could see everything: customer files, financial documents, and internal records. The files sitting in the open share were named things like "Customer Credit Cards" and "Payroll Information."

  Nobody broke in. The door was already open.

  
  

  How we can fix it: Audit all shared folders immediately. Remove guest access. Require authentication for every share. Apply least privilege — employees should have access only to the specific folders they need for their jobs, not to the entire server.

• AutoRun is enabled on the workstation.

  AutoRun allows external devices — such as USB drives and external hard drives — to run content automatically when plugged in. This is the technical mechanism behind USB drop attacks, in which an attacker leaves a drive somewhere, expecting a curious employee to pick it up and plug it in.

  With AutoRun enabled, that plugged-in drive doesn't need the employee to do anything else. It runs on its own.

  
  

  How we can fix it: Disable AutoRun via Group Policy. Train employees never to plug in USB drives or other external devices unless they were received from a trusted source. This is one of the few security controls that requires both a technical fix and a change in human behavior.

• Unnecessary services are running.

  Telnet was enabled on the Windows workstation. Telnet is a decades-old remote access protocol that transmits everything — including usernames and passwords — in plain text. It was replaced by SSH for exactly this reason. It has no business being enabled on a modern machine.

  On the firewall, Universal Plug and Play (UPnP) was enabled. UPnP allows devices on the network to automatically open ports on the firewall without any approval or authentication. It's convenient and dangerous in equal measure.

  Every unnecessary service is a door that doesn't need to be there. The fewer doors, the fewer ways in.

  
  

  How we can fix it: Audit running services on every machine. Disable anything not actively required for business operations. This is particularly important for services with known security histories, such as Telnet, FTP, and UPnP.

• Missing HTTP security headers on web server (TA0043).

  The Apache web server running on the Ubuntu machine was missing several standard security headers that modern browsers rely on for protection:

  The missing X-Frame-Options header leaves users vulnerable to clickjacking — attacks in which a malicious page overlays an invisible frame on a legitimate one, tricking users into clicking things they didn't intend to.

  The missing X-Content-Type-Options header allows browsers to guess file types rather than trusting the server's declaration, which can be exploited to execute malicious content.

  These headers cost nothing to implement and are considered baseline hygiene for any web server.

  
  

  How we can fix it: Add the missing security headers to the web server configuration. This is a configuration change that takes minutes and immediately improves the security posture of any web-facing service.

  
  

• Full version disclosure on the web server.

  Apache was broadcasting its exact version number — Apache/2.4.58 — in every HTTP response. This tells any attacker precisely what they're dealing with and makes it trivial to search for known vulnerabilities specific to that version.

  Obscurity isn't security, but there's no reason to hand attackers a shopping list.

  
  

  How we can fix it: Configure the web server to suppress version information in response headers. In Apache, this is a single-line change in the security configuration file.

Detect

• Logging was disabled on the firewall. No record of who connected, what traffic passed through, or when any of it happened.

• No intrusion detection system was present anywhere on the network. Nothing is watching for suspicious patterns, port scans, or brute force attempts.

• No centralized log management existed. Even on the machines that were generating logs, those logs lived only on that machine — siloed, unmonitored, and useless for any kind of network-wide visibility.

• Brute force attacks generated no alerts. I ran Hydra against SSH for an extended period. The attack was visible in the auth.log file on the Ubuntu machine — hundreds of failed login attempts in rapid succession — but nobody was watching that log. The attack ran to completion without triggering a single notification.

  
  

  How we can fix it: All four of these can be fixed in tandem. Start with basic logging: Enable it everywhere and ensure logs are stored in a central location. Even a simple solution like shipping logs to a cloud storage bucket is better than nothing. Consider a basic IDS like Snort or Suricata as a longer-term investment, or a Single Pane of Glass (SPoG) solution like Datadog or Grafana to have all your security monitoring and response tools in one place.

Respond

• The organization's attack surface was unknown.

  Nobody had mapped what was running, what was exposed, or what the realistic threat landscape looked like. You can't respond to threats you don't know exist.

  
  

  How we can fix it: Create an asset inventory that is updated annually to ensure new acquisitions and things you no longer use are accounted for. The second an unfamiliar machine appears, detection and response will be much faster

  
  

• No documented incident response plan existed.

  If something went wrong on this network tonight, nobody would know what to do, who to call, or in what order to do things. Countless studies have shown that snap-decisions made in a panic after a breach are almost always worse than decisions made calmly in advance.

  
  

  How we can fix it: Write a basic incident response plan. We can start with a one-page document covering who to contact, what to shut down first, and how to preserve evidence. Even rudimentary is better than nothing. Reviewing this with your team and updating it annually will be very important for maintaining your MTTR going forward

Recover

• No documented backup and recovery procedure existed.

  If ransomware hit this network tomorrow and encrypted every file on every machine, there would be no clean copy to restore from. The choice would be to pay the ransom or start over from scratch.

  
  

  How we can fix it: One backup is good; two is better; but three is best. That's the basis of the 3-2-1 rule for data backups. Always have three copies of your data, stored on two separate media types, with at least one stored offsite or in the cloud.

  
  

• No restoration capability had been tested.

  Even organizations that do maintain backups frequently discover — at the worst possible moment — that their backup process was broken, incomplete, or producing files that couldn't actually be restored. Data is never guaranteed; transfers can be corrupted, solid-state drives can degrade over time, and hard drives can break.

  
  

  How we can fix it: Test restoration from backup at least once per year. A backup you've never tested is a backup you can't trust.

Risk Matrix

As a visual learner, I find it best to see the bigger picture by laying out all my findings and color-coding them by severity. It's not just me; a risk matrix is a great way to give the equivalent of a 'security elevator pitch' to managers or members of your organization outside IT. It shows the gravity of the situation without going too in-depth with technical jargon, and when your audience are the ones controlling the budget, making your claim in a language they can understand is paramount. All the better if financial numbers are attached:

MS08-067 — Remote Code Execution on XP 🔴 Critical

Legacy OS with no compensating controls 🔴 Critical

Default credentials on firewall 🔴 Critical

Unauthenticated SMB access 🔴 Critical

Weak passwords across all systems 🔴 Critical

Unencrypted firewall management interface 🟠 High

Disabled Windows Defender and Firewall 🟠 High

AutoRun enabled on workstation 🟠 High

No logging or IDS present 🟠 High

Telnet and UPnP enabled 🟡 Medium

Missing HTTP security headers 🟡 Medium

Full web server version disclosure 🟡 Medium

No asset inventory 🟡 Medium

No incident response plan 🟡 Medium

No backup and recovery procedure 🟡 Medium

Proof of Concept

These screenshots highlight everything that's been discussed so far. They show each instance in which I exploited a vulnerability within the business network.

Yes, I created these vulnerabilities and knew where to look, but I cannot stress enough how common these vulnerabilities are. Anyone with know-how and an afternoon could access this lab and discover the same things I have using these tools. That's what makes this exercise so scary - it can happen to anyone, anywhere, with ease.

Recommendations Summary

We have discussed many ways this network can be hacked. The good news, however, is that not everything has to be changed at once. While that would be ideal, implementing these changes will take time, especially in larger networks spanning hundreds to thousands of devices. Here is the action plan I've devised for this network specifically:

Immediate - 30 days

• Change all default credentials - keep all passwords in a dedicated password manager for best results

• Enable multi-factor authentication (MFA) on all accounts

• Isolate the Windows XP Machine, or decommission and upgrade if possible

• Re-Enable Windows Defender and Firewall

• Restrict SMB share permissions

short term - 60 days

• Implement centralized logging

• Configure firewall rules properly: block everything, and create an allow list only for what's needed

• Enable HTTPS on all management interfaces, and disable HTTP

• Audit all services on the network and disable any unnecessary ones

long term - 90 days

• Create an inventory of assets

• Develop an Incident Response Plan (IRP)

• Implement backup and recovery procedures

• Conduct regular security assessments

• Deploy an Intrusion Detection System (IDS)

Conclusion

The truth is, breaking into a network is easy.

It doesn't take a sophisticated attacker or a nation-state threat actor. It takes a default password that nobody changed. A share that someone opened up in a hurry and never closed. A machine that IT said they'd get around to updating. An antivirus that got disabled during troubleshooting and never turned back on.

None of the vulnerabilities in this network were exotic. They were ordinary. And that's exactly what makes them dangerous — because ordinary vulnerabilities exist on ordinary networks, in ordinary small businesses, every single day.

This project was great for basic network design, but it has also laid the groundwork for something bigger. This simulated network is now a digital playground — a place to learn how to harden systems, deploy and defeat intrusion detection systems, implement and attack AI agents, and test new penetration testing techniques in a controlled environment. Every phase makes the next client engagement sharper, more informed, and more valuable.

Every step I take on this journey brings me closer to my goal: a career in cybersecurity. More importantly, it allows me to think and act like a scientist - observing how things act, react, and how to change the outcome. I'm proud of the work that I've done, and I cannot wait to see where else it will take me.

Thanks for taking the time to read this installment of A Beginner's Guide to Learning Cybersecurity, and I can't wait to see what I will find out next.