- Join Our Company
- Email: sales@pjnetworks.com
- Phone: +91-9818361787
When we tell prospects about the value of 24/7 monitoring, their first question is usually: “What would you actually catch that we wouldn’t?”
Fair question. Here’s our answer — real incidents from our SOC, anonymised. All detected during overnight or weekend shifts, by engineers who were watching when nobody else was.
Client: Multi-site retail chain (Pan-India)
When: Sunday, 3:17 AM
Detection: SNMP trap from a critical switch showed unexpected cold start. Within 30 seconds, our NMS flagged it as “unusual reboot — not within maintenance window.”
What happened: An automated firmware update pushed by the vendor had triggered a rollback. The switch came back online but with a mismatched configuration — VLANs were missing, trunk ports were down, and 12 stores in one region had lost connectivity to the central inventory system.
Outcome: Our engineer alerted the client within 4 minutes of the reboot. The client’s network team had the switch reconfigured by 4:00 AM. All 12 stores were back online before opening hours. No revenue impact.
Would the client have caught it? The client had no after-hours IT staff. The first sign would have been store managers calling at 8 AM to say the POS system wasn’t working. Estimated detection time: 5 hours after the incident. Revenue impact: significant.
Client: Financial services firm (Mumbai HQ)
When: Tuesday, 11:47 PM
Detection: SIEM correlation rule triggered on 47 failed SSH authentication attempts from a single IP over 3 minutes. The source IP was in a country where the client had no operations.
What happened: A brute force attack targeting a perimeter firewall’s management interface. The attacker was cycling through common usernames, attempting 15 logins per minute. Our SOC traced the pattern: same IP had scanned the client’s public IP range 2 hours earlier, then returned to target the management interface specifically.
Outcome: Our engineer added a block rule on the upstream firewall and notified the client. The attack continued for 47 more minutes from different source IPs — all blocked. Total failed attempts blocked: 1,283 across 5 source IPs. Total exposure: 0 successful logins.
Would the client have caught it? Their SIEM would have logged it. But they had no after-hours SOC to review the logs until the next morning. By then, the attacker would have either gained access or moved on to another target. Worse — if one attempt had succeeded, the attacker would have had 8+ hours of undetected access before morning review.
Client: Healthcare provider (4 hospitals)
When: Saturday, 1:15 AM
Detection: NMS showed a critical hypervisor host at 94% CPU with unusual disk I/O patterns. The automated backup job had been failing silently for 6 days — the vendor’s monitoring dashboard showed “success” for each job, but the actual data wasn’t being written to the backup target.
What happened: A configuration drift between the backup software and the storage target had caused backups to appear to succeed while actually producing empty archives. Patient records, clinical databases, and EMR data — all the crown jewels of a healthcare provider — hadn’t been backed up in nearly a week.
Outcome: Our NMS detected the anomaly via CPU and I/O patterns that didn’t match a normal backup cycle. We alerted the client’s IT manager, who confirmed the backup failure, re-ran the full backup, and resolved the configuration mismatch. Full backup restored within 3 hours.
Would the client have caught it? The backup software said “100% successful” every day. Only a unit-level health check — looking at actual data written, not just process completion — caught the discrepancy. Without cross-layer monitoring, they would have discovered the gap during a restore scenario. The worst possible time to discover you have no backups.
Client: Manufacturing company (3 plants)
When: Thursday, 3:32 AM
Detection: SOC analyst noticed a VPN connection from an unusual geographic region authenticating to the vendor access network. The account was legitimate — a vendor technician — but the source IP didn’t match the vendor’s known office ranges.
What happened: A third-party vendor’s technician credentials had been compromised. The attacker was using the VPN to map the client’s industrial control network. Our SOC identified the anomalous login, cross-referenced it with the vendor’s registered office IPs, and flagged it as a probable credential theft.
Outcome: VPN session terminated. Vendor notified. Credentials reset. Forensic review confirmed no data exfiltration occurred. The client instituted MFA on all vendor VPN accounts the same day.
Would the client have caught it? The VPN was set to “always allow” for the vendor’s account group. Without behavioural monitoring — looking at where a login comes from, not just whether the credentials are valid — this attack would have succeeded. The vendor had no idea their credentials were compromised until we called them.
Every one of these incidents had one thing in common: they were detected within minutes by a SOC that was watching, correlating, and thinking — not just collecting logs.
We’re not sharing these to scare you. We’re sharing them to show what 24/7 monitoring actually catches: the firmware updates that go wrong at 3 AM, the brute force that nobody sees until morning, the backup that lies to you, the vendor account that becomes a backdoor.
These aren’t exotic nation-state attacks. They’re the daily reality of running an enterprise network — and they happen when nobody is watching.
Talk to P J Networks about 24/7 NOC/SOC monitoring for your organisation. We’ve been watching networks for 30 years. We don’t miss much.
P J Networks. 24/7 NOC and SOC operations. Since 1996.