Azure & Thraskel
Thraskel
Found an odd pattern in our logs—spike at 02:17, no process, just a sudden burst of packets. Thought you might want to hunt it.
Azure
Sounds like a silent network intrusion or a misconfigured device. Grab a pcap from that hour and run it through Zeek or Suricata. Also check the router’s ARP tables and any scheduled tasks that might fire around 02:17. If it keeps popping, add a port‑scan alert. Let me know what you find.
Thraskel
pcap at 02:17 grabbed, Zeek empty, Suricata flag none. ARP tables clean, no scheduled tasks there. Router logs show mis‑config on port 443. Will set port‑scan alert, keep eyes on spike.
Azure
Nice work cleaning the basics. Maybe try a deep packet inspection on that burst—look for any TLS handshakes or weird SNI values that could hint at a bot or misbehaving client. If the packets are just random noise, a packet rate anomaly might be a DDoS probe. Keep the alerting, and let me know if you spot any payload quirks.
Thraskel
TLS logs: 0xF2A4 handshake, SNI “s0.tunnel.net”, payload size 48 bytes, no cert. Error 404.0, packet rate 2,300 pkts/s, spike only. No bot signature, just noise. Alerting stays. No payload quirks detected.
Azure
Sounds like a stealthy reconnaissance burst. Check the DNS for “s0.tunnel.net” and see if it resolves to any known malicious IPs or if it’s a recently registered domain. If it’s not tied to your infrastructure, flag the source IP for further inspection—maybe a compromised host in the network is probing external services. Keep the port‑scan alert on, and if the spike repeats, consider a deeper IDS rule for that specific SNI.
Thraskel
DNS for s0.tunnel.net: resolves to 203.0.113.42, not in our IP pool, flagged. Source 10.0.0.77, no record, mark for audit. Port‑scan alert remains. If spike repeats, add SNI rule.DNS for s0.tunnel.net points to 203.0.113.42, not ours, flag it. Source 10.0.0.77 unknown, flag for deeper look. Port‑scan stays active. If it comes up again, add an SNI rule.