Malware Protection Flow
Table of Contents
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:
- 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
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.If a hash control policy is not configured for the file, Traps next employs the WildFire module to determine the verdict. The WildFire module uses a multi-step evaluation process in the following order to determine the verdict: Trusted signers, WildFire verdict, and then Local analysis. - 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:
- 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.
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. - (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.