Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

PHP.Net Site Infected with Malware

Earlier today, users attempting to access the site were met with malware warnings from Google's Safe Browsing plugins in Chrome/Firefox and other browsers -


So, what was the problem?


Malware Redirection Details

Google's SafeBrowsing currently lists the following for the site:



The malware was tied to the javascript call on line 21 of the main index.php page:



When clients accessed this page on the server, there was a conditional injection of obfuscated javascript code appended to the end of the file:



This javascript data decodes to a new hidden Iframe:

The "stat.htm" page returned the following html code:


The PluginDetect_All.js is used to identify installed browser software and the page initiates a form POST back to the stat.htm page indicating the screen size and if Java and Acrobat are installed. It then returns with a 302 Redirect:


The clients get redirected to a number of different temp domains and served with various exploit payloads:

hxxp:// -> which attempted a SWF exploit:


Another instance tried to send down a PE file similar to this one on Malwr while another attempted to exploit CVE-2013-2551.


Initial Compromise Vector

The initial attack vector is not currently confirmed. What we do know at this point is that the conditional malware was executing on the "" domain and appending data to the userprefs.js file. At the time of these infections, the IP address for was and was running a lighttpd/1.4.28 web server version where as today the IP address is and is running nginx/1.4.1 so some changes were obviously made.


Mitigation Options

It is not confirmed that the attackers were able to install a malicious module such as Darkleech or Cdorked.A but it is not out of the realm of possibility. In these cases, when attackers have that level of access to install a malicious web server module, there isn't much you can do locally to prevent these attacks. What would be possible, however, would be to use an external WAF such as ModSecurity to dynamically add in new Content Security Policy (CSP) response headers or alter the HTML itself with a meta tag. Using this type of topology, even if attackers were able to compromise the web server and send out malicious JS code, the WAF would add the CSP data on a separate system on the way out to the intended victim's browser.

The following ModSecurity rules show an example of modifying the HTML to add in a meta tag which would only allow iframe sources from

SecContentInjection OnSecStreamOutBodyInspection OnSecRule REQUEST_FILENAME "@endsWith .php" "chain,phase:request,t:none,nolog,pass"   SecRule STREAM_OUTPUT_BODY "@rsub s/<head>/<head>|00|<meta http-equiv=\"Content-Security-Policy\" content=\"frame-src\"<\/>/"

This is how the HTML would look to the browser:


In this scenario, even if Google Chrome received the malicious JS code, it would not execute it due to this CSP policy:


Applying security policies such as CSP externally to your normal website has value as it prevents them from being disabled or modified in the event of a local compromise.

Latest SpiderLabs Blogs

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More

Physical Address Strangeness in Spam

Ten years ago, Congress passed the "CAN-SPAM Act" (also known as theYou-CAN-SPAM Act, since it defined legal spam and supersedes any stricter state-antispam laws). One of the provisions of the act is...

Read More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising

During an Advanced Continual Threat Hunt (ACTH) investigation that took place in early December 2023, Trustwave SpiderLabs discovered Ov3r_Stealer, an infostealer distributed using Facebook...

Read More