Was doing a routine check on our middleware layer logs and Prolexic flagged this sequence. It's hitting a non-public API endpoint we use for syncing CRM contacts to our ERP. The pattern looks like a probe, not a full attack.
Here's the sanitized log snippet Prolexic surfaced:
```
2024-03-15T04:18:22Z GET /api/v1/internal/sync?type=contact&id=1
2024-03-15T04:18:23Z GET /api/v1/internal/sync?type=contact&id=2
2024-03-15T04:18:24Z GET /api/v1/internal/sync?type=contact&id=3
2024-03-15T04:18:25Z GET /api/v1/internal/sync?type=contact&id=4
...
2024-03-15T04:18:31Z GET /api/v1/internal/sync?type=contact&id=99
2024-03-15T04:18:32Z GET /api/v1/internal/sync?type=order&id=1000
```
Key details from the Prolexic dashboard:
* Source IP was a known proxy/VPN pool.
* User-Agent string was generic `curl/7.68.0`.
* Rate was exactly 1 request per second, perfect for avoiding simpler rate limits.
* Stopped after the `type=order` call, like they got what they wanted.
Prolexic dropped the traffic after the 10th request, tagged it as "probing for application structure." The fact it was looking for sequential IDs and then switched entity types (`contact` to `order`) is the tell.
My takeaway:
* The protection worked, but it exposed a design flaw. This internal sync API shouldn't be exposed directly. Moving it behind our Workato middleware, accessible only via a queue/job, would be better.
* Prolexic's strength here is catching the *pattern*, not just the volume. A simple rate limit might have missed this.
Anyone else seen probes that look like this? More importantly, how are you structuring internal APIs to avoid this exposure in the first place? I'm leaning towards "zero direct access, all through the integration platform."
Integration is not a project, it's a lifestyle.
The sequential ID probing is a classic recon pattern, but what's interesting here is the switch from `contact` to `order`. That's an attempt to map your data model's relationships or key structure. They're checking if IDs are shared across entity types (like a global incrementing ID) or are entity-specific.
Since Prolexic already dropped it, the immediate threat is contained. But this should trigger a review of that internal endpoint's actual access controls, not just its obscurity. Is it guarded by an internal network policy, an API gateway with strict allow-lists, or just a "don't tell anyone" secret? A true internal sync endpoint shouldn't be reachable from a VPN/proxy pool at all.
You'll also want to check for any correlating events in your CRM or ERP audit logs around that timestamp. Sometimes these probes run concurrently from another ingress point to validate data changes.
- Mike
Spot on about the pattern. The switch from `contact` to `order` is the real kicker - it's not just about finding IDs, it's about understanding how your data is linked.
Prolexic dropping the traffic is great for defense, but this is a solid nudge to look at why that endpoint was reachable. I've seen "internal" APIs that were only protected by being unadvertised, which is basically security through obscurity.
Since your middleware flagged it, can your team trace if any of those specific IDs were accessed or modified in the CRM or ERP around that same time? That could tell you if the probe was just mapping or if it had a more specific data target.