Help Center
When Network Control is configured with a deny-all policy and traffic is allowed using Keywords or ThreatLocker Objects, a brief timing condition can occur during system startup or when the ThreatLocker service restarts. During this window, the endpoint may initiate network connections before the ThreatLocker service is fully initialized. As a result, connections from known and trusted IP addresses may initially be denied, followed by a permitted action once the service is fully operational.
A perfect example of this is permitting traffic to a print server from known and trusted IPs (ThreatLocker Objects). During startup, attempts to send data to the print server may be blocked until the ThreatLocker service is fully initialized. This will result in network denies in the Unified Audit followed about a minute later by a permit from the same source.
This can be identified using the Unified Audit.
Search for Action: Any Deny, Action Type: Network.
Select a deny log that should have been permitted.
In the sidebar, in the Network section under details, the source IP will be a hyperlink. Select it to open a list of devices in ThreatLocker that have been associated with that IP address.
If the list is empty, the IP address has never been associated with a device in ThreatLocker.
If the list returns devices that should have been permitted, select the device name to open the device sidebar.
Find the time of the deny and look to see if the device was checking in to the ThreatLocker portal at the time. Above, you can see that there was a period of time this device was not checking in, and this time coincides with the unexpected deny.
The Unified Audit shows that a deny occurred at 7:39:43 AM and then was permitted at 7:39:51 AM. Collaborating the information from the check in history shows that the device checked in at 7:39:49 AM, and the deny occurred slightly before the computer had checked into the portal.