Phishing-as-a-Service (PHaaS) - A Case Study

I've written this article for the code.kiwi.com blog.

Analysis (a.k.a. The Facts)

Step 1: Email

The email is as simple as emails go. No fancy HTML/CSS, no more than 4 lines of text:

Dear Taxpayer,

Please find a correspondence letter of summon against your company.

VIEW SARS LETTER OF SUMMON HERE

For enquiries, kindly contact us using the number on the top right corner of the letter.

Vaguely threatening, with a hint of indifference that is so reminiscent of a bureaucratic style. The link will send you to www.file.io.

Step 2: File.io

File.io is a super-simple file-sharing service. Give them a file; they’ll store it for a while. They even have an API – https://www.file.io/about/#api. The file that we are getting is an HTML file.

Step 3: file.html -> autocode.com

These are the contents of the file (without the link, of course):

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
    <meta http-equiv="Refresh" content="0;URL=https://<user-name>.autocode.dev/my-new-project@dev/<page-name>.html"
    ...
  </head>
  <body>
  ...

Citing Autocode docs – Autocode is an automation software suite that allows you to instantly connect APIs together with code in response to HTTP (web) requests or SaaS events, like slack.command, stripe.charge.succeeded or shopify.order.created.

You’ll be greeted with the ugliest of pages:

Page

Containing the ugliest of forms:

Form

This is the point where you would enter your credentials.

Step 4: POST

This is the action of the form.

POST /<redacted-path>.php HTTP/1.1
Host: <redacted-host>.com
Content-Length: 84
Cache-Control: max-age=0
Sec-Ch-Ua: "Not A(Brand";v="24", "Chromium";v="110"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Linux"
Upgrade-Insecure-Requests: 1
Origin: https://<redacted-username>.autocode.dev
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.5481.78 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://<redacted-host>.autocode.dev/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: close

emaie=youremail%40yourcompany.com&pasowrd=YourPassword,Hopefully&button2=VIEW+DOCUMENT

Upon success, you’ll be redirected to a valid official page vaguely resembling the original email.

This POST throws an error message with an empty body:

{"signal":"bad","msg":"Please fill in all the fields.","redirect_link":null}

Step 5: Infrastructure

The attackers didn’t bother to comply with all of the best practices: they left the directory listing open.

Listing

A “DNS round trip” – dig the domain and then dig -x the IP reveals that the infrastructure is run on some VPS at inmotionhosting.com.

Interpretation (a.k.a Opinions)

Infrastructure

I personally find it hard to believe that the attackers would pay for their infrastructure. I suspect that they simply managed to hack some poor folks who left some default admin accounts in their apps or perhaps used an insecure version with a known exploit.

As we can see from the directory listing, the app itself is rather simple – a few PHP files around 1KB that might refer to different campaigns.

Credential harvesting

Starting with the “analysis” of the error message, a few google searches lead me to:

Since the app seems to be dead simple, I suspect that the .php file grabs the creds+metadata and actually sends an email somewhere for further processing.

I’d also like to point out the randomization of fields in the POST requests – “emaie” and “pasowrd” instead of the email and password that a normal person would expect.

I suppose this might further confuse the endpoint protection solutions – “No sir, there are no credentials sent, nothing to see here.”

Autocode.com

Autocode.com has a starter tier that is free and more than sufficient for such attacks. I believe (but IANAL) that this breaks their ToU at point 8.4b.

Email

A small side note about the email – the only link it contains is a file.io link. Since file.io is a legitimate service, this is probably an attempt to evade checks for malicious emails.

Overall flow

One thing stood out in this attack: the level of obfuscation that the attackers have used.

A simple campaign might be carried out with a single server:

Simple phish

  • Server sends an email
  • User is redirected to the server webpage in that email
  • User enters credentials, these are stored in the server

In this campaign, a different service is used for each step:

Complex phish

  • Dedicated email server sent the email
  • Inside the email there was a link to file.io service
  • The link contained an .html file that would redirect the victim to autocode.dev
  • A POST is made to another server that will process the credentials
  • If my suspicion is true, those captured credentials are sent via email to yet another unknown server for further processing

This complicated approach has benefits:

  • A security researcher (that’s me!) has a harder time tracking down the attackers
  • Using valid third-parties for critical steps (email contents, frontend pages) might side-step most protective measures present in a system
  • The distributed nature of the flow also makes it harder to stop the attack as there are multiple different sources, and some of them are valid services that are abused
  • Simplicity of the credential harvester (one .php file that sends emails!) ensures a very fast deployment time – even more important if this part runs on a compromised machine
  • The standard benefit of modular design applies – you can swap each step with minimal effort. Usually, the only things you are changing are hyperlinks.

Operating a PHaaS

You might have noticed that there are multiple such .php files on the server accepting credentials.

I suspect that the attackers are providing this Phishing as a Service (PHaaS – that’s a thing), and then it starts clicking together.

Using free third-party services relieves them of a lot of planning and infra costs. Since the usages are minimal (a file here, a static page there), they are able to abuse the free tiers. And yes, they break all kinds of ToU, probably, but when did criminals care about these, right?

When operating on a compromised infrastructure, simplicity and speed are paramount. The ability to send emails and execute PHP are probably the most commonly bundled features for projects on small hostings. If your email receivers are not picky, you should be good to go immediately with zero additional configuration. Just hardcode an email address into the PHP file, upload it, and you are on-line.

If they are really sending the compromised credentials via emails, they have again covered some more tracks, and they would be able to send results from the campaign directly to different customers.

You can probably imagine that automating this should be fairly simple – use the APIs of the free services, some basic shell scripting and organize a few links per campaign somewhere.

Weak points

One of the hardest parts of these campaigns is sending emails. Spam filters are great, and there are more mechanisms to bypass, such as domain reputation. Even if you manage to get a full score at spam verificators such as mail-tester, you are not guaranteed that your email will arrive (see this article). I suspect that this is the least cost-efficient part of the attack.

The weak point of this campaign, in particular, was the front end. No way around it – it was just too ugly. Simple text without formatting, downloading random HTML files, all of the pages were painful to look at.

Also, the more hops you need your rabbits to do, the less inclined they would be to do all of them (suspicion and laziness are your enemies here). The complexity of the campaign might have worked against them in this case.

Conclusion

Successfully performing a phishing campaign in 2023 is no easy task. You have these pesky antivirus solutions, firewall blocks, spam filters, domain reputations, and many more obstacles in your way.

I believe we’ve observed a highly-scalable campaign that managed to dodge most of these issues. Moreover, it seems that one set of attackers is making serious money from their clients to whom they rent their know-how without taking on the operational risk. Definitely a “sell the tools in a gold rush” mindset.

(Un)fortunately for the attackers using this platform, they cheaped out on the human part of the equation, and their campaign was doomed to fail.

tags: securityphishing