Exposing Phishers via Bad OpSec
I got a phishing email at work forwarded to me and was surprised it got through our filter. Looking at it, it was an email with the subject line “Confirm your identity” with an .HTML attachment.
Opening the .html attachment up shows a pretty legit looking PayPal page.
I put in some bogus info and hit continue
Really? My SSN? If you say so
Hitting “Continue” then presumably submits the phished data and then redirects you to the actual paypal.com page, so the entire thing seems legit.
Let’s dissect this a bit further.
I’ll use Burp Suite to see where this .html file is actually sending stuff to.
Immediately upon opening the .HTML file, it sends a connection request to what is presumably a compromised website. (Actual URL and names will be blacked out)
After filling out the .HTML form and clicking continue, I see it sends the data as a POST request to a PHP file
But going to that .PHP file redirects to paypal.com, so I decided to look at the directory it was sitting in, /lm/
So the attacker failed to practice good OpSec and indexing is allowed. I download the “Jokapo Team VBV Scam” .Zip file
Inside I find a few files
Including kapos.php, which is the .php file that takes the POST request data.
And now your .php code is exposed…
Looking further I see that it opens a .txt file and writes to it
But I swear I’ve seen that .txt file before
So he is storing the harvested, phished, data in a plain .txt file that is accessible to anyone. But wait, there’s more!
So, to test out their scam, the scammer used their real gmail account
So what do we do with any scammers email?
We sign them up for farmersonly.com and Christianmingle.com
As well as signing up for free spam email
And then of course reporting him to Google.
Moral of the story: If you’re going to phish people, at least be good at it…
The owner of the compromised website was also contacted but the site looks like it was last updated in 2014, so I doubt anything will happen there.