When collecting Zeek data, you have a rich source of information for analysis. However, when monitoring systems, it's crucial to distinguish between the questions: "What do I need to 'alert' on?" and "What do I need to 'analyze'?" An alert is something requiring immediate action (e.g., something you want to receive a page for). Analysis involves looking for patterns in the data, possibly using visualizations to aid in that process. Another type of network data analysis involves validating or invalidating cyber attack/compromise via threat hunting data.
Below is a list of conditions that should be considered when creating zeek alert monitors in most network environments. These conditions play a crucial role in enhancing the effectiveness of an NDR alert systems and ensuring a proactive approach to network security.
Remote RDP into your environment
Why is monitoring for remote RDP into your environment important?
RDP, or 'Remote Desktop Protocol,' serves as the primary standard for system administrators logging onto Windows servers from remote system. While RDP is a legitimate network utility designed for remote server access, it is generally not considered legitimate or secure practice to expose your organization's servers' RDP services directly to the Internet. Allowing random individuals from the Internet to attempt remote logons to servers can pose significant security risks.
Note: There is also a valuable detection point for Remote Desktop Protocol (RDP) usage between workstations within your environment. It's typically uncommon for employees to require RDP access to another employee's workstation. However, implementing this detection mechanism involves capturing East/West traffic in your network sensor. Keep in mind that East/West traffic analysis may introduce more noise in alerting and also requires additional effort to fine-tune effectively.
Efficiently setting up alerts for this activity with Zeek sensors involves configuring them to recognize the organization's local networks. This configuration enables alerts when the source of the Remote Desktop Protocol (RDP) session is external to your local networks, and the destination is within your local networks.
Another insightful approach to this detection is detailed in the Sigma Rule named 'Publicly Accessible RDP Service.' This rule operates under the assumption that your organization's internal IP address space utilizes private IP addresses. Therefore, any RDP session originating from a non-private IP address to a private IP address is likely an externally sourced RDP session connecting to your environment. You can find the 'Publicly Accessible RDP Service' Sigma rule here: https://detection.fyi/sigmahq/sigma/network/zeek/zeek_rdp_public_listener/
Zeek Log Search - External RDP
conn.log services=rdp where local_orig=false & local_resp=true or id.orig_h=external & id.resp_h=internal
Remote SSH into your environment
Why is monitoring for remote SSH into your environment important?
SSH, or 'Secure Shell,' is a primary tool for system administrators managing Linux servers and network engineers handling network equipment. Remote administrators commonly utilize SSH to connect to systems, especially when dealing with network equipment like routers and firewalls, which are often designed to be connected to the Internet.
While network equipment ideally should be managed through a separate control plane disconnected from the Internet, this isn't always feasible. Remote SSH access from external to internal environments can still serve as a high-value alert if external remote SSH access is prohibited. Even if external SSH access is allowed in certain cases, such as remote router management, you can set up alerts for external SSH connections to internal systems where external SSH is not authorized. This detection often reveals misconfigured network devices that unintentionally exposed their SSH service to the Internet.
Enabling remote SSH detection is also achieved by configuring your local networks in your Zeek sensor. Alternatively, you can base your detection on the assumption that your internal or local networks will use private IP addresses.
Zeek Log Search - External SSH
conn.log services=ssh where local_orig=false & local_resp=true or id.orig_h=external & id.resp_h=internal
SSH Outbound Tunneling
SSH is frequently utilized in attacks to establish tunnels from internal to external networks. Therefore, setting up alerts for suspicious outbound SSH connections can be a valuable detection method. SSH tunneling is so common that there are several SSH outbound tunneling Sigma rules available on the website: https://detection.fyi
Note: While these SSH tunneling Sigma rules mainly rely on server logs, you can also generate additional SSH tunneling alerts from Network Detection and Response (NDR) data by identifying unauthorized SSH outbound sessions in Zeek logs.
conn.log services=ssh where local_orig=true & local_resp=false or id.orig_h=internal & id.resp_h=external
The 'ssh.log' file in Zeek also includes a 'direction' field, which can be utilized in searches.
ssh.log direction=outbound where local_orig=true or id.orig_h=internal
Note: Attackers commonly employ a technique in which they tunnel SSH through other protocols such as HTTPS. They choose this method because HTTPS is frequently permitted outbound through target organization boundary firewalls, providing a covert channel for SSH use in their attacks. In these cases, attackers are not utilizing SSH as a covert channel but as a tool to administer their own attacks. The detection of this scenario using Zeek data is not detailed above and will be addressed in a separate article.
Remote Access and Remote Monitoring & Management (RMM) Tools
Why is monitoring for Remote Access and Remote Management Tools into your environment important?
Having remote GUI access to a system is invaluable, as it enables attackers to swiftly navigate and locate sensitive files for theft or encryption. Attackers often leverage a variety of remote access tools commonly used by system administrators to control systems and assist users. Some frequently used Remote Access Tools in IT departments but also used by Ransomware operators include:
VNC
TeamViewer
GoToMyPC
AnyDesk
Atera & Splashtop
ConnectWise (formerly ScreenConnect)
The utilization of legitimate remote access tools in cyber-attacks has become so prevalent that CISA issued an advisory addressing their use. According to CISA, "Remote access software provides IT/OT teams with flexible ways to detect anomalous network or device issues early on and proactively monitor systems. Cyber threat actors are increasingly co-opting these same tools for easy and broad access to victim systems. While remote access software is used by organizations for legitimate purposes, its use is frequently not flagged as malicious by security tools or processes." (Source: CISA Advisory https://www.cisa.gov/resources-tools/resources/guide-securing-remote-access-software
VNC Usage Detection
VNC operates using a protocol known as Remote Frame Buffer (RFB). For detailed information on VNC and the RFB protocol, you can refer to the following link: https://help.realvnc.com/hc/en-us/articles/360002320638-How-does-VNC-technology-work-
Detecting VNC inbound from remote.
conn.log services=rfb where local_orig=false & local_resp=true or id.orig_h=external & id.resp_h=internal
Team Viewer Detection
TeamViewer predominantly establishes outbound and inbound connections through TCP and UDP port 5938. In the event of port 5938 connectivity issues, TeamViewer will switch to port 443. If connecting through port 443 is also unsuccessful, it will attempt to establish a connection on port 80. For more details, you can refer to TeamViewer's documentation on the ports used: https://community.teamviewer.com/English/kb/articles/4139-ports-used-by-teamviewer.
Detecting Team Viewer usage Outbound.
conn.log where proto=udp & id.resp_p=5938 & local_orig=true & local_resp=false
Other ways to detect Team Viewer in your environment:
http.log look for hostname *.teamviewer.com
ssl.log look for server_name *.teamviewer.com
GoToMyPC Detection
GoToMyPC predominantly operates on port 443, but it may also utilize UDP ports 8200 and 443. Effective detections of GoToMyPC through network traffic involve examining Zeek logs for instances of gotomypc.com:
Detecting Go to My PC outbound.
In http.log, search for the hostname *.gotomypc.com
In ssl.log, look for the server_name *.gotomypc.com
The GoToMyPC site provides a list of other domains it utilizes, which can be found at https://support.logmeininc.com/gotomypc/help/what-are-the-optimal-firewall-configurations
AnyDesk Detection
AnyDesk uses TCP ports 80, 443, 6568. AnyDesk also uses UDP ports 50001-50003 to 239.255.102.18 for multicast to allow discovery on your local network. (Source: https://support.anydesk.com/knowledge/firewall )
Detecting AnyDesk Outbound.
conn.log where id.resp_p=6568 & local_orig=true & local_resp=false
conn.log where id.orig_h=239.255.102.18 & local_orig=true & local_resp=false
Other ways to detect Any Desk in your environment:
In http.log, search for the hostname *.net.anydesk.com
In ssl.log, look for the server_name *.net.anydesk.com
Atera & Splashtop Detection
Atera and Splashtop remote access tools have also been observed in ransomware cases. " Along the way, the threat actors installed remote management tools such as Atera and Splashtop for persisting in the environment." (Source: https://thedfirreport.com/2022/04/04/stolen-images-campaign-ends-in-conti-ransomware/ )
The Atera agent primarily uses port 443, but connections reach out to atera.com. The best detections for atera would be looking for atera.com in hostname and server_name fields.
Splashtop uses port 443 but also uses ports 6783, 6784, and 6785 which offers some additional network detection opportunities.
conn.log where id.resp_p=6783 or 6784 or 6785 & local_orig=true & local_resp=false
Splashtop also connects to splashtop.com
In http.log, search for the hostname *splashtop.com
In ssl.log, look for the server_name *splashtop.com
ConnectWise ScreenConnect Detection
Another frequently observed remote access tool in ransomware cases is Screen Connect. An insightful article titled "From ScreenConnect to Hive Ransomware in 61 hours" by DFIR Report delves into the utilization of Screen Connect in a ransomware case. You can access the article here: https://thedfirreport.com/2023/09/25/from-screenconnect-to-hive-ransomware-in-61-hours/
Screen Connect uses ports 443 and 8040 and 8041. But also uses UDP port 75 for Verify that only the Enhanced Heartbeat.
Detecting ScreenConnect outbound
ScreenConnect:
conn.log where proto=tcp & id.resp_p=8040 or 8041 & local_orig=true & local_resp=false
ScreenConnect heartbeat:
conn.log where proto=udp & id.resp_p=75 & local_orig=true & local_resp=false
Other ways to detect ScreenConnect in your environment:
In http.log, search for the hostname *screenconnect.com
In ssl.log, look for the server_name *screenconnect
Conclusion
Several other remote access and management tools are frequently employed in ransomware cases, which were not covered in the list provided earlier. Most remote access management tools predominantly utilize common ports like 443. Port 443 traffic was not included in the examples above due to its widespread usage in legitimate traffic. Furthermore, numerous methods exist for detecting remote access and management tools and their usage through endpoint operating system monitoring and threat hunting. This article simply outlined some detection opportunities through Zeek traffic analysis. Any unauthorized usage of remote access and management tools in your environment should trigger immediate alerts and prompt investigation.
Comments