During my school internship I had to develop few interesting tasks. Previously I talked about the USB reverse shell program I built, but there was another very interesting exercise I was tasked with creating and that was a forensics exercise where the one doing the exercise would have to analyze the phishing server log files to determine –
- Who sent the phishing emails.
- Which users received these emails.
- Which users opened the emails.
- Which users entered their credentials on the phishing site.
Here’s how I approached the task:
Firstly I had to plan how I would create this server with all the log files. I chose to make the email server on an Ubuntu server with Postfix for the SMTP server and Dovecot for the IMAP server. After setting these up, I had to figure a way of creating the fake email users to send the mail to so I chose to use PostfixAdmin for this because it allows creating virtual email domains and accounts without the need for creating a brand new account on the Linux server itself.
Once I had the emails set up I had to come up with an idea for a phishing email. In the beginning I just copied some banking site log in page and set it up running on the server where after the user would try to log in, they would be redirected to an error page of the legitimate site and the credentials would be logged on my server in a text file. The email template itself was a warning about a ”security upgrade” urging the users to log in their accounts using my sent link if they don’t want their accounts to be deleted. This worked well, but would arise a lot of suspicion from the users prespective if they would try to log in and get redirected to an error page. The use might try to change their password if they realized they have been scammed. So I had to come up with an better idea of doing this.
The idea that came to my mind and I ended up using was making my server act as a man-in-the-middle between the user and the legit website. A tool for doing this already exists and it’s called Evilginx. The tool is a really good one because it not just captures the credentials of the user credentials, but also captures the users session cookies. This is a really big thing because many sites nowadays use MFA which makes just knowing the username and password not enough to log in to someones account. But with session cookies this problem is gone because you can just enter them in your browser and log in the users account as long as the cookie is valid. Though this isn’t bullet proof because there are ways companies defend against such attacks. Such as checking the browser and settings used to log in, short expiry times, IP monitoring, etc.. In the beginning I tried to set this attack up acting as a banking site, but the problem was that banks have very strict session checking mechanisms. In my case the deal breaker was single-session enforcement the site had and the session very short expiry times which would make the attack too much of a hassle to get done so I ended up using one of the top email website in my country for the attack. This site also supported 2fa, but because of the session hijacking functionality Evilginx has, this wasn’t an issue.
Now that the server was set up for sending emails to virtual users and site to use for the phishing attack, I had to find a way of how to keep track of which email users have opened the phishing site and entered their credentials. For doing this, I found about about cannary tokens and spy pixels. I decided to use a spy pixel stored on my server with an parameter to the user email to include in the phishing emails to see which users actually opened my email (if they have HTML viewing enabled) by viewing the web server log files and by adding a different image to the site’s dashboard which would do pretty much the same thing. For users to view the emails in HTML format I had to install Roundcube web client to the server. Well I could have done this without doing all this painful setting up of programs because you could also find which users opened the emails and which entered their credentials by analyzing some of the sent messages in the log files, but I found it fun to learn more about using spy pixels.
After all was set up, I just had to send the fake phishing emails to the fake virtual email users and open some of them up so later the log files could be used for solving this exercise. For automating the phishing email sending I made a small python script which would automate this. The virtual user creation and realistic email server simulation took a long time and was quite boring not gonna lie, but overall the task was fun and teached me a lot about how attackers send phishing emails, how hackers think when sending these emails and common techniques that are used and to look out for.