giip
SES Proposal
Security monitoring

Signature detection stayed silent. GIIP sec-watch caught the reconnaissance campaign — and proved it never got in.

Verified customer engagement

Environment
A beauty & cosmetics company with roughly ¥180 billion in annual revenue, running hundreds of servers across the web, application and database tiers — already protected by a WAF with managed signature rule groups and a large in-house security monitoring operation.
Challenge
Signature detection only fires on payloads it already knows. On 2026-11-06, a single external source ran an 83-minute reconnaissance campaign — OAuth endpoint probing, an SSRF attempt using an external callback service, a working XSS payload, rotation of ten User-Agents inside the same millisecond, canary brute-forcing of paths and query parameters, and finally probing of authenticated areas (/login, /dashboard). The WAF's managed signature rule groups (SQLi, Common, PHP, Known Bad Inputs) did not react to any of it. The requests were stopped only by an IP allowlist rule — not by attack detection. Seeing the attempt was not the same as knowing what it was, whether it succeeded, or what it touched.
AI-automated
GIIP sec-watch (Jev-based second-stage verdicts over WAF, CDN and database audit logs) surfaced 30 suspicious events from this environment in two sweeps on the same day. The monitoring machine then cross-checked every verdict against the original records — WAF logs, CDN logs and database audit logs, quoted verbatim — and rebuilt the full timeline. It separated the 30 events into four groups with evidence for each: the 21-event malicious campaign (all blocked at the WAF, origin never reached); 7 manual injection-character tests against a real content ID arriving through an allowlisted legitimate client path (allowed through, origin reached with 200/301 responses, actor unconfirmed — reported as "caution", not silently passed); and 2 false positives (a normal internal CMS operation, and a known mis-registration in the monitor's own IP list), each cleared with its basis. The report stated the investigation scope, the attack patterns, whether each attack succeeded, and what was targeted — with confirmed facts and inferences kept explicitly separate, plus concrete follow-ups (an explicit deny-list entry, server-side validation of the tested parameter, removal of the mis-registered IP).
Human review
Decisions and changes stayed with people: whether to add the source to an explicit deny list, whether to ask the legitimate client about the injection tests on its path, and the server-side validation change were handed to the customer's team as proposals with evidence — the report draws the line at verified facts and recommendations, and does not silently change a production security policy.
Result
Same day, the customer had a verdict for all 30 events: the campaign never reached the origin and there was no evidence of data extraction; the two false positives were closed as normal operations; and the one realistic risk path — an allowlisted client route with no signature detection behind it — was named explicitly, with the parameter to validate. Detection raised the events; the investigation is what turned them into decisions.

Services used in this story

Discuss your environmentSee all customer stories