NSDC logo

BRICS 2026 – AWS WAF Monitoring & Threat Detection

Securing uninterrupted access across a high-visibility global event

~ 20M

Requests Monitored

~ 500K

Malicious Requests Blocked

189

Hourly Checkpoints

0

Downtime

Client Overview

Digital India Corporation (DIC) supported the digital presence for BRICS 2026, a high-visibility international summit hosted in India that attracted global media, diplomatic, and public attention. The digital presence needed to remain secure and continuously accessible across the summit, including its public website, media and document delivery, and backend services.

Client

Digital India Corporation (DIC)

Industry

Government & Public Sector

Requirement

Provide continuous, evidence-based security monitoring for DIC’s digital presence for the BRICS 2026 summit, with visibility across three production AWS WAF Web ACLs and proactive identification of abnormal traffic and emerging threats.

Have a similar requirement?

Get in touch with us →

Executive Summary

At the BRICS 2026 summit - a high-profile global event hosted in India - the Security Operations team delivered continuous, hour-by-hour AWS WAF monitoring across three production Web ACLs protecting DIC’s digital presence for the event. Across 3 days, checkpoints and roughly 20 million requests, 97.4% of traffic was legitimate global visitor activity that reached the site without friction, while nearly 500k malicious or automated requests (2.5%) - including a coordinated SSRF and credential-harvesting campaign and a sustained overnight reconnaissance run - were identified and blocked. The outcome: zero downtime, zero confirmed impact to legitimate users, and full confidence in the WAF's layered defence for the duration of the event.

About BRICS 2026 & The Security Challenge

DIC’s digital presence for BRICS 2026 supported a high-visibility, high-traffic international summit hosted in India, drawing global media, diplomatic, and public attention. Events of this profile carry an elevated threat profile:

  • Total vs. Allowed vs. Blocked request volume, per Web ACL
  • The top rule of concern for that hour and its rule-hit count
  • The top source IP and country associated with that activity, and the top targeted URI/path
  • Dedicated spike flags: Rate-Limit Spike, SQLi / Bad-Input Spike, Login/Admin Attack
  • An AI-assisted traffic-pattern read ('Normal' / 'Watch'), validated against AWS WAF Sampled Requests

Given this, uninterrupted availability and integrity of the event's web presence - public site, media/document delivery, and backend services - depended on WAF monitoring being proactive and evidence-based rather than reactive.

Our Monitoring Approach

The team ran hourly, 24×7 monitoring across all three shifts (Day / Evening / Night) for the full event window, staffed by a six-analyst rotation, generating 189 hourly log entries across the three Web ACLs. Each hourly check captured:

  • Total vs. Allowed vs. Blocked request volume, per Web ACL
  • The top rule of concern for that hour and its rule-hit count
  • The top source IP and country associated with that activity, and the top targeted URI/path
  • Dedicated spike flags: Rate-Limit Spike, SQLi / Bad-Input Spike, Login/Admin Attack
  • An AI-assisted traffic-pattern read ("Normal" / "Watch"), validated against AWS WAF Sampled Requests

Dashboard checks were completed and sampled-request validation was performed — evidence of consistent monitoring discipline rather than spot-checking. Per the team's runbook, L1 analysts identified and escalated anomalies but never modified WAF rules, IP sets, rate limits, or Count → Block settings directly; all such changes required L2/L3 approval.

Rule-Group Effectiveness

The monitoring covered multiple AWS WAF rule groups, including four AWS Managed Rules for anonymous IPs, bot activity, IP reputation, and known bad inputs, along with multiple custom rules for geo-based blocking, rate limiting, and malicious IP addresses.

Key Threats Observed & Mitigated

  • Geo-Based Blocks - IP Rule

    The custom geo-blocking rule was the top rule of concern in 34 hourly checkpoints, blocking nearly 500k requests in total. Traffic concentrated on WordPress media/upload paths rather than sensitive endpoints - e.g., 202 requests blocked from a source targeting a media upload path at 01:00–02:00 on 12-Sep, and 4,080 blocked from a source at 14:00–15:00 on 11-Sep. Analyst notes consistently confirmed no accompanying rate-limit, SQLi, or login abuse - the rule cleanly separated out-of-policy geographies without collateral impact on legitimate traffic.

  • Anonymous IP / Hosting-Provider Bots

    AWSManagedRulesAnonymousIpList was the single most frequently triggered rule of the event (64 occurrences, 1.15M cumulative hits) - automated scraping and proxy traffic from hosting and VPN infrastructure. A representative spike: 3,180 of 3,240 requests (98.1%) blocked from a source hitting the ALB root path across three separate hourly windows (11-Sep 11:00–12:00; 12-Sep 04:00–05:00 and 16:00–17:00) - the same anonymized source returning repeatedly and blocked every time.

  • IP Reputation & Reconnaissance

    This was the most sophisticated threat category of the event. A 6-IP cluster ran a coordinated scan against waf-alb at 06:00–07:00 on 12-Sep: mass .env/credentials enumeration (91 BlockSensitiveFiles + 74 KnownBadInputs hits) combined with 36 confirmed SSRF attempts against the EC2 instance-metadata endpoint via /fetch, /proxy and /redirect parameters. Every attempt was blocked by BotControl/CommonRuleSet; the event was rated P2/High with clear follow-up actions defined (block the /24 range; verify IMDSv2 enforcement; audit for open URL-fetch/proxy endpoints).

    Related reconnaissance included a similar credential/config-enumeration burst from sources (02:00–03:00 on 12-Sep) probing crypto-wallet files (wallet.json, seedphrase.txt, metamask-vault.json), plus isolated probes for a cloud-service-account file, a known PHPUnit remote-code-execution path, and a command-injection scanner string. Separately, a source drove a sustained multi-hour campaign under AmazonIpReputationList, detailed under Hour-wise Insights below.

  • CommonRuleSet / Bot Control — No-User-Agent Signals

    The BotControlRuleSet's SignalNonBrowserUserAgent signal repeatedly flagged a recurring India-based automated client across five separate hourly windows over three days, plus two "mostly no-user-agent" bursts on 11-Sep (18:00–19:00: 2,220 of 252,990 blocked; 22:00–23:00: 5,500 of 225,310 blocked, the latter rated P3/Medium). Non-browser automation was cleanly separated from genuine visitor traffic without manual intervention.

Given this, uninterrupted availability and integrity of the event's web presence - public site, media/document delivery, and backend services - depended on WAF monitoring being proactive and evidence-based rather than reactive.

Hour-Wise Insights

Malicious activity concentrated disproportionately in overnight hours, while business hours carried the overwhelming bulk of clean, legitimate global traffic:

Window
Night (00:00–06:00)
Total Requests
1,473,946
Block Rate
4.85%
Window
Business Hours (09:00–18:00)
Total Requests
10,125,994
Block Rate
1.66%

Night-time traffic was blocked roughly three times more often than daytime traffic - the pattern expected when automated scanning runs around the clock against a comparatively thin base of legitimate overnight visitors. The clearest example: a sustained campaign against waf-alb between 01:00 and 06:00 on 13 September, flagged under AmazonIpReputationList and targeting backend/config paths including /Kubernetes/.env. Block rates held above 99% for five consecutive hours:

Time Slot (13-Sep)
01:00–02:00
Total Req
10,412
Blocked
10,324
Block Rate
99.15%
Time Slot (13-Sep)
02:00–03:00
Total Req
5,762
Blocked
5,723
Block Rate
99.32%
Time Slot (13-Sep)
03:00–04:00
Total Req
8,096
Blocked
8,043
Block Rate
99.35%
Time Slot (13-Sep)
04:00–05:00
Total Req
14,600
Blocked
14,524
Block Rate
99.48%
Time Slot (13-Sep)
05:00–06:00
Total Req
8,160
Blocked
8,100
Block Rate
99.26%

By contrast, daytime hours reflected strong legitimate global interest in event content: the official New Delhi Declaration PDF alone was fetched and allowed cleanly by visitors from the US, Netherlands, Japan, and Bosnia & Herzegovina across at least ten separate hourly windows - every one of those checkpoints rated a routine, healthy "Informational" traffic pattern.

Impact & Results

AWS Components
WAF-ALB
Total Requests
1,17,70,332
Allowed
1,12,85,777
Blocked
4,67,008
Block Rate
86.8%
AWS Components
WAF-CloudFront
Total Requests
7,526,188
Allowed
7,506,136
Blocked
20,195
Block Rate
0.3%
AWS Components
Total
Total Requests
19,296,520
Allowed
18,791,913
Blocked
487,203
Block Rate
2.5%
  • Zero downtime: No availability-impacting incident recorded across 189 hourly checkpoints.
  • Zero confirmed false positives: No analyst finding across the log identifies legitimate user traffic being wrongly blocked; every escalation-worthy block correlated with a confirmed malicious signature.
  • Disciplined severity distribution: Of 189 checkpoints, 179 were rated Informational, 2 Medium (P3), and 1 High (P2) — a single formal escalation across the entire 72-hour window, resolved without production impact.
  • Risk absorbed at the right layer: The disproportionately targeted waf-alb (83.4% block rate) carried the least genuine user traffic of the three ACLs, meaning the surface most attractive to attackers was also where the WAF absorbed nearly all of the pressure — insulating the high-traffic public site (96.5% allowed) and media/document delivery (99.7% allowed) from any measurable impact.

Protection Pack Rule-Level Activity (Sequential Rules View)

Beyond the top-line Allowed/Blocked totals, the WAF console's Protection Pack activity view traces how traffic actually moved through each Web ACL's rule chain — showing, in sequence, which rule group first matched a request and where it was ultimately allowed, blocked, challenged, or monetized. The three flows below confirm the pattern described above: waf-alb's traffic is absorbed almost entirely by the geo-block, IP-reputation, and bot-control rules before it ever reaches the default action, while waf-cloudfront and waf-alb pass the large majority of traffic cleanly through to Allowed, with only the automated and out-of-policy share peeled off along the way.

Learnings & Recommendations for Future High-Profile Events

  • Pre-authorize a fast-track /24 (or ASN-level) block procedure for confirmed multi-IP coordinated scan clusters, to shorten response time on P2-class incidents such as the SSRF campaign observed here; enforce IMDSv2 account-wide so the same SSRF path can't reach credentials even if a scan gets through.
  • Formalize a "high-interest asset" watch-list (official documents, press releases) so spikes in legitimate global interest are distinguished quickly from scraping activity.
  • Continue the three-shift, hourly, cross-validated (dashboard + sampled-requests) monitoring cadence — it delivered complete, audit-ready coverage with no gaps in this event.
  • Review Count-mode rules ahead of major events and promote to Block where recon patterns justify it before the event window opens, not during it, and standardize analyst observation/severity-tagging conventions to speed up post-event analysis.

Conclusion

BRICS 2026 concluded without a single availability incident across any of the three web properties monitored as part of DIC’s digital presence, despite sustained automated reconnaissance, a coordinated credential-harvesting and SSRF attempt, and geo-targeted traffic throughout the event window. The combination of layered AWS WAF rule groups and disciplined, hourly human monitoring meant that 97.4% of nearly 20 million requests — the world's legitimate interest in the summit — reached the site without friction, while the 2.5% that didn't belong there never got the chance to cause harm. From a security operations standpoint, BRICS 2026 stands as a clear success: real threats were detected early, contained without escalation, and the platform remained fully available to a global audience throughout.

Vishal Deep Prajapati

Vishal Deep Prajapati

Chief Technology Officer, DevOps

Project Delivery Leadership

Vishal Deep Prajapati, CTO at AppSquadz, brings expertise in AWS infrastructure, DevOps, and cloud security. His technical leadership aligns with the demands of high-stakes security operations, such as the BRICS 2026 engagement for Digital India Corporation (DIC), where AppSquadz delivered 72 hours of continuous AWS WAF monitoring, monitored nearly 20 million requests, and blocked approximately 500k malicious requests while maintaining zero downtime.

AWS & Cloud Security • DevOps & Infrastructure Operations • Threat Monitoring • Security & Reliability

Your Next Big Solution Starts Here!

Connect with our experts today and let us help you craft seamless, high-performance solutions that drive success.

Get in Touch with Our Experts

Whether you have a project in mind, a query, or simply want to explore how we can collaborate, we’re here to help.

India (Noida) HQ

8th Floor, Tower B, Bhutani Alphathum, Sector 90, Noida, Uttar Pradesh- 201305

+91-9711440630

India (Hyderabad)

Rajapushpa Summit, ISB Rd, Financial District, Gachibowli, Nanakramguda, Telangana- 500032

+91-9711440630

India (Chennai)

7th Floor: 141, Kandanchavadi, Perungudi, Rajiv Gandhi Salai (OMR), Chennai, Tamil Nadu- 600096

+91-9711440630

USA

2203 Milford Rd, East Stroudsburg, PA 18301, United States

+1-570-234-9288
+1-570-994-3526

UK

3rd Floor, 207 Regent Street, London, Greater London- W1B 3HH United Kingdom


UAE

Office No. 137-B-31, Sultan Business Centre, Oud Metha, Dubai, United Arab Emirates (UAE).


Malaysia

1513A, Wisma UOA 2, Jalan Pinang 50450 Kuala Lumpur W.P. Malaysia


Australia

9-B Grasslands Avenue Craigieburn 3064

+61468283403

Singapore

3 Shenton Way #19-02 Shenton House Singapore 068805


Netherlands

Marsmanlaan 33, 1422CG Uithoorn, Netherlands