[This is a Guest Diary by Josh Lockwood, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].

Summary

I performed a comparison of Web Honeypot logs from cloud-deployed Dshield honeypots in AWS and Azure in order to test the theory that some URL requests are targeted towards specific deployments. I found evidence to support my hypothesis in that only the AWS-hosted honeypot received requests for AWS-specific resources.These requests were most likely focused towards hosts based on the public IP address for the cloud service.

Research and Analysis

During the course of the internship, I often found that many of the HTTP requests I encountered and investigated appeared to be untargeted, testing for vulnerabilities to exploit over a wide range of devices and patches. However, I also began to notice HTTP requests for AWS-specific URLs nearly everyday in my Web Honeypot logs. I found this particularly interesting due to the fact that I deployed my honeypot using an EC2 instance at the beginning of the internship. I hypothesized that certain bots and scripts specifically look for AWS EC2 and VPC IP addresses and submit requests to try and find vulnerable deployments, web applications, and service on those hosts.

Inspection of two of the more common URLs, “/aws credentials” and “/.aws/config” on the Dshield website showed similar, interesting trends. Per AWS documentation, these files are used to store configuration settings and credentials for users and resources in AWS[2]. Both URLs had been seen prior to my deployment of the honeypot in AWS EC2, but there was a notable uptick around the same time that I deployed my honeypot.There was a clear increase in requests for both URLs on 2023-10-17, the first full day that the honeypot was deployed [3][4].

Figure 1. Trend for /aws/credentials URLs since Feb. 2023.

 

Figure 2. Trend for /.aws/config URLs since Feb. 2023.

In order to test my hypothesis that the requests were targeted at my AWS deployment, I deployed another honeypot in the Azure Cloud on 2024-01-13. I collected sixteen full days of Web Honeypot logs (2024-01-14 to 2024-01-20 and 2024-02-02 to 2024-02-10) from both honeypots and compared the results. I used the command “cat webhoneypot-2024-01-14.json | jq .url | sort | uniq -c | sort -n | grep -i "aws/"” to list out the AWS-specific URLs in each honeypot for 2024-01-14 and compared the results. I repeated the process for each of the other fifteen days. I observed no AWS-specific URLs from the Azure honeypot, while I observed at least one nearly daily in the AWS honeypot, the exceptions being 2024-02-08 and 2024-02-09 where no AWS config/credential file requests were captured.

Figure 3. Search results from the AWS honeypot 2024-01-14 to 2024-01-20.

 

Figure 4. Search results from the AWS honeypot 2024-02-02 to 2024-02-10.

 

Figure 5. Search results from the Azure honeypot 2024-01-14 to 2024-01-20.

 

Figure 6. Search results from the Azure honeypot 2024-02-02 to 2024-02-10.

I also reviewed some of the information surrounding the URL requests. I found that both GET and POST requests were used. I compiled a list of each IP that was used each day and organized them by IP and Country. I checked each IP on VirusTotal to confirm the host country and to see if the IPs were flagged as malicious by any of the security vendors. All but three of the IPs were flagged as malicious by at least one security vendor. Additionally several of the IPs were repeated across different days. The three most common were 78.153.140.175, 78.153.140.177, and 78.153.140.224, all of which are IPs associated with HostGlobal.plus in Great Britain and have been flagged as malicious by at least once vendor on VirusTotal.

Table 1. IPs observed as part of the investigation.

Date	IP	Country	Flagged by VT
2024-01-14	194.67.201.41	RU	Yes
2024-01-15	4.151.191.148	USA	No
	78.153.140.175	GB	Yes
	78.153.140.177	GB	Yes
	78.153.140.224	GB	Yes
2024-01-16	45.92.229.151	USA	Yes
	45.92.229.153	USA	Yes
	45.130.83.8	USA	Yes
	45.130.83.11	USA	Yes
	45.130.83.23	USA	Yes
	45.130.83.28	USA	Yes
	78.153.140.177	GB	Yes
	141.98.11.107	LT	Yes
2024-01-17	8.222.213.27	SG	Yes
	78.153.140.224	GB	Yes
2024-01-18	54.222.143.33	CN	No
	78.153.140.175	GB	Yes
2024-01-19	13.250.8.18	SG	No
	54.222.143.33	CN	No
	78.153.140.177	GB	Yes
2024-01-20	78.153.140.177	GB	Yes
2024-02-02	78.153.140.175	GB	Yes
2024-02-03	78.153.140.177	GB	Yes
	78.153.140.224	GB	Yes
2024-02-04	34.209.164.218	USA (Amazon)	Yes
	78.153.140.175	GB	Yes
2024-02-05	78.153.140.177	GB	Yes
2024-02-06	35.85.58.38	USA (Amazon)	Yes
	78.153.140.175	GB	Yes
	78.153.140.177	GB	Yes
2024-02-08	NONE
2024-02-09	NONE
2024-02-10	78.153.140.177	GB	Yes

 

The AWS config and credential files can be set up by the AWS user and are maintained by the AWS CLI. “The AWS CLI stores sensitive credential information that you specify… in a local file named credentials, in a folder named .aws in your home directory. The less sensitive configuration options that you specify… are stored in a local file named config, also stored in the .aws folder in your home directory” [5]. Considering the nature of the contents of these files, the presence of requests for them suggests that attackers are interested in gaining access to the deployed resources. This highlights the reality that incorrectly configured credential files can lead to compromised systems and accounts in the AWS space, a result that businesses likely wish to avoid. I then checked other requests for configuration files as part of my test to see if this was specific to AWS or if I could find patterns for Azure or other deployments. For this search I focused my search over the nine day timeframe of 2024-02-02 to 2024-02-10. I focused on looking for URLs that contained the string “config” rather than “azure” or “aws” so that I could narrow down the URL count without intentionally excluding any services. While I did not observe any requests for Azure-specific configuration URLs on either honeypot, I did observe a number of other requests for git configuration files. The “/.git/config” files are used to set and control all aspects of the visual and operational aspects of Git repositories for each user [6]. This information can include user identity and settings information. Several other configuration file requests were also observed including “/main_configure.cgi”, “/config.json”, and “/cgi-bin/config.exp”.

Figure 7. Results for named configuration files in the AWS honeypot.

 

Figure 8. Results for named configuration files in the AWS honeypot continued.

 

Figure 9. Results for named configuration files in the Azure honeypot.

Conclusions

Based on the data that I collected between these two honeypots, I believe that scripts used to attempt to resolve these URLs were designed to target AWS-deployed resources and
instances. The lack of any AWS-related URLs from the Azure honeypot supports this theory. My belief is that bots and crawlers look for IPs that are designated to AWS and then attempt to search for misconfigured files that contain valuable information about the users and deployments for further exploitation purposes. With this in mind, businesses and users alike should always remember to follow the AWS best practices[7] to ensure that their deployments are properly secured.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html
[3] https://dshield.org/weblogs/urlhistory.html?url=L2F3cy9jcmVkZW50aWFscw==
[4] https://dshield.org/weblogs/urlhistory.html?url=Ly5hd3MvY29uZmln
[5] https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html
[6] https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup
[7] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html

 

--
Jesse La Grew
Handler