# Incident Report — IR-2026-003 | Field | Value | |-----------------|-------| | **IR ID** | IR-2026-003 | | **Date/time** | 2026-05-14 02:11 UTC | | **Severity** | Low | | **Status** | Closed | | **Category** | Misconfiguration — blocked traffic generating scan alert | | **Source host** | 192.168.10.11 (ws02, VLAN 10 — Users) | | **Target** | 192.168.20.10, 192.168.20.20, 192.168.20.30 (VLAN 20 — Servers) | | **Protocol** | TCP port 22 (SSH) | | **Firewall action** | Blocked — rule `users-default-deny` (SSH not in permitted User→Server flows) | --- ## 1. Detection **T+0 — 02:11:08 UTC** Suricata fires `ET SCAN Potential SSH Scan OUTBOUND` (SID 2001569). Alert appears in syslog-ng at 192.168.20.30, source 192.168.10.11, destinations: 192.168.20.10, 192.168.20.20, 192.168.20.30. Three distinct targets, repeated attempts over ~180 seconds. Suricata alert detail: ``` 05/14/2026-02:11:08 [**] [1:2001569:20] ET SCAN Potential SSH Scan OUTBOUND [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.10.11:52341 -> 192.168.20.10:22 BLOCKED (pfSense label: users-default-deny) ``` pfSense filter log (excerpt, `/var/log/filter.log`): ``` May 14 02:11:08 pfsense filterlog: 5,,,1000000103,em2,match,block,in,4,0x0,,127, 51243,0,DF,6,tcp,60,192.168.10.11,192.168.20.10,52341,22,0,S,4045123456,,64240,, May 14 02:11:11 pfsense filterlog: 5,,,1000000103,em2,match,block,in,4,0x0,,127, 51301,0,DF,6,tcp,60,192.168.10.11,192.168.20.20,52401,22,0,S,4045124102,,64240,, May 14 02:11:14 pfsense filterlog: 5,,,1000000103,em2,match,block,in,4,0x0,,127, 51362,0,DF,6,tcp,60,192.168.10.11,192.168.20.30,52468,22,0,S,4045124899,,64240,, ``` **Key observations from the log:** - Rule ID `1000000103` = `users-default-deny` on em2 — traffic is already blocked, no active threat. - TCP flags `S` only — SYN packets, never completing a handshake. - Three distinct destinations across VLAN 20; systematic, not random. - Source port increments predictably — consistent with a single process iterating a host list. --- ## 2. Triage **T+5 — 02:16 UTC** Queried pfSense state table to confirm no established sessions from 192.168.10.11 to port 22: ``` pfctl -s state | grep "192.168.10.11.*22" # (no output — all attempts blocked, no state established) ``` Confirmed: no breach, no lateral movement. Severity downgraded to Low. Alert pattern (sequential host scan, single port) is consistent with an application iterating a configured host list rather than human-operated tooling. --- ## 3. Investigation **T+10 — 02:21 UTC** Queried syslog-ng for all activity from 192.168.10.11 in the prior 30 minutes: ```bash grep "192.168.10.11" /var/log/syslog/hosts/192.168.10.11/current | \ awk -F'\t' '{print $1, $5}' | tail -40 ``` Found entries from the Veeam Agent for Linux process starting at 02:08 UTC: ``` 2026-05-14T02:08:31Z ws02 veeamagent[3421]: Starting backup job "Daily-Servers" 2026-05-14T02:08:31Z ws02 veeamagent[3421]: Probing targets: 192.168.20.10, 192.168.20.20, 192.168.20.30 2026-05-14T02:08:32Z ws02 veeamagent[3421]: Transport: ssh (configured), port 22 2026-05-14T02:08:33Z ws02 veeamagent[3421]: ERR connect 192.168.20.10:22 — Connection timed out ``` Root cause identified: **Veeam Agent was updated to version 6.2 on 2026-05-13.** The update changed the default transport for managed mode from the application port (9443) to SSH-based transport. The agent's configuration file was not reviewed post-update and still pointed to the full VLAN 20 subnet scan for auto-discovery. The backup agent was trying to SSH to all three server-subnet hosts to negotiate backup transport. All attempts blocked correctly. **No compromise. No data exfiltration. No escalation.** --- ## 4. Containment **T+20 — 02:31 UTC** No active threat — firewall was already blocking all connection attempts. Containment action: confirm the block is in place (done at T+5). Documented the source process; no need to isolate the host. Scheduled the backup job to be disabled until the agent is reconfigured. ```bash # On ws02 (via management VLAN SSH from 10.0.30.5) systemctl stop veeam systemctl disable veeam # temporary until config corrected ``` --- ## 5. Eradication **T+35 — 02:46 UTC** Corrected Veeam Agent configuration on ws02: ```ini # /etc/veeam/veeam_config.xml (relevant section, before) # After correction ``` Verified the agent probe succeeds against 192.168.20.30:9443 (no firewall rule for this yet — adding via CR): ```bash nc -zv 192.168.20.30 9443 # Connection refused — port is open on server, rule not yet added ``` --- ## 6. Recovery **T+45 — 02:56 UTC** Filed **CR-2026-016**: permit TCP from 192.168.10.11 to 192.168.20.30 port 9443. Rule added to baseline.rules (label: `users-backup-agent-explicit`). Backup agent re-enabled and job run confirmed: ```bash systemctl start veeam veeamconfig job start --name "Daily-Servers" # Job completed successfully at 03:14 UTC ``` Suricata alert confirmed silent after config correction. --- ## 7. Lessons learned | Finding | Action | |---------|--------| | Backup agent update changed transport silently | Add post-update review step to change management process for any endpoint software that opens network connections | | `users-default-deny` rule was blocking correctly but without a named block rule for SSH specifically, audit logs required a rule-ID lookup | Added explicit `users-no-ssh-to-servers` block rule with a clear label for faster future triage | | Auto-discovery scan against all VLAN 20 hosts is unnecessary | Veeam configured to target only 192.168.20.30; principle of least access applied to backup target list | | Alert fired correctly; triage took 10 minutes | Acceptable for a non-critical low-severity alert; no SLA breach | **Time to resolve:** ~65 minutes from alert to job verified clean. **Impact:** Zero. All traffic blocked; no services degraded. --- *Closed: 2026-05-14 03:20 UTC — Alex Chmiel*