I thought we were investigating “attacks targeting Japan’s Golden Week,” but what I found was a global-scale bot economy
1. Introduction — Investigation that started from intuition #
“It feels like the number of blocked attacks has been decreasing lately.”
About one month into production operation of BASTION. We heard this comment internally. Was it just a feeling, or was there actually a real decline in attacks? — While analyzing the attack logs with this in mind, we discovered that **an abnormal spike occurred on May 1, 2026**.
About 40,000 blocks occurred on that single day — triple the normal daily volume.
However, as we dug deeper into the data, a completely different story emerged. This article is a record of that “true-story investigation.”
2. Hypothesis verification — The Japan-targeting theory was refuted #
If this were “an attack targeting Japan’s Golden Week,” we should have seen an increase in reconnaissance activity from neighboring countries (China, Korea, Russia). But the data showed otherwise.
| Country | May 1 ratio | Normal day (May 8) ratio | Difference |
|---|---|---|---|
| US | 33.5% | 54.6% | -21.1% |
| RU | 2.9% | 8.3% | -5.4% |
| CN | 2.0% | 4.8% | -2.8% |
| JP | 0.0% | 0.7% | -0.6% |
| (Unknown origin) | 48.3% | 22.5% | +25.8% |
The ratios from neighboring countries actually decreased. What increased instead was a group of “unknown small-scale ASNs.” This alone disproved the “Japan-targeting theory.”
Furthermore, the events captured by web server-level Agents were actually lower on May 1st (432 lines vs. 570 lines on a normal day). The true nature of the spike was L1/L4 TCP port scanning, not a campaign targeting Japanese websites.
So, **what exactly were these “unknown ASNs”?** This is where the investigation entered its serious phase.
3. Identifying the “unknown ASNs” one by one #
We used only publicly available information. Specifically:
- Team Cymru’s whois service — ASN-to-organization mapping
- Spamhaus DROP / EDROP / ASNDROP lists — known bot infrastructure
- Tor Project’s Exit Node list — anonymized communications detection
With just these, you can dig remarkably deep. No commercial licenses required.
Our investigation target was 41 ASNs that stood out in the May 1st spike. These exposed the structure of a global-scale bot economy.
4. The biggest discovery — the prime suspect was Namecheap #
In preliminary investigation, one of the top attack sources in the May 1st spike was **AS22612**, an “unknown” ASN. It triggered 1,152 events in a single day.
When we looked it up on Team Cymru:
AS22612 | US | arin | 2011-06-21 | NAMECHEAP-NET - Namecheap, Inc., USNamecheap — a domain registrar and VPS provider. A world-renowned company, but known in security circles for slow abuse response, making it popular with attackers.
What was even more interesting was the behavioral pattern. AS22612 appeared on only 4 days out of 30, and on May 1st alone it accounted for 99% of all its events (1,152/1,163). This is classic behavior of a “disposable VPS rented just for May 1st.”
5. The 3-layer structure of bot infrastructure #
As we progressed, we discovered that the attack sources participating in the May 1st spike fell into three distinct layers.
| Layer | Nature | May 1 ratio | Representative examples |
|---|---|---|---|
| Layer 1 | Disposable infrastructure (Use-and-burn) | 44% (18 ASNs) | IOFLOOD, Biznet, Layerstack, OFFERHOSTINC, etc. |
| Layer 2 | Bulletproof hosters | 32 ASNs participated | Aeza (RU), Stark Industries (MD), DMZHOST (SC), etc. |
| Layer 3 | Persistent major cloud providers | 46% (19 ASNs) | Google Cloud, AWS, DigitalOcean, Linode, etc. |
5.1 Layer 1: Disposable infrastructure — “Attack infrastructure that vanishes in 24 hours” #
Rented short-term from budget VPS providers worldwide, operating only on attack day and then disappearing. The providers we identified include IOFLOOD (USA), Biznet (Indonesia), Layerstack (Hong Kong), Rackforest (Hungary), Wolast (Bangladesh), SKSA (Malaysia) — distributed globally.
What was particularly interesting: AS208220 (OFFERHOSTINC, Seychelles). ASN registration date: May 19, 2025 — just six months before the May 1st attack. Attackers are constantly replenishing their infrastructure.
5.2 Layer 2: Bulletproof hosters — 32 providers officially designated by Spamhaus as “bot operation infrastructure” #
These are providers officially registered on the Spamhaus ASN-DROP list (Spamhaus’s official list of ASNs determined to be “botnet operation infrastructure”).
Of these, the ones participating in the May 1st spike were:
- Aeza (Russia)
- Stark Industries (Moldova)
- PROSPERO (Russia)
- DMZHOST (Seychelles)
- STORMINDUSTRIES (Luxembourg)
- IP Volume Inc (Netherlands)
- VPSVAULTHOST (United Kingdom)
- Serverion (Netherlands)
- 24 others
These operate on a business model that ignores abuse reports and charges attackers premium rates. Known as bulletproof hosting, they function as legitimate gray-zone businesses at global scale.
Geographic distribution (ASN count by country): GB 6, DE 3, HK 3, NL 2, UA 2, MD 2, SC 2, BG 2, RO 2, US 2, RU 2, LT 1, LU 1, SG 1, IR 1. **Concentrated in jurisdictions with ambiguous legal authority.**
5.3 Layer 3: Persistent major cloud — “background noise” in continuous operation #
Google Cloud, AWS, DigitalOcean, Linode, Vultr, Hetzner, OVH, Contabo — major cloud providers anyone can use. These showed activity for all 30 days, with activity multiplied several times on May 1st.
Since legitimate customers and attackers share the same infrastructure, ASN-level blocking is not an option. We must observe individual IP behavioral patterns and identify only malicious VM instances.
6. Tor was 0% — Economic rationality over anonymity #
One surprising finding in our investigation was Tor’s usage rate.
Tor exit node matches: 0 / 5,317 IPs (0.000%)Attackers were not using anonymization networks like Tor. The reason is obvious: Tor is slow, has bandwidth limits, and is unsuitable for bot scanning. Instead, “disposable VPS is more economically rational” — even if tracked, just use it up and move on.
7. Behavioral pattern analysis — “Infrastructure nature” revealed by persistence #
Using 30 days of logs, we analyzed whether each ASN appeared on days other than May 1st.
| Category | Days active | ASNs | Infrastructure nature |
|---|---|---|---|
| A. May 1st only | 1 day | 18 (44%) | Disposable VPS |
| B. Hit-and-run | 2-3 days | 4 (10%) | Short-term campaign |
| E. Persistent (both sides) | 4+ days | 19 (46%) | Always-on infrastructure |
The “burn rate” is 53.7%. Over half of the ASNs operated with short-term consumption models.
The 19 ASNs with persistent activity were mostly Google Cloud / AWS / DigitalOcean / Vultr / Hetzner — large cloud providers where legitimate customers and attackers coexist. This means “distinguishing only the malicious instances” is necessary.
8. Implications for defense — BASTION design decisions proved correct #
This investigation revealed that several of BASTION’s design decisions were, in retrospect, the right choices.
8.1 Automatic expiring TTL aligns with “disposable cycles” #
BASTION intentionally implements automatic expiration of intentional blocks with finite TTL. Initially decided to “prevent permanent false positive registration,” but in retrospect this aligned with the typical lifespan of attack infrastructure — a rational design decision.
8.2 ASN-level detection, not individual IP blocking, is essential #
Disposable VPSs change IPs every 24 hours. Chasing individual IPs is futile. Capturing behavior patterns where multiple IPs in the same ASN perform diverse scans simultaneously allows detection even when IPs change. BASTION implements this exact approach through group correlation detection with ASN-level grouping.
8.3 Integration with Spamhaus ASN-DROP #
Spamhaus officially identifies 410 ASNs as bulletproof hosters. Traffic from these can automatically be treated as suspicious. BASTION plans to implement automatic ASN-DROP list ingestion with increased sensitivity in future updates.
8.4 The value of 24/7 automatic defense #
Since attacks concentrate during times when SOC personnel are reduced, a defense system that functions automatically without human presence is essential. BASTION was designed from the start with this premise.
9. Lessons — What became visible from a “probably nothing” investigation #
An offhand internal comment — “attack blocks seem to be decreasing” — led to an investigation that ultimately made visible the structure of a global-scale bot economy.
Summarizing the findings:
- The May 1st spike was not Japan-targeted, but rather a surge in global bot activity
- The main culprit was disposable attacks using Namecheap VPSs rented for 24 hours
- Cheap VPSs worldwide are being consumed en masse as attack infrastructure
- 32 Spamhaus-designated bulletproof hosters participated on the day
- Zero Tor usage, all VPS-based — modern attackers operate by economic rationality
- BASTION’s automatic expiring TTL, ASN-level detection, and 24/7 automatic defense ultimately proved to be correct design choices against this “disposable economy”
To our initial question: “Did the reduced block count mean BASTION is working?” — we cannot yet say definitively. 30 days of data is too short. We must continue the same observations through other extended holidays (Obon, year-end/new year) and confirm repeatability.
However, the insights gained during investigation proved more valuable than the answer to the original question.
10. Future direction #
- Repeatability confirmation during Obon (Aug 13-15) and year-end/new year (Dec 29 – Jan 4) — whether similar spikes occur during Japan-specific holidays
- Automatic ASN-DROP ingestion from Spamhaus — integration into BASTION sensitivity determination
- Algorithmization of “short-term VPS campaign detection” — mechanically identify “ASNs that conduct high-volume scanning over short periods”
- Calendar-linked automatic sensitivity adjustment — stricter thresholds before/after holidays
We will address these sequentially. BASTION’s evolution continues.
11. Related articles #
- How multilayer correlation campaign detection works — Theoretical foundation of ASN-level detection
- DMZ Agent and verification engine — Defense at the public web server level
- Implementation record: achieving accuracy and decisiveness with local LLM infrastructure log auto-analysis — LLM foundation supporting analysis
- Evolving BASTION from “security product” to “AI Ops Platform” — The evolution story of BASTION overall
12. Contact #
For organizations considering BASTION deployment or interested in joint demonstration programs, please contact us via the contact form.
Analyses like “statistical analysis of production logs” described in this article can be provided as quarterly reports to BESTNET customers. We will provide proposals based on custom pricing according to scope.