Malware Protection Flow
To protect the endpoint from malicious and unknown executable files, the malware prevention engine employs four methods of protection:
- Phase 1: Evaluation of Child Process Protection Policy
- Phase 2: Evaluation of the Restriction Policy
- Phase 3: Evaluation of Hash Verdicts
- Phase 4: Evaluation of Malware Protection Policy
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 the Endpoint Security Manager. 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 the Endpoint Security Manager. 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 the Endpoint Security Manager 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 evaluates the verdict for the file (see Phase 3: Evaluation of Hash Verdicts).
Phase 3: Evaluation of Hash Verdicts
When WildFire is enabled (see Set Up the ESM to Communicate with WildFire), Traps calculates a unique hash using the SHA-256 algorithm for every executable file, DLL, and macro that attempts to run on the endpoint. Depending on the WildFire features that you enable, the Traps WildFire module performs additional analysis to determine whether an unknown file is malicious or benign. Traps can also submit unknown files to the ESM Server for in-depth analysis by WildFire. The following figure illustrates the evaluation flow.
To determine a verdict for a file, Traps evaluates the file in the following order:
- Administrative hash control policy—The administrative hash control policy (also referred to as a verdict override or simply hash control policy), enables you to override the verdict for a specific file without affecting your WildFire integration settings. The hash control policy is evaluated first and takes precedence over all other methods to determine the hash verdict.From the ESM Console, you can configure a verdict override for any of the following situations:
After you configure a hash control policy, the ESM Server 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 control policy for the file. The hash control policy specifies whether to treat the file as malware. If the file is assigned a benign verdict, Traps permits it to open.
- You want to block a file that has a benign verdict.
- You want to allow a file that has a malware verdict. 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
- Trusted signers—Legitimate software is often signed by a trusted signer to signify that the software has not been altered or tampered with. Palo Alto Networks regularly reviews and makes changes to the list of trusted signers and makes the list available with the default security policy. The list of trusted signers in the default policy is currently aligned with the WildFire list of trusted signers. Any updates to the list of trusted signers are made available with Content Updates.When a user attempts to open an unknown file for which a hash control policy does not exist, the WildFire module begins the verdict evaluation process by verifying whether a file is signed by a trusted signer as defined in the default or user-defined malware security policy (see Manage Trusted Signers). The list of trusted signers in the default policy is currently aligned with the WildFire list of trusted signers.On Mac endpoints, if a file is signed by a trusted signer, Traps permits it to run regardless of the WildFire verdict. On Windows endpoints, Traps distinguishes highly trusted signers such as Microsoft from other known signers and 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 on Windows endpoints, or a known trusted signer on Mac endpoints, Traps next evaluates the WildFire verdict.
- WildFire verdict—If a file is not signed by a highly trusted signer on Windows endpoints or a known trusted signer on 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 Endpoint Security Manager and, depending on the configured behavior for malicious files, Traps then does one of the following:
If the verdict for a hash indicates that the associated file is benign, Traps moves on to the next stage of evaluation (see Phase 4: Evaluation of Malware Protection Policy).On Windows endpoints, 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. On Mac endpoints, Traps next performs Local analysis.
- Blocks 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.
- (Windows only) Known Signers—Files signed by known (but not highly trusted) signers require WildFire evaluation of the file before Traps permits the file to run. This prevents Traps from allowing a file to run when its signature is revoked and the WildFire verdict is malware.
- 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. The local analysis module uses a statistical model that was developed using 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 the ESM Server is unreachable. Traps can rely on the local analysis verdict until it receives an official WildFire verdict or updated hash control policy.Local analysis is enabled by default in the WildFire policy. Because local analysis always returns a verdict for an unknown file, enabling the Unknown Verdict Configuration to Block unknowns only applies to agents for which local analysis is not enabled or for agents running versions earlier than Traps 3.4. To change the default settings, clone the default WildFire rule and disable Local Analysis (not recommended). For more information, see Configure a WildFire Rule.
Phase 4: Evaluation of Malware Protection Policy
If neither the hash control policy nor the WildFire module identify 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 Endpoint Security Manager.
If no malicious behavior is detected, Traps permits the file to run.
Malware Protection Overview
Malware Protection Overview Malicious files, known as malware, are often disguised as or embedded in non-malicious files. These files can attempt to gain control, gather ...
Malware Protection Malware Protection Policy Best Practices Malware Protection Flow Manage Malware Protection Rules Manage Restriction Rules WildFire Integration Manage Hashes for Files Manage Trusted ...
Configure a WildFire Rule
Configure a WildFire Rule WildFire rules determine how Traps detects and responds to malware on your endpoints. You can create or edit WildFire rules on ...
Features Introduced in Traps Endpoint Security Manager
Features Introduced in Traps Endpoint Security Manager The following topics describe the new features introduced in Traps Endpoint Security Manager (ESM) and Traps 4.2. For ...
Manage Trusted Signers
Manage Trusted Signers Palo Alto Networks regularly reviews and makes changes to the list of trusted signers and makes the list available with the default ...
Traps Endpoint Security Manager Known Issues
Known issues with the Traps Endpoint Security Manager and Traps agent 4.2. ...
Verdicts WildFire delivers verdicts to identify samples it analyzes as safe, malicious, or unwanted (grayware is considered obtrusive but not malicious): Unknown —Initial verdict for ...
Monitor - Agent
Monitor - Agent The following table displays the agent logs you can forward to an external logging platform or email. Event Name Description Agent Access ...