1. Extending Zero Trust To The Endpoint
Kevin Harvey & Jon Bosche
Cyber Security Specialist Team
Palo Alto Networks

2. Agenda
Harsh Reality – We are at more risk than ever Why we are still getting infected Zero Trust Model – Network Security Extending the Zero Trust model to the endpoint Recent APT Campaigns Summary

3. We All Know The Risks J.P Morgan ~80M Records Target 40M CC
$200M Cost
SONY
40M CC
70M Records
$100M Cost
In an interview in 2007 Sony’s Director of information security Jason Spaltro said “it’s a valid business decision to accept the risk, I will not invest 10M to avoid a possible $1M loss”
This is why we’re here, having this webinar- we should all be well aware of the risks involved when it comes to information security.
Carbanak
~1B in stolen funds

4. Harsh Reality -We Are More at Risk than Ever$
Attackers are well funded and more sophisticated
91%
Increase in targeted attacks in 2013 $
Launching Zero-Day attacks is more accessible and common
Of exploit kits utilize
vulnerabilities less than two years old
78%
Targeted attacks can only
be solved on the endpoint
71%
Of breaches involve
a targeted user device
Unfortunately there isn’t a week that goes by where we aren’t learning about some new data breach. Up until this point the industry hasn’t really kept pace with the increasing sophistication of cyber attacks. Not only are these attacks more targeted in nature, the toolkits that attackers use increasingly utilize a growing pool of software vulnerabilities. Some vulnerabilities are known only to the attacker, referred to as Zero-Day vulnerabilities. Others are known to the general public but have to yet to be patched by the software vendor, or patches have yet to be deployed by individuals such as yourself. A fact attackers are very much aware of.
The stats paint a very grim picture –
A 91% increase in targeted attacks in 2013 (Symantec: Internet Security Threat Report, 2014)
78% of the exploit kits use vulnerabilities that are less than 2 years old and have yet to be patched by the manufacturer or organization. (Verizon DBIR, 2013)
71% of breaches occur at the expense of a user device (NTT 2014 Global Threat Intelligence Report)
Until today these devices were simply ill-equipped to defend against these targeted attacks. Before we get into what’s changed let’s take a quick look at what happening in the wild.
Additional background notes:
Exploit kits ramp up their capabilities to leverage recent vulnerabilities: Research indicates exploit kit developers are pruning older exploits and favoring new ones, as 78% of current exploit kits are taking advantage of vulnerabilities less than 2 years old. While organizations are getting around to removing updating or patching older systems attackers are addressing the eventual change in the environment, knowing a history of poor maintenance practices are likely to repeat (Verizon DBIR, 2013)
Organizations are at risk to vulnerabilities in the wild: Data collected in 2013 demonstrates organizations are not protected against common vulnerabilities which are included in widely distributed hacking exploit kits to pose a significant threat to their organizational security. NTT identified top 10 vulnerabilities identified in customer environments which are also present in exploit kits. (NTT 2014 Global Threat Intelligence Report)

5. Understanding the Threat Exploit vs. Malware – What’s the difference?
All pieces of software contain bugs
Some bugs may be security vulnerabilities
Some security vulnerabilities can be exploited to achieve (remote) code execution (RCE)
Exploit
Malware
Malformed data file that is processed by a legit app
Malicious code that comes in an executable file form
Aims to achieve code execution abilities
Already executes code - Aims to control the machine
Small payload
Large payload

6. A Typical Cyber Security Attack Life Cycle
“(…) threat is orchestration of the overall attack, not necessarily the sophistication of the individual components…”
Jayce Nichols, Manager of Cybercrime Analysis Team iSight
Silent Infection
Leverage Exploit
Malicious File Delivered
Deliver Malware
Malware Communicates with Attacker
Control Channel
Data Theft, Sabotage, Destruction
Steal Data
Gather Intelligence
so if we look closer at an attack lifecycle we’ll see how these two methods play out in an attack, and understand the role of an exploit.
-Explain cycle -
Plan the Attack

7. Why Do We Still Get Infected?
Today's Harsh Reality
225
Average Days to Detect a Targeted Attack
Requires prior knowledge
Scanning vs. activity-focused
Can be reverse engineered
Traditional Detection
Detection and Remediation
Malicious activity can disable detection
Remediation takes a great effort
Too much noise – detection is ignored
84%
Attacks Discovered via Third Party
Can’t see all content
No visibility to endpoint infections
Hard to block malicious activity on legit protocols
Network-Layer Security
There’s no doubt that Zero Trust model as it’s coined today for Network Security has and will continue to have a huge impact on organizations security posture and reduce the risk tremendously. BUT we must not tell ourselves that it will fully protect you from attackers getting into your environment.
So why is what we have not enough?
traditional network security like stateful-based firewalls.
you have traditional tools from companies like Symantec, McAfee and Trend Micro.
companies like Mandiant fit this mold.
FireEye, and our own WildFire.
If you pull this forward you want to make sure it’s clear that while highly effective for most threats, our NGFW + WildFire can’t protect against 100% of the attacks. There remain a number of vectors that can only be protected by endpoints. Including instances where the endpoint may be operating out of protective environment of the organization and therefore suspect to the dangers of an insecure network environment.
Can’t simulate all environments
Threat emulation can be identified by the malware
Can’t enforce actions on the endpoint
Cloud-Based Emulation
Detection Alone is Not a Strategy

8. The Patch Race
All applications have vulnerabilities so it’s just a question of whether they are known, have a patch from the software developer, and if there is a patch – whether the organization updated the software.
Zero Day Vulnerability – not known in the wild
End-of-Life; Windows XP, Windows Server 2003
The inevitable delays in deploying patches and the ubiquity of unknown vulnerabilities make patching a losing battle.

9. It’s time for a new approach
Demand Zero Trust on the Endpoint

10. Zero Trust Model – Network Security
All resources are accessed in a secure manner regardless of location.
Trust
Access control on a “need-to-know” basis should be strictly enforced.
Inspect and log all traffic
“Never Trust
Always Verify”
With the changes in the threat landscape, Forester research sought to change the paradigm by which many organizations think about defending the enterprise information infrastructure.
They came up with the “Zero Trust Model” - With Zero Trust there is no default trust for any entity—including network segments, users, devices, and applications. In addition, verifying that authorized entities are always doing only what they are allowed to do is a requirement.
Concept #1:
Ensure all resources are accessed securely regardless of location.
This suggests not only the need for multiple trust boundaries, but also increased use of secure access for communication to/from resources, even when sessions are confined to the “internal” network. It also means ensuring that only devices with the right status and settings (e.g., ones that are compliant with security policy) are allowed access to the network.
Concept #2:
Adopt a least-privilege strategy and strictly enforce access control. The goal in this case is to absolutely minimize authorized access to resources in order to reduce the pathways available for malware and attackers to gain unauthorized access and subsequently spread laterally and/or exfiltrate sensitive data.
Concept #3: Inspect and log all traffic. This reiterates the need to “always verify” while also making it clear that adequate protection requires more than just strict enforcement of access control. Close and continuous attention must also be paid to exactly what is happening in “allowed” applications, and the only way to do this is to inspect the content for threats.

11. Extending Zero Trust to the Endpoint
Don’t trust known applications
-Exploit Prevention
-Child Process Blocking
-Block injection of malicious code
Trust
Don’t trust unknown executables
-Static Whitelisting
-Dynamic Analysis
“Never Trust
Always Verify”
with the reality of exploited software vulnerabilities being a way to gain a foothold into the organization- it looks as though trusting and whitelisting ‘good’ or signed applications would be harmful. so it seems odd that we wouldn’t extend the same never trust always verify motto to the endpoint.
What would a zero trust model look like on the endpoint?
Do not trust unknown applications: Executables that have never been seen on the endpoint before should not be trusted. This concept can be applied in two ways:
Static Whitelisting: The administrator can establish a static list of approved applications or digital signers that are allowed to run on the endpoint.
Dynamic Analysis: The endpoint agent integrates with a dynamic analysis engine that analyzes new executables to determine if they are malicious or not. By leveraging the dynamic analysis capabilities of Wildfire, we gain the advantages of the massive scale of this cloud based threat intelligence service.
Do not trust known applications: Trusted applications have vulnerabilities that can be exploited by attackers. In order to have zero trust on the endpoint, exploitation of trusted applications must be prevented for both known and unknown vulnerabilities. This involves multiple methods including:
Exploit Prevention: Exploit prevention that can be applied to any application including proprietary, legacy, or industry specific applications.
Child Process Blocking: Some applications should not be allowed to create child processes.
Do not trust external media
Prevent execution from removable media
Don’t trust unknown locations
-Removable Media
-Invalid folder locations

12. Whitelisting alone is not enough
Trusted applications can be exploited
Malware can run in memory without creating a new .exe
Signing certificates can be compromised
Whitelisting can be difficult to manage in dynamic environments
Source: Malware Don’t Need Coffee
Many new products have been developed in attempts to combat the increasingly sophisticated and targeted threats facing organizations today. One approach taken by some products is application whitelisting.
Instead of defining applications that shouldn’t run and scanning for malicious files, this approach will only allow specified “trusted applications” to run, preventing any other file from executing, thus achieving maximum protection for the endpoint. While this basic functionality can be useful to reduce the attack surface, it is by no means a comprehensive approach to endpoint security.
Source: The Register
COMP

13. Don’t trust known applications Exploit Prevention
Exploit Technique 2
Exploit Attack
1. Exploit attempt contained in a PDF sent by “known” entity.
Begin
Malicious Activitiy
2. PDF is opened and exploit techniques are set in motion to exploit vulnerability in Acrobat Reader.
3. Exploit evades AV and drops a malware payload onto the target.
Exploit Technique 1
Exploit Technique 3
4. Malware evades AV, runs in memory.
Normal Application Execution
Activate key logger
Steal critical data
More…
To gain a better understanding of these exploit techniques and how they are used by attackers, let’s walk through an example:
The graphic here represents an application – Adobe acrobat reader, for example. As with most applications, this application has a certain number of vulnerabilities. Some may be known, in which case patches might be available. Other vulnerabilities have yet to be discovered.
The application normally runs its normal functions (for example, display a document, print, etc.).
The attacker’s goal is to cause the application to do something it is not meant to do (ie, run a piece of code supplied by the attacker). In order to make that happen, the attacker needs to use a series of exploit techniques, in a particular order. If those techniques succeed, the attacker can exploit a vulnerability in the application.
So the user in this example opens the PDF document, the document displays as it normally would, but in the background these techniques are set in motion.
Click forward, showing the 3 exploit techniques…
If all three of these techniques succeed (and they often do because anti-virus is not good at detecting them), the acrobat reader software is exploited and malware can be executed.
Click forward to “Begin Malicious Activity”
Gaps Are Vulnerabilities

14. Don’t trust known applications Exploit Prevention
Exploit Attack
1. Exploit attempt contained in a PDF sent by “known” entity.
2. PDF is opened and exploit techniques are set in motion to exploit vulnerability in Acrobat Reader.
3. Exploit evades AV and drops a malware payload onto the target.
Exploit Technique
Blocked
4. Malware evades AV, runs in memory.
Normal Application Execution
Traps Exploit Prevention Modules (EPM)
1. Exploit attempt blocked. Traps requires no prior knowledge of the vulnerability.
Traps EPM
Now let’s look at the same scenario again, this time with our Traps Exploit Prevention Modules in place.
Our Traps Advanced Endpoint Protection agent runs on the endpoint and injects these exploit prevention modules into each application that runs. This process is seamless and transparent to the end-user.
Note that the exploit prevention modules require no knowledge of where the vulnerabilities are in the application. So you are protected from exploitation of both known and unknown vulnerabilities.
Click forward: Exploit Technique Blocked.
As you can see, as soon as the exploit technique is attempted, it is blocked by Traps. At this point Traps would terminate the application and send a notification to the end-user and the administrator console with detailed information about the attempted attack.
No malicious code was allowed to execute so no harm has been done.
Now – You might be wondering: “What if the attacker invents a new exploit technique? Or What if the attacker is able to circumvent one of the exploit prevention modules?” Click forward…

15. Don’t trust known applications Exploit Prevention
Exploit Technique
Blocked
Exploit Attack
1. Exploit attempt contained in a PDF sent by “known” entity.
No Malicious Activity
2. PDF is opened and exploit techniques are set in motion to exploit vulnerability in Acrobat Reader.
3. Exploit evades AV and drops a malware payload onto the target.
Exploit Technique 1
4. Malware evades AV, runs in memory.
Normal Application Execution
Traps Exploit Prevention Modules (EPM)
Traps EPM
As mentioned previously, an attack will only be successful if a series of exploit techniques succeed – usually 3-5.
So let’s walk through the scenario where the first exploit prevention module is bypassed and Exploit technique #1 succeeds.
Click
Click again to the second exploit technique being blocked.
Due to the chain-like nature of exploit techniques, even if one succeeds, the next one will be blocked. This will break the chain and prevent successful exploitation of the vulnerable application. So despite the fact that one technique succeeded, the exploit still failed and no malicious activity occurred on the system..
Click – “No Malicious Activity” comes up and the file type starts changing from PDF to other types
Remember, we use adobe acrobat as an example here but this can be any application, including proprietary applications. The nature of the Traps exploit prevention modules is such that they do not require any prior knowledge of the application, how it works, or its vulnerabilities.
1. Exploit attempt blocked. Traps requires no prior knowledge of the vulnerability.
2. If you turn off EPM #1, the first technique will succeed but the next one will be blocked, still preventing malicious activity.

16. Exploit Prevention Case Study – Clandestine Fox1 2 3 4
Use After Free
Utilizing OS Function
Heap Spray
ROP
Preparation
Triggering
Circumvention
Post
Prevention of One Technique in the Chain will Block the Entire Attack
Algorithmic Memory Traps Placement
Logic-Flaws Real-Time Intervention
Memory Corruption Mitigation
OS Functions Shielding
Let’s drill down into how that works using a recent Zero-Day as an example – cve , also known as Clandestine Fox.
The actual process of exploiting a system via a vulnerability involves the use of multiple techniques working in concert.  In order for an attack to be successful the attacker must execute each of these exploit techniques in a path that has multiple stages that lead to the execution of the malicious activity. In this CVE you can see the exploit techniques used in each of the stages…
They can’t begin their malicious activity until they’ve concluded these steps. Some attacks may involve more steps, some may involve less. In all cases you can count on at least two or three techniques that must be used in order to exploit that endpoint. The reason why I’m providing this background is because it’s important to understand the process an attacker must take, the chain of events their exploit must follow, in order to achieve their objectives. If you understand this process it will be easy to understand the approach we’ve taken with Traps. At a basic level Traps employs a series prevention modules aimed at blocking the different exploit techniques available to attackers. These modules operate like “traps”, injected into the user processes, and designed to block the attackers exploit technique as soon as it’s used.
It’s critical that your approach be able to block all techniques. These techniques can be grouped into the following four buckets [Click]. In each case we’re able to block the attack without having any prior knowledge of the vulnerability. This didn’t require signatures or software updates to prevent. Even though an attack may have involved a Zero-Day that had never been seen before.

17. Do not trust unknown executables or locations
Static Whitelisting
Prevent Unknown Executables Whitelisting for static environments
Prevent Malicious Executables with cloud-based threat intelligence and dynamic analysis
Dynamic Whitelisting
Device and Location Restrictions
Static Whitelisting: The administrator can establish a static list of approved applications or digital signers that are allowed to run on the endpoint.
Dynamic Analysis: The endpoint agent integrates with a dynamic analysis engine that analyzes new executables to determine if they are malicious or not. By leveraging the dynamic analysis capabilities of Wildfire, we gain the advantages of the massive scale of this cloud based threat intelligence service.
Prevent Malicious Executables
Attempting to run from unauthorized devices or folder locations

18. Malicious Executable Prevention
File is Allowed to Execute
WildFire
User Tries to Open Executable File
Policy-Based
Restrictions Applied
HASH Checked Against WildFire
Malware Technique Prevention Employed
Examples
Indicated as Malicious?
Examples
Child Process?
Thread Injection?
Restricted Folder or Device?
Here’s how that looks in practice:
When a user goes to open an executable file we first take a look to see if there are any policy-based restrictions in place. Is the file coming from attached media, child processes, from a restricted folder or device? If any policies are triggered the file is not allowed to execute.
If there are no policies then we take a hash of the file and send it to WildFire for inspection, or compare against the local cache. If it’s known to be bad the file is once again blocked. If we’ve never seen the file before it continues to open. During that time our malware technique mitigation engine is waiting to block any malicious activity (thread injection, usage of OS components). If any malware techniques are employed that file is blocked.
The net result of all these steps is that malware can’t run. And it’s stopped before the malicious activity is allowed to proceed.
Safe!
Forensics Collected

19. Advanced Threats Attack Vectors
Spear Phishing - Individual Users
Watering Hole: Mass Users
CEO
Finance
Website
Attachment HR

20. Spear Phishing Case Study: Anunak Campaign
January 2013
Present
CVE
CVE
CVE
win32k.sys
Anunak campaign was targeting financial institutions and managed to access banking systems servers and working stations.

21. Spear Phishing Case Study: NetTraveler Campaign
June 2013
Present
CVE
CVE
NetTraveler campaign was targeting different sectors such as governmental institutions, embassies, the oil and gas industry, research centers, military contractors and activists.

22. Spear Phishing Case Study: ICeFog Campaign
September 2013
Present
CVE
CVE
JRE
CVE
JRE
IceFog campaign targeted the chain supply of major defense vendors, including government institutions, military contractors, maritime and ship-building groups, telecom operators, satellite operators, industrial and high technology companies and mass media.

23. Spear Phishing Case Study: Carbanak Campaign
December 2013
Present
CVE
CVE
CVE
Carbanak campaign hit more than 100 banks and financial organizations Causing losses estimated at $1b.

24. Traps Protection Against Carbanak Campaign Exploits
Heap Spray
DEP Circumvention
ROP JIT Spray
Utilize OS Functions
CVE
Memory Limit Heap Spray Check
UASLR
ROP Mitigation
DLL Security
CVE
ROP Mitigation
DLL Security
Memory Limit Heap Spray Check
CVE
UASLR
ROP Mitigation
DLL Security

25. Watering Hole Case Study: Department of Labor
May 2013
Present
A Zero day vulnerability in
Microsoft Internet Explorer 8.
CVE
The CVE was exploited in the wild
as part of some of most familiar
campaign (Dragonfly).
This vulnerability was later
incorporated in common exploit
kits like LightsOuts, Private EK
and Infinity.
Tibet.Net

26. Watering Hole Case Study: Central Tibetan administration website
August 2013
Present
A site providing information
about the parliament, cabinet,
administrative departments and
public offices 
CVE
The attacks used
Trojan.Win32.Swisyn.cyxf
CVE was exposed
as a zero day after being seen
exploited in-the-wild in 2012
and was detected and blocked by
TRAPS.
Tibet.Net

27. Watering Hole Case Study: LightsOut Exploit Kit
September 2013
Present
Firms in the energy sector
CVE
CVE
CVE
Compromise energy related law firm site.
CVE
Users visiting the site were redirected to a third party site hosting the exploit kit
39essex[.]com
The kit checks for Java, IE and Adobe reader.
Following the check various exploits are triggered.

28. Watering Hole Case Study: ‘Operation Snowman’
February 2014
Present
Targeted websites in France
and USA using Internet Explorer
Zero-Day
CVE
Main targeted site:
U.S. Veterans of Foreign
Wars website
The vulnerability allows the
Attacker to by pass DEP and
ASLR.
vfw.org

29. Traps Protection Against LightsOut Exploit Kit
Memory Corruption Vulnerabilities
Java Vulnerabilities
Java Sandbox Escape
Heap Spray
DEP Circumvention
ROP JIT Spray
Utilize OS Functions
ROP Mitigation
DLL Security
UASLR
Shellcode Preallocaiton
CVE
CVE
Memory Limit Heap Spray Check
CVE
Java
CVE
Java

30. Summary
Traditional security solutions are not equipped to deal with today’s threats
Whitelisting provides basic protection but is not sufficient to prevent advanced threats
Extending Zero Trust to the endpoint
Don’t trust even the known applications - prevent exploits
Don’t trust unknown executables
Don’t trust external media or unauthorized folder locations

31. Learn about Traps Advanced Endpoint Protection on our website