Currently browsing

Product

We are excited to announce a new capability to detect unusual DNS resolver activity.

This detection notifies you of unusual behavior by a virtual machine or container in your cloud environment, which is communicating with a public DNS resolver that it hasn’t communicated with recently.

DNS Resolvers

Trusting your DNS resolvers is a critical part of your overall security hygine, since this is the component that maps out IP addresses for hosts connected to the Internet.

Indicators of Compromise

Due to its important nature, DNS resolution issues are often the cause of network outages. Errors such as misconfigurations in a single DNS server can cause widespread communication failures for all services that communicate with it, and they are typically very difficult to identify since teams often need to investigate each server individually in order to find issues.

DNS is also the focal point or frequent target for many attacks, due to its important role in internet communication. Attackers can hijack resources and cause them to communicate with a public DNS resolver in attempts to gain access to an environment or steal data.

This detection notifies you of unusual behavior by a virtual machine or container in your cloud environment, which is communicating with a public DNS resolver that it hasn’t communicated with recently. This is suspicious because it deviates from the established baseline behavior of the resource within the environment and may indicate an attempt to use alternative DNS resolvers for bypassing network monitoring, exfiltrating data, or other malicious activities aimed at evading detection.

Upwind leverages runtime data to rapidly identify unusual DNS resolver communication and immediately alert you to suspicious activity. Read more about DNS resolver detections in the Upwind Documentation Center (login required).

We are excited to announce support for a new detection type – the identification of malicious port sweeps.

Port sweeps can occur when compromised hosts or containers within your environment probe a port on a large number of publicly routable IP addresses or a large number of internal IP addresses. This type of activity is typically used to find vulnerable hosts or services to exploit.

Port sweeps are conceptually related to port scans, with port sweeps looking for a specific port or ports across multiple hosts, and port scans enumerating any ports to be found on one or more hosts. Sometimes attackers will use a port sweep to narrow down their attack surface, and follow with a port scan, targeted at finding a vulnerable service.

TCP Ports

TCP ports number from 0 to 65535, with the standard ports occupying numbers 0 to 1023. Discovering that a standard port is “open” can indicate either an already infected port, or one that is vulnerable to attack. 

Commonly used ports include:

• Port 20 (UDP): File Transfer Protocol (FTP) for data transfer
• Port 22 (TCP): Secure Shell (SSH) protocol for secure logins, FTP, and port forwarding
• Port 23 (TCP): Telnet protocol for unencrypted text commutations
• Port 53 (UDP): Domain Name System (DNS) translates names of all computers on internet-to-IP addresses
• Port 80 (TCP): World Wide Web HTTP

Indicators of Compromise

Potentially malicious port sweeps are detected through their suspicious access patterns – including repeated attempts to connect to a port with a large number of publicly routable IP addresses over a short period of time, or using a large number of internal IP addresses to connect to a port or ports over a short period of time. A port sweep attack aims to locate open ports to discover which services the machine is running and to identify its operating system, to inform which vulnerabilities to exploit.

Internally-based port sweeps are similar to port scan attacks, but rather than leveraging an external application to scan for vulnerable hosts through repeated port scans, internal port sweeps use compromised internal resources to perform port sweeps, with the same goal of identifying vulnerable hosts.

A port sweep can provide useful information about a network environment, including: 

• Existing network defenses, such as firewalls
• Running applications
• Machines that are online
• Information about the targeted system
• Information about vulnerable networks and servers

Attackers can then use this information to conduct an attack on a virtual machine or container.

Upwind leverages runtime data and machine learning to rapidly identify unusual port sweeps and immediately alert you to suspicious activity. Read more about port sweep detections in the Upwind Documentation Center (login required).

We are excited to announce a new detection type, identifying unusual DoT activity.

This detection notifies you of unusual DNS over TLS (Transport Layer Security) communication, often referred to as DoT, which could indicate attempts to blend malicious communications with regular encrypted web traffic to evade detection.

DNS over TLS (DoT) 

DNS is a crucial part of infrastructure that maps out IP addresses for hosts connected to the internet through a process called DNS resolution, allowing users to access websites with user-friendly names rather than remembering specific IP addresses for sites.

DNS is a fundamentally “insecure” network whose communication can easily be intercepted. To avoid security risks, DNS needs TLS or HTTPS (Hypertext Transfer Protocol Secure) encryption protocols to improve network security.

TLS is a widely-used protocol that is designed to keep data secure in Internet communications. By using DNS over TLS, users can protect data that is being transferred, keeping it private even if it is intercepted. By using DNS over TLS (DoT), you send DNS requests over an encrypted TLS tunnel and can ensure the data is not readable by unauthorized parties – acting as a needed safeguard against data breaches. 

This is why DoT has become a popular method of safeguarding DNS communications.

Indicators of Compromise 

While DoT helps safeguard data, it can still be compromised by attackers. Upwind detects when a host or container in your cloud environment engages in DoT communication that deviates from established baseline behavior, which may indicate a “Command and Control” or “Defense Evasion” attempt using encrypted channels. This unusual communication could indicate an attacker’s method to compromise your system remotely, exfiltrate data, or deliver further payloads, blending malicious communications with regular encrypted web traffic to evade detection.

Upwind leverages runtime data to rapidly identify unusual DNS over TLS (DoT) communication and immediately alert you to suspicious activity. Read more about DNS over TLS (DoT) detections in the Upwind Documentation Center.

We are excited to announce support for a new detection type: identification of malicious port scans.

Port scanners are applications that probe a host or server to find open ports or “weak points” in your network. These can be used by malicious actors to exploit vulnerabilities and identify network or security services running on a host.

Port Scanning
There are a variety of TCP ports, numbered from 0 to 65535, with the standard ports occupying numbers 0 to 1023. A standard port that is left open can indicate an infected or vulnerable port. 

Commonly used ports include:

• Port 20 (UDP): File Transfer Protocol (FTP) for data transfer
• Port 22 (TCP): Secure Shell (SSH) protocol for secure logins, FTP, and port forwarding
• Port 23 (TCP): Telnet protocol for unencrypted text commutations
• Port 53 (UDP): Domain Name System (DNS) translates names of all computers on internet-to-IP addresses
• Port 80 (TCP): World Wide Web HTTP

Port scans are not always malicious – they can also occur when security services are deployed on virtual machines in your environment. This occurs because the services  conduct port scans to alert you to potentially misconfigured ports that have been left open. 

Indicators of Compromise

Potentially malicious port scans are detected through their suspicious access patterns – including repeated attempts to connect to multiple ports over a short period of time, or connecting a resource or host to multiple ports over a short period of time. A port scan attack aims to locate open ports to discover which services the machine is running and to identify its operating system, to inform which vulnerabilities to exploit.

A port scan can provide useful information about a network environment, including: 

• Existing network defenses, such as firewalls
• Running applications
• Machines that are online
• Information about the targeted system
• Information about vulnerable networks and servers

Attackers can then use this information to conduct an attack on a virtual machine.

Port Scan Attack Methods

In a port scanning attack, attackers generally do one of the following:

1. Leverage a resource to perform outbound port scans to a remote host
2. Use a remote host to port scan a resource 
3. Use an internal source to port scan a resource 
4. Leverage a remote host using UDP to port scan a resource 

Upwind leverages runtime data to rapidly identify unusual port scanning and immediately alert you to suspicious activity. Read more about port scanning detections in the Upwind Documentation Center.

We are excited to announce a new threat detection, with the ability to identify an exposed Kubernetes Dashboard.

This threat detection will inform you when the Kubernetes dashboard for your cluster is exposed to the internet by a Load Balancer.  Exposing your dashboard to the internet makes the management interface of your cluster vulnerable to attack. This creates an opportunity for adversaries to exploit weaknesses in authentication and access control, compromising the security of your system.

What is the Kubernetes Dashboard?

The Kubernetes Dashboard is a web-based Kubernetes user interface (UI) that is used to manage a Kubernetes system, allowing you to run commands on pods within the dashboard and deploy access keys to your clusters.

The Kubernetes Dashboard has a number of uses, including:

• Deploying containerized applications to the Kubernetes cluster
• Troubleshooting your containerized application
• Managing cluster resources
• Getting on overview of applications running on the cluster
• Creating or modifying Kubernetes resources such as DaemonSets or Deployments

The Kubernetes Dashboard also gives you information on the state of Kubernetes resources in your cluster and notifies you or any potential errors.

Indicators of Compromise

While the Kubernetes Dashboard gives you extensive capabilities for managing Kubernetes, it can also be a launchpad for attacks if there are misconfigurations or excessive/loose permissions. A Load Balancer can expose your Kubernetes Dashboard to the Internet if not properly configured, ultimately making the management interface of your cluster vulnerable. This can also create an opportunity for attackers to exploit any weaknesses in authentication and access control, such as overly permissive RBAC, which can potentially compromise the security of your system.

Use Upwind’s Exposed Kubernetes Dashboard Detection to identify any exposures of your Kubernetes Dashboard and proactively remediate exposures or open attack paths. For  more information on the Exposed Kubernetes Dashboard detection, please visit the Upwind Documentation Center (login required).

We are excited to announce the release of a new threat detection type – exec command in a kube-system namespace.

This detection alerts you that kubectl exec has run a command in your environment in the kube-system namespace, which may indicate a suspicious activity. 

What is Kubectl Exec?

Kubectl is a command line tool used to communicate with Kubernetes clusters via the Kubernetes API. This is an admin tool for Kubernetes clusters that can be used to monitor Kubernetes status, manage and edit resources. 

Kubectl exec gives you full shell access to the container, meaning you can execute commands inside a container directly from kubectl. Before you use kubectl exec to execute a command in a container, you need to know the container namespaces in the cluster. kubectl exec is a powerful tool, it is primarily used for inspecting containers and viewing containers’ status and contents.

Indicators of Compromise

While kubectl exec is used for improving container monitoring and performance, it can also be used by bad actors even if one token of your kubernetes has gotten into the wrong hands. 

One sign of compromise can be if kubectl exec is used to execute a command in the kube-system namespace. The kube-system namespace is a default namespace that is used mostly for system-level components like kube-dns and kube-proxy. It is very unusual to execute commands inside pods or containers in the kube-system namespace because they should be immutable at runtime and acquire high permissions by default and have access to secrets and control-plane resources.

A kube-system attack often includes:

1. An attacker uses kubectl exec in the kube-system namespace, which has high permissions by default
2. The attacker then uses kubectl exec to run the exec command in a pod and establish a temporary shell session
3. Using kubectl exec and a temporary shell session then gives the attacker the ability to execute any process or command in the pod. 
4. The attacker then uses the interactive shell to run commands and gain access into the pod’s data, including permissions and secrets. 

Upwind leverages runtime data to rapidly identify unusual kubectl exec commands run in the kube-system namespace and immediately alert you to suspicious activity. Read more about Kubectl Exec detections in the Upwind Documentation Center.