Last Updated: 2019-08-02 20:52:14 UTC
by Rob VandenBrink (Version: 1)
As Infosec folks, we spend a lot of time on the latest and greatest exploits, attacks and malware – we seem to be (abnormally) driven towards continuing education in our field. This is a great thing, but often we lose sight of the fact that the attackers don’t always try so hard.
I got a text this morning, telling me my Netflix payment was unsuccessful. This was really interesting to me, as I’ve canceled my Netflix subscription (I guess I’m a luddite). Looking at the text, the link is pretty obviously malicious.
So let’s browse there (from a sandbox VM). That login page looks pretty good! It should, since if you look at the page source, it pulls most of the visible elements from the Netflix website. This looks a lot like something we’d do in a penetration test using the Social Engineering Toolkit (SET).
Let’s put some fake credentials in: firstname.lastname@example.org / TestTest123!
Oh surprise, the credentials worked! What are they asking for next? Personal Information and Credit Card details of course!
So no fancy malware, just "click here and give me your credit card" phishing - the only different thing is the SMS source, and really that's not even all that out-of-the way these days anymore.
This follows along with what you might do in a penetration test, except in a pentest likely you are just collecting the credentials – I don’t think anybody would be cool with pentesters taking that next step. (least of all Law Enforcement). Though depending on the site, quite often your credentials might be worth more than your credit card information.
Oh, but I’d never fall for that you say! But think of other folks in your family, the ones who ask you about “computer stuff” over the holidays. Or your neighbours, coworkers and so on. This attack was a pretty obvious “spray the area code / cell phone range” attack – they didn’t attack me personally, they’re blanketing as many people as they can find. Even if 1 person in a hundred, or one person in a thousand go the distance, this makes money. And think about it, if you made a list of people you know, there’s almost certainly a “clicker” in the 10, I know my “clicker friends and family” ratio is certainly well above 1%.
Also think of how people work. Once they click that first link (in the text message), they’re almost certain to take that next step. In fact, the more hoops they need to jump through, the more likely they are to jump through that next hoop. It’s almost like they’re determined to get the prize at the bottom of the cracker-jack box (I just dated myself there too I guess).
Every person who get to the end of this scam is now on the hook for fraudulent credit card transactions. Either it’ll be a one-time $4999 hit (or whatever the fraud watermark number is these days), or they’ll be buying small items forever (which the attacker then likely returns, with the return going into a different account) until they figure out that they’ve been hacked. And given the supply chain, the victim’s credit card info might be sold a few times before it’s ever used. I doubt that the original attacker wants the risk of being busted on the financial side.
If you’ve been following my recent blogs, you’ll note that I tend to write a lot about the Center for Internet Security Critical Controls. This attack falls squarely into Control 17 – Implement a Security Awareness and Training Program. An attack like this is certainly something that you might present to the non-technical folks in your workplace. Or from the other perspective, if you can get your developers to look at unusual site activity (for instance – identify and log on malicious IP addresses that pull the site graphics but aren’t actually loading the page), you can work that into your perimeter IPS or WAF configs – a decent home-grown Threat Intelligence feed (those are often the best kind IMHO).
Unfortunately, effective end user education is hard. Either you need to pay for it, or you need to take time away from your technical challenges and prepare material to then deliver the actual program (whatever format that takes). And almost without fail, we are almost all measured more heavily on the tech work we do, as opposed to things like end user education.
Has your organization’s web assets been impersonated in an attack on 3rd parties? Have you had folks in your organization fall for something like this? Or have you used attacks of this kind to bolster your perimeter? Please, share via our comment form, almost every facet of this topic is something we fall short on.
======= update 4:45 ============
A bit more analysis - a quick check shows that the host for this scam resolves to 126.96.36.199
Using our "Whereis" tool ( https://isc.sans.edu/tools/whereis.html ), this was found in ASN 26496, in a Godaddy datacenter - it's just a quick cloud site. Godaddy currently has these on for $2/month, for the host + DNS + the certificate. So if you're making money on this site, it's a nice "throw-away" cost, especially if you've got stolen credit card info to pay for it :-)
This means that our adversaries are 100% using cloud services, with all the associated automation and orchestration benefits. My bet is that, after all the HTML was written, this site took less than 20 minutes to stand up, SSL and all. (I know my corporate site took about that long, I'm hosted on github)
Not only that, but because it's all automated, the SSL/TLS implementation is done as right as right can be - this site gets an "A" on the qualys SSL checker site (see Bojan's story from last week - https://isc.sans.edu/forums/diary/Verifying+SSLTLS+configuration+part+1/25162/ )
Given the target audience, the SSL and "lock" symbol adds a lot more credibility to this site than it should - non-technical folks see that and just assume that everything is secure and "as it should be"
Where was the "fail" in this? With all the automation in standing up these cheap sites, the hosting provider missed the fact that this was an obvious phishing domain - there's nobody looking at these DNS names as they whiz by, so if the algorithm misses it, it gets the green light and up it goes. They get an "A" for automation on the ops side, something less than that on the "let me check your bona fides before we sell you the thing" algorithm.