Attackers Hunting For Twilio Credentials
One up and coming request I recently noticed in our honeypots was pretty simple:
GET /twilio.env HTTP/1.1
Host: [redacted]
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Twilio is a popular service used to send/receive SMS messages and phone calls [1]. They offer a simple API and integration is very easy. To authenticate to the API, requests need to include an "Account SID" and "Auth Token". Like in many similar APIs, each request includes these credentials.
Twilio's documentation suggests to store these credentials in environment variables and use a .env file to initialize the variables [2].
It’s important to keep credentials such as your Twilio Account SID and Auth token secure by storing them in a way that prevents unauthorized access. One common method is to store them in environment variables which are then accessed from your app. This keeps them out of code and other places where credentials don’t belong. Let’s take a look at how to work with environment variables with a variety of operating systems and languages.
Using environment variables to store credentials is common practice and not the worst way to store this kind of data. A secure credential wallet/management system is of course preferred, but Twilio's advice makes sense in that it is language agnostic and not limited to a particular solution a developer may have selected.
But the location of the .env file matters. Files like this should NEVER be placed inside the Web Root / Document Root of a website. Instead, they should be placed outside in a location not directly accessible by a browser. In addition, direct access to these files should be blocked by the webserver. The webserver will likely need read permissions to access the file, but the file should be blocked from being delivered to the user unparsed.
twilio.env isn't the only .env file that attackers are looking for. The particular attacker is also looking for:
GET /.env.dev
GET /.env.prod
GET /.env.stage
In Apache, you may use the following Files directive to block access to ".env*' files:
<FilesMatch "\.env">.
Order allow,deny
Deny from all
</Files>
Or nginx:
location ~ /\.env {
deny all;
}
In the past, I sometimes blocked access to all files starting with ".", but be careful to allow access to .well-known for the Let's Encrypt ACME protocol.
[1] Twilio.com
[2] https://www.twilio.com/docs/usage/secure-credentials
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Application Security: Securing Web Apps, APIs, and Microservices | Online | US Eastern | Jan 27th - Feb 1st 2025 |
Comments
Anyway, after 1 month, 400+ url paths and (almost) 1000 IP address are block, most of what I see in the logs no are /.env requests (230 last 30 days). Looking into 2 IP addresses captured from the the same IP range (8 hours apart) and turning up a 3rd (seemingly innocent) from 3 days before, I think I might have stumbled on a Phishing probe network.
The caught IP address with "mail." domains, and an accidentally wrong IP lookup turned up another. Further checking exposes UK registered company with Dutch & Romainian IP addresses across 3 ranges, a (virtual) host with phone support "during Italian office hours", and more mail domains. Most of the domains are "questionable" at first glance, all of which are registered through 1 domain registrar, and the ones I looked up all registered out of Iceland.
Checking the IP range owner reviels more domains bound to their own server, but of a "less questionable nature" (maybe), and include .co .cc .de .me .xyz .one .icu .club .ga with there most populus domain being registered in Hungaria parked by a non-functioning German registered domain parking site. More questionable mail servers are Gabon domains.
If you have someone there who is interested I can provide details.
Anonymous
Aug 24th 2021
3 years ago