The Emperor’s New Security Tools: Building a MITRE ATT&CK-Based Network Monitor in Under an Hour

Introduction

As cybersecurity professionals, we’ve all sat through the same vendor pitches: “Our revolutionary AI-powered solution leverages proprietary algorithms to detect threats that others miss.” Yet, when we peel back the layers of marketing, many “innovative” security products are merely repackaging established techniques with a fresh coat of paint.

To illustrate this point, I decided to run an experiment: How much functionality could I implement in a network security monitoring tool in under an hour? The results were eye-opening and raise important questions about the direction of our industry.

The One-Hour Challenge

Using Python, Scapy, and the MITRE ATT&CK framework, I created a functional network security monitoring tool in less than 60 minutes. With the assistance of Cursor IDE’s AI pair programming capabilities, I was able to rapidly implement a surprisingly comprehensive set of security monitoring features.

The tool includes:

1. Network device discovery and inventory management
2. Real-time traffic monitoring across multiple protocols
3. MITRE ATT&CK-based threat detection and classification
4. Whitelisting capabilities for trusted systems

Core Components

Let’s examine the key components that make up this rage coded security tool:

Network Discovery and Device Tracking

The tool automatically scans the network to build an inventory of connected devices, mapping IP addresses to MAC addresses for later reference:

def discover_network_devices(self):
    """Scan the network to discover all devices"""
    print("Scanning network for devices...")
    
    # Get local IP to determine network range
    local_ip = self.get_local_ip()
    if not local_ip:
        print("Could not determine local IP address")
        return
        
    # Determine network range (assuming /24 subnet)
    ip_parts = local_ip.split('.')
    network_prefix = '.'.join(ip_parts[0:3])
    network_range = f"{network_prefix}.0/24"
    
    try:
        # Create ARP request packets for all IPs in the range
        arp_request = scapy.ARP(pdst=network_range)
        broadcast = scapy.Ether(dst="ff:ff:ff:ff:ff:ff")
        arp_request_broadcast = broadcast/arp_request
        
        # Send packets and receive responses
        answered_list = scapy.srp(arp_request_broadcast, timeout=3, verbose=False)[0]
        
        # Process discovered devices
        discovered_devices = {}
        for sent, received in answered_list:
            ip = received.psrc
            mac = received.hwsrc.lower()
            discovered_devices[ip] = mac
            
            # Add to known devices if not already there
            if ip not in self.known_devices:
                self.add_known_device(ip, mac)

MITRE ATT&CK Integration

The tool maps network behavior to MITRE ATT&CK techniques, providing meaningful context about potential threats:

class MitreAttackData:
    def __init__(self):
        self.techniques = self.load_mitre_techniques()
        
    def load_mitre_techniques(self):
        """Load MITRE ATT&CK techniques from JSON file"""
        # Default techniques in case file doesn't exist
        default_techniques = {
            "T1046": "Network Service Scanning",
            "T1049": "System Network Connections Discovery",
            "T1055": "Process Injection",
            "T1057": "Process Discovery",
            "T1070": "Indicator Removal on Host",
            "T1071": "Application Layer Protocol",
            # Additional techniques...
        }

It can pull the attack patterns from a file mitre_techniques.json as well if the file is present in the project’s root directory.

Protocol-Specific Threat Detection

For each network protocol, the tool implements specific detection logic. For example, here’s a snippet showing how it analyzes TCP packets:

def analyze_tcp_packet(self, packet):
    if not packet.haslayer(scapy.IP):
        return
        
    src_ip = packet[scapy.IP].src
    dst_ip = packet[scapy.IP].dst
    src_port = packet[scapy.TCP].sport
    dst_port = packet[scapy.TCP].dport
    
    # Skip whitelisted IPs for port scanning detection
    if src_ip in self.whitelisted_ips:
        return
        
    # Port scanning detection (T1046)
    self.port_scan_tracker[src_ip].append((dst_port, time.time()))
    
    # Check for port scanning
    recent_ports = [p[0] for p in self.port_scan_tracker[src_ip] 
                  if time.time() - p[1] < 5]  # Ports in last 5 seconds
    
    if len(set(recent_ports)) > self.scan_threshold:
        # Check cooldown before alerting
        if src_ip not in self.scan_alert_cooldown or time.time() - self.scan_alert_cooldown[src_ip] > 300:
            self.alert("T1046", f"Port Scanning Detected from {src_ip}, {len(set(recent_ports))} unique ports")
            self.scan_alert_cooldown[src_ip] = time.time()
        self.port_scan_tracker[src_ip] = []  # Reset after alert

What This Demonstrates

The ease with which I was able to construct this tool raises several important points:

1. Core Security Functionality Isn’t Exotic

Many of the features marketed as advanced by security vendors are built on widely understood techniques that have existed for years. Port scan detection, ARP spoofing identification, and protocol analysis aren’t novel concepts — they’re the fundamentals of network security monitoring.

2. The Problem of Tool Proliferation

Security operations centers (SOCs) are drowning in tools. Many organizations maintain 20+ security products, each generating its own alerts, dashboards, and management overhead. Yet, as this experiment shows, the core functionality of many tools overlaps significantly.

Consider that this one-hour project implemented detection capabilities for 171 different MITRE techniques including:

• Network scanning (T1046)
• ARP spoofing (T1070)
• Man-in-the-Middle attempts (T1557)
• Port scanning (T1046)
• Brute force attacks (T1110)
• Web application attacks (T1190)
• Command injection (T1059)
• DNS tunneling (T1071)
• Denial of service patterns (T1498)

Many commercial solutions charge substantial subscription fees for similar functionality, wrapped in slick UIs and marketing language.

3. Context Remains the Missing Piece

Despite the rapid development of this tool, it still suffers from the same fundamental limitation as many commercial products: it produces alerts that require human analysis. Adding more tools to the stack doesn’t solve the underlying problem of alert fatigue and context deficit.

The Path Forward: Beyond Incremental Improvements

If we can build significant security monitoring functionality in under an hour using open-source tools and AI assistance via Cursor IDE, we need to ask harder questions about what we’re paying for in commercial security solutions.

Rather than continuing to bolt new tools onto our existing security stacks, the industry needs to consider fundamentally different approaches:

LogLMs: A New Paradigm for Security Analysis

A distant cousin of Large language models, LogLMs are specialized for log and security data presenting a promising direction. Unlike traditional tools that rely on pre-defined rules or statistical anomalies, these models can:

1. Process and correlate massive amounts of security data across disparate sources
2. Understand the semantic meaning of security events in context
3. Learn from historical incidents to improve future detection
4. Communicate findings in natural language that security analysts can readily understand

The potential of LogLMs isn’t in replacing human analysts but in providing them with meaningful, contextualized insights derived from the flood of security data. Rather than presenting more alerts, these systems could present coherent narratives about potential security incidents.

Re-examining Our Fundamentals

We need to question core assumptions about security architecture:

1. Does the endpoint-centric paradigm still make sense? With the rise of cloud services, containerization, and serverless computing, the concept of an “endpoint” becomes increasingly abstract.
2. Is detection-and-response the right model? Perhaps we need to shift toward architectures where security is truly embedded in systems from design through operation, rather than bolted on afterward.
3. How can we better incorporate threat intelligence? Current implementations often amount to glorified blocklists rather than actionable intelligence that adapts to changing tactics.

Conclusion

The rapid development of a functional security monitoring tool demonstrates that many commercial security solutions may not be delivering value proportionate to their cost and complexity. Rather than continuing to add incremental features to existing approaches, the security industry needs to embrace fundamentally new paradigms.

The future of security technology isn’t in more alerts or more dashboards — it’s in meaningful context, integrated security architecture, and tools that genuinely augment human capabilities rather than overwhelm them with information.

So What Now

As security professionals, we need to:

1. Challenge vendor claims about “innovative” technologies by understanding what’s truly novel versus repackaged standard techniques
2. Advocate for consolidation rather than proliferation in our security stacks
3. Invest in research around technologies like LogLMs that represent genuine paradigm shifts
4. Share knowledge about open-source alternatives to commercial security tools
5. Push for greater integration between security tools, development processes, and operational workflows

The security tools of tomorrow should help us make sense of complexity, not add to it. By reimagining security from the ground up rather than continuing to patch an increasingly unwieldy system, we can build more effective defenses against an ever-evolving threat landscape.

If you want to see the full code check out the repo here