The first 17 hours: what bots looked for on our website
In 17 hours, bots sent 58 requests to digimasi.com looking for .env files, the .git folder, cloud keys and AI keys. The data, and how to check your site.
Read the article →A week of bot requests: two thirds were after .env files
Last week we wrote about the first 17 hours of our sensor on digimasi.com: 58 requests from bots looking for files this website has never had. Now the first full week is in, from the evening of 12 October, when the sensor started, to the end of 18 October. There is far more data, and patterns are starting to show.
The numbers
- 1,744 requests from 91 IP addresses, recorded from 12 October 18:38 to the end of 18 October, Jakarta time.
- Those addresses are registered in 29 countries. Again, that is where the servers are, not necessarily where the people are.
- Almost half of all requests (846) came from just 3 addresses, all in the same network.
- 16 requests carried a guessed username or password, sent to login pages that do not exist.
None of them succeeded. The files they asked for do not exist on our website, so every request got the "not found" page.
Compared with the first 17 hours
The week's numbers include those first 17 hours.
- Addresses went from 9 to 91, countries from 7 to 29.
- .env files went from a third of all requests to almost two thirds: 20 of 58 then, 1,141 of 1,744 now.
- The .git folder went the other way: from a third (19 of 58) to about 4% (76). And 29 of the requests for /.git/HEAD came from just 2 addresses.
- Cloud and server keys went from 3 requests to 41, from 13 addresses.
So the first 17 hours did not show the whole picture. Back then .git looked as important as .env. After a week, .env is far ahead.
What they looked for
- Secret configuration files, .env (1,141 requests, 39 addresses). Nine of the ten most requested paths are a variation of .env: /.env (86), /.env.local (42), /.env.backup (38), /.env.production (35), /.env.bak (34), then /.env.save, /.env.dev, /.env.old and /.env.staging. Bots guess the names developers give to copies and other versions of the file.
- PHP files (198 requests). Our website does not run PHP.
- WordPress (197 requests, 50 addresses). Login pages and other WordPress paths. Our website does not run WordPress either.
- The code history folder, .git (76 requests).
- Other configuration files (70 requests).
- Cloud and server keys (41 requests).
- Other (21 requests). Paths typical of certain frameworks (13) and admin panels (8).
Worth noting: many visitors, a few heavy hitters
WordPress was tried by 50 addresses, more than any other category, but at about 4 requests per address. .env was the opposite: 39 addresses, at almost 30 requests each. WordPress gets a quick check from many bots; .env gets dug into by a few bots carrying a long list.
The networks show the same concentration. More than half of all requests (950) came from servers registered in Germany, followed by the Netherlands (144), the United States (119), Belgium (112) and Poland (105). The largest network was Virtualine Technologies (846 requests from 3 addresses), then Google LLC (338 from 14 addresses), TC DATACENTER (133) and DigitalOcean (64 from 17 addresses). A network name is the owner of the address block, usually a server or cloud provider. Whoever rents a server there can use it; it does not mean the company itself sent the requests.
Check your own website
You can check all of this yourself in five minutes, on a website you own:
- Open yourdomain.com/.env in a browser. You should see "not found". If you see the file's contents instead, move the file out of the public folder at once, then change every password and key inside it.
- Try the variations too: /.env.local, /.env.backup, /.env.production, /.env.bak. Bots try all of them, and a forgotten copy is as dangerous as the original.
- Open yourdomain.com/.git/HEAD. This should also be "not found". If text appears, anyone can open your .git folder.
- Keep cloud and service keys in the server's settings, not in a file inside the website folder. Set a spending limit on the service account too, so a leaked key cannot run up the bill.
- If you use WordPress: limit login attempts, turn on two-step verification for admin accounts, and switch off xmlrpc.php if you do not use it. 50 different addresses tried WordPress on our website this week, and we do not even use it.
About this data
We only observe. All the data comes from bots that came to digimasi.com on their own; we never scan anyone else's website, and we do not show IP addresses here. Addresses that clearly attack us are reported to AbuseIPDB. The full method is on the methodology page, and the numbers for every week are on the weekly records page.
Data: Digimasi security research, weekly sensor records (https://doi.org/10.5281/zenodo.23466873).
We will keep recording and compare the weeks as they come in.