After a few painful incidents in which it took days to clean all of the infected accounts, I'm pleased to say we've honed our incident response plan for this scenario to the point where it is very effective:
Prevention
Our user awareness training teaches that any suspicious emails are to be reported immediately as phishing instead of normal spam. The recent incidents have kept this in the forefront of our users' minds. In the future, we may begin using testing services or our own SP Toolkit instance to simulate phishing campaigns.
Detection
Our users became our initial detection mechanisms. With the spam gateways letting lots of phishing messages through and with phishing subject lines that are too varied to filter manually, the last line of defense and chance for detection is the user.
Containment
We streamlined and formalized our procedures for mass phishing scenarios. Our staff in key roles knew ahead of time exactly what to do and when. Specifically:
- Lock an account
- Force a logout
- Purge all email boxes of a specific subject line
- Monitor for successful phishes
- Block related on IP's and web sites
Monitoring for successful phishes is where ELSA comes in. With ELSA logging URL's, we were able to take a given phishing email and monitor for any access to the phishing URL's. StreamDB would then be used to pull out the POST data to show exactly which user submitted credentials to the phishing site so that containment procedures could be followed.
However, ELSA gives us the ability to go deeper than that and use generalizations from the phishing campaigns our users notice to find phishing that has gone unreported.
Fishing for Phishing with ELSA
In our case, a user reported a phishing email which had a URL of:
hxxp://www.pirini-trade .hr/narudzba/use/web/form1.html
My staff searched ELSA for:site:www.pirini-trade.hr
No hits, so that particular email failed in its phishing attempt. However, what if other phishing emails went out with a similar format? Let's try some other searches:uri:narudzba
Nope.uri:"use/web/form1.html"
Nope.How about this?
+method:POST +uri:use +uri:form1.html
Nope.Just this:
+uri:use +uri:form1.html
Ok, now we've got some very interesting hits, but no POST's:GET www.charlesgorley.ca /form/use/Text/form1.html
That looks very similar, but did anyone post data?
+method:POST +site:www.charlesgorley.ca
Hit!POST www.charlesgorley.ca /form/use/Text/process.php
So, we can use this for our query:+method:POST +uri:use +referer:form1.html
Set it to alert, and now we've got some decent coverage for variants of this campaign. If it continues, writing this into a Suricata alert may even be a good idea. In the meantime, we initiate our incident response plan for this user account.Detection as Prevention
So, this is great, but how is this prevention as the account was already compromised? In the case of this example, the POST we found was two days ago. The key concept to understand is that even though the credentials are compromised, they are not used immediately. In fact, we have noticed an average turnaround of six days between account compromise and account misuse. The criminals harvesting the credentials have staff, code, and infrastructure to maintain just like the good guys, so all but the very best lack automation when it comes to actually utilizing the accounts for further phishing. In fact, our experience has shown an organizational structure much more akin to sweatshop labor than elaborate and sophisticated technology. Specifically, it is more economical for the criminals to pay low-wage workers to perform the mundane tasks of exploiting compromised accounts to send spam than it is to write scripts to do it.
How do we know this? The attackers in our previous phishing attacks have all been from a few distinct geographic locations (Spain, France, and Nigeria) and have a distinct operational signature. They use a browser plugin called "Crazy Browser" which allows a basic Internet Explorer instance to have multiple sub-windows open at the same time in one IE window. The most likely reason to do this is for easy copy-and-paste between their personal email from which they receive orders from their criminal boss and the various webmail accounts they're logged into for the purposes of spamming. The point is, if you need a lot of browser windows open, then you're obviously not doing a lot of scripting, and there is most certainly a human involved in the account use.
So, why is this important in shaping our IR plan? It means that if we know it will be several days between account compromise and account misuse, we can lock down the account before it is misused with sufficiently fast detection. Yes, the initial prevention via spam filter failed, and the phishtank.com coverage did not show up until a day after the phish was delivered, but from a business perspective, we were able to detect the compromise in time to prevent it from becoming a problem for the business. ELSA enhances our detection abilities by letting us retroactively investigate phishes based on new leads.
I'm not the first to suggest that detection is the new prevention, but I think it's important to use examples to show how the two are intertwined, and what that means for the business. Specifically, it means that visibility and analytics are more valuable than (or at least necessary alongside) traditional preventative measures, and we as security professionals need to arm our orgs with the tactical resources to provide these capabilities.
