Last weekI posted about some of the reconnaissance tools that attackers are using against E-Commerce sites, then about what some of the evidence looks like in the logs. Now I want to go over what they are doing with their ill-gotten access.
Attackers aren't just in it for the fun anymore. While we still see our share of political defacement's and attacks that are pulled off just to prove a point, most of the cases that forensics firms like mine are working involve the theft of data. Attackers are stealing Personally Identifiable Information and selling it to crooks that use it to defraud Medicare/Medicaid and other social programs. The same data can be used to commit classic "Identity Theft" and open accounts under other peoples names.
Even easier is the theft of Cardholder Data, there is a sophisticated black market built around the sale of credit card numbers. I talk about it in my conference presentation "Hunting Carders for Fun and Profit" (coming to a con near you in 2013) and it really blows people away how readily available the hardware, plastics and card numbers are. It's really easy for an attacker to gather card numbers and sell them in bulk to a middleman that specializes in parting out these "dumps" for a set price.
All of this data capture and sale really is the "End Game". It's how they get there that I want to talk about.
The top way I see data being exfiltrated is SQL injection. I talked about this in my last post and put up a quick example. I usually see an attacker hammer away at a site for a couple of days with different tools, but once they find that vulnerable page, it's over in a matter of minutes or hours. This is a very direct kind of attack. They poke around until they find a way to directly access your DB and just suck all the records right out. It's very effective but not terribly sophisticated (usually, see Hunting Carders for a very sophisticated attack).
Tuesday, February 5, 2013
Saturday, February 2, 2013
New Year, New Look, New Post: How did they find me? Part 2.
Last post we went through some of the free utilities available to attackers for reconnaissance purposes. The utilities I talked about in that post are all things that I have seen used over and over again in successful attacks. What I did not touch on was what these attacks look like in Apache and IIS log-files.
Let's start with some basic search methodology. The idea here is to "read" through a log-file and search it for specific terms. You can use grep by itself or sed, awk, gawk or a dozen other commands. If you use a Linux workstation or the windows ports of Linux utilities it will look something like this:
grep -i "keyword" -r *
If the output doesn't look the way you want it to or you are having trouble targeting specific files with grep alone, you can refine somewhat by stacking commands like so:
Strings -s *.log |grep -i "keyword"
I guess the big secret here is the keywords. They will vary slightly from case to case but, generally speaking, SQL injection can be identified by searching for union select, xp_cmdshell, concat and also by looking for specific database table names in the logs. The last of these is especially true if you know what type of data is at risk and where it resides. One of my favorite PCI related searches is to look for "cvv" in the logs or "cc_number". If you are concerned about data being snatched from a particular database, grab the table names and run a search. It's very common to see fields like "First_Name, Last_Name, Address"
Let's start with some basic search methodology. The idea here is to "read" through a log-file and search it for specific terms. You can use grep by itself or sed, awk, gawk or a dozen other commands. If you use a Linux workstation or the windows ports of Linux utilities it will look something like this:
grep -i "keyword" -r *
If the output doesn't look the way you want it to or you are having trouble targeting specific files with grep alone, you can refine somewhat by stacking commands like so:
Strings -s *.log |grep -i "keyword"
I guess the big secret here is the keywords. They will vary slightly from case to case but, generally speaking, SQL injection can be identified by searching for union select, xp_cmdshell, concat and also by looking for specific database table names in the logs. The last of these is especially true if you know what type of data is at risk and where it resides. One of my favorite PCI related searches is to look for "cvv" in the logs or "cc_number". If you are concerned about data being snatched from a particular database, grab the table names and run a search. It's very common to see fields like "First_Name, Last_Name, Address"
OUCH!
Subscribe to:
Posts (Atom)