A curated collection of articles exploring this topic in depth.
Why Toronto! and Why, Toronto?
One CloudFront edge location dominated the probe traffic by a factor of six. Pulling that thread led to Azure Canada Central and a particular kind of internet scavenger.
The security dashboard breaks down probe traffic by CloudFront edge location. When I looked at the geographic distribution, one bar dominated everything else.
Toronto: 9,727 probe requests. Paris, the next largest: 1,742. That is not a gentle skew. Toronto handled more probe traffic than the next five edge locations combined.
CloudFront edge locations reflect where a request entered the CDN, not where the scanner physically sits. So the question was not "why are attackers targeting Toronto" but "why are so many scanners routing through it?"
The IPs
The probe sources table on the security dashboard lists the top scanning IPs by volume. I started with the most active:
| IP | Hits | Unique paths | Edge location |
|---|---|---|---|
| 20.48.232.178 | 2,151 | 223 | Toronto |
| 20.63.96.180 | 540 | 81 | Toronto |
| 20.151.201.236 | 441 | 99 | Toronto, Montreal |
| 20.220.232.240 | 396 | 72 | Toronto |
| 4.204.200.32 | 366 | 100 | Toronto |
| 20.63.83.113 | 273 | 47 | Toronto, Montreal |
| 20.220.210.206 | 249 | 83 | Toronto |
| 52.138.39.105 | 185 | 100 | Toronto |
Every one of the top eight sources sits in a 20.x.x.x, 4.x.x.x, or 52.x.x.x range. All three are Microsoft Azure allocations.
Azure Canada Central
Microsoft publishes its Azure IP ranges and service tags(opens in a new tab) as a downloadable JSON file, updated weekly. Cross-referencing the probe source IPs against the AzureCloud.canadacentral service tag confirmed what the CloudFront edge data already suggested. Every one of the top Toronto probe sources falls within Canada Central's allocated ranges(opens in a new tab):
20.48.128.0/18through20.48.224.0/1920.63.0.0/1720.151.0.0/1620.220.0.0/184.204.0.0/1552.138.0.0/18
Azure Canada Central's physical infrastructure sits in the Toronto area. CloudFront's nearest point of presence is its Toronto edge. The scanners are not choosing Toronto. The geographic concentration is an artefact of infrastructure proximity, not targeting.
Scanning behaviour
The dashboard records timing data for each probe source. Two distinct patterns are visible in the Toronto cluster.
The top source, 20.48.232.178, was active across a fifteen-day window from late March to early April, probing 223 distinct paths at roughly one request every ten minutes. A slow, methodical sweep that stays under most rate-limiting thresholds.
At the other extreme, 20.220.210.206 compressed 249 requests across 83 unique paths into 97 seconds: roughly 2.6 requests per second. A fast, noisy pass that finishes before anyone can respond.
Different approaches, same assumption: there are always more hostnames to try.
What they are looking for
The dashboard also records the paths each source requested. The top path across the entire Toronto cluster is /wp-content/plugins/hellopress/wp_filemanager.php. Others include /wp-admin/alfa.php, /wp-admin/css/bolt.php, /wp-content/radio.php, and /wp-content/plugins/pwnd/as.php.
These are not probes for known software vulnerabilities. "HelloPress" is not a legitimate WordPress plugin with a security flaw. It is a malicious plugin(opens in a new tab) planted by attackers on already-compromised installations, providing a file manager web shell. /wp-admin/alfa.php checks for Alfa Shell(opens in a new tab), a PHP web shell created by a group known as ALFA TEaM. The remaining paths are common filenames used to disguise web shells inside WordPress directory structures.
The scanners are not trying to break in. They are checking whether someone already broke in and left a web shell(opens in a new tab) behind. This is scavenging, not hunting.
Why Azure
Several of the probe sources in the dashboard data were active for only hours or days before disappearing. The pattern is straightforward: provision a virtual machine, run a sweep across a target list, discard the instance. Cloud platforms with free tiers and low-friction sign-up make this cheap and repeatable.
This is not unique to Azure. GreyNoise documented a coordinated scanning campaign(opens in a new tab) in May 2025 where 251 Amazon AWS IPs, all geolocated to Japan, collectively probed 75 distinct vulnerability categories in a single day. The IPs showed no activity before or after: temporary infrastructure, provisioned for a single operation and then abandoned.
The pattern in my data looks similar in shape if not in scale. A cluster of cloud-hosted IPs, concentrated in one region, scanning methodically for web shells and known exploit paths. Canada Central also offers low-latency routing to North America. The provider and region vary. The economics do not.
What this means for the dashboard
Nothing, practically. The site is a static export served from S3. Every one of these probes returns a 403 or 404. The scanners will cycle through their target lists, receive nothing useful, and move on.
But the Toronto anomaly illustrates what the geographic distribution on the security dashboard actually represents. The edge location chart does not show where attackers are. It shows where cloud providers have data centres, and where those data centres sit relative to CloudFront's points of presence. The Toronto bar is not a threat indicator. It is a map of Azure's Canadian infrastructure and its proximity to AWS, reflected through CDN routing.