Kaspersky for Business

Get Protectedfrom Exploits

www.kaspersky.com#truecybersecurity

Get Protected from Exploits
Exploits as a part of modern threat landscapeuse is high enough to make these attacks well worthwhile.
For example, a well-known CVE-2010-2568 vulnerability,
once used by Stuxnet, remains the top performer in termsof number of users attacked, and the WannaCryransomware pandemic also used a vulnerability that has
an available patch. Then again, even the most securityaware companies sometimes have vulnerable software
running in business-critical processes – for a number ofreasons, including complicated update procedures,compatibility issues or configuration-sensitive legacy
applications.

Despite some recent trends, such as the heavy use ofnon- malware components in their toolsets,
cyberattackers as a whole retain their reliance on
vulnerability exploitation as an attack spearhead, theprimary means for initial penetration. In 2016-2017, the useof exploits increased overall by roughly a quarter, and forcorporate users alone the percentage was even higher.
The most widespread scenarios remain unchanging: either
exploit-carrying attachments to e-messages, or drive-byattacks, including malicious links and ‘watering hole’
redirects to the same links, with exploits on hand to attack
whatever vulnerabilities the victim’s system possesses. And
it’s long been obvious that, while attackers may get lucky
and find a zero-day, most of the time it’s known
vulnerabilities that are exploited. The fact is that theprobability of finding an unpatched OS or old app still in

So protection against vulnerability exploitation remains
a primary concern for Endpoint Security. After all, thewhole data breach prevention task turns on how
effectively the attack’s spearhead can be blocked.

The exploit’s own kill chain - and counteractions
Counteraction: There are only a limited number ofways to insert this rogue data, and all are well known,
so modern Operating Systems offer built-in mitigations
to counter exploits at this phase. But, to be effective,these mitigations require applications to be compiled
with particular parameters in a modern development
environment. Unfortunately, this is not possible forsome older apps. Some mitigations can be invokedexternally, but the flip side of the coin is that externallyforcing memory use restrictions can result in instability
and the crashing of the application that the security
solution is trying to protect.

Of course, for the end user, the best possible outcome is allthat really matters: if the existing security solution successfully
prevents the attacker from doing anything malicious, thatcounts as a victory.
But for the solution’s vendor, this particular phase ofa cyberattack is a very delicate point – it involves theuser’s own applications, which all too often don’t tolerateunsubtle handling and can react with crashes and The Blue
Screen of Death. Every phase of an exploit’s own ‘kill chain’presents different opportunities and challenges for thedefender. Let’s look at this in more detail:3) E xploitation. Here’s where activities which aren’t partof the general order of things start happening. Using
the existing vulnerability, the attacker coerces theattacked app’s process into performing actions, which
may or may not be within its standard capabilities, but,in any case, are instrumental in the attacker’s progress.
Depending on the attack scheme, this is usuallyfollowed by shellcode execution, though in somecases standard app functionality can be leveraged todeliver the malware payload from the C&C server.

1) D elivery. Typically an email attachment or website, asabove. This ends with the targeted application beginning
to process the offered data – including the exploit code.
Counteraction: Some exploits can be blocked during
this phase using proper mail server security, anti-phishingand content analysis. A considerable amount of mass
malware is, in fact, blocked here. But more sophisticatedspecimens, especially in well-prepared targeted
attacks, can shake static analysis mechanisms off theirtrail. The dynamic study of everything that comes yourway in a sandbox is a good move, but, to be reallyeffective, it requires considerable resources and skill.
Also, in most scenarios, it would not allow blocking but
would only alert corporate security officers, which,given the time gap between delivery and actual
sandbox detonation (there’s usually a queue), means
this is not a true defense against exploits.

Counteraction: To be able to detect and influence
activities occurring during this phase, the security
solution must have access to the protected
process’s context. The only way to do this efficiently
is by performing a process injection, not unlike themalware technique itself. While this approach offers
an opportunity to stop exploits at an earlier stage andallows the protection of arbitrary processes, it also
suffers from considerable drawbacks. Performancedegradation and compatibility issues are notinfrequent, and their probability increases with each
mitigation technique switched on for a particular
process. Also, for processes the solution was notpreviously tested with, the need for tedious trial-and-error
configuration can cause great inconvenience, especially2) M emory manipulation. During this phase, rogue datais placed into different memory areas. This is nota violation of any security principles and is mostly
harmless in itself – but at a later stage, once thevulnerability has been exploited, this data is used in
specific attack processes.

15) Payload execution. The payload can be downloaded
as a file – or, in the case of a fully bodiless scenario,
it can be loaded and executed directly in the system’smemory. After this point, the malicious activity starts.

for hard-pressed generalist IT administrators. Some
vendors strongly recommend consulting with theirsupport teams prior to any attempts at mitigation rulecustomization.

Counteraction: Launching another application orexecution thread can look suspicious, especially if theapp in question is known to lack this functionality. So
this may well serve as a pretext for a security solution
to set execution to ‘pause’ and to analyze the legalityof the launch in more detail. Additional behavioral
indicators provided by execution tracking mechanisms
should allow the solution to block the payload
execution with confidence.

It is also worth noting that every new version-changeof the application can result in unexpected crashes andthe need to either tweak security settings to find a safe
configuration – or to refrain from using thismechanism until (if ever) the solution’s vendor
manages to adjust it sufficiently.
4) S hellcode execution. This is where the attacker’s
arbitrary code is executed, resulting in the execution ofa malicious payload.

This particular phase applies to the whole plethora of
exploitation scenarios – any exploit’s ultimate goal is tolaunch a payload. So this becomes a bottleneck –leaving the attacker with very little space to maneuver.
Despite the fact that the exploitation has alreadyhappened, the whole attack sequence is at its mostvulnerable right now.

Counteraction: This is where the exploited process
starts doing things it’s mostly not expected to, and thiscan be detected externally, using non-invasive
behavior tracking mechanisms. Such mechanisms
usually don’t require any manual configuration, whichsaves a lot of time and effort for IT staff. Also,
there’s no meddling with the protected process itself,
so there’s zero chance for compatibility andperformance issues. In fairness, it should be noted that,besides understanding what activities should betreated as suspicious, this approach’s effectivenessalso depends on a knowledge of what the process
normally does, so it’s hardly suitable with previously
unknown apps. But then again, 99.9% of exploitation
scenarios target quite a limited number of popularapplications and system components, so the gains interms of hassle-free defense clearly outweigh thelimitations. This approach can also benefit fromadditional sources of threat intelligence, such as lists ofknown attack-related hosts and IP addresses.

As you can see, different phases of the exploit’s micro-killchain may require different counteraction mechanisms.
While we, in Kaspersky Lab, consider a multi-layered
approach to cybersecurity the most effective, we also
understand that providing the best outcome for customers
means not only reliable protection, but also the lowest
possible impact on existing business processes.
And so we created our Exploit Prevention1, a multi-layered
system in its own right that utilizes not only the mosteffective, but also the most reliable, resource-efficientand hassle-free combination of techniques to ensure
a smooth experience for both end users and administrators.2

Attack techniques, zero-days and Kaspersky Exploit
Prevention
While it intuitively feels safer to block an exploit as earlyas possible in its kill chain, the techniques for doing thisactually pay off much less frequently than we’d wish. Multiple
compatibility issues and issues around any change in theprotected apps led us at Kaspersky Lab to decide on avoiding
most of these mitigations and focusing on non-invasive
behavioral prevention. It’s also important to remember thatthese mitigations work with previously known techniqueclasses, which are common knowledge. So when it comes toa zero-day exploit which uses something out of the ordinary,they’re likely to be sidestepped by the attacker. Many of thesemitigation techniques used by vendors other than Kaspersky Lab
are, in fact, very similar to those used by well-known Microsoft
EMET – and there are multiple PoCs showcasing exactly how
these can be outmaneuvered.

On the other hand, behavioral detection uses a number ofindirect indicators. Kaspersky Exploit Prevention, for example,
can also leverage additional sources of information provided
by different security layers, such as tracking changes inparticular memory areas, addressing suspicious URLs and soon. Both independent testing and multiple real world cases
prove that Kaspersky Exploit Prevention successfully detects
both synthetic and real zero-day exploits, despite having noprevious knowledge of the attack. Also, thanks to Exploit
Prevention, Kaspersky products demonstrate outstanding
effectiveness against exploit-using ransomware families, such
as CryptXXX, during the earlier campaign stages when noinformation about these attacks has had time to build up.
Still, some mitigations don’t require process tinkering andthe heavy use of resources, and are safe to use with certain
applications – so AEP makes use of these as well.
Here’s how Kaspersky Endpoint Security armed with AEP
withstands different attack techniques (note that not all ofthem are, in fact, directly related to vulnerability exploitation):

1 Exploit Prevention is available in Kaspersky Endpoint Security for Business and Kaspersky Security for Virtualization Light Agent
2 See the results of independent tests by MRG Effitas and AV Comparatives.

2Delivery

Data
Execution
Opportunity

Memorymanipulation

Stack
Execution
Opportunity

Heap
Spray
Allocation

Null
Page
Allocation

Stack
Pivoting

Exploitation

Sem
Overwriting
Passing Flow
Control to
Rop-Chain

Import/Export
Address
Table
AttackShellcode
execution

Dynamic
Heap SrpayThreatsBloсkedby Exploit
PreventionDirect Syscall
Calls

Start payload
execution

Execution
Controlledby Behavior
Detection

Payloadrunning3Exploitation Technique | Mitigation

Kaspersky Endpoint Security
Mitigation | Prevention

Buffer overflow | DEP (Data Execution Prevention)

Provided by OS

Leveraging data at predictable locations | ASLR (Address Space Layout
Randomization)

Mitigated

Stack Pivot | Stops abuse of the stack pointer

Mitigated

Null page exploit | Null Page Allocation

Mitigated and Provided by OS

Placing shellcode copies at as many memory locations as possible | Heap SprayAllocation

Prevented

Dynamic Heap Spray | Stops attacks that spray suspicious sequences on the heap

Prevented

Structured Exception Handler (SEH) overwrite | SEHOP (Structured Exception
Handler Overwrite Protection)

Provided by OS

ROP-chain | Stops Return-Oriented Programming attacks

Prevented

Token Swapping | Stops Escalation of Privileges

Prevented

Syscall | Stops system call abuse

Prevented

VBScript God Mode | Stops VBScript safety options modifications

Prevented

Our point of view here is simple: as we said earlier, weconsidered using these mitigations, and concluded that thisjust didn’t pay off in most cases. This is particularly true forlegacy systems, where too many user-mode interceptions
can easily consume precious system resources and slow
the machine’s speed below a bearable limit. And
that’s putting aside the fact that, as explained above, themajority of them can be sidestepped.
Even if a vulnerability in a venerable edition of MS Word isexploited, we know we’ll catch it immediately afterwards,
when it starts behaving improperly. After all, the mostimportant thing in exploit protection is preventing theexploit from launching the malicious payload – which isexactly what Kaspersky Exploit Prevention does toperfection. And in the most complicated cases, as withWannaCry ransomware using TCP packet-based kernel
exploits, Exploit Prevention, as one of the technologies
leveraging Behavior Detection, passes the baton to the next
security layer, the post-execution protective mechanism.

It’s worth mentioning that special attention is directed tothe execution of malicious scripts, e.g. PowerShell, HTA, JS/VBS, which is one of the most popular and dangerous
techniques used in vulnerability exploitation scenarios.
Mitigation and prevention capabilities of Exploit Prevention,
combined with the post-execution detection technology ofBehavior Detection and empowered by Remediation
Engine, allow us to achieve perfect protection level,
blocking many threats of post-exploitation stage, such as:
Fileless attacks, WoW64, DLL Hijacking and Reflective
DLL injection, Loading malicious libraries from UNC
paths or by placing them on network paths, Hollow
Process Injection, Malicious PowerShell scripts,
Malicious TaskScheduler tasks, Malicious WMI
subscriptions, Malicious script execution via legitimate
executables, Application Whitelisting Bypass, JavaLockdown, Application Lockdown and others.
Of course, some issues arise regarding mitigations provided
by the OS only. What about those cases when newer
Operating Systems or applications supporting theirembedded mitigation features can’t be used? Several
security vendors stress their solutions’ ability to provide
mitigation even in these difficult conditions - so what about
Kaspersky Lab?

With this sort of multi-layered approach, it’s no big surprisethat, as long as they had the appropriate security featuresswitched on, Kaspersky Lab customers suffered no damage
at all from the dreaded WannaCry pandemic.

4Kaspersky Lab
Enterprise Cybersecurity: www.kaspersky.com/enterprise
Cyber Threats News: www.securelist.com
IT Security News: business.kaspersky.com/

ExpertAnalysis#truecybersecurity#HuMachine
HuMachine™

www.kaspersky.com© 2019 AO Kaspersky Lab. All rights reserved. Registered trademarks and service
marks are the property of their respective owners.

MachineLearning

Big Data /Threat Intelligence