Pwn2Own Ireland Day One: 32 Zero-Days in Routers, NAS, and IoT Gear — A Defender's Playbook Before the Patches Land

Day one of Pwn2Own Ireland has already produced 32 previously unpatched vulnerabilities across consumer and small-office hardware — the routers, NAS appliances, printers, cameras, and smart-home hubs that sit quietly at the edge of your network and inside your employees' home offices. None of these flaws had public patches when they were demonstrated on stage. That's the uncomfortable math of Pwn2Own: for the next 90 days (the standard disclosure window Trend Micro's Zero Day Initiative gives vendors), your perimeter-adjacent devices are running code that some of the best offensive researchers in the world have already proven exploitable — and whose rough shape is now visible to every threat actor watching the contest leaderboard.

I've been on both sides of this. I've watched red teams chain a NAS bug into a domain foothold, and I've led IR engagements where a consumer-grade router in an executive's home office was the initial access broker's entry point. The defensive lesson from every Pwn2Own is the same: you cannot patch your way out of the first 30–90 days. You have to detect and contain your way out. This post is about exactly that.

Technical Analysis

What Pwn2Own Ireland actually targets

Pwn2Own's Ireland event (hosted alongside the EMEA-focused security calendar) concentrates on the embedded/IoT category set rather than enterprise servers. The competitive categories historically include:

• SOHO routers and mesh systems — the WAN-facing chokepoint of remote workers
• Network-attached storage (NAS) — QNAP, Synology-class devices holding backups and file shares
• Printers and multifunction devices — perennially unpatchable, permanently on the LAN
• Surveillance/NVR systems — often VLAN-hopping bridges between physical security and corporate networks
• Smart home hubs and speakers — increasingly present on executive home networks that now carry corporate VPN traffic

The vulnerabilities demonstrated at these events cluster into predictable classes, because embedded Linux firmware keeps making the same mistakes:

1. Memory corruption in network-facing daemons — custom HTTP servers, UPnP/ssdp handlers, and proprietary management services written in C, reachable pre-authentication from the LAN (and sometimes the WAN).
2. Command injection in web management interfaces — unsanitized parameters flowing into system()/popen() calls in CGI binaries. This is the single most common NAS and router bug class we see at Pwn2Own.
3. Authentication bypasses in management APIs — broken session handling, hardcoded tokens, or path-confusion that lets an unauthenticated request reach an authenticated handler.
4. Chained bugs for full compromise — contestants rarely demo one bug; they chain an info-leak or auth-bypass into an RCE primitive to hit the payout tier.

Exploitation status

As of disclosure, these 32 flaws are zero-days under coordinated disclosure — no public PoC, no CVE assignments yet published, no CISA KEV entries. That is the best-case scenario and it is temporary. Historical precedent matters here:

• Pwn2Own-winning bugs routinely appear in CISA KEV within months of vendor patch release, because patch-diffing embedded firmware is fast and the devices are internet-exposed in bulk.
• Botnet operators (Mirai-lineage and successors) specifically mine router/NAS patch notes for command-injection diffs. We've watched exploitation of Pwn2Own-disclosed classes begin within days of patch release in prior cycles — the patch is the exploit's blueprint.
• The attack surface is not hypothetical: Shodan-indexed exposure of SOHO router and NAS management interfaces numbers in the millions globally.

The defensive window is now: after the bug class is known to exist, before the working exploit is public.

Why this hits enterprises, not just consumers

If your organization has remote workers, you have these devices in your trust path. The home router terminates your VPN clients. The home-office NAS may hold synced corporate documents. The printer on the office LAN is a persistence host nobody monitors. In incident response, I treat any unmanaged embedded device on a network segment as a potential adversary foothold by default — Pwn2Own day-one results are the annual reminder of why that posture is correct.

Detection & Response

You cannot write signatures for 32 undisclosed vulnerabilities. What you can do is detect the post-exploitation behaviors that every embedded-device RCE converges on, regardless of which bug delivered it. An exploited router, NAS, or printer behaves in ways a healthy one never does: it spawns shells from web service processes, it makes outbound connections it has no business making, and it pulls payloads from infrastructure that isn't the vendor's. These detections target that convergence point.

Sigma Rules

---
title: Web Service Process Spawning Shell on NAS or Embedded Appliance
description: Detects HTTP/web management service processes spawning command shells or script interpreters — the canonical post-exploitation behavior of command injection and memory corruption RCE against NAS and embedded device web interfaces.
references:
  - https://attack.mitre.org/techniques/T1190/
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
status: experimental
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/nginx'
      - '/httpd'
      - '/apache2'
      - '/lighttpd'
      - '/thttpd'
      - '/uhttpd'
      - '/mini_httpd'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/ash'
      - '/busybox'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/perl'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate vendor backup/sync jobs on NAS appliances may spawn shells from web-triggered tasks — baseline per-device and alert on deviations
  - Firmware update processes (typically short-lived and signed-script based)
level: high
---
title: IoT or Edge Device Initiating Outbound Connection to Non-Vendor Infrastructure
description: Detects embedded devices (routers, NAS, printers, cameras) establishing outbound network connections to destinations outside expected vendor update/NTP/DNS infrastructure — a strong indicator of C2 or payload retrieval following exploitation.
references:
  - https://attack.mitre.org/techniques/T1071/001/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
status: experimental
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1071.001
  - attack.t1105
logsource:
  category: firewall
detection:
  selection:
    src_zone:
      - 'iot'
      - 'guest'
      - 'print'
      - 'camera'
      - 'iot_vlan'
    action: 'allow'
    dst_ip|cidr:
      - '!10.0.0.0/8'
      - '!172.16.0.0/12'
      - '!192.168.0.0/16'
  filter_known_vendor:
    dst_host|contains:
      - 'amazonaws.com'
      - 'ntp.org'
  condition: selection and not filter_known_vendor
falsepositives:
  - Cloud-backup-enabled NAS devices (vendor-specific FQDNs should be allowlisted per deployment)
  - Devices using vendor cloud relay services — build the allowlist from your actual inventory
level: medium
---
title: Download and Execute Pattern via Embedded Shell
description: Detects wget/curl piped to shell or fetching executables from external hosts — the standard payload-staging sequence used after router/NAS command injection, including Mirai-lineage botnet recruitment.
references:
  - https://attack.mitre.org/techniques/T1059/004/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
status: experimental
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
  - attack.t1105
logsource:
  category: process_creation
  product: linux
detection:
  selection_pipe:
    CommandLine|contains:
      - 'wget '
      - 'curl '
    CommandLine|contains:
      - '| sh'
      - '|sh'
      - '| bash'
      - '|bash'
  selection_stage:
    CommandLine|contains:
      - 'wget http://'
      - 'curl -O http://'
      - 'curl http://'
    CommandLine|contains:
      - '/tmp/'
      - '/var/run/'
      - '/dev/shm/'
  condition: selection_pipe or selection_stage
falsepositives:
  - Admin provisioning scripts on managed Linux (rare on embedded devices — tune scope to IoT/NAS hosts)
level: high

The first rule is the workhorse here. A NAS web daemon spawning /bin/sh or busybox is never routine on a healthy box, and it fires on any of the 32 bugs — that's the point of behavioral detection over signatures.

KQL — Microsoft Sentinel / Defender

Embedded devices rarely run EDR agents, so hunt them from the network telemetry they emit — firewall Syslog/CEF ingested into Sentinel, plus Defender for Endpoint network events from adjacent managed hosts.

// Hunt 1: Outbound connections from IoT/edge device segments to rare external destinations
// Tune the subnet list to your actual IoT/printer/camera/NAS VLANs
let IoTSubnets = dynamic(["10.50.0.0/16", "192.168.30.0/24", "172.20.10.0/24"]);
let VendorInfra = dynamic(["pool.ntp.org", "time.google.com"]);
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where ipv4_is_in_range(SourceIP, IoTSubnets[0])
     or ipv4_is_in_range(SourceIP, IoTSubnets[1])
     or ipv4_is_in_range(SourceIP, IoTSubnets[2])
| where not(ipv4_is_private(DestinationIP))
| where DestinationHostName !has_any (VendorInfra)
| summarize ConnectionCount = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            Ports = make_set(DestinationPort),
            Protocols = make_set(Protocol)
  by SourceIP, DestinationIP, DestinationHostName
| where ConnectionCount > 5 or array_length(Ports) > 3
| order by FirstSeen asc;

// Hunt 2: Managed endpoints observing inbound connection attempts FROM embedded devices
// Lateral movement signal: an exploited NAS/printer probing internal hosts
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemoteDeviceName has_any ("qnap", "synology", "diskstation", "router", "printer", "nvr")
     or InitiatingProcessFileName has_any ("sh", "busybox", "wget", "curl")
| where ActionType == "InboundConnectionAccepted" or ActionType == "ConnectionSuccess"
| summarize Connections = count(), Targets = make_set(LocalIP), Ports = make_set(LocalPort)
  by RemoteIP, RemoteDeviceName, bin(TimeGenerated, 1h)
| order by Connections desc;

Hunt 2 catches the scenario that matters most in an enterprise: the compromised embedded device pivoting inward. A printer or NAS initiating connections to workstation SMB/RDP/WinRM ports is a high-fidelity lateral movement signal.

Velociraptor VQL

For managed Linux NAS appliances where you can deploy the Velociraptor agent (or for triage of a Linux jump host adjacent to the IoT segment), hunt for the shell-spawn behavior directly:

-- Hunt for shells and download tools spawned by web service processes
-- Targets the post-exploitation convergence point of embedded device RCE
LET suspicious_children = pslist()
WHERE Name =~ '(?i)^(sh|bash|ash|dash|busybox|curl|wget|nc|ncat|python|perl)$'

SELECT Pid,
       Ppid,
       Name,
       CommandLine,
       Exe,
       Username,
       CreateTime,
       dict(Pid=Ppid) AS _Parent
FROM suspicious_children
WHERE get(item=pslist(pid=Ppid), field='Name') =~ '(?i)(nginx|httpd|apache|lighttpd|thttpd|uhttpd|mini_httpd|cgi)'

-- Companion: enumerate listening sockets on unexpected high ports (bind shells, C2 listeners)
SELECT Pid,
       Name,
       Address,
       Port,
       Status
FROM netstat()
WHERE Status =~ 'LISTEN'
  AND Port > 10000
  AND Name !~ '(?i)(smbd|nfsd|postgres|mysql|docker|containerd)'

Verification & Hardening Script

Run this on a management host (or via your NAC/EDR) to inventory the exposed embedded attack surface and verify basic hygiene across your IoT segments. It audits for internet-exposed management interfaces, UPnP (a perennial Pwn2Own bug vector), and unexpected listeners on discovered devices.

#!/usr/bin/env bash
# Embedded/IoT attack surface audit — run against your IoT, printer, camera, and guest VLANs
# Requires: nmap. Produces a CSV of exposed management surfaces for triage.

SEGMENTS="10.50.0.0/24 192.168.30.0/24"   # <-- replace with your IoT/edge segments
OUT="iot_surface_audit_$(date +%F).csv"

echo "ip,open_ports,services,risk_notes" > "$OUT"

for SEG in $SEGMENTS; do
  echo "[*] Scanning $SEG for management interfaces and UPnP..."
  nmap -Pn -sV --open \
       -p 22,23,53,80,443,1900,5000,5001,8080,8081,8443,9000,9100 \
       -oG - "$SEG" | awk '/Up$/{ip=$2} /Ports:/{print ip" "$0}' | while read -r line; do
    ip=$(echo "$line" | awk '{print $1}')
    ports=$(echo "$line" | grep -oE '[0-9]+/open/[^,]*' | tr '\n' ';')
    notes=""
    echo "$ports" | grep -q '1900/open' && notes="${notes}UPnP-EXPOSED;"
    echo "$ports" | grep -q '23/open'  && notes="${notes}TELNET-ENABLED;"
    echo "$ports" | grep -qE '8080|8443|9000' && notes="${notes}ALT-MGMT-PORT;"
    echo "$ports" | grep -q '9100/open' && notes="${notes}RAW-PRINT-PORT;"
    echo "$ip,\"$ports\",$notes" >> "$OUT"
  done
done

echo "[+] Audit complete: $OUT"
echo "[!] PRIORITY TRIAGE: any host flagged UPnP-EXPOSED, TELNET-ENABLED, or with"
echo "    WAN-reachable management ports. Isolate pending vendor firmware updates."

# Verify outbound containment is working: from a test host on the IoT segment,
# devices should FAIL to reach arbitrary internet destinations.
# Expected result for a properly contained segment: all probes timeout/deny.
echo "[*] Testing IoT segment egress containment (expect failures)..."
for probe in "1.1.1.1:80" "8.8.8.8:53"; do
  host="${probe%%:*}"; port="${probe##*:}"
  timeout 5 bash -c "</dev/tcp/$host/$port" 2>/dev/null \
    && echo "  [FAIL] Egress to $probe is OPEN — review firewall policy" \
    || echo "  [PASS] Egress to $probe is blocked"
done

Remediation

There are no patch links to hand you yet — that's the definition of a zero-day disclosure window. Your remediation plan is layered containment until vendor firmware ships, then aggressive patch velocity after:

1. Inventory and isolate (this week). You cannot protect what you haven't enumerated. Run the audit above across every segment hosting embedded devices. Move routers, NAS, printers, cameras, and smart devices onto dedicated VLANs with deny-by-default egress and no route to corporate workstation/server segments except explicitly required flows (e.g., print spooling through a hardened print server — never direct client-to-printer).
2. Kill the easy bug classes. Disable UPnP on every router (it is a recurring Pwn2Own exploitation vector and has no business being enabled). Disable Telnet. Restrict management interfaces to a dedicated admin VLAN or, for home-office guidance, LAN-side only — verify no management port is forwarded or exposed to the WAN. Turn off remote administration features on NAS devices unless tunneled through your VPN.
3. Deploy the detections above now. The Sigma web-daemon-shell rule and the IoT-egress KQL hunt are your early warning for the entire 90-day disclosure window and beyond. They detect the bug class, not a specific CVE — they remain valuable after patches ship.
4. Track the ZDI disclosure pipeline. Subscribe to the Zero Day Initiative's published-advisories feed. As each Pwn2Own finding matures into a ZDI advisory and then a vendor patch (typically within the 90-day window), you get CVE numbers, affected firmware versions, and fixed builds. Queue these as emergency changes, not standard patch-cycle items — embedded-device command injection is exactly what botnet operators patch-diff first.
5. Patch within 72 hours of vendor firmware release. The exploitation curve for Pwn2Own-disclosed bugs is measured in days after patch release, not months. Establish firmware update procedures now for devices that are normally set-and-forget — many have never received an update since installation.
6. Extend policy to remote workers. Publish guidance for staff home networks: current firmware on the router, UPnP off, admin interface on LAN only, ISP-provided gateways replaced or bridged where possible. Your VPN terminates at their router; their router's hygiene is your perimeter's hygiene.
7. Plan for end-of-life devices. Any device past vendor support that appears in your audit is unpatched forever. Replace it. A $200 router is cheaper than an IR engagement — I have priced both.

The broader lesson Pwn2Own reinforces every year: the embedded edge is your softest surface and your least monitored one. Thirty-two zero-days in a single day isn't an anomaly — it's an annual audit result the offensive community hands you for free. The organizations that treat the disclosure window as a detection-and-segmentation exercise, rather than waiting passively for patches, are the ones that never call me for the incident that follows.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub