In this blog post, we will be analysing a very recent Phishing Kit that was found to be active last month. We will be taking a look at how the Phishing Kit is deployed, how it collects the information that you enter into it and how it is sent to the scammers using server-side code; PHP. This is my first ever Phishing Kit I am analysing, so this one is not too complicated and is quite straight forward but there may be some inaccuracies so if you spot any, comment them below please!
The Phish Kit
So first, we download the Phish Kit. This can be done in may ways, sometimes the Phishing website will have a directory where the Phish kit was set up in and may have a zip file for you to download. Or the most common way to obtain one is via someone's GitHub, which is what I have done.
Once we have the Phish kit downloaded, we want to unzip it to a working directory. We also need to get the phish kit running locally, an option could be to spin up a python http server, however it does not handle or run PHP files well. Instead I used PHP’s web server to run the phish kit from my working directory.
Php –S 127.0.0.1:80This will allow us to run the PHP phish kit and access it via localhost in our web browser.
looking at the directory structure above we see there is a default.php file which would be the equivalent of the index page. Looking inside this PHP file we can see that it collects information about visitors to the website and logs them to a Visit.txt file. It then redirects the visitors to /login/default.php page which acts as the main landing page for this Phish Kit.
Lets start with accessing localhost (127.0.0.1), we are automatically redirected to the login page at 127.0.0.1/login/default.php. This webpage is an exact carbon copy of the legitimate standard bank of Namibia login page. There are actually a number of free and easy ways to download a whole website for offline viewing and to construct a phishing website. There are a number of free online services that will do this for you and also a quick curl or wget command will download a webpage for you.
The only difference here is that the URL’s are different; the Phishing page has the URL 127.0.0.1/login/default.php and the legitimate website has the URL https://www.ibanking.standardbank.co.na/#/login. Also notice that the legitimate website has SSL (Https) to encrypt your connection and keep your data secure.
Taking a look at what the phishing website’s login page is doing, we will need to look at the code behind the default.php webpage. This is the source code behind the login page that handles your input into the login form when you enter your details and press sign in.
We can see the highlighted code snippet is sending data via POST to process.php.
In a previous blog post, we saw that credentials were being sent via POST request to another domain. We will be able to see here how the POST request is handled and how credentials are subsequently stolen. In process.php we see how this is done.
The below is a full code snippet from process.php, we can see straight away on lines 6 and 7 that the userId and the password from the login page are being received via POST request.
Looking back at default.php we can see the name of the input boxes set to userId and password which are then sent via POST request to process.php. Ordinarily these credentials would be used for authentication to allow a user to log in, here they are processed and subsequently logged and then sent to an attacker.
POST requests are handled by process.php by the name of the field they are given in default.php and are saved in global variables which are accessed in process.php.
From the below snippet from process.php, Session_start(); starts a session to receive the credentials being sent via POST. $date = gmdate(“Y/m/dH:i:s”); is used to get the current date, month and year, Hour min and seconds according to this documentation page.
$ip =$_SERVER[‘REMOTE_ADDR’]; is used to get the IP address from the connecting party, from which the request were sent to the webserver.
The values userId and Password are sent via POST request to the process.php page and are received and used to initiate the variables userId and password:
$userId = $POST[‘userId’];
$password = $_POST[‘password’];
A message variable is created and in this, the userId and password are sent along with information about the connecting party such as their IP and date and time. The IP variable is passed as a URL parameter to a geoip link so that the attacker can have the URL sent to them via email to locate where the connecting party is connecting from.
The mail function allows the attacker to send emails with a message, subject and a recipient email address. Currently the recipient email address is set to attacker-email@gmail.com. The PHP snippet below also shows us that the attacker is writing the contents of the $message variable to a file called login.txt in a log directory. Both methods of credential storage mean that the attacker receives credentials via email and can also access the txt files on the server hosting the phishing site.
@fclose(@fwrite(@fopen”../log/login.txt”, “a”),$message));
The code then exits from the current php script with the die(); function and redirects the victim to the otp/default.php page. This follows the exact same procedure as the login/default.php page to collect user credentials. The aim of this is to mimic the real website, where you enter your details and then are required to enter an OTP code.
Taking a step back, we’re at the login/default.php page, currently the log directory is empty as no credentials have been logged. When we enter some credentials and press sign in the UserID and Password are sent via POST to process.php and are logged in login.txt.
The message from process.txt was written to the log directory in a file named login.txt.
As soon as the victim presses login, their credentials are logged and they are immediately redirected to this /otp/default.php page where their OTP codes are harvested. This would allow an attacker to log into their account with their credentials and with their 2FA code. You can see below that it says that the OTP has been sent to +264********, this is actually a hard coded value to make the webpage look more realistic as the Namibia country code is +264.
When we enter an OTP it is sent to the log directory and is saved in otp1.txt using the exact same technique as we saw with the login page.
When we click verify we are taken to an error page /error/default.php where we are told we have given an invalid OTP. This is the perfect opportunity for the attacker to request more PII from the victim to authenticate themselves.
Clicking continue takes the victim to the /resend/default.php page which goes through the process again of requesting another OTP and then redirects the victim to /email/default.php as shown below in process.php.
When the victim reaches /email/default.php, the webpage harvests their email and password. Gathering emails and passwords can be used for credential reuse on other websites or can be used on the official Namibia bank’s website as an alternate authentication method.
The process behind this /email/default.php is that the victims email and password are sent via POST to process.php. Here the victims credential are logged to an email_access.txt file and are also emailed to the attackers. At this point, the attackers have the userId, OTP, email and password of the victim. They have been asked to confirm two OTP codes and their email and password, once the attacker has enough information to compromise their account the process.php page redirects the victim to the genuine banking website as shown on line 24 below.
Everything entered into the phishing site is stored on the webserver the attackers are hosting this site on and the logs would look like this.
Everything saved in the logs is also emailed to the attackers so in real time they would receive userId, email, OTP and passwords and would be able to compromise an account instantly if the mailboxes were monitored frequently.
What can I do if I see a phishing website?
If you come across a phishing link, report it via the Palo Alto link checker and also perform a whois lookup on the domain and see if you can find an abuse contact email address. Send them an email notifying them of the phishing site so that they can take it down. The NCSC also have a new webpage for reporting suspicious websites, the more people that are proactively reporting phishing sites the harder it is for them to operate and hopefully the less successful they become.
We have now completed a very quick and simple analysis of a recent Phish Kit.
I hope I explained this well for anyone wondering how Phish Kits worked. If you have any feedback, I would love to hear it as I want to keep improving. I am still learning and if you spot any mistakes or inaccuracies, please let me know!
Comments