Archive
This post is archived and may contain outdated information. It has been set to 'noindex' and should stop showing up in search results.
This post is archived and may contain outdated information. It has been set to 'noindex' and should stop showing up in search results.
Analyzing a Recent Exploit Attack with HTTP Request Log
Aug 7, 2015Web DevelopmentComments (0)
On Monday July 20th at 10AM, H3XED received 13,507 http requests over the course of about 6 minutes (38 per second) from IP 87.69.252.212, which is located in Israel. The user agent was Java/1.8.0_05 and they were mostly GET requests. They were looking for exploitable endpoints by running through a long list of URLs and checking for response codes. Here is a breakdown and analysis of the attack.
The bot was looking for unsecured and exploitable pages on the site, such as hidden admin pages or files that might contain credentials (e.g. _userdb.php, admin_login.zip). They didn't find any, and thankfully the server handled the traffic without a problem. It's a good lesson that you should make sure all pages are secure, even if there are no links pointing to them.
View the complete log of http requests in Excel format.
Most requests were met with a 404 response, but when the bot received a 200 response (a valid page), it hit it a second time to double-check, and then hit it a third time from user agent USERAGENTAAA (same IP). It seems to be that the Java/1.8.0_05 bot looks for the existence of pages and then the USERAGENTAAA bot does something else with them; perhaps it downloads them and analyzes them for useful information (usernames, passwords, email addresses, etc).
CloudFlare challenged 165 of the requests. I had Security set to Low as I don't want to inconvenience legitimate visitors. I am surprised that CloudFlare didn't catch on, receiving 38 hits per second sustained over 6 minutes, all from the same IP address. I have since increased the security level a notch. Ideally CloudFlare would have caught on much earlier and avoided most of the requests making their way to my server.
I only noticed the attack because of server-side analytics. JavaScript analytics would have been oblivious to the activity. When checking the dashboard on Google I also noticed that the "service provider" was listed as "please send abuse/spam complaints to abuse@012.net.il".
Access Pages
The bot was looking for unsecured and exploitable pages on the site, such as hidden admin pages or files that might contain credentials (e.g. _userdb.php, admin_login.zip). They didn't find any, and thankfully the server handled the traffic without a problem. It's a good lesson that you should make sure all pages are secure, even if there are no links pointing to them.
View the complete log of http requests in Excel format.
Most requests were met with a 404 response, but when the bot received a 200 response (a valid page), it hit it a second time to double-check, and then hit it a third time from user agent USERAGENTAAA (same IP). It seems to be that the Java/1.8.0_05 bot looks for the existence of pages and then the USERAGENTAAA bot does something else with them; perhaps it downloads them and analyzes them for useful information (usernames, passwords, email addresses, etc).
CloudFlare
CloudFlare challenged 165 of the requests. I had Security set to Low as I don't want to inconvenience legitimate visitors. I am surprised that CloudFlare didn't catch on, receiving 38 hits per second sustained over 6 minutes, all from the same IP address. I have since increased the security level a notch. Ideally CloudFlare would have caught on much earlier and avoided most of the requests making their way to my server.
Server-Side Analytics
I only noticed the attack because of server-side analytics. JavaScript analytics would have been oblivious to the activity. When checking the dashboard on Google I also noticed that the "service provider" was listed as "please send abuse/spam complaints to abuse@012.net.il".