Software Vulnerability Exploitation

Trends
Exploring the impact of software mitigations on patterns of vulnerability exploitation

Software Vulnerability Exploitation Trends

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS,
IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
This document is provided as-is. Information and views expressed in this document, including URL
and other Internet Web site references, may change without notice. You bear the risk of using it.
Copyright 2013 Microsoft Corporation. All rights reserved.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.

Authors
Swamy Shivaganga Nagaraju Microsoft Security Response Center
Cristian Craioveanu Microsoft Security Response Center
Elia Florio Microsoft Security Response Center
Matt Miller Microsoft Security Engineering Center

1 Vulnerability Exploitation Trends

Table of contents
Foreword .......................................................................................................................................................... 3
Introduction .................................................................................................................................................... 4
Exploitation trends ........................................................................................................................................ 5
Improvements in Windows 8 .................................................................................................................... 13
Recommendations ...................................................................................................................................... 17
References ..................................................................................................................................................... 18
Appendix: Data Sources and Glossary ................................................................................................... 19

Vulnerability Exploitation Trends

Foreword
Using security science to create more secure products and services
The Microsoft Security Engineering Center carries out some of the software industrys most advanced security science research.
Leveraging insights we glean from the Microsoft Security Response Center, the team examines new techniques that are used to
attack Microsoft products and services and third-party applications running on Microsoft platforms. They use this
understanding on how the attacks succeed to design countermeasures to defeat them.
The output of this research feeds back into the Microsoft Security Development Lifecycle, a mandatory part of the
development process that every Microsoft product or service must implement. The result is that each new version of an
operating system, browser or application is harder to attack than previous versions, making it more difficult and costly for
criminals to develop malicious attacks. The more expensive it is to develop an attack, the less likely it is that the attack will be
created and used.
This whitepaper examines the effectiveness of this approach. The paper analyzes software vulnerabilities addressed through
Microsoft security updates that were exploited, and provides recommendations that can help to minimize risk of attack. Two
findings are clear first, the innovations introduced by security science have forced attackers to change the attack methods
they use, often requiring the development of more expensive multi-stage attacks. Second, new attacks continue to be
developed for older, less secure versions of products and services.
A special note to those still running Windows XP - the paper also examines the security features in Windows XP Service Pack 3
and compares them with the features in Windows 8, our most secure operating system to date. Only a quarter of Windows 8
protections are available in any form in Windows XP Service Pack 3. This means that the attack techniques that have been
developed in the ensuing eight years can still be deployed against Windows XP, even though those techniques are mitigated
by the updated security features in Windows 8. Running Windows XP on network-connected systems carries additional risk; the
fact that Windows XP will no longer be supported at all after April 8, 2014 means that this risk will only increase over time.
The Microsoft Security Engineering Center continues their work examining new attack techniques as they are developed, which
will ensure the security of Microsoft products and services keeps pace with ever-improving attack techniques.
Matt Thomlinson
General Manager
Microsoft Trustworthy Computing Security

3 Vulnerability Exploitation Trends

Introduction
One of the security challenges that both individuals and
organizations face is gauging the risks that are associated with
vulnerabilities in the operating systems and applications that they
use. Although such vulnerabilities always have some level of
potential risk, this risk only becomes actualized when an attacker
develops a functioning exploit. The existence of an exploit is what
allows a malicious attacker to take advantage of a vulnerability
and potentially compromise affected computers. From a risk
management perspective, the likelihood of an exploit being
developed can be an important factor in providing a more
precise estimation of a vulnerabilitys actual risk. To this point,
Microsoft security updates always include a description of a
vulnerabilitys expected worst-case impact and, beginning in
2008, an Exploitability Index1 (XI) rating that measures the
likelihood of a vulnerability actually being exploited.

This white paper explores the impact of improvements that

Microsoft has made over time to address software vulnerabilities.
This analysis is based on a survey of Microsoft vulnerabilities that
have been addressed through security updates over the past
seven years (2006 2012) and are known to have been exploited.
The survey focuses on assessing trends in the types of
vulnerabilities that have been exploited, the product versions that
have been targeted, and the exploitation techniques that have
been used by attackers. It also highlights security improvements
in Windows 8 that help mitigate techniques that are currently
being used by attackers. The findings of this survey were used to
create a set of recommendations on how to effectively minimize
risk associated with software vulnerabilities.

A key factor that influences the likelihood that a vulnerability will

be exploited is how difficult and costly it will be for an attacker to
develop a reliable exploit. Over the past decade, Microsoft has
introduced numerous defense-in-depth security features into
Windows and other products that have been specifically designed
to increase the cost and complexity of developing exploits. These
security features, which are detailed in the white paper
Mitigating Software Vulnerabilities,2 are particularly noteworthy
because they offer protection even when the details of a
vulnerability are not yet known to a vendor or a vulnerability has
not yet been addressed through a security update.

http://technet.microsoft.com/en-us/security/cc998259.aspx

Vulnerability Exploitation Trends

A KEY FACTOR THAT

INFLUENCES THE LIKELIHOOD
THAT A VULNERABILITY WILL
BE EXPLOITED IS HOW
DIFFICULT AND COSTLY IT
WILL BE FOR AN ATTACKER
TO DEVELOP A RELIABLE
EXPLOIT.

www.microsoft.com/enus/download/details.aspx?id=26788
2

Exploitation trends
This section explores historical
exploitation trends for Microsoft
vulnerabilities that have been
addressed through security updates
within the past seven years (2006
2012). Evidence about which
vulnerabilities have been exploited was
gathered from public and private
reports as well as Microsoft
antimalware telemetry feeds. Although
this data is believed to be thorough
and complete, it is possible that

vulnerabilities may have been

exploited without being detected.
However, the scale of any such
exploitation is expected to have been
small because no discernible evidence
exists.
Unless otherwise stated, this analysis
focuses on remote code execution
(RCE) vulnerabilities because these
vulnerabilities are often the most
severe.

KEY FINDINGS
The key findings that were made through this analysis of historical exploitation trends are:

The number of RCE vulnerabilities that are known to be exploited per year appears to be decreasing.

Vulnerabilities are most often exploited only after a security update is available, although recent years have shown an upward
trend in the percentage of vulnerabilities that are exploited before a security update is available.

Windows 7 and Internet Explorer 9 are being increasingly targeted by exploits.

Stack corruption vulnerabilities were historically the most commonly exploited vulnerability class, but now they are rarely
exploited.

Use after free vulnerabilities are currently the most commonly exploited vulnerability class.

Exploits increasingly rely on techniques that can be used to bypass the Data Execution Prevention (DEP) and Address Space
Layout Randomization (ASLR).

5 Vulnerability Exploitation Trends

Scale
To help set the context for assessing exploitation trends, it is
helpful to start by considering the scale at which vulnerabilities
are actually known to have been exploited.
The following figure represents the number of common
vulnerabilities and exposures (CVEs) that were classified as RCE
CVEs over the last seven years. This data shows that

approximately 29% of the CVEs addressed during this period had

evidence of being exploited, ranging from 18% in 2008 to 41% in
2011. The data also suggests that 2011 was a turning point in the
upward trend of vulnerabilities being exploited and that 2012
showed a significant decline in the number of known exploits. As
subsequent sections will show, this decline coincides with the
increasing adoption of Windows 7, Office 2010, and Internet
Explorer 9all of which benefit from stronger defenses.

100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%

2006

2007

2008

2009

2010

2011

2012

Known exploit

28

21

21

33

66

49

27

No known exploit

66

78

94

94

113

70

75

Figure 1. CVEs that were exploited and resolved through security updates

The general timeframe within which vulnerabilities are known to

be exploited is also an important factor when managing risk. The
following figure shows that, with the exception of 2006 and 2007,
most RCE issues only had evidence of being exploited after a
security update was available. This information emphasizes the
point that staying current with security updates is an effective

way to minimize risk. However, recent years have shown an

upward trend in the percentage of vulnerabilities that are
exploited before a security update is available. This increase
means that it is also important to have mitigations in place that
are able to complicate exploitation without requiring prior
knowledge of a specific vulnerability.

Vulnerability Exploitation Trends 6

100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%

2006

2007

2008

2009

2010

2011

2012

Exploited before update

16

12

11

14

16

12

Exploited after update

12

16

22

52

33

15

Figure 2. Percentages of CVEs that were exploited before vs. after security updates were available

The Windows Vista lull

In 2007 and 2008, there was an apparent lull in the number of
CVEs that were known to have been exploited. This lull occurred
despite the fact that the total number of RCE vulnerabilities that
were addressed through security updates actually increased
compared to 2006. One explanation for this lull is that the release
of Windows Vista may have forced a period of attacker

innovation, because Windows Vista included many security

improvements that were designed to break exploitation
techniques that attackers relied on at the time. Most notably,
Windows Vista was the first version of Windows to support
address space layout randomization (ASLR) as well as a
significantly hardened heap implementation.

Targets
The product versions that are affected by a vulnerability are what
define the set of at-risk targets that an attacker could attempt to
exploit. In practice, exploits often target only a small subset of the
affected product versions, for multiple reasons; one key factor is
that the runtime environment of an application tends to be
different between product versions. These differences can make it
difficult to build an exploit that functions and is reliable against
the complete set of potential targets. Accordingly, exploit writers
typically target affected versions that are seen as high yield, such
as those versions that are used by the largest portions of the
population.

7 Vulnerability Exploitation Trends

Of the exploit data that was analyzed, only 34% of the CVEs had
at least one exploit for which the intended targets were known.
The following figure shows the versions of Windows that were
targeted for this subset. Notably, a downward trend is evident
over the last seven years in the number of exploits that targeted
Windows 2000, which no longer appeared as a target in 2012.
The number of exploits that targeted Windows XP and Windows
Vista has also begun trending downward in the past three years,
which corresponds to the increase in exploits that target
Windows 7.

CVEs

15
13
11
9
7
5
3
1
-1

2006

2007

2008

2009

2010

2011

2012

Windows 2000

14

Windows XP

14

11

13

Windows Vista

Windows 7

Figure 3. The number of CVEs for which exploits were written that targeted specific Windows versions

For exploits that targeted vulnerabilities reachable through

Internet Explorer, the following figure shows how Internet
Explorer 6, 7, and 8 appear to be trending downward as targets
whereas Internet Explorer 9 started being explicitly targeted in
2012. As a point of reference, the release dates for each version
of Internet Explorer were as follows:
Internet Explorer 6. August, 2001

Internet Explorer 7. October, 2006

Internet Explorer 8. March, 2009

Internet Explorer 9. March, 2011

8
7
6
CVEs

5
4
3
2
1
0

2006

2007

2008

2009

2010

2011

2012

Internet Explorer 6

Internet Explorer 7

Internet Explorer 8

Internet Explorer 9

Figure 4. The number of CVEs for which exploits were written that targeted specific Internet Explorer versions

Vulnerability Exploitation Trends 8

Vulnerabilities
The root cause of a vulnerability plays a key role in defining the
set of exploitation techniques that an attacker can use when
developing an exploit. As a result, the level of difficulty in
developing an exploit is heavily dependent on the type of
vulnerability that is being exploited. In terms of risk management,
the root cause of a vulnerability can be an important factor in
influencing the likelihood that an exploit will be developed. As
the following two figures illustrate, there have been some
noteworthy shifts in the classes of vulnerabilities that are known
to have been exploited.
The first clear shift can be seen through the decline in the
percentage of exploits for stack corruption vulnerabilities, such as
stack-based buffer overruns. (See the Glossary section at the
end of this paper for a definition of stack corruption
vulnerabilities.) This vulnerability class has historically been the
most likely to be exploited, but since 2009 it has been steadily

declining. Two factors that could be contributing to this decline

are the increasing prevalence of exploit mitigations for stack
corruption issues (such as /GS and SafeSEH) and the increasing
effectiveness of static analysis tools designed to detect such
vulnerabilities.
A second shift can be seen in the increasing number of use after
free vulnerabilities that have been exploited. This vulnerability
class includes issues that arise because of incorrect management
of object lifetimes (see the Glossary section at the end of this
paper for a definition of use after free vulnerabilities.) One reason
for this increase is that client-side vulnerabilities have become a
prime focus for attackers and object lifetime issues are a common
vulnerability class encountered in applications such as web
browsers.

100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
2006

2007

2008

2009

2010

2011

Stack Corruption

Heap Corruption

Use After Free

Type Confusion

Command Execution

Unsafe DLL Load

Uninitialized Use

Invalid Free

Memory Read

Other

XSS

Cryptography

Unsafe Control Transfer

Figure 5. The distribution of CVE vulnerability classes for CVEs that are known to have been exploited

9 Vulnerability Exploitation Trends

2012

100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
Windows 2000

Windows XP

Windows Vista

Windows 7

Stack Corruption

Use After Free

Heap Corruption

Command Execution

Type Confusion

XSS

Unsafe DLL Load

Uninitialized Use

Invalid Free

Other

Unsafe Control Transfer

Figure 6. The distribution of CVE vulnerability classes for which exploits were written
that targeted specific versions of Windows over the past seven years

Techniques
Attackers have developed a variety of exploitation techniques
over time that can potentially enable them to exploit
vulnerabilities under differing circumstances. These techniques
encompass the fundamental methods of leveraging a particular
class of vulnerability as a means of running malicious code. In
recent years, additional techniques have been identified for
bypassing exploit mitigations such as DEP and ASLR under
certain conditions. From a risk management perspective, the
ability for an attacker to employ certain exploitation techniques

can be another factor that influences the likelihood that an

exploit will be developed for a vulnerability.
Of the exploit data that was analyzed, approximately 28% of the
CVEs had an exploit for which the exploitation techniques were
readily identifiable. The different exploitation techniques that
were used by these exploits is shown in the following figure.

Vulnerability Exploitation Trends 10

8
7
6

CVEs

5
4
3
2
1
0
2006

2007

2008

2009

2010

2011

2012

Bypass ASLR (info disclosure)

Bypass ASLR (non-ASLR image)

Bypass DEP (.NET control)

Bypass DEP (ROP)

Heap Spray

Stack Return Address Overwrite

Stack SEH Overwrite

Figure 7. The number of CVEs that were exploited using specific exploitation techniques

As this data suggests, the increasing prevalence of DEP and ASLR

has forced attackers to identify techniques that can be used to
exploit vulnerabilities even when these features are enabled.
These techniques have led to an increasing number of exploits
that attempt to bypass ASLR by relying on images that have not
opted into ASLR or by leveraging a vulnerability to disclose
information about the layout of an applications address space.
Similarly, the use of return-oriented programming (ROP) has
become common in exploits that seek to bypass DEP. The
increasing use of ROP was a focal problem for the winning
solutions that were submitted to the Microsoft BlueHat Prize
competition in 2012some of which were integrated into the
Microsoft Enhanced Mitigation Experience Toolkit (EMET) 3.5
technical preview.
The data in the preceding figure also shows that attackers
leveraged .NET user controls between 2008 and 2010 as a
method of bypassing both DEP and ASLR in Internet Explorer, but
this technique was mitigated with the release of Internet Explorer
8 in 2009 and therefore is no longer useful to attackers who try to
exploit Internet Explorer 8 and more recent versions. The data on
which classes of vulnerabilities have been exploited showed a
clear downward trend in the number of stack corruption

11 Vulnerability Exploitation Trends

vulnerabilities that are being exploited. This trend is further

reflected by the decrease in the number of exploits that rely on
stack-based exploitation techniques such as return address and
SEH overwrites.
Would enabling certain mitigations have broken exploits
seen in the past?
Another way to view the techniques used by attackers is to
identify exploits that would no longer function correctly if a
mitigation were enabled. The chart in the following figure shows
the number of CVEs that had exploits that would have been
mitigated if DEP were enabled compared to the number of CVEs
that had exploits that bypassed DEP. With the exception of the
lull in 2007 and 2008, there appears to be a clear downward trend
in DEPs ability to retroactively break exploits. This trend is not
because DEP is no longer effective; rather, it is an indication that
attackers have been forced to adapt to environments in which
DEP is already enabledat increased cost and complexity. The
evidence is the increasing number of CVEs that had exploits that
bypassed DEP.

14
12

CVEs

10
8
6
4
2
0
2006

2007

2008
Mitigated by DEP

2009

2010

2011

2012

Bypassed DEP

Figure 8. The number of CVEs for which exploits were written that could have been mitigated by
enabling DEP as compared to the number of CVEs that had exploits that bypassed DEP

Vulnerability Exploitation Trends 12

Improvements in Windows 8
Windows 8 contains numerous security
improvements that are specifically
designed to increase the cost and
complexity of exploiting vulnerabilities.
This section highlights some of the
security improvements in Windows 8
by showing the impact they are
designed to have on current trends in
vulnerability exploitation.
Enhanced /GS
Stack corruption vulnerabilities are rarely exploited in Microsoft
products today, thanks in part to the /GS stack buffer overrun
protection and SafeSEH features of the Microsoft Visual C++
compiler. Despite this positive trend, there have still been cases
during the past seven years in which stack corruption
vulnerabilities were successfully exploited. In Visual C++ 2010,
the heuristics that /GS uses when deciding whether to enable
protection for a function were extended to cover a broader set of
cases. For example, the new heuristics now protect functions that
have a plain old data structure (POD) of a certain size or that have
a fixed-size local array of a non-pointer type. These enhanced
heuristics provide protection for past vulnerabilities that were not
previously protected by /GS. Because Windows 8 has been built
with these enhancements to /GS, it will be even more difficult for
attackers to develop an exploit for stack corruption vulnerabilities
that may exist in Windows 8.

Heap hardening
Heap corruption vulnerabilities are one of the most commonly
exploited vulnerability classes. In most cases, attackers attempt to
exploit these vulnerabilities by corrupting the state of application
data that is stored on an applications heap. For example, an
attacker might use a heap buffer overrun to corrupt the virtual
table of a C++ object that is later called through, which would
allow them to take control of program execution.

In Windows 8, new security features have been added to the

heap that were specifically designed to make it more difficult to
corrupt application data on the heap. Exploits that are written for
13 Vulnerability Exploitation Trends

heap corruption vulnerabilities often require precise control of

where objects are allocated on the heap with respect to one
another. By randomizing the order in which objects are allocated,
Windows 8 makes it more difficult for an attacker to reliably
position objects within the heap. In addition, Windows 8 also
inserts no-access guard pages between certain regions within the
heap. These pages help to ensure that an application will
terminate if an exploit causes a program to read or write to them.
Both of these features are enabled by default in Windows 8, so all
applications are able to benefit from them.

VTGuard (Virtual Table Guard)

Use after free vulnerabilities are currently the most exploited
vulnerability class in Internet Explorer. To exploit these
vulnerabilities, attackers generally rely on creating a fake instance
of a C++ object that has a fake virtual function table whose
content is controlled by the attacker. In this way, an attacker is
able to force an application to execute attacker-specified code
when a virtual method call is made.
To help mitigate this, Internet Explorer 10 takes advantage of a
compiler security feature known as VTGuard. This feature acts as
a probabilistic mitigation for vulnerabilities that can be used to
corrupt a C++ objects virtual table pointer. VTGuard works by
adding a secret value as an element of the virtual table for a
protected C++ class. The compiler also inserts logic prior to each
virtual method call for the protected class. At runtime, this logic
verifies that the virtual table for the current C++ object has the
expected secret value. If the secret cannot be confirmed, the
application is safely terminated.

Force ASLR

High Entropy ASLR

The most common exploitation technique that is currently used

to bypass ASLR involves taking advantage of a dynamic-link
library (DLL) that has not actually opted into ASLR. By coercing an
application into loading such a DLL, an attacker can cause known
executable code to be placed at a known fixed location in the
address space of an application. This placement can enable an
attacker to make use of other techniques to bypass DEP.

Heap spraying has consistently been one of the most popular

techniques used by exploits over the past seven years. Exploit
writers generally use heap spraying to place attacker-controlled
code or data at a desired location in memory. This placement is
typically accomplished by coercing an application into allocating
large quantities of data and thereby filling a large portion of the
address space.

To prevent attackers from using this technique, Windows 8

introduced support for a feature known as Force ASLR. When
Force ASLR is enabled for an application, all relocatable DLLs will
be mapped at a randomly selected base address regardless of
whether or not they have opted into ASLR. Because Internet
Explorer and Office were often targeted by exploits that relied on
non-ASLR DLLs, Internet Explorer 10 and Office 2013 have both
enabled Force ASLR as well.

In Windows 8, 64-bit applications that enable support for High

Entropy ASLR are generically protected against traditional heapspraying techniques because High Entropy ASLR uses 24 bits of
entropy when selecting the base address for heap regions.
Approximately 1 terabyte of variance is available for allocation of
heap regions, which means that an attacker would need to
allocate more memory than a commodity PC typically has to
reliably control the content of memory at a known address. Like
the Force ASLR feature, the 64-bit versions of Internet Explorer 10
and Office 2013 have both enabled High Entropy ASLR.

For versions of Windows prior to Windows 8, the Microsoft

Enhanced Mitigation Experience Toolkit (EMET) can be used to
enable Force ASLR.

Vulnerability Exploitation Trends 14

Comparing Windows XP to Windows 8

The threat landscape has changed dramatically since Windows XP was first released 12 years ago. In the years that followed Windows
XPs initial release, multiple internet worms were created that exploited vulnerabilities in remote services provided by Windows (Code
Red, Blaster, Sasser). Microsoft responded to these attacks by releasing Windows XP Service Pack 2 in August 2004 which enabled the
Windows firewall by default and also introduced support for Data Execution Prevention (DEP). These platform security features played a
key role in helping to address the major threats at that time. Windows XP Service Pack 3 was released in April 2008. This is the final
Service Pack for Windows XP, and will not be supported after April 8th 2014. After that date there will be no more security updates
released for any version of Windows XP.
As of 2013, the predominate threats that individuals and organizations face are now much different. Rather than actively targeting
remote services, attackers primarily focus on exploiting vulnerabilities in client applications such as web browsers and document
readers. In addition, attackers have refined their tools and techniques over the past decade to make them more effective at exploiting
vulnerabilities. As a result, the security features that are built into Windows XP are no longer sufficient to defend against modern
threats.
To illustrate this point, the table below compares the mitigation features supported by Internet Explorer 8 on Windows XP Service Pack
3 with the features supported by Internet Explorer 10 on Windows 8. As this table shows, Internet Explorer 10 on Windows 8 benefits
from an extensive number of platform security improvements that simply are not available to Internet Explorer 8 on Windows XP.
Windows XP SP3
Internet Explorer 8

Windows 8
Internet Explorer 10

No

Yes

No

Yes

No

Yes

No

Yes

Limited

Extensive

Stack randomization

No

Yes

Heap randomization

No

Yes

Image randomization

No

Yes

Force image randomization

No

Yes

Bottom-up randomization

No

Yes

Top-down randomization

No

Yes

High entropy randomization

No

Yes

PEB/TEB randomization

Yes

Yes

Limited

Extensive

Header encoding

No

Yes

Terminate on corruption

No

Yes

Guard pages

No

Yes

Allocation randomization

No

Yes

Safe unlinking

Yes

Yes

Header checksums

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

SEHOP
Protected Mode
Enhanced Protected Mode (EPM)
Virtual Table Guard
ASLR

Heap hardening

/GS
Enhanced /GS
SafeSEH

15 Vulnerability Exploitation Trends

Malware infection rates on different operating system versions

The security features that are available with different versions of the Windows operating system and the differences in the way people
and organizations use each version affect the malicious software infection rates for the different versions and service packs. The
Microsoft Security Intelligence Report (SIR) shows the normalized malicious software infection rates for several different versions of
Windows. This infection rate data is gathered from the Malicious Software Removal Tool (MSRT) which executes on more than 600
million Windows systems around the world each month. The data gathered is normalized to allow comparison between the various
different operating system versions and service packs, and displayed as a metric called CCM (Computers Cleaned per Mille) which
represents the number of computers cleaned for every 1,000 executions of the MSRT. The data in the latest version of the SIR shows a
dramatic difference in malicious software infection rates between Windows XP Service Pack 3 and later versions of Windows, especially
Windows 8.
12.0

11.3

10.0

8.0

6.0
4.6

4.8
3.7

3.5

4.0

4.5

4
3.3
2.5

2.0

Too
little
data

0.0
32-bit

64-bit

Too
little
data

0.8
0.2
32-bit

64-bit

32-bit

64-bit

32-bit

64-bit

Windows XP SP3 Windows Vista Windows 7 RTM Windows 7 SP1

SP2

32-bit

64-bit

Windows 8 RTM

32-bit

64-bit

Too
little
data
32-bit

64-bit

Windows Server Windows Server

2003 SP2
2008 R2 SP1

Figure 9. Infection rate (CCM) by operating system and service pack in the fourth quarter of 2012

Vulnerability Exploitation Trends 16

Recommendations
The likelihood that a vulnerability will
be successfully exploited depends on
many factors, including the type of
vulnerability being exploited, the
product versions being targeted, an
attackers ability to make use of the
necessary exploitation techniques, and
the amount of time required to build a
reliable exploit. The following
recommendations show how these
factors can be influenced to help
reduce the likelihood of exploitation
and thereby minimize risk.

17 Vulnerability Exploitation Trends

Stay current on security updates

Most vulnerabilities only showed signs of being exploited after a
security update had been made available. Installing security
updates as soon as they are available can help minimize risk.

Use the newest application versions

Windows 8, Internet Explorer 10, and Office 2013 all take
advantage of improved security features that more effectively
mitigate techniques that are currently being used to exploit
vulnerabilities.

Use the Enhanced Mitigation

Experience Toolkit (EMET)
EMET can be used to protect applications that run on all
supported versions of Windows. The features included in EMET
are specifically designed to break exploitation techniques that are
currently used by attackers.

References
Microsoft Exploitability Index
http://technet.microsoft.com/en-us/security/cc998259.aspx
Mitigating Software Vulnerabilities
http://www.microsoft.com/en-us/download/details.aspx?id=26788
The Enhanced Mitigation Experience Toolkit
http://www.microsoft.com/emet

Vulnerability Exploitation Trends 18

Appendix: Data Sources and Glossary

Data sources
This survey used the following data sources:

Publicly available, commercially available, and privately

reported exploits, including proofs of concept, exploit
descriptions, and complete exploit modules.

Antimalware telemetry for exploits observed in the wild.

The data sources surveyed did not universally provide

information about targeted product versions or techniques used
by exploits. As such, this portion of the analysis is limited to
exploits in which this information was readily available.
The antimalware telemetry data that was used in this survey is
signature-based and therefore does not constitute proof that a
given vulnerability was actually being exploited. Despite this fact,
the inclusion of this data provides a more accurate upper bound
on which vulnerabilities were actually exploited.

Glossary
ASLR. An acronym for address space layout randomization, a
platform security feature that randomizes the location of code
and data in the address space of a process. The first version of
Microsoft Windows to support ASLR was Windows Vista in 2007.
DEP. An acronym for Data Execution Prevention, a platform
security feature that prevents data from being executed as code.

Stack corruption vulnerabilities. Exploitable vulnerabilities that

allow the general purpose data structure known as the stack to
be corrupted. The stack is that portion of computer memory that
is used for storing local variables, function parameters, and other
saved register values.

Exploit. Malicious code that attempts to take advantage of a

vulnerability in computer applications or operating systems.

Uninitialized memory use vulnerabilities. Exploitable

vulnerabilities that occur when a program accesses memory that
has not been properly initialized. If exploited, these vulnerabilities
could allow remote code execution (RCE).

Exploitability Index. An index of information created by

Microsoft that provides information about the potential
exploitability of software vulnerabilities that have been rated as
Important or Critical. Microsoft publishes this information for
customers who wish to use it for risk analysis purposes.

Use after free vulnerabilities. Exploitable vulnerabilities that

occur when an object is accessed after it has been freed.
Attackers might use such vulnerabilities to cause programs to use
their own values, crash programs, or achieve remote code
execution (RCE).

RCE exploit. RCE is an acronym for remote code execution. An

RCE exploit is one that enables an attacker to execute arbitrary
code of their choosing remotely, without having physical access
to the targeted computer.

Vulnerability. A weakness in a product that could allow an

attacker to compromise the integrity, availability, or
confidentiality of that product.

19 Vulnerability Exploitation Trends