Last time, we took a look at a few common mistakes that are easy to make when trying to attribute cyber attacks. To recap:
- Panic over one indicator
- Chase unrealistic threat models (Are you a cleared defense contractor or a law firm servicing one? No? Then APTs are probably not for you.)
- Demand unambiguous data before implementing mitigations. You will not get it, and you will annoy your SOC.
This is actually pretty decent as banking phishes go. There aren’t any obvious English mistakes tying the content to a specific geographic region*, the language is not hyperbolic, and the signature at the bottom is for a real person. Further, there is no WHOIS data, so the first inclination is to throw up our hands and call it a day. But when we pulled up the landing page, servicesbay[.]ru/server.one (currently down), it has provided a form to enter personal financial information that mirrored MBNA site resources but did not validate user input. Further, the root domain had an open directory leading to other phishes. From an attribution standpoint, we now know a few things:
- The phish was not targeted. No personal victim information appeared on the pitch, and elements of its language could be tracked back to at least 2012.
- The threat actor sophistication is low.
We could stop here, if so inclined. Looking at the mechanism of the phish itself, one can form a reasonable belief that it is not targeted specifically to our organization, and the actor is of low sophistication. Those are really the bare bones needed to implement threat mitigations. But let's take it a little further.
Passive DNS on the landing page has yielded the following (now mostly down):
One of those hits is a vk.com profile:
And there we have a name to match our phish. Some caveats:
We have absolutely NOT proven 100% that the above name is behind the phish. Passive DNS does not prove a direct one-to-one link between ownership of multiple websites, even when the overall number of hosts is exceptionally low. Further, we don’t know who the cs-def site owner has given admin credentials to; and lastly, we can’t discount the possibility of a malicious third-party executing a takeover of his infrastructure. However...
We have a reasonable, evidence-backed suspicion that a Russian actor has instigated a generic, low-sophistication phishing wave sent to targets of opportunity.Given that the above statement is sufficient grounds to make an informed decision on security mitigations, we can consider the attribution complete. Notice that none of the information above is definitive. Alternative Competing Hypotheses can still be applied. The important part is that internal attribution** does not have to be definitive. It has to be reasonable. Should new information alter prior judgement, the attribution should swing back to incomplete and we start the process over.
So we can see using the above example that attribution does not have to be painful, dramatic, or movie-plot ridiculous. At its core, practical cyber threat attribution is about making reasonable judgments against a typically reliable data set in order to drive mitigation decisions. No Pandas, Bears, or three-dimensional matrices required. Tune in next time for Part III: Where Do I Go From Here?
* People go wrong here quite a bit. Amateur language analysis tends to rely heavily on tone, and quantity of mistakes. This is wrong. Rough geographic language typing is done by the quality of mistakes, as second language communicators tend to make English mistakes congruent with the grammar of their native language.
** ALL of your attributions should be internal.