ThreatSync+ NDR Level 1 Policies

Applies To: ThreatSync+ NDR

ThreatSync+ NDR includes over 100 default policies that you can enable. Because some default policies might not be appropriate for your network or your security policies, most default policies are disabled by default. Only a subset of Level 1 policies are enabled by default and automatically generate alerts.

We recommend you start with these Level 1 policies when you monitor your network for threats.

Each section in this topic includes:

  • A description of a Level 1 policy
  • How the policy works to detect threats
  • How you can tune the policy to work more effectively in your network

For specific Level 1 policy details, go to these sections:

AA21-356A — Detect Potential Log4Shell Attacks to New Organizations Through LDAP or RMI

As recommended in CISA Alert AA21-356A, this policy identifies LDAP and RMI activity to sites never communicated with previously.

How it Works

The Log4j vulnerability, also known as Log4Shell, is a critical remote code execution (RCE) vulnerability that affects some Apache Log4j 2 Java library versions. This vulnerability enables attackers to gain total control of affected systems, including the ability to:

  • Steal passwords and logins
  • Extract data
  • Infect networks with malicious software
  • Launch ransomware

The vulnerability is due to a flaw in how the Java Naming and Directory Interface (JNDI) resolves variables. Attackers can exploit the vulnerability by submitting a specially crafted request to a vulnerable system, which causes the system to execute arbitrary code.

This crafted request has a reverse shell connection to the attacker machine, and ThreatSync+ NDR monitors this reverse connection when traffic sent on LDAP or RMI ports goes to a public Internet domain that the source address has not communicated with in the past. This traffic must be outgoing. The policy definition includes all common LDAP and RMI ports (ports 389, 636, 1636, 1099, 1389, 3268, 3269).

How to Tune

This alert can be a false positive if you have an LDAP server or Active Directory Domain Server in the public cloud. If you do, you can exclude these public IP addresses from the policy by adding them to the Destination Zone exclusion list. For more information, go to Configure ThreatSync+ Policies.

AA21-356A — Detect Potential Log4Shell Attacks Through LDAP or RMI

As recommended in CISA Alert AA21-356A, this policy identifies LDAP and RMI activity to known malicious IP addresses.

How it Works

This policy generates an alert when traffic sent on LDAP or RMI ports (ports 389, 636, 1636, 1099, 1389, 3268, 3269) goes to any IP address on the ThreatSync+ NDR malicious IP address list. This list is a collection of threat feeds of public Internet addresses reported as malicious.

How to Tune

There policy does not require tuning.

AA21-356A — Detect Unusual Volume of DNS, LDAP, or RMI Activity Due to Potential Log4Shell Attacks

As recommended in CISA Alert AA21-356A, this policy identifies high volumes of LDAP and RMI activity.

How it Works

This policy generates an alert when an excessive volume of DNS, LDAP or RMI traffic (ports 53,389, 636, 1636, 1099, 1389, 3268, 3269) leaves the network. This could indicate of a Log4J attack.

How to Tune

This alert can be a false positive if you have an LDAP server or Active Directory Domain Server in the public cloud. If you do, you can exclude these public IP addresses from the policy. To do this, add them to the Destination Zone exclusion list. For more information, go to Configure ThreatSync+ Policies.

Active Directory to External

This policy generates alerts when Active Directory servers are communicating improperly with the outside world on ports other than 53, 80, 123, or 443.

Microsoft Active Directory Domain Controllers are critical resources and should not be used for general user activity. They should be restricted for use by known authorized activity only. Any activity that varies from that should generate an alert.

How it Works

This policy is set up to monitor outgoing activity on any port that is not commonly used for expected Microsoft Active Directory Domain Controller functions. It is designed to generate an alert when rogue applications might be installed, users are running unauthorized applications on the console, or an attacker has taken control.

How to Tune

False alerts can occur if there is authorized activity on the server that does not match the ThreatSync+ NDR list of ports. If you have a specific application that you want to allow, you can add it to the policy definition. If there is a port in the definition that you never expect to be used in your environment, you can remove it from the list.

Activity Between Development and Production

This policy generates alerts when unauthorized development systems communicate with production systems. This is a classic Separation of Duties control that makes sure that users working in a development environment do not also work simultaneously in the production environment.

How it Works

The policy requires that the built-in zones Production and Development be configured to reference the areas of your internal network that contain development devices and production devices.

To include devices in the Production Zone, tag each device with the label Production. With the Development Zone, use the device tag Development.

If you do not tag any devices, this policy will never trigger any violations. If the list of your production and development devices is static, you can manually set these tags or set them with a bulk import of device configurations.

How to Tune

If you separate development and production environments by separate subnets, we recommend that:

  • You configure those subnets as internal organizations in the Subnets and Organizations Configuration Settings
  • You tag the organizations with “Production” and “Development” tags
  • You modify the zone configurations to include all devices in organizations that have those tags

For more information, go to Configure Subnets and Organizations.

Activity From High-Risk Countries

This policy generates alerts for traffic from high-risk countries to internal devices.

How it Works

This policy generates alerts when ThreatSync+ NDR detects any traffic activity initiated from countries defined in the Prohibited Countries zone and sent to any internal device.

The Prohibited Countries zone contains an initial list of countries that are historically high-risk. This includes China, Russia, and other nations that some governments have labeled as terrorist-supporting countries. The countries that are high-risk for your environment might vary. To add and delete additional countries in the list of Prohibited Countries, edit the zone.

How to Tune

This zone is shared across multiple policies, so if your list of high-risk countries is different for incoming and outgoing traffic, you can create a separate zone for each one and define the prohibited countries list with the policy definitions.

For more information, go to Manage ThreatSync+ Zones.

Activity Involving IP Addresses in the Blocklist

This policy generates alerts for traffic to or from IP addresses in the blocklist.

How it Works

ThreatSync+ NDR maintains a blocklist of high-risk public IP addresses. This list is updated periodically. This policy continuously compares IP addresses from all traffic against the blocklist.

This policy generates alerts when ThreatSync+ NDR detects any traffic to or from IP addresses listed in the blocklist. This policy monitors all traffic from the internal network (the internal devices zone) to any public IP address (all external domains zone).

How to Tune

If there are parts of your network such as a guest network or public access that you do not want to monitor this type of activity for, you can exclude those internal subnets or organizations from the source zone.

Because the blocklist IP address feed is maintained by ThreatSync+ NDR, you cannot directly edit it or replace it, but you can define exceptions within the policy and define a list of your own high-risk IP addresses and then add the IP addresses to the destination zone.

You can also create a separate, similar policy for your own blocklist. For more information, go to Manage ThreatSync+ Zones.

Activity to High-Risk Countries

This policy generates alerts for traffic from internal devices to high-risk countries.

How it Works

This policy generates alerts when ThreatSync+ NDR detects any traffic activity initiated from your internal network to countries defined in the Prohibited Countries zone.

The Prohibited Countries zone contains an initial list of countries that are historically high risk. This includes China, Russia, and other nations that some governments have labeled as terrorist-supporting countries.

How to Tune

The countries that are high-risk for your environment might vary. To add or delete additional countries in the list of Prohibited Countries, edit the zone.

This zone is shared across multiple policies, so if your list of high-risk countries is different for incoming and outgoing traffic, you can create a separate zone for each one and define the Prohibited countries list with the policy definitions.

For more information, go to Manage ThreatSync+ Zones.

Activity to Social Media Sites

This policy generates alerts when anyone communicates with a prohibited social media site.

How it Works

This policy generates alerts when ThreatSync+ NDR detects traffic flowing from your internal network (the All Internal Devices zone) to any website domains defined in the Social Media Sites zone.

How to Tune

If your organization has no access restrictions for social media sites, we recommend that you deactivate this policy.

If the list of social media sites in the predefined zone Social Media Site does not match your list of restricted sites, edit the zone to match the list of unauthorized domains in your Social Media access policy. We also recommend that you block these sites at your firewall.

If there are parts of your network that are allowed to connect with these social media sites, you can exclude those subnets from the source zone to not generate alerts on activity from these subnets.

If you have different access policies for Social Media for different parts of your network, you might have to define multiple policies to fully configure the necessary combinations of subnets and destination domains.

Anomalous Activity from High-Risk Countries

This policy generates alerts when any anomalous events occur with communication from high-risk countries.

This policy is different from the Activity from High-Risk Countries policy. In addition to verifying that the traffic comes from these high-risk countries, this policy also requires that anomalous activity is detected in that traffic.

How it Works

ThreatSync+ NDR generates alerts anomalous events such as, but not limited to, unusual incoming connection duration and a high rate of incoming packets from high-risk countries defined in the Prohibited Countries zone.

How to Tune

You can add or delete additional countries in the Prohibited Countries zone. You can also add exceptions for specific false alerts. To do this, add traffic flow rules that include or exclude specific IP addresses, countries, localities, or domains.

This zone is shared across multiple policies, so if the list of high-risk countries is different for incoming and outgoing countries, you can create a separate zone for each one and define the high-risk countries list with the policy definition.

Anomalous Activity to High-Risk Countries

This policy generates alerts when any anomalous events occur in communication to high-risk countries.

This policy is different from the policy, Activity to High-Risk Countries. In addition to verifying that the traffic goes to these high-risk countries, this policy also requires that anomalous activity is detected in that traffic.

How it Works

ThreatSync+ NDR looks for anomalous events such as, but not limited to, unusual outgoing connection duration and a high rate of outgoing packets from high-risk countries defined in the Prohibited Countries zone. Alerts are generated when detected.

How to Tune

You can add or delete additional countries in the Prohibited Countries zone. You can also add exceptions for specific false alerts. To do this,add traffic flow rules that include or exclude specific IP addresses, countries, localities, or domains.

This zone is shared across multiple policies, so if the list of high-risk countries is different for incoming and outgoing countries, you can create a separate zone for each one and define the high-risk countries list with the policy definition.

Beaconing Through the Web API

This policy generates alerts when possible automated beaconing activity through a third-party web service occurs between an IP address in your network and a remote location. This could indicate unauthorized Command and Control activity.

How it Works

This policy generates alerts when ThreatSync+ NDR detects a beacon or payload in an executable or program that communicates back to the Command and Control server of the attacker through an HTTPS-enabled communication channel from an internal source.

How to Tune

If you do allow some remote locations to source ethical API connections to external sites, even this genuine behavior could lead to policy alerts. You can add exceptions for specific false alerts. To do this, add a traffic flow rule to include remote locations that are approved in your environment.

Communicate with Suspicious AA21-062A IP Addresses

This policy generates alerts for communication from a set of IP addresses that are well-known to be used by attackers for Log4J attacks. Although these are tied to virtual private servers (VPSs) and virtual private networks (VPNs), responders should investigate these IP addresses on their networks.

How it Works

This policy generates alerts when ThreatSync+ NDR detects an incoming connection to unpatched Microsoft exchange from Suspicious AA21-062A IP addresses to exploit RCE vulnerabilities CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065 that allows remote code execution.

How to Tune

This policy cannot be tuned because Suspicious AA21-062A IP addresses are certified malicious IP addresses.

Detect Large Volume to File Sharing Sites

This policy generates alerts when a large volume of data is uploaded to a file-sharing website.

How it Works

This policy generates alerts when more than 40K bytes is uploaded within a 30 minute period to a web file-sharing domain listed in the destination zone. It can indicate that unauthorized data is being exfiltrated to a public file-sharing site by unauthorized attackers or insider threats.

How to Tune

This policy provides data leak prevention and monitors exfiltration. You can add or delete additional file-sharing sites in the destination zone of the policy.

You can raise the threshold for data volume in the trigger configuration of the policy if you want to increase sensitivity.

Internal LLMNR Traffic

This policy generates alerts when Link-Local Multicast Name Resolution (LLMNR) traffic (on port 5355 UDP) passes between two internal endpoints. This is Unnecessary or Unexpected Port Activity that should be blocked to prevent ransomware attacks.

How it Works

This policy helps to identify LLMNR poisoning attacks, and generates alerts when ThreatSync+ NDR detects any internal traffic greater than 1 byte to UDP port 5355. Throughout LLMNR poisoning attacks, the traffic from the client to the attacker machine is expected to be greater than 1 byte.

LLMNR is the successor to NetBIOS. NetBIOS (Network Basic Input/Output System) is an older protocol that was used in early versions of Windows networking. NBT-NS is a component of NetBIOS over TCP/IP (NBT) and is responsible for name registration and resolution. Similar to LLMNR, NBT-NS is a fallback protocol when DNS resolution fails. It allows local name resolution within a LAN, so when you disable this feature in an Active Directory environment, it mitigates the alerts. However, if any application is authorized to use the LLMNR ports, you can exclude those authorized application servers from the destination zone.

How to Tune

If applications are authorized to use the LLMNR ports, you should exclude those authorized application servers from the destination zone.

Internal mDNS Traffic

This policy generates alerts when Multicast Domain Name service (mDNS) traffic (port 5353 UDP) is detected between two internal endpoints. This is Unnecessary or Unexpected Port Activity that should be blocked to prevent ransomware attacks.

How it Works

This policy helps to identify mDNS poisoning attacks, and it generates alerts when ThreatSync+ NDR detects any internal traffic greater than 1 byte to UDP port 5353. Throughout mDNS poisoning attacks, the traffic from the client to the attacker machine is expected to be greater than 1 byte.

How to Tune

There are no recommended tuning actions for this policy.

Internal WUDO Traffic

This policy detects Windows Update Delivery Optimization (WUDO) traffic between devices within your network. WUDO is the protocol used by Microsoft to update the Windows operating system from peer computers.

How it Works

Microsoft Windows uses the WUDO protocol to distribute the OS update process to peer Windows devices, which enables updates to be distributed through an uncontrolled peer-to-peer network.

If you control operating system updates through an enterprise distribution tool, then WUDO provides an unregulated opportunity for users to install unauthorized, untested or even malicious updates.

The policy generates alerts by when ThreatSync+ NDR identifies activity on port 7680 between devices within your private network. The policy is configured to generate alerts on any 7680 traffic, so if WUDO is authorized to be used within your network, alerts will be generated often.

How to Tune

The policy is enabled by default because our recommendation is to not use WUDO in your enterprise. If you use WUDO as an authorized method of Windows software distribution, deactivate this policy.

If you allow WUDO on specific networks, like isolated guest networks or specific areas of the organization, then you can tune the source and destination zones to exclude those subnets that are authorized.

LLMNR Traffic Crossing Network Boundary

This policy generates alerts for Link-Local Multicast Name Resolution (LLMNR) traffic (port 5355 UDP) traveling across the network boundary. This is unnecessary or unexpected activity, and it should be blocked to prevent ransomware attacks.

How it Works

This policy generates alerts when ThreatSync+ NDR detects traffic from an internal source to port 5355 exiting or evading the edge network.

LLMNR (Link-Local Multicast Name Resolution) traffic should not be allowed to leave an enterprise network. LLMNR is a protocol that allows hosts to resolve names for other hosts on the same local network. It operates over UDP on port 5355.

LLMNR is susceptible to attack because it does not have an authentication mechanism, so anyone can respond to an LLMNR request. Some attacks that can be performed using LLMNR include:

  • Name collision attacks
  • LLMNR poisoning

How to Tune

LLMNR is the successor to NetBIOS. NetBIOS (Network Basic Input/Output System) is an older protocol that was used in early versions of Windows networking. NBT-NS is a component of NetBIOS over TCP/IP (NBT) and is responsible for name registration and resolution. Similar to LLMNR, NBT-NS is a fallback protocol when DNS resolution fails. It allows local name resolution within a LAN, so when you disable this feature in an Active Directory environment, it mitigates the alerts. However, if any application is recommended to use the LLMNR ports, you can exclude those authorized application servers from the destination zone.

NetBIOS-NS Traffic Crossing Network Boundary

This policy generates alerts when NetBIOS-NS traffic (port 137 UDP) is detected crossing the network boundary. This is unnecessary or unexpected port activity, and it should be blocked to prevent ransomware attacks.

How it Works

This policy receives an alert when ThreatSync+ NDR detects any traffic on port 137 from the internal host to the external network. Similar to a LLMNR poisoning attack, NTB-NS is used without a suitable response from the DNS server. This means that an attempt is made to find an answer in the local network. This usually happens when the user makes a typo when searching for a network resource, is not in the correct network, has not configured a DNS server or, for example, has forgotten to connect to the VPN and cannot reach the desired network resource.

In this case, if the attacker knows the IP address of the network resource, the attacker can send the client a different IP address in response. This IP address arrives at a server hosted by the attacker.

How to Tune

NetBIOS. NetBIOS (Network Basic Input/Output System) is an older protocol that was used in early versions of Windows networking. NBT-NS is a component of NetBIOS over TCP/IP (NBT) and is responsible for name registration and resolution. Similar to LLMNR, NBT-NS is a fallback protocol when DNS resolution fails. It allows local name resolution within a LAN, so when you disable this feature in an Active Directory environment, it mitigates the alerts. However, if any application is recommended to use the NBT-NS ports, you can exclude those authorized sites from the destination zone.

RDP Attempts From External to Internal

This policy generates alerts when Remote Desktop Protocol (RDP) sessions are attempted to be established into your network from an External IP address, but fail.

How it Works

RDP traffic into your network should be limited to a small set of entry points to control and monitor access from outside your enterprise. This policy generates an alert whenever failed RDP sessions, those that are too short to indicate that authentication was successful, are detected from an external network source.

This policy is initially configured to generate an alert on any failed RDP connection. It is appropriate for organizations that do not allow RDP connections into the enterprise.

How to Tune

If you do allow RDP traffic to enter your network through a specific set of servers in your Demilitarized Zone (DMZ), exclude those servers from the destination zone. Use this policy to identify when unauthorized RDP servers are accessible.

RDP Connection From New External Host

This policy generates alerts for incoming RDP connections from the Internet when the external source IP address connects to an internal IP address for the first time.

How it Works

When incoming RDP connections are allowed, there is usually a limited and well-known set of users that are actively connecting. This policy alerts you when new locations are connecting so you can have visibility into when new RDP users are connecting.

How to Tune

If you receive too many alerts for this policy because the external domains or Internet Service Providers are constantly rotating their IP addresses, you can modify the policy to use one of the other anomalous events, such as Connection from New Domain, Connection from New Organization, or Connection from New Locality instead of Connection from New IP.

You can also exclude specific domains, organizations, or countries from the source zone so they do not generate alerts from those areas.

RDP From External to Internal

This policy generates alerts for inbound RDP connections from an external IP address.

This policy is different from the Policy RDP Attempts from External to Internal in that it only generates alerts when enough activity is detected in the session to indicate that the user successfully connected and entered correct credentials.

How it Works

RDP traffic into your network should be limited to a small set of entry points to control and monitor access from outside your enterprise. This policy generates alerts whenever ThreatSync+ NDR detects an RDP session with greater than 5 KB of data from an external network source.

How to Tune

If you do allow RDP traffic to enter your network through a specific set of servers in your Demilitarized Zone (DMZ), exclude those servers from the destination zone. Use this policy to identify when unauthorized RDP servers are accessible.

SSH Attempts from External to Internal

This policy generates alerts when failed SSH sessions are attempted to be established into your network from an external IP address.

How it Works

Authorized SSH traffic into your network is a rare occurrence and should be limited to a small set of entry points to control and monitor access from outside your enterprise. This policy generates alerts whenever ThreatSync+ NDR detects any SSH traffic from an external network source.

This policy is initially configured to generate alerts on any SSH connection. It is appropriate for organizations that do not allow SSH connections into the enterprise.

How to Tune

If you do allow SSH to enter your network through a specific set of servers in your Demilitarized Zone (DMZ), exclude those servers from the destination zone. Use this policy to identify when unauthorized SSH servers are accessible.

Suspected Data Exfiltration through DNS

This policy generates an alert when an unusually large volume of traffic passes from internal endpoints to external locations using the DNS protocol. This might be an indication of data exfiltration through DNS Tunneling, a common ransomware-related Command and Control activity.

How it Works

ThreatSync+ NDR monitors DNS traffic to identify sessions with larger than expected payloads and generates an alert when it detects a DNS tunnel between an internal and an external IP address.

How to Tune

It is possible that normal DNS activity might occasionally exceed the limits used in the detection. To address this, the destination of this policy is defined to be an external IP address that is not a member of a well-known DNS service.

If you have common, reputable DNS services that are not included in that destination zone, you can edit the zone to include your additional external DNS service domains.

Unexpected DNS Resolution Server

This policy generates alerts when traffic from internal endpoints passes to unexpected external DNS resolution servers. This might be an indication of the DNS protocol being used for ransomware-related Command and Control activities.

How it Works

This policy generates alerts when DNS traffic (port 53) connects to a new domain where traffic has never been sent before.

This is a powerful policy in that it is self-learning. It triggers only once for any new domain, so if the domain is unauthorized, make sure to block it at your firewall.

How to Tune

The only tuning that you might perform for this policy is to exclude any internal subnets in your source zone that you do not want alerts for. For example, a guest network.

Unsecured Inbound FTP/TFTP Traffic

This policy generates alerts when FTP or TFTP traffic passes from external sources to internal devices. If you allow activity on unencrypted application ports to enter your enterprise from the Internet, it can make your organization vulnerable to attacks such as ransomware.

How it Works

This policy generates alerts when two-way conversations using FTP traffic on port 21or TFTP traffic on port 69 enter the internal network.

Because FTP and TFTP are unencrypted protocols, the access to your network through these protocols should be highly controlled. If you cannot move FTP traffic to a different encrypted protocol or enclose it in an encrypted VPN, it is important to control the points of entry for this data.

How to Tune

If you require the use of FTP or TFTP, you should identify the limited set of jump servers in your DMZ that are authorized to accept FTP or TFTP connections and create exceptions in this policy for these servers.

Add these as exclusions to the destination zone in the policy.

Unsecured Inbound IRC Traffic

This policy generates alertswhen IRC traffic passes from external sources to internal devices. If you allow activity on unencrypted application ports to enter your enterprise from the Internet, it can make your organization vulnerable to attacks such as ransomware.

How it Works

This policy generates alerts when two-way conversations using IRC enter the internal network.

Because IRC is an unencrypted protocol, the access to your network through this protocol should be highly controlled. If you cannot move IRC traffic to a different encrypted protocol or enclose it in an encrypted VPN, it is important to control the points of entry for this data.

How to Tune

If you require the use of IRC, identify the limited set of jump servers in your DMZ that are authorized to accept IRC connections and create exceptions in this policy for these servers.

Add these as exclusions to the destination zone in the policy.

Unsecured Inbound Telnet Traffic

This policy generates alerts when Telnet traffic (port 23 TCP) passes from external sources to internal devices. If you allow activity on unencrypted application ports to enter your enterprise from the Internet, it can make your organization vulnerable to attacks such as ransomware.

How it Works

This policy generates alerts when two-way conversations using Telnet enter the internal network.

Because Telnet is an unencrypted protocol, the access to your network through this protocol should be highly controlled. If you cannot move Telnet traffic to a different encrypted protocol such as SSH or enclose it in an encrypted VPN, it is important to control the points of entry for this data.

How to Tune

If you require the use of Telnet, identify the limited set of jump servers in your DMZ that are authorized to accept Telnet connections and create exceptions in this policy for these servers.

Add these as exclusions to the destination zone in the policy.

Unsecured Inbound Web Server Activity

This policy generates alerts when unsecured HTTP web server traffic (port 80 TCP) passes from external sources to internal devices. If you allow activity on unencrypted application ports to enter your enterprise from the Internet, it can make your organization vulnerable to attacks such as ransomware.

How it Works

This policy generates alerts when two-way conversations using HTTP enter the internal network.

Because HTTP is an unencrypted protocol, the access to your network through this protocol should be highly controlled. If you cannot move HTTP traffic to a different encrypted protocol such as HTTPS or enclose it in an encrypted VPN, it is important to control the points of entry for this data.

How to Tune

If you require the use of HTTP, identify the limited set of jump servers in your DMZ that are authorized to accept HTTP connections and create exceptions in this policy for these servers.

Add these as exclusions to the destination zone in the policy.

Unsecured Internal Telnet Traffic

This policy generates alerts when Telnet traffic (port 23 TCP) passes between internal devices. If you allow activity on unencrypted application ports to enter your enterprise from the Internet, it can make your organization vulnerable to attacks such as ransomware.

How it Works

This policy generates alerts when two-way conversations using Telnet enter the internal network.

As Telnet is an unencrypted protocol, its use should be highly controlled. If you cannot move Telnet traffic to a different encrypted protocol like SSH or enclose it in an encrypted VPN, it is important to closely monitor its use.

How to Tune

If you require the use of Telnet, identify the limited set of servers in your network that are authorized to accept Telnet connections and create exceptions in this policy for these servers.

Add these as exclusions to the destination zone in the policy.

WUDO Traffic Crossing Network Boundary

This policy generates alerts when Windows Update Delivery Optimization (WUDO) traffic passes between devices within your network and the public Internet. This policy is focused on outbound WUDO traffic.

Microsoft Windows uses the WUDO protocol to distribute the operating system update process to Windows devices, which enables updates to be distributed through an uncontrolled peer-to-peer network.

If you control operating system updates through an enterprise distribution tool, then WUDO provides an opportunity for users to install unauthorized, untested, or even malicious updates.

How it Works

The policy generates alerts when ThreatSync+ NDR detects activity on port 7680 from devices within your private network to public IP addresses on the Internet.

Even if you allow users to use WUDO within your organization, you might not want them to use it externally to install updates from untrusted locations on the Internet.

How to Tune

This policy is configured to generate alerts on any 7680 traffic, so if WUDO is authorized to be used within your network, alerts will be generated often.

The policy is enabled by default because our recommendation is to not use external WUDO updates in your enterprise. We recommend that you rely on your software distribution service to control which updates are allowed to be installed.

However, if you allow external WUDO as an authorized method of Windows operating system software distribution, then you should deactivate this policy.

If you allow external WUDO on specific networks, such as isolated guest networks or specific areas of the organization, then you can tune the source zone to exclude those subnets that are authorized.

If you allow WUDO to be used in a limited set of external domains, you can configure those domains in the destination zone.

Related Topics

Configure ThreatSync+ Policies

Policy Tuning

Manage ThreatSync+ Zones

Cybersecurity and Infrastructure Security Agency