Visit From an Old Friend: Counter.php
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2010-0188 | Arbitrary Code Execution in Adobe Reader and Acrobat via Malicious PDF Handling CVE-2010-0188 is an unspecified code-injection (CWE-94) flaw in Adobe Reader and Acrobat that allows attackers to cause a denial of service or possibly execute arbitrary code on the victim's machine. It is triggered when an affected application processes a maliciously crafted PDF document, typically delivered as an email attachment or downloaded from a website, so simply viewing the file with vulnerable software is enough to expose the user. A successful attack gives the attacker code execution in the context of the logged-on user, which can be leveraged to install malware or ransomware. Anyone running Adobe Reader or Acrobat is affected; CISA lists the products without published version ranges, so all Adobe deployments should be treated as potentially in scope. Exploitation is confirmed in the wild: the flaw is in CISA KEV (added 2022-03-03) with known ransomware use, and EPSS assigns an 88.2% probability of exploitation within 30 days (100th percentile). Do: Apply updates per vendor instructions: install the Adobe security update that fixes CVE-2010-0188 on any legacy Acrobat/Reader deployment and migrate unsupported installations to a currently supported Acrobat/Reader release. Given the known ransomware association, hunt for signs of compromise such as suspicious PDF attachments opened around malware activity, and block or sandbox PDFs at email and web gateways. Verify no critical hosts or automated workflows still depend on outdated Reader/Acrobat components for PDF processing. | — | 88% | KEV ransomware |
| masshundreds of millions of installed copies (Reader/Acrobat historically shipped as the default PDF handler on most Windows PCs; exact count of still-vulnerable… | |
| CVE-2011-3402 | Remote Code Execution in Microsoft Windows Kernel TrueType Font Parser (win32k.sys) CVE-2011-3402 is a flaw in the TrueType font parsing engine of win32k.sys, part of the kernel-mode drivers in Microsoft Windows. A remote attacker can trigger it by presenting crafted font data to a user — for example, embedded in a Word document or on a web page — and gains the ability to execute arbitrary code on the target system. All Microsoft Windows versions covered by the vendor advisory are affected; the provided data does not enumerate specific version ranges. The vulnerability was famously exploited in the wild in 2011 by the Duqu malware campaign (the subject of Microsoft Security Advisory 2639658), and CISA added it to the Known Exploited Vulnerabilities catalog on 2025-10-06. EPSS assigns a 78.3% probability of exploitation within the next 30 days; no current public proof-of-concept is known. Do: Verify that every Windows host — prioritizing legacy, embedded, and internet-exposed machines — has the TrueType font-parsing fix released via Microsoft Security Advisory 2639658 (November 2011), and inventory missing patches rather than assuming modern builds are covered. Per CISA KEV/BOD 22-01 guidance, apply vendor mitigations or discontinue use of the product where patching is not possible. Given the 2025-10-06 KEV listing and 78.3% EPSS, treat any host without the win32k.sys font-parsing update as exposed and remediate within required timelines. | — | 78% | KEV |
| massOrder of hundreds of thousands to millions of unpatched legacy Windows systems (Windows install base exceeds 1 billion devices) | |
| CVE-2013-0422 | Java Applet Permission-Restriction Flaw Enables Remote Code Execution in Oracle JRE CVE-2013-0422 is a flaw in how Oracle's Java Runtime Environment restricts the permissions of Java applets (CWE-264), allowing an applet to run with privileges beyond its intended security sandbox. It is triggered when a user loads a web page that delivers a malicious Java applet, such as via a drive-by visit or a phishing link pointing to an attacker-controlled site. Successful exploitation lets the attacker execute commands in the context of the current user on the client system, which in the 2013 campaigns was used to deliver malware families tracked in exploit kits and APT activity (e.g., Whitehole, Miniduke, Icefog) and is recorded by CISA as being used in ransomware. Any system with Oracle JRE installed—especially workstations and browsers with the Java applet plug-in enabled—is affected. Exploitation is confirmed in the wild: the flaw was mass-exploited by exploit kits at the time of disclosure, it carries a 97.6% EPSS probability of exploitation (100th percentile), and it was added to CISA KEV on 2022-05-25, so patching remains an active requirement. Do: Apply Oracle's Java updates per vendor instructions — at disclosure this meant the emergency Java 7 Update 11 or later, and today the current supported Java release. As interim mitigation, disable the Java browser plug-in (or Java in browsers) and uninstall JRE where it is no longer needed. Given known in-the-wild use by exploit kits and ransomware, prioritize KEV remediation and check endpoints for drive-by web-borne infections delivered via malicious applets. | — | 98% | KEV ransomware |
| masshundreds of millions of Java installs (Java was near-ubiquitous on enterprise desktops and servers in 2013) | |
| CVE-2013-2423 | Remote Integrity-Affecting Vulnerability in Oracle JRE HotSpot (CVE-2013-2423) An unspecified vulnerability in the HotSpot component of Oracle's Java Runtime Environment (JRE) can be triggered remotely, allowing attackers to affect the integrity of the affected system. Oracle did not publish technical detail for the flaw, so defenders should treat unpatched legacy JRE deployments as potentially exposed without being able to precisely scope the trigger. An attacker who successfully exploits it gains the ability to tamper with the target's integrity; related reporting around the LightsOut Exploit Kit and compromised websites suggests Java flaws of this era were used in drive-by web attacks. Any endpoint or server running an unpatched Oracle JRE is affected, with legacy Java installations that never received current updates being the most likely remaining targets. The vulnerability was added to CISA's Known Exploited Vulnerabilities catalog on 2022-05-25, and EPSS assigns it an 85.3% probability of exploitation within 30 days (100th percentile), though no public proof-of-concept is catalogued and ransomware use is unknown. Do: Apply Oracle's Java updates immediately per CISA's required action: upgrade all JRE installations to a currently supported release, at minimum incorporating the April 2013 Oracle Critical Patch Update that addressed this flaw. Inventory endpoints and servers for legacy JRE installs, remove or disable the Java browser plugin where it is not required, and watch for drive-by exploit kit activity (e.g., LightsOut) as an indicator of exposure. | — | 85% | KEV |
| masshundreds of millions of endpoints (Java's historical install base), of which the remaining unpatched legacy subset is likely tens of thousands to millions of… |
Indicators of compromiseauto-extracted · verify before use · export allAll →
| Type | Indicator | Context |
|---|---|---|
| url | http://globalbrowserstatistic.com/statG/stat.php? | econd redirection to stat.php has the following parameters: hXXp://globalbrowserstatistic.com/statG/stat.php? ip=YOUR_IP &useragent=mozilla%2F4.0%20(compatible%3B%20msie |
Full article981 words · extracted from securelist.com · click to collapse
Around one year ago I posted about what were the most common web attacks in Spain and how the malware was spread. It is time for an update!
We regularly collect data regarding infected web sites based in our detections on KSN. Apart from the general verdicts that I usually find in the top of the rank, there was another one in the top 3 for the last months that caught my eye: Trojan.JS.Iframe.aeq.
This verdict was quite popular during the last months specially in .ES sites. The detection shows that the victims of it are quite widespread:
But, what is Trojan.JS.Iframe.aeq?
The name is quite self-descriptive, a Javascript code redirecting the victim by creating an iframe. This is good enough for a verdict, but I want the details. So let’s take a look to the infected sites. The malicious code is quite obvious. At the end of the source code of the infected web site we find this:
Counter.php has a long story of malicious redirections in many different ways. In this case it was interesting to see the iframe after the tab. My colleague Micha-san found some examples back in March as you can see here. Interestingly most of the sites analyzed in Japan were also hosted in Spain. Counter.php then returns something like:
The redirection won’t return you the code under some conditions, as we will see later. The first condition is not to access twice from the same IP. When executed (there are the typical checks for avoiding execution in a non-browser environment) translates into:
So here we get the second redirection for the exploit kit site with an unique ID.
The exploit kit
This was the first time I personally found Styx exploit kit in the wild. You can find more information about it here . Basically it runs a script function called PluginDetect to profile the victim:
At the end of the HTML we find the code for selecting the exploit:
for complicating things a bit more, the “gujny” element is referenced by an iframe:
and contains:
combining this content with the calling code we have:
and now everything makes more sense. Depending on the Java version detected by the PluginDetect function, it chooses the right exploit in jorg.html (versions [5-6.32] or [7-7.09]), jlpn.html (versions [7.1-7.21]) or pdfx.html for the rest (non Java exploit).
The exploits
According to the analysis by our colleagues of McAfee here the vulnerabilities exploited are:
- “jorg.html” CVE-2013-0422
- “jlnp.html” CVE-2013-2423
- “pdfx.html loads “fnts.html” CVE-2011-3402
- “jovf.html” CVE-2013-1493
- and downloads a .pdf file CVE-2010-0188
We can confirm that jorg.html exploited the CVE-2013-0422, but we didn’t analyze the kit exhaustively (for the other vulnerabilities). You can find a very interesting analysis of this vulnerability when it was found in the wild as a 0 day here. This is the downloaded applet with the parameter for downloading the binary:
The applet was not easy to analyze as no Java decompiler can handle it, you can find my analysis in Securelyst.com/Analysis soon. It is interesting to see how the applet was only detected by Kaspersky Lab (according to VT and at the moment of the analysis) thanks to the Anti Exploit Prevention technology.
All exploits target quite recent vulnerabilities, which is worrisome. Let’s check how popular they are in our stats and what do they target:
- CVE-2013-2423 Oracle java – This is the most common vulnerability according to KSN
- CVE-2013-0422 Oracle java – 11th most common vulnerability
- CVE-2011-3402 Win32 TrueType – not in the top 20
- CVE-2013-1493 Oracle java – 9th most common vulnerability
- CVE-2010-0188 Adobe Reader – not in the top 20
Well, now we have more data to be worried about, as this kit exploits the most common vulnerability according to our data.
The infection
How did the sites distributing this malware get infected in the first place? As we said in the beginning, counter.php has a long story of malicious appearances, but it regularly changes the infrastructure, the iframes and the javascript code. All the infected sites (a surprisingly high number hosted in Spain) run different technologies, are hosted in different providers and apparently have nothing in common. So I decided to contact the hosting companies for more details. I was suspicious of a vulnerability in software like Plesk (there was one last May and a 0day found in June), WordPress or something like that. After checking the evidences with the hosting companies, we think that the FTP accounts of the users of these websites were compromised. We don’t know how, but this data may have been stolen months or years ago.
Hosting companies where very collaborative (thank you guys) and they shared the famous counter.php where all the users are redirected in the first place. Let’s take a look:
That translates into this. Interestingly different functions and strings are stored in base64 into arrays:
And now we see more details of the global structure. When users are redirected to counter.php, then there is a second redirection to stat.php after checking that the user agent of the request does not contain google, bing, yahoo, baidu, msn (search engine evasion) or opera,safari,chrome (browser selection). This second redirection to stat.php has the following parameters:
hXXp://globalbrowserstatistic.com/statG/stat.php? ip=YOUR_IP &useragent=mozilla%2F4.0%20(compatible%3B%20msie%207.0%3B%20windows%20nt%206.0) &domainname=REFERER_DOMAIN &fullpath= REFERER_FULL_PATH &check=0
Counter.php was filtering requests to the exploit kit avoiding reinfections. As stat.php does not check that the parameter IP is the remote address, now we know how to create requests for getting samples from the exploit kit.
The malware
The malware is freshly generated for new requests to avoid signature detection. Basically it drops a heavily packed dropper that, depending on the geolocation of the referer IP, drops a fakeAV or ZeroAccess (at least) in the second stage. My colleague Marta helped me with this part and she will post very soon the analysis of the downloader.
Apparently, it dropper has Russian speaking origins, as we can see in the metadata:
FileDescription:
Text extracted automatically; images, tables and formatting may be missing. Original: https://securelist.com/visit-from-an-old-friend-counter-php/57478/