How to Tell a Landscaper From a Thief

Monday, July 20, 2015

Or Katz

8eb7be5a13cc39a3e56b78aba08b2039

If I can see a person standing in front of a neighboring house inspecting the windows and the doors, should I call the police?

Maybe it is the air-condition technician looking for the best place to install a new air-condition unit, or maybe it is a robber doing reconnaissance and checking what is the easiest way to get into the house. It is hard to tell!

Now what if I can see a user sending requests to non-existing pages in my application? 

Maybe these are broken links created mistakenly by that user, or maybe these are attack reconnaissance, pre-attack activity done by a malicious user. It is also hard to tell! 

A key objective for any security team is to make sure that organizational assets -- whether these are servers, applications or data -- are protected. Therefore a preliminary attack reconnaissance activity that target non-existing assets may be casually dismissed due to lack of: interest, human resources or even proper security controls. More to that, attack reconnaissance activity may look like legitimate users traffic when inspected in the wrong context.

From a threat intelligence point of view these casually dismissed attack reconnaissance should be considered as valuable information and should be treated as such. In many cases this reconnaissance activity is the first or even the only opportunity to detect malicious activity just before it slips under the detection radar.

This article presents an example of how threat intelligence analysis utilizing cloud network and inspecting requests for non-existing Web application pages can help with predicting the up-coming brute force attacks. In other words, how to catch a robber just before he tampers with the door lock.   

The Good, The Bad and The Ugly

Brute force Web attackers attempt to gain privileged access to a Web application by sending a very large set of login attempts. In many cases brute force attacks will start with a preliminary reconnaissance process of finding the login pages in the targeted Web application.

While trying to find those login pages attackers will use a dictionary of possible login pages. Not all of these login pages exist on the targeted Web application; therefore accessing those non-existent pages will result with a Web application failure.

There are 3 questionable scenarios for failures: Good, Bad and Ugly. 

The Good

Q: What if we detect someone trying to accesses a non-existing page “login.aspx” on the Web application?

A: If it happened just once, this kind of activity should be ignored. It is possible that it is a mistake made by a legitimate user, trying to access the wrong page. There is not enough information for determining that this is a malicious attempt.

The Bad

Q: What if we detect many attempts to access different files on the same Web application (“login.aspx”, “log-in.asp”…), all results with failure?

A: It seems like this attacker is looking for the logging page of the Web application and he is just one step from launching a brute force attack. The attacker may use “slow & low” attack technique in order to evade security controls detection.   

The Ugly 

Q: What if we detect “bad” activity of many attempts to access different files, but this time across many different Web applications?

A: It seems like attacker is planning to launch a distributed targets attack against many applications. Executing reconnaissance on several Web applications at the same time in order to scale and increase attack surface.

Learning from the cross-targeted activity of the attack, leads us to one unavoidable conclusion – it is going to be Ugly!

Summary

If the attacker knows the location of the login page, looking at failures in the reconnaissance activity won’t work, but everybody make mistakes – even (especially) attackers. It is up to the security teams to be patient and attentive in detecting similar failures and mistakes leading to the detection of variety of web attacks.

The accuracy of combining those reconnaissance activates into reliable insights rely on the diversity of the analyzed data. In the example presented above, the reconnaissance across many different Web applications was the differentiator in the threat intelligence analysis. Therefore, it is only natural that cloud networks should utilize the rich, diverse and continuous data, streaming through their infrastructure into threat intelligence.   

And when a suspicious person is wandering across your neighborhood inspecting houses doors and windows, it is time to call the police! 

About the Author: Or Katz is a security researcher at Akamai Technologies.

Possibly Related Articles:
19718
Enterprise Security
Information Security
Threat Intelligence
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.