What’s The Deal With Behavioral Engines?



I recently wrote a post on how scanning engines evolved from their primitive, signature-based roots in the 1980s to the present day. In that article, I touched upon how file scanning itself is just a small piece of the puzzle when it comes to protecting endpoints from threats such as malware and exploits. Today, I focus on behavioral engines, AKA host-based intrusion prevention systems (HIPS).

Put simply, behavioral engines work by monitoring the execution of processes on a system for potentially malicious actions. If a malicious action, or series of actions are spotted, the process is killed. This ensures that a malicious payload never completes its objective.

F-Secure Internet Security 2007

Behavioral monitoring… introduced about a decade ago.

In addition to blocking malware executables, behavioral monitoring can also be used to stop web-based exploit attempts and to block malware infection vectors from non-PE sources, such as Office macros and PDFs. This is achieved by monitoring common applications such as web browsers and document viewers/editors.

For example, if a user visits a malicious site, behavioral monitoring will notice the signs of an exploit attempt in the browser process itself and kill that process before the exploit runs. As it turns out, this is a great way to stop zero-day exploits.

So, why are behavioral engines so useful? The fact is, a majority of malicious payloads use the same small bag of tricks to infect systems. If an Excel file writes executable or shell code to disk, or attempts to launch executable code on the system, we can be pretty sure it is malicious. That sort of behavior is completely unheard of in legitimate documents.

Blocking on behavior is great because you don’t need to care what the sample “looks” like. New malware is published on a  frequent basis in order to avoid signature-based scanning approaches. But all those different versions will still perform the same set of actions. If you detected the first one based on behavior you’re going to detect the rest of them too.

The only way malware authors can circumvent behavioral rules is to come up with a new set of actions. And new infection vectors don’t present themselves very often. This is why, in a majority of cases, when new malware or exploits surface, we already have them covered by our own behavioral engines. The tricks malware authors have been using for some time will, most likely, continue to be used in the future.

Behavioral monitoring on the client-side is not without its caveats, though. Any monitored process will suffer a slight performance hit. For this reason, limiting what is being monitored is important. This can be achieved in a few ways.

Whitelisting is a simple and quick way to skip all scanning, and therefore it is not uncommon for endpoint protection software to run whitelisting checks prior to any other analysis step. Files can be whitelisted based on simple metadata, such as the sample’s cryptographic hash, or on more complex metadata such as signing certificates.

Scanning engines are typically faster than behavioral engines. Hence, if a scanning engine can be used to determine if a file is malicious before it is executed (for instance, when that file is written to disk, or as it is arriving over the network), a small performance improvement can be gained.

Let’s take a look at a human analogy to illustrate how this all works.

A team of security guards at a company are tasked with monitoring the building’s physical security. They spend most of their time monitoring an array of CCTV feeds. Some of the security guards take turns patrolling the building.

People arrive at, and leave the building all day long. Most employees wear visible ID badges. Some employees are even known to the security personnel. In our analogy, these ID-wearing employees are whitelisted samples. The security guards don’t need to pay a lot of attention to them, since they’re “known good”.

Visitors also come and go during the day. Newly arriving guests are unknowns to our security guards. Visitors are instructed to wait at the reception for an escort, and obtain a temporary ID card before they are allowed to continue into the building. While on the premises, they must be escorted by an employee at all times. The process of meeting an employee, signing in and obtaining a temporary ID is roughly analogous to a sample being run through a scanning engine. The scanning engine will not determine them as “known good”, but it might possibly determine that they are not malicious.

In our hypothetical situation, at some point during the afternoon a person arrives who doesn’t follow procedure. Since not all employees remember to wear their ID cards, it is possible this new arrival is an employee. None of the guards are, however, familiar with his face. Shortly after arriving, the unknown proceeds directly past reception and tailgates an employee into the main building. The security personnel immediately notice this behavior, and keep a close eye on him via the CCTV feeds. They also contact one of the patrolling guards, asking him to proceed to the unknown’s location. This step is analogous to initiating behavioral monitoring.

As the security personnel continue to closely monitor the visitor’s behavior, they observe him navigate some corridors in the building until he finally stops, produces a crowbar from his backpack, and attempts to open one of the company’s server rooms. At this point, the security guard on the scene and prevents him from accessing the room.

A single action is not always enough to determine whether a threat is truly malicious. A series of actions, in this case, tailgating into the main building unescorted, and attempting to break into a locked room, were the series of indicators that led to finally taking action.

While behavioral monitoring on the client-side is one of the most effective ways of protecting systems against common malware and exploits, back end behavioral analysis provides us with another powerful tool.

Using cloud computing infrastructure, it is possible to run thousands of instrumented sandboxes simultaneously. Files and URLs are fed into these sandboxes for execution. Each individual run generates metadata based on what happened during the execution. This metadata can include both changes to the system where the sample was run, and an execution trace of the sample itself. This resulting metadata is then analyzed by a series of rule engines for suspicious behavior. Samples are flagged for further analysis, and in many cases, automation generates detections on the fly.

By utilizing back end sandboxes it is possible to analyze hundreds of thousands of files and URLs per day – something that would be almost impossible to do manually. This process, paired with an automated static analysis process, allows samples to be categorized and grouped easily, allows new malicious samples to be identified quickly, and allows simple cloud-based detections to be generated in almost real-time.

Behavioral monitoring is a powerful tool for protecting systems against malicious threats whether used on the client itself, or in the back end. The circumstances in which behavioral monitoring technologies come into play on the endpoint are dependent on how the system encountered the threat. As we’ve explained, behavioral blocking kicks in when visiting a malicious site, opening a malicious document or running a malicious executable (action!). For this reason, you won’t see the results of this sort of technology in VirusTotal scan reports. If you’d like to check how our products fare in real world situations, where behavioral blocking is a factor, check out the testing from AV-Comparatives and AV-Test.

If you’re interested in a more technical explanation on how our own HIPS technology works, check out this white paper.

Tagged: Antivirus, Engines, Kyb3r

AV-Comparatives Real-World Test Results



AV-Comparatives runs a monthly “Whole Product Dynamic Real-World Protection” test. The organization just released its third set of results covering April 2016. And we’re pretty happy about how our products have been faring so far this year!

AV Comparatives April Real-World test results

The results of the AV Comparatives’ April “Whole Product Dynamic Real-World Protection” test.

The guys at AV-Comparatives run extremely thorough tests. In order to properly ascertain how security products function against real-world threats, they scour the Internet for actual compromised sites. This is a tough job considering that compromised sites are often taken down quickly once they’re discovered. In this latest test, they installed systems with Windows 7 SP1 and a set of fully updated third-party software. Finding malicious sites that are able to exploit fully patched software is a tough job, and we commend them on their diligence.

In all of AV-Comparatives’ real-world tests this year, we’ve blocked 100% of the threats thrown at us. (Only one of two vendors to get three-in-a-row! #hattrick) We do, however, suffer from a few false positives. This is mostly due to the fact that our product utilizes logic that makes decisions based on the prevalence of a sample. If none or very few of our customers have seen one of the samples tested against, there’s a chance we’ll block it based on its uniqueness. Andreas Clementi and his team (to their credit) are quite sly when it comes to finding clean samples that none of our own customers have encountered before, and that’s why we often end up with some false positives on their tests. But we’re not stressing out too much about them. None of the samples are critical system files, and we have special logic in our products to ensure we’ll never hit false positives on files that might break systems or software. In the end, for us, it’s more important to block all threats that we encounter than it is to avoid all potential hiccups.

Not that we’re resting on that logic… if you recall from a past post, we’re in the process developing improved automation for collecting and analyzing legit files. We want to outdo Clementi & team when it comes to hunting down clean samples.

We’d like to thank Andreas and everybody else at AV-Comparatives for putting in the hard work that they do. Their testing is important to our industry. And these tests provide us with an invaluable measurement of how well we’re protecting our customers.

Tagged: AV, AV-Comparatives, Kyb3r, Real-World Protection

PSA Payload Via Hacked Locky Host



Earlier this month, researchers at Avira discovered a Locky crypto-ransomware distribution network that had been hacked by a grey hat. In an apparent effort to disrupt Locky, the hacker replaced the payload with a 12 byte text file – which contained the message “Stupid Locky”.

Today, Päivi, a researcher on our Threat Intelligence team discovered evidence of a similar grey hat hack… but with a new message.

Locky Payload Replaced - HTTP Capture

The JScript (.js) attachment tested by Päivi fetched this attempt at a public service announcement.

Locky Payload Replaced

Emails attachment? I get the sense this grey hat speaks English as a second language. But that’s okay, it’s a decent first attempt at a PSA. But a word of advice to whom it may concern…

Perhaps you could replace the biohazard symbol with something else, such as a peace sign? Panic doesn’t help educate people in the long run. And seeing a biohazard symbol is likely to induce panic rather than just grabbing your subject’s attention.

And you might be surprised how many people will not understand what a “malicious file” is – so perhaps consider something like:

You are reading this message because you clicked on a computer virus. But I (or is it we?) hacked them so they couldn’t hack you. You might not be so lucky next time. Be more careful in the future.

Tagged: Crypto, Kyb3r, Locky, Ransomware

What’s The Deal With Scanning Engines?



People (such as tech journalists and product reviewers) often ask us how our scanning engines work, and what the difference is between signature engines and other types of scan engines. In fact, we were asked such a question just last week. So, let’s explore the topic in-depth….

Signature-based scanning refers to the practice of checking a full-file hash or a series of partial-file hashes against a list or database, in order to obtain a verdict on an object. This is roughly where antivirus began, back in the 1980s. The emergence of polymorphic malware in the early 1990s was the catalyst that spurred an evolution from the signature-based approach to more complex file scanning engines.

Brain. On a floppy.

This is how we received new samples in the 80s.

Endpoint protection solutions include file scanning engines. They’re not really just for scanning files, though. Give them any sort of input buffer, such as a piece of memory or a network stream, and they’ll do their job.

File scanning engines have become very sophisticated. They include archive traversal mechanisms, parsers for multiple file formats, static and dynamic unpackers, disassemblers, and emulators capable of running both scripts and executable formats. Today’s detections are really just complex computer programs, designed to perform intricate sample analysis directly on the client. Modern detections are designed to catch thousands, or even hundreds of thousands of samples. A far cry from the one hash per sample approach of the old days.

As you might imagine, it takes time to create sophisticated detections. An analyst must to collect samples, inspect them, write code, and test, before finally releasing to customers. Fairly simple signature-based detections can, on the other hand, be generated easily by automation. As new samples arrive, they are run through a series of static and dynamic analysis tools, and rule engines in order to quickly deliver a verdict.

Hence, when a new threat emerges, back end automation kicks in to cover early samples while the analysts get to work writing proper detections. Since today’s software can quickly and easily perform hash lookups over the Internet, these simple detections are not even delivered as part of a local database update. This cloud-lookup mechanism has an added benefit in that it allows us to protect customers against emerging threats very quickly, and regardless of when they emerge.

But that’s not the whole story.

All modern endpoint protection solutions utilize multiple mechanisms to keep customers protected. The following is a very simple picture of how endpoint protection works today.

  1. URL blocking. Preventing a user from being exposed to a site hosting an exploit kit or other malicious content negates the need for any further protection measures. We do this largely via URL and IP reputation cloud queries. Spam blocking and email filtering also happen here.
  2. Exploit detection. If a user does manage to visit a site hosting an exploit kit, and that user is running vulnerable software, any attempt to exploit that vulnerable software will be blocked by our behavioral monitoring engine.
  3. Network and on-access scanning. If a user receives a malicious file via email or download, it will be scanned on the network or when it is written to disk. If the file is found to be malicious, it will be removed from the user’s system (for instance, to a quarantine).
  4. Behavioral blocking. Assuming no file-based detection existed for the object, the user may then go on to open or execute the document, script, or program. At this point, malicious behavior will be blocked by our behavioral engine and again, the file will be removed. The fact is, a majority of malware delivery mechanisms are easily blocked behaviorally. In most cases, when we find new threats, we also discover that we had, in the distant past, already added logic addressing the mechanisms it uses.

Antivirus software of yore, with its nightly disk-grinding scheduled scans has evolved into the latest generation of endpoint protection used today. One of the best ways to protect endpoints against modern threats is to prevent threats from making contact with their victims in the first place. Failing that, utilizing a multi-pronged approach to block common attack vectors ensures that multiple opportunities exist to stop attacks in their tracks.

File scanning is just one of the many mechanisms that “AV vendors” use to protect endpoints. Since we often have actual attack vectors covered well with both our exploit detection and behavioral blocking mechanisms, we often don’t bother adding file-based detections (i.e., static signatures) for every new threat. And remember, at the end of the day, we always test our protection components against real-world threats using our entire product, not just individual pieces of it.

Tagged: Antivirus, Detections, Engines, Kyb3r

Bye Bye, Flash! Google Chrome Plans To Go HTML5 By Default



As was reported last week, the development team behind Google’s Chrome browser is planning to go “HTML5 by Default” during Q4 2016.

Anthony LaForge, Technical Program Manager at Google:

“Later this year we plan to change how Chromium hints to websites about the presence of Flash Player, by changing the default response of Navigator.plugins and Navigator.mimeTypes. If a site offers an HTML5 experience, this change will make that the primary experience. We will continue to ship Flash Player with Chrome, and if a site truly requires Flash, a prompt will appear at the top of the page when the user first visits that site, giving them the option of allowing it to run for that site.”

Earlier this year, in our 2015 Threat Report, I predicted that Google Chrome would soon move to deprecate Adobe Flash.

Google Chrome Flash prediction

And that Mozilla and Microsoft will follow. One down… two to go.

Here’s the article, reprinted from the report.

Flash: The Last of the Low-Hanging Fruit

Malware exploits have been a commodity for more than a decade. So much so that during 2006, the day following Microsoft’s monthly “Patch Tuesday” began to be jokingly referred to by InfoSec analysts as “Exploit Wednesday”. Quick turnaround was the key to success. On Tuesday, Microsoft released its updates which were then quickly reverse engineered in order to discover the underlying vulnerability. And then, once the vulnerability was known, an exploit was crafted for use in malware attacks, which aimed to hit those who had not yet updated.

In late 2006, malware became further commoditized with the advent of malware kits. Early kits such as MPack were victims of their own success, unable to scale rapidly to meet the ever-growing demand. But such growing pains were soon enough overcome by malware services and today there are numerous exploit kits available via underground markets.

Exploit Wednesday is no longer a thing. Microsoft’s software[¹] is far more secure than it was 10 years ago and its patches roll out much more quickly. Exploit kits moved on from Microsoft to Adobe. Reader was the biggest target for a time (also Flash). But browsers began to offer native PDF support and Reader became unnecessary for most. Adobe adopted strong update cycles and its software moved, for a time, out of harm’s way. Then Java’s browser plugin became the favorite target — the weakest of the herd. Browser developers more or less forced it into a very restricted place.

And so at the moment… Adobe’s Flash is the last “best” plugin still standing for exploit kits to target. But for how long?

On April 29, 2010, Steve Jobs published an open letter called “Thoughts on Flash” explaining why Apple would not allow Flash on iOS devices. Many technology analysts point to this as the beginning of the end for Flash Player, at least on mobile devices. This proved to be true. On June 28, 2012, Adobe announced there would be no certified implementations of Flash Player for Android 4.1 and it would limit installations via Google Play on August 15th 2012 [²].

Flash has since hung on to its desktop market, but everywhere you look, it’s being deprecated. In August 2015, Amazon announced that “Beginning September 1, 2015, Amazon no longer accepts Flash ads.” Google followed Amazon’s lead in February 2016. Its ad networks, AdWords and DoubleClick, will no longer accept Flash-based display ads starting from June 30th, 2016. They’ll disable Flash-based ads on January 2nd, 2017.

It’s at this point that I’ll make the following prediction for early 2017 — once it no longer needs to support Flash-based ads — the Google Chrome browser will start aggressively forcing users to whitelist sites that require any sort of Flash. Mozilla’s Firefox and Microsoft Edge will do the same, and by spring of 2017… Flash will be effectively decapitated as far as exploit kits are concerned.

Exploit kits face a disruptive future without much new fruit in sight. Commoditized malware services will turn even further toward the use of malware attachments such as the macro-based malware that is currently trending.

If only we could keep people from clicking “okay” to make the box go away.

[¹] Silverlight is a general exception, it is currently exploited by kits. But hopefully Silverlight will soon go extinct as Netflix is dumping the technology.

[²] Ironically, a great deal of Android malware is pushed at people via deceptive ads claiming that a Flash update is required. Even when there is no Flash, its legacy provides a social engineering vulnerability. Google’s search engineers are beginning to configure Chrome to warn about sites that display such ads.

Tagged: Exploit Kits, Flash, Google, Kyb3r

Is AV Dead?



This year, F-Secure is hosting the annual AVAR (Association of Anti Virus Asia Researchers) conference, which will be held in Kuala Lumpur, Malaysia. The conference will start on November 30th and end on December 2nd. This is the 19th AVAR conference, and the first time it’s being held in Malaysia. The event will be held at the prestigious Grand Hyatt Kuala Lumpur.


We hope this year’s theme promotes some lively debate.

The theme this year is based on the perennially-controversial topic: Is AV dead?

We just opened our call for papers. If you have an opinion about this year’s topic, and you have some interesting material you think would be relevant to the argument, either for or against, go ahead and make a submission! You can find the form here.

We’re excited to see what people come up with around this topic, and we’re very much hoping it prompts some interesting discussion!

Hope to see you there.

Tagged: AV, AVAR, Conference, Kyb3r

On The Monetization Of Crypto-Ransomware



Over the last few years, technologies and infrastructure, in the form of crypto-currencies, the dark web and well-organized criminal affiliate programs have aligned to create the perfect storm. And from that storm, the crypto-ransomware beast has arisen.

There’s a reason why crypto-ransomware is making the news almost daily – it’s unique compared to every other threat we’ve seen in the last few years in that it offers a tangible service to the victim – pay the ransom and you get your files back. And, as we’ve seen in an increasing number of high-profile cases, this is exactly what people are doing. There’s no need to remind you of a recent case where a hospital shelled out a considerable sum of Bitcoin to recover their infrastructure. It has been estimated that the crypto-ransomware industry makes as much as 100,000,000 EUR per year.

Crypto-ransomware continues be a lucrative money-making vehicle for criminals, and it’s possible it will continue displace alternative malware models such as banking trojans as time goes on. As with all business, focus must invariably shift into models that optimize and improve return on investment. We liken the business models of today’s ransomware campaigns to those of the early Internet era – still very simple in nature and largely unfocused. The bottom line is there’s still a great deal of room for creativity and innovation. The business models behind crypto-ransomware are slowly maturing and recently we’ve started to notice some attempts at innovation.

Select crypto-ransomware campaigns have specifically targeted “tier 1” countries such as the US, UK, Australia, and Canada. This targeting makes sense from a bang-for-the-buck perspective. The ransomware itself doesn’t need to be localized, the target demographic is relatively affluent, and some studies have shown a willingness for victims in these regions to actually pay the ransom.

Phishing campaigns carefully tuned for specific regions and sometimes timed to calendar events are another trick we’ve seen. In one recent example we observed a spam campaign run in Sweden, where victims received a convincing message from their local post office about the arrival of a parcel. Although these sort of targeted, regional spam campaigns are nothing new, some malware actors are turning to them for superior uptake rates.

Some crypto-ransomware families have been working on improving their support interfaces in the hopes of making it easier for the victim to pay. Support sites are becoming more intuitive, and, in some cases (such as PadCrypt), even include live chat interfaces. Instructions on how to obtain Bitcoin, how to connect through Tor to the support site and how to get your files back are becoming clearer and more well presented. Unsurprisingly, crypto-ransomware supporting services are, in many cases, better than those run by legitimate companies. As an interesting aside, we’ve also seen independent IT support guys getting into the business of brokering Bitcoin for their customers in order to facilitate decryption of victims’ files.

The TrueCrypter family allows payments to be made using Amazon gift cards. We’ve also seen crypto-ransomware families accepting iTunes cards for payment. You might think that this is a risky move on the part of the criminals, since Amazon or Apple could easily go after the folks using those cards. As it turns out, the criminals are likely to immediately flip those gift cards on site such as eBay, leaving the buyer to deal with the consequences. Given the richer set of content on the US iTunes store, there’s a demand for US-based iTunes gift cards in Europe.

In another surprising direction, we’ve seen one crypto-ransomware family attempt to force a payment by applying pressure on the victim. We recently encountered the Jigsaw family, which deletes an increasing number of files every hour as long as the ransom hasn’t been paid, and presents the victim with a 72 hour deadline after which all files will be deleted. Rebooting the machine, or forcibly killing the agent will cause 1000 files to be instantly deleted. These tactics are not unlike hostage situations you might have seen on TV shows or movies. Unfortunately, at this moment we don’t have data available to determine whether this particular tactic makes people more, or less likely to pay up.

Jigsaw ransomware

Would you pay the ransom?

The above examples show how actors behind crypto-ransomware are starting to experiment with different business models in an effort to gain better return on investment. Criminals have learned that large crypto-ransomware campaigns will get you noticed and taken down. At least that’s what happened to the guys behind CryptoLocker a few years back. So they’re all running smaller campaigns nowadays. But smaller campaigns aren’t just important for staying under the radar of major law enforcement agencies, they’re also important for maximizing profits in a world where you must pay for each infected computer or each spam message sent.

We recently ran a poll asking users how much they’d be willing to pay to decrypt their files, should they fall victim to crypto-ransomware.

At the time that he ran the poll, many ransoms were around 1 BTC, or just north of $400. After doing some simple math, we came to the conclusion that, by halving the price, these guys could almost triple their money. Conducting that research and coming to that conclusion didn’t take too much effort, and it’d take even fewer lines of code to implement. We aren’t sure if we tipped off some malware authors with those tweets, but we have recently seen a trend towards cheaper ransoms.

It seems that not all ransomware authors got that memo, though. Just a few days ago, a new strain of crypto-ransomware appeared that claims to donate the ransom to charity. However, at 5 BTC, or about $2,200 at the time of writing, we don’t expect many people to be so generous.

Down the road, we’re expecting to see more intelligence and sophistication applied to the pricing models used by crypto-ransomware. Right now, the software is rather unintelligent, setting a fixed-price ransom for any and every infected machine. We expect variable pricing schemes to show up at some point, perhaps based on number or type of files encrypted, or whether the software detected the machine to be personal computer versus one being used by a corporate employee. A 1 BTC ransom is a fairly hefty fee for most individuals, but peanuts for many companies.

Many crypto-ransomware families already attempt to infect network shares, but none do it in an intelligent way; a single payment would, in theory, allow a victim to get back all files, including those on the share. For this reason, we’re also expecting to see developers build some intelligence into their software in order to more efficiently propagate throughout a network, upping the number of infected machines, or again, pricing the ransom based on the environment.

The folks behind crimeware affiliate networks and malware campaigns are already showing a fair amount of business savvy. It is not unimaginable that these individuals, when given the task of maximizing profits or return of investment, will devise more creative software and process models, based on pricing, ease-of-use, network propagation, or smart-targeting. We fully expect to see progress in the sophistication of both business and monetization models used by crypto-ransomware in the near future.

Tagged: Bitcoin, Crypto, Kyb3r, Ransomware