Traps Evaluation and Protection Flow

Traps utilizes advanced multi-method protection and prevention techniques to protect your endpoints from both known and unknown malware and software exploits.

Exploit Protection for Protected Processes

In a typical attack scenario, an attacker attempts to gain control of a system by first corrupting or bypassing memory allocation or handlers. Using memory-corruption techniques, such as buffer overflows and heap corruption, a hacker can trigger a bug in software or exploit a vulnerability in a process. The attacker must then manipulate a program to run code provided or specified by the attacker while evading detection. If the attacker gains access to the operating system, the attacker can then upload malware, such as Trojan horses (programs that contain malicious executable files), or can otherwise use the system to their advantage. Traps prevents such exploit attempts by employing roadblocks—or traps—at each stage of an exploitation attempt.
traps-exploit-evaluation-protection-flow.png
When a user opens a non-executable file, such as a PDF or Word document, and the process that opened the file is protected, the Traps agent seamlessly injects code into the software. This occurs at the earliest possible stage before any files belonging to the process are loaded into memory. The Traps agent then activates one or more protection modules inside the protected process. Each protection module targets a specific exploitation technique and is designed to prevent attacks on program vulnerabilities based on memory corruption or logic flaws.
In addition to automatically protecting processes from such attacks, Traps reports any security events to Traps management service and performs additional actions as defined in the endpoint security policy. Common actions that Traps performs include collecting forensic data and notifying the user about the event.
The default endpoint security policy protects the most vulnerable and most commonly used applications but you can also add other third-party and proprietary applications to the list of protected processes.

Malware Protection

Traps provides malware protection in a series of four evaluation phases:
traps-malware-evaluation-protection-flow.png

Phase 1: Evaluation of Child Process Protection Policy

When a user attempts to run an executable, the operating system attempts to run the executable as a process. If the process tries to launch any child processes, Traps first evaluates the child process protection policy. If the parent process is a known targeted process that attempts to launch a restricted child process, Traps blocks the child processes from running and reports the security event to Traps management service. For example, if a user tries to open a Microsoft Word document (using the winword.exe process) and that document has a macro that tries to run a blocked child process (such as WScript), Traps blocks the child process and reports the event to Traps management service. If the parent process does not try to launch any child processes or tries to launch a child process that is not restricted, Traps next moves to Phase 2: Evaluation of the Restriction Policy.

Phase 2: Evaluation of the Restriction Policy

When a user or machine attempts to open an executable file, Traps first evaluates the child process protection policy as described in Phase 1: Evaluation of Child Process Protection Policy. Traps next verifies that the executable file does not violate any restriction rules. For example, you might have a restriction rule that blocks executable files launched from network locations. If a restriction rule applies to an executable file, Traps blocks the file from executing and reports the security event to Traps management service and, depending on the configuration of each restriction rule, Traps can also notify the user about the prevention event.
If no restriction rules apply to an executable file, Traps next moves to Phase 3: Evaluation of Hash Verdicts.

Phase 3: Hash Verdict Determination

Traps calculates a unique hash using the SHA-256 algorithm for every file that attempts to run on the endpoint. Depending on the features that you enable, Traps performs additional analysis to determine whether an unknown file is malicious or benign. Traps can also submit unknown files to Traps management service for in-depth analysis by WildFire.
To determine a verdict for a file, Traps evaluates the file in the following order:
  1. Hash exception—A hash exception enables you to override the verdict for a specific file without affecting the settings in your Malware Security profile. The hash exception policy is evaluated first and takes precedence over all other methods to determine the hash verdict.
    For example, you may want to configure a hash exception for any of the following situations:
    • You want to block a file that has a benign verdict.
    • You want to allow a file that has a malware verdict to run. In general, we recommend that you only override the verdict for malware after you use available threat intelligence resources—such as WildFire and AutoFocus—to determine that the file is not malicious.
    • You want to specify a verdict for a file that has not yet received an official WildFire verdict.
    After you configure a hash exception, Traps management service distributes it at the next heartbeat communication with any endpoints that have previously opened the file.
    When a file launches on the endpoint, Traps first evaluates any relevant hash exception for the file. The hash exception specifies whether to treat the file as malware. If the file is assigned a benign verdict, Traps permits it to open.
    If a hash exception is not configured for the file, Traps next evaluates the verdict to determine the likelihood of malware. Traps uses a multi-step evaluation process in the following order to determine the verdict: Highly trusted signers, WildFire verdict, and then Local analysis.
  2. Highly trusted signers (Windows and Mac)—Traps distinguishes highly trusted signers such as Microsoft from other known signers. To keep parity with the signers defined in WildFire, Palo Alto Networks regularly reviews the list of highly trusted and known signers and delivers any changes with content updates. The list of highly trusted signers also includes signers that you whitelist from Traps management service. When an unknown file attempts to run, Traps applies the following evaluation criteria: Files signed by highly trusted signers are permitted to run regardless of the WildFire verdict. When a file is not signed by a highly trusted signer, Traps next evaluates the WildFire verdict. For Windows endpoints, evaluation of other known signers takes place if WildFire evaluation returns an unknown verdict for the file.
  3. WildFire verdict—If a file is not signed by a highly trusted signer on Windows and Mac endpoints, the Traps agent performs a hash verdict lookup to determine if a verdict already exists in its local cache.
    If the executable file has a malware verdict, Traps reports the security event to the Traps management service and, depending on the configured behavior for malicious files, Traps then does one of the following:
    • Blocks the malicious executable file
    • Blocks and quarantines the malicious executable file
    • Notifies the user about the file but still allows the file to execute
    • Logs the issue without notifying the user and allows the file to execute.
    If the verdict is benign, Traps moves on to the next stage of evaluation (see Phase 4: Evaluation of Malware Protection Policy).
    If the hash does not exist in the local cache or has an unknown verdict, Traps next evaluates whether the file is signed by a known signer.
  4. Local analysis—When an unknown executable, DLL, or macro attempts to run on a Windows or Mac endpoint, Traps uses local analysis to determine if it is likely to be malware. On Windows endpoints, if the file is signed by a known signer, Traps permits the file to run and does not perform additional analysis. For files on Mac endpoints and files that are not signed by a known signer on Windows endpoints, Traps performs local analysis to determine whether the file is malware. Local analysis uses a statistical model that was developed with machine learning on WildFire threat intelligence. The model enables Traps to examine hundreds of characteristics for a file and issue a local verdict (benign or malicious) while the endpoint is offline or Traps management service is unreachable. Traps can rely on the local analysis verdict until it receives an official WildFire verdict or hash exception.
    Local analysis is enabled by default in a Malware Security profile. Because local analysis always returns a verdict for an unknown file, if you enable Traps to Block files with unknown verdict, Traps only blocks unknown files if a local analysis error occurs or local analysis is disabled. To change the default settings (not recommended), see Add a New Malware Security Profile.

Phase 4: Evaluation of Malware Security Policy

If the prior evaluation phases do not identify a file as malware, Traps observes the behavior of the file and applies additional malware protection rules. If a file exhibits malicious behavior, such as encryption-based activity common with ransomware, Traps blocks the file and reports the security event to the Traps management service.
If no malicious behavior is detected, Traps permits the file (process) to continue running but continues to monitor the behavior for the lifetime of the process.

Related Documentation