There's a conversation happening in cybersecurity boardrooms that needs a hard reset.

Too many mid-market and startup security companies are still talking about AI like it's 2022 — debating whether to train their own models, hire ML engineers, and build proprietary LLMs. Meanwhile, the hyperscalers are spending tens of billions of dollars a year on foundation model development. Anthropic, OpenAI, Google, Meta — these companies are in a capital expenditure arms race that no $50M-revenue security vendor is going to win. Or even compete in.

And they shouldn't try.

The real opportunity for cybersecurity companies isn't in building models. It's in using them with ruthless economic precision.

The Pentest Team Analogy

Think about how a penetration testing engagement actually works. You don't put your most experienced red teamer on port scans. You don't have your principal consultant running Nmap against ten thousand hosts. That would be an absurd misallocation of talent and cost.

Instead, you tier the work. Junior analysts handle enumeration and reconnaissance. Mid-level testers run structured exploit attempts and analyze scan output. Senior consultants synthesize findings, identify attack chains, make judgment calls about lateral movement, and determine what to pursue next.

This isn't just an efficiency play. It's how you get the best results. Each tier is operating where their capabilities matter most.

AI models work the same way. And cybersecurity companies should be designing their architectures accordingly.

The Tiered Model Architecture

Here's what this looks like in practice for something like autonomous penetration testing:

The strategist — expensive reasoning models. Models like Claude Opus handle the high-stakes cognitive work. They plan attack paths, chain findings across hosts and services, decide when to pivot, interpret ambiguous results, and make risk-weighted decisions about resource allocation. This is the senior consultant. You pay a premium, and you use them sparingly on the decisions that actually change outcomes.

The analyst — mid-tier models. Models like Claude Sonnet handle semi-structured analysis. Parsing scan output. Classifying vulnerabilities against known CVEs. Writing targeted exploit code. Correlating findings from different tools and phases. This is your experienced mid-level tester — capable, reliable, and significantly cheaper per token than the reasoning tier.

The operator — lightweight, fast models. Models like Claude Haiku or purpose-built small models handle high-volume, repetitive execution. Banner grabbing. Fuzzing parameter generation. Log parsing. Formatting enumeration results. This is where the majority of computational work happens, and it can run at a fraction of the cost.

The economics are stark. If your reasoning model costs 10-15x what a lightweight model costs per token, and roughly 80% of your workload is repetitive task execution, you're looking at the difference between an autonomous test that costs $500 in compute and one that costs $50. At scale, that's the difference between a viable product and a science project.

This Is a Strategy Question, Not a Technical One

The mistake I see companies making isn't technical. It's strategic.

There's a gravitational pull toward the idea that AI differentiation means model differentiation. That you need your own foundation model, your own training pipeline from scratch, your own proprietary weights to have something defensible. For the vast majority of cybersecurity companies, that's a losing bet against organizations spending tens of billions on the problem.

But here's the nuance that gets lost in the "build vs. buy" debate: there's a massive middle ground between training a foundation model and using one off the shelf.

Techniques like LoRA (Low-Rank Adaptation) let you take a capable hyperscaler model and fine-tune it with domain-specific expertise at a fraction of the cost of full training. If you have years of penetration testing data — successful attack chains, exploitation techniques, the subtle pattern recognition that separates a good pentester from a great one — you can inject that expertise into an existing model without starting from scratch.

This is the real exception to the "don't train models" argument. You're not competing with the hyperscalers on general intelligence. You're standing on their shoulders and adding a layer of specialized knowledge that they'll never prioritize building themselves. A foundation model doesn't know the difference between a textbook SQL injection and the kind of chained, context-dependent exploitation that an experienced red teamer spots instinctively. But a LoRA-adapted model trained on real engagement data? That starts to close the gap.

The cost profile is compelling too. Full model training might run millions of dollars. A LoRA fine-tune on domain-specific data can cost orders of magnitude less while producing meaningful performance improvements on the tasks that actually matter for your product.

So the strategic picture has two layers. First, orchestration intelligence — the ability to decompose complex security workflows into tasks, route each task to the right model tier, and coordinate the results into something that's greater than the sum of its parts. Second, domain-adapted models — using techniques like LoRA to make the models at each tier meaningfully better at cybersecurity-specific tasks than their generic counterparts.

Think about what both of these require. Deep domain expertise in the actual security workflow. Understanding which decisions are high-stakes versus routine. Building tooling, integrations, and feedback loops. And curating the specialized data that makes fine-tuning actually work.

None of that comes from training a foundation model. All of it is something a focused cybersecurity company is uniquely positioned to build.

The Vulnerability Management Connection

This gets even more interesting when you connect the orchestration layer to existing security intelligence.

If you already have a vulnerability management platform that identifies, prioritizes, and tracks vulnerabilities across an environment, you have something incredibly valuable: context. Your AI-driven testing system doesn't need to spend expensive reasoning tokens rediscovering the attack surface from scratch. It inherits a prioritized view of where to focus.

The reasoning model's budget of expensive tokens gets allocated to the decisions that actually matter — evaluating whether a chain of medium-severity findings creates a critical attack path, or determining whether a particular configuration weakness is exploitable in this specific environment. The cheap models handle the grunt work of validating individual findings at scale.

This is where the compounding advantage lives. The more context you feed into the orchestration layer, the more efficiently you can allocate model resources, and the better your results get per dollar spent.

What This Means for the Market

If I'm right about this, a few things follow.

Cybersecurity companies should stop hiring ML engineers to train foundation models and start hiring AI engineers who understand both token economics and domain adaptation. The skill set that matters isn't "can you build a transformer from scratch." It's "can you design a system that orchestrates model tiers efficiently, and can you fine-tune those models with LoRA to be genuinely better at security tasks than anything a hyperscaler will ship out of the box."

Investors should be skeptical of cybersecurity startups claiming model differentiation — but should pay attention to domain adaptation strategies. If a company is just wrapping a foundation model API, that's thin differentiation. But if they're combining intelligent orchestration with LoRA-adapted models trained on real security engagement data, that's a meaningful and defensible technical moat. The question to ask isn't just "how are you using AI?" It's "what domain-specific data flywheel are you building that makes your models get better over time?"

The hyperscalers will keep making models better and cheaper. That's a tailwind, not a threat, for companies building on top of them. Every improvement in model capability and every reduction in token cost makes your orchestration layer more valuable, not less. You're surfing someone else's R&D curve.

The winners will be companies that treat AI compute like a managed resource, not a fixed cost. Just like cloud computing moved from "buy a server" to sophisticated resource management, AI usage will move from "call the API" to intelligent orchestration that dynamically allocates model resources based on task complexity, cost constraints, and quality requirements.

The Bottom Line

The AI revolution in cybersecurity isn't going to be won by whoever builds the best foundation model. It's going to be won by whoever builds the best system for using models — and for making them smarter in their specific domain. The companies that understand token economics, respect the tiering, invest in domain adaptation through techniques like LoRA, and focus their engineering effort on the orchestration layer that turns general intelligence into domain-specific excellence.

Stop trying to compete with the hyperscalers on building foundation models. Start building the intelligence and adaptation layers that make their models work harder — and smarter — for your customers.

That's where the real moat is.

I found this out when I received a spoofed email — from myself, to myself — that landed directly in my inbox. Every authentication check failed, and yet it was delivered without being flagged as junk.

Here’s what happened, why it happened, and how to fix it in about two minutes.

The Attack

I received an email that appeared to come from my own address at my custom domain. The subject line was a random string. The body contained a short numeric string and a massive tracking pixel — likely a probe to confirm my email address was active and being read.

Digging into the headers told the full story. The email originated from a Linode IP (173.255.231.177), authenticated to a compromised Bluehost shared hosting account (admin@misamajic.com), and was relayed through Proofpoint's Cloudfilter infrastructure into iCloud. The attacker simply set my email address as both the envelope sender and the From: header. That's it. No sophisticated exploit — just typing someone else's address into the "from" field and hitting send.

iCloud Detected It — But Couldn’t Act on It

Here’s where it gets interesting. iCloud’s mail infrastructure did detect the fraud. The headers showed the full picture:

• SPF: softfail — the sending server wasn’t authorized for my domain
• DKIM: none — no signature present at all
• DMARC: fail — failed alignment on both SPF and DKIM
• ARC: fail
• Spam score: 4.42, flagged as X-Spam-Flag: yes and X-Suspected-Spam: true

Every single authentication check failed, and iCloud’s own systems correctly scored this as spam. However, two additional headers appeared that changed the outcome:

X-ICLOUD-MAIL-BWL: 1
X-Apple-Action: WL/INBOX

A whitelist rule — likely triggered because the “from” address matched my own iCloud custom domain — moved the message to my inbox. Because my DMARC policy was set to p=none, iCloud had no authorization from my DNS records to reject or quarantine the message based on the authentication failures alone.

The Root Cause: Apple’s Default DNS Configuration

When you set up a custom domain in iCloud Mail, Apple provides specific DNS records to add. Here’s what they recommend for SPF and DMARC:

Apple’s default SPF:

v=spf1 include:icloud.com ~all

Apple’s default DMARC:

v=DMARC1; p=none; rua=mailto:<your-report-address>

Both of these are intentionally permissive.

The SPF record uses ~all (soft fail), which tells receiving servers: "If the sender isn't authorized, mark it as suspicious but don't reject it." The DMARC policy is set to p=none, which tells receiving servers: "Even if authentication fails, don't take any action — just send me a report."

This is standard practice for initial email setup. The p=none DMARC policy is meant to be a monitoring phase — you collect reports, verify that all your legitimate mail is authenticating properly, and then tighten the policy once you're confident everything is working. The gap is that the setup process doesn't guide you through that second step. There's no follow-up prompt in iCloud settings, no reminder to revisit your DMARC policy after a monitoring period, and no indication that your domain is still operating in monitor-only mode.

If you set it and forget it — which is easy to do when everything appears to be working — your domain remains open to spoofing indefinitely.

How to Fix It

If you’re running a custom domain on iCloud Mail, you need to change two DNS records. If you’re only sending email through iCloud Mail (not using third-party services like Mailchimp, SendGrid, or a CRM), these changes are safe to make immediately.

1. Harden Your SPF Record

Change the ~all to -all:

Before:

v=spf1 include:icloud.com ~all

After:

v=spf1 include:icloud.com -all

The -all (hard fail) tells receiving servers to reject mail from unauthorized senders outright, rather than just flagging it as suspicious.

2. Enforce Your DMARC Policy

Change p=none to p=reject:

Before:

v=DMARC1; p=none; rua=mailto:<your-report-address>

After:

v=DMARC1; p=reject; rua=mailto:<your-report-address>

This is the big one. With p=reject, any email that fails DMARC authentication — meaning it fails both SPF and DKIM alignment — will be rejected by the receiving server. The spoofed email I received would never have made it past the gateway.

If you want to be cautious, you can use p=quarantine first, which sends failures to the spam/junk folder instead of rejecting them outright. Run that for a week or two while monitoring your DMARC reports, then move to p=reject once you're confident nothing legitimate is getting caught.

3. Verify DKIM Is Working

Apple handles DKIM signing automatically when you send through iCloud Mail. You should already have a CNAME record like this:

sig1._domainkey.<yourdomain> → sig1.dkim.<yourdomain>.at.icloudmailadmin.com

You can verify it’s working by sending yourself an email from your custom domain to a Gmail address and checking the headers — you should see dkim=pass in the Authentication-Results.

Why This Matters

Email spoofing isn’t just about spam. A spoofed email from your domain can be used for phishing attacks against your contacts, business email compromise, or simply to confirm that your address is active for future targeting. The tracking pixel in the email I received suggests the latter — someone was building a list of verified, actively-monitored email addresses.

With proper SPF and DMARC enforcement, spoofed mail gets rejected before it ever reaches a recipient’s inbox. Without it, you’re relying entirely on the receiving server’s spam heuristics — and as I discovered, those heuristics can be overridden by well-intentioned but poorly-implemented whitelist rules.

Room for Improvement

This isn’t unique to Apple — most email providers default to permissive settings during initial custom domain setup to avoid breaking legitimate mail flow. It’s a reasonable starting point. The opportunity is in what comes after.

Apple is well-positioned to improve this experience because they control both the setup guidance and the receiving mail infrastructure. A few things that would help:

• A follow-up prompt after a monitoring period (30–60 days) suggesting users tighten their DMARC policy to p=quarantine or p=reject
• A security health indicator in iCloud Mail settings showing the current state of SPF, DKIM, and DMARC for your custom domain
• Stricter handling of self-addressed mail that fails authentication, even when the DMARC policy is permissive

The fix on the user side is simple — two DNS record changes that take less than a minute. But most people using iCloud custom domains aren’t email security specialists. Making the path from monitoring to enforcement more obvious would go a long way.

In the meantime, check your DNS records.

Metasploitable3 is an intentionally vulnerable virtual machine designed for security training and penetration testing practice. While the official build process uses Vagrant and VirtualBox, many security professionals prefer running their lab environments on Proxmox for better resource management and isolation.

This guide shows you how to get Metasploitable3 running on Proxmox without installing VirtualBox — perfect for headless servers or systems where VirtualBox isn’t compatible.

Why This Approach?

The traditional Metasploitable3 setup requires:

• VirtualBox (often conflicts with other hypervisors)
• Vagrant for building
• Time-consuming build process (30–60 minutes)

Our method:

• ✅ No VirtualBox installation needed
• ✅ Works on any Linux system with Vagrant
• ✅ Downloads pre-built images (faster)
• ✅ Direct import to Proxmox

Prerequisites

• A Linux machine for downloading the images (doesn’t need to be Proxmox)
• Proxmox VE server with available storage
• SSH access to your Proxmox server
• ~2.5 GB disk space for the download
• Basic familiarity with command line

Step 1: Install Vagrant

On your Linux machine (I used Debian testing, but this works on Ubuntu, Fedora, etc.):

# Download Vagrant
wget https://releases.hashicorp.com/vagrant/2.4.1/vagrant_2.4.1-1_amd64.deb

# Install it
sudo dpkg -i vagrant_2.4.1-1_amd64.deb

# Fix any dependency issues
sudo apt --fix-broken install

# Verify installation
vagrant --version

Step 2: Download the Metasploitable3 Box

# Create a workspace
mkdir ~/metasploitable3-workspace
cd ~/metasploitable3-workspace

# Download the pre-built Ubuntu box
vagrant box add rapid7/metasploitable3-ub1404

When prompted, select option 1 (virtualbox). Don’t worry — you don’t need VirtualBox installed; we just want to download the box file.

Note: There’s also a Windows Server 2008 version available (rapid7/metasploitable3-win2k8), but the Ubuntu version is more commonly used and easier to work with.

Step 3: Extract the VM Files

The downloaded box contains the VMDK and OVF files we need:

# Navigate to the downloaded box
cd ~/.vagrant.d/boxes/rapid7-VAGRANTSLASH-metasploitable3-ub1404

# Check the version (yours may differ)
ls -la

# Go into the virtualbox directory
cd 0.1.12-weekly/virtualbox  # Version number may vary

# List the files
ls -la

You should see:

• box.ovf - VM configuration file
• metasploitable3-ub1404-disk001.vmdk - Virtual hard disk (~2.1 GB)
• Vagrantfile - Vagrant configuration (not needed)
• metadata.json - Box metadata (not needed)

Step 4: Transfer Files to Proxmox

Copy the OVF and VMDK files to your Proxmox server:

# Replace <proxmox-ip> with your Proxmox server's IP address
scp box.ovf metasploitable3-ub1404-disk001.vmdk root@<proxmox-ip>:/tmp/

Example:

scp box.ovf metasploitable3-ub1404-disk001.vmdk root@192.168.1.100:/tmp/

Step 5: Import to Proxmox

SSH into your Proxmox server:

ssh root@<proxmox-ip>

Navigate to the temp directory and import:

cd /tmp

# Choose an available VM ID (check your Proxmox web UI)
# Replace <vmid> with something like 100, 101, 102, etc.

# Import the OVF configuration
qm importovf <vmid> box.ovf local-lvm

# Import and convert the disk to qcow2
qm importdisk <vmid> metasploitable3-ub1404-disk001.vmdk local-lvm -format qcow2

Example with VM ID 100:

qm importovf 100 box.ovf local-lvm
qm importdisk 100 metasploitable3-ub1404-disk001.vmdk local-lvm -format qcow2

Note: If you’re using a different storage pool (not local-lvm), replace it with your storage name.

Step 6: Configure the VM (Critical!)

Open your Proxmox web interface and navigate to your new VM. These configuration changes are essential for the VM to boot properly:

1. Attach the Imported Disk

• Go to Hardware tab
• You’ll see “Unused Disk 0”
• Double-click it (or select and click Edit)
• Click Add to attach it

2. Change SCSI Controller (CRITICAL!)

This is the most important step — VirtIO SCSI will cause boot failures:

• Select SCSI Controller
• Click Edit
• Change from “VirtIO SCSI” to “LSI 53C895A”
• Click OK

Without this change, you’ll get boot errors like “dev/mapper/metasploitable-root doesn’t exist”

3. Set Boot Order

• Go to Options tab
• Select Boot Order
• Click Edit
• Enable only the SCSI disk
• Move it to first position
• Click OK

4. Configure Network (Security Important!)

⚠️ WARNING: Metasploitable3 is intentionally vulnerable. NEVER expose it to the internet or your production network.

• Go to Hardware tab
• Select Network Device
• Click Edit
• Options:
  • Use an isolated internal network/VLAN
  • Or create a dedicated “pentest” bridge
  • Or set to “No network device” if you’ll only access via console

5. Optional: Adjust Resources

The default settings are usually fine, but you can adjust:

• Memory: 2048 MB (2 GB) is recommended
• Processors: 2 cores is plenty
• Display: Default (keep it)

Step 7: Start the VM

• Click Start in the Proxmox interface
• Open the Console
• Watch it boot (takes 30–60 seconds)

Step 8: Login

Default credentials:

• Username: vagrant
• Password: vagrant

Once logged in, you can verify the system:

# Check the hostname
hostname

# Check IP address
ip addr show

# List vulnerable services
sudo netstat -tulpn

Security Best Practices

1. Network Isolation: Run Metasploitable3 on an isolated network segment
2. Firewall Rules: Block any outbound internet access
3. Snapshot Before Use: Take a Proxmox snapshot before each testing session
4. Regular Cleanup: Delete when not in use
5. Access Control: Limit who can access your Proxmox server
6. No Sensitive Data: Never store real data on Metasploitable3

Troubleshooting

VM Won’t Boot / Gets Stuck

Problem: Boot hangs or shows “dev/mapper/metasploitable-root doesn’t exist”

Solution: You forgot to change the SCSI controller! Go back to Step 6.2 and change it to LSI 53C895A.

Can’t Connect to Network

Problem: VM boots but has no network connectivity

Solution:

• Check that network device is properly configured
• Verify bridge/VLAN settings in Proxmox
• Inside the VM, check: ip addr show

Import Fails with Storage Error

Problem: qm importovf or qm importdisk fails with storage errors

Solution:

• Verify you have enough free space: pvesm status
• Check storage name is correct (might not be local-lvm)
• Try using a different storage pool

Slow Performance

Problem: VM is sluggish or unresponsive

Solution:

• Increase RAM to 2–4 GB
• Add another CPU core
• Ensure Proxmox host isn’t overloaded

What’s Next?

Now that you have Metasploitable3 running, you can:

• Practice with Metasploit Framework
• Test Nmap scanning techniques
• Explore web application vulnerabilities
• Practice privilege escalation
• Learn exploit development

Popular vulnerable services in Metasploitable3:

• UnrealIRCd (backdoor)
• ProFTPD (various exploits)
• Samba/SMB (multiple vulnerabilities)
• Apache/PHP (web vulnerabilities)
• MySQL (weak credentials)
• Docker (privilege escalation)

Getting the Windows Version

Want the Windows Server 2008 version too? Follow the same process but use:

vagrant box add rapid7/metasploitable3-win2k8

The Windows version has different vulnerabilities focused on Windows-specific exploits, Active Directory attacks, and Windows services.

Cleanup

When you’re done with the files:

# On your Linux download machine
rm -rf ~/metasploitable3-workspace
vagrant box remove rapid7/metasploitable3-ub1404

# On Proxmox server
rm /tmp/box.ovf /tmp/metasploitable3-ub1404-disk001.vmdk

Alternative: Docker Approach

If you only need the Ubuntu version and prefer containers, there’s a community Docker image:

docker pull kirscht/metasploitable3-ub1404

However, the Proxmox VM approach gives you:

• Full OS access
• Better network isolation
• Snapshot/restore capabilities
• Both Windows and Linux options

Conclusion

Running Metasploitable3 on Proxmox gives you a professional penetration testing lab environment without the overhead of VirtualBox. By downloading the pre-built Vagrant boxes and importing them directly, you skip the time-consuming build process and get straight to learning.

Remember: This is a deliberately vulnerable system. Always keep it isolated from production networks and the internet!

Resources

• Metasploitable3 GitHub
• Proxmox VE Documentation
• Vagrant Downloads
• Metasploit Unleashed (Free Training)