Tor Exit Nodes: Risks, Monitoring, and Defensive Use

Insights

????

What Are Tor Exit Nodes?

Tor exit nodes frequently appear in cybersecurity discussions, and for good reason. This post explains why they matter so you can decide if your security team should take a closer look.

The Tor network is a powerful tool for enabling anonymity online, and like many privacy-preserving technologies, it has both legitimate and malicious uses (we’re looking at you, DoH!). While it supports privacy for users around the world, it also helps attackers hide their infrastructure, evade detection, and bypass traditional defenses. Understanding how Tor works and how it’s used across different stages of an attack can help defenders apply controls, such as traffic monitoring and access policies, more effectively.

The Tor (The Onion Router) network is a system designed to enable anonymous communication over the Internet. When a user routes their connection through Tor, their data is encrypted and bounced through a series of volunteer-operated nodes, also known as relays, in a layered manner, like peeling an onion. Tor exit nodes are the final relay in the Tor network through which traffic emerges before reaching its destination.

Here’s how it works:

  1. Client Encryption and Path Building:
    When a user initiates a connection via the Tor Browser, the client software selects a random path through the Tor network, consisting of three relays:

    • Entry (Guard) Node – The first hop; it knows the user’s IP address.
    • Middle Node – The second hop; it connects the entry and exit nodes.
    • Exit Node – The final hop; it decrypts the traffic and sends it out to the public Internet.
  2. Onion Routing:
    Each relay only knows the previous and next hop, not the full path, and traffic is encrypted in multiple layers. As each relay receives the data, it peels away one layer of encryption (hence “onion routing”) until the exit node forwards the plaintext traffic to the destination website or server.
  3. Exit Node Role:
    The exit node is where the traffic appears to originate from as far as the destination is concerned. It sees the content of the request (unless it’s encrypted with HTTPS), but not the origin IP address of the user. This is why exit nodes are a focus in both privacy discussions and cybersecurity operations.

Because exit nodes are the only points in the Tor network that interact with the open Internet, they are a key observation point for defenders monitoring suspicious traffic. You can download a current list of active exit nodes and as well as find more technical detail about changes to the service on their official blog.

Why Tor Exit Nodes Matter in Cybersecurity

While Tor has many legitimate uses, its anonymity makes it attractive to threat actors. Attackers frequently leverage Tor for:

  • Exfiltration of data after compromising a system
  • Command-and-control (C2) communications
  • Scanning and probing for vulnerabilities anonymously
  • Anonymized web scraping or credential stuffing

Traffic emerging from Tor exit nodes presents challenges for attribution, enforcement, and even rate-limiting. Monitoring or blocking these nodes can help reduce noise and risk in certain environments.

MITRE ATT&CK TTPs

To further the discussion about Tor’s significance in cybersecurity, it’s helpful to look at how the MITRE ATT&CK framework classifies the different ways attackers abuse it. We compiled the following list to emphasize the broad utility of Tor (or similar services) across the threat landscape. From infrastructure obfuscation and anonymous scanning to covert data theft, Tor enables a wide spectrum of malicious operations. By showcasing its versatility, we aim to help defenders implement more effective detection and mitigation strategies in their environments.

Tactic Technique ID Technique Name Description Use Case
Command and Control T1090.003 Proxy: Multi-hop Proxy Multi-hop proxy chains are used to conceal the true source and destination of network traffic. Tor acts as a multi-hop encrypted proxy. Operators route C2 traffic through it to hide their infrastructure and bypass perimeter defenses.
Command and Control T1102 Web Service Legitimate web services can be leveraged to carry out C2 communications while blending with normal traffic. Tor hidden services (.onion domains) are used to host C2 endpoints anonymously, making them harder to block or trace.
Command and Control T1102.001 Dead Drop Resolver Commands or payloads are stored at web-accessible locations and retrieved by malware. Malware connects over Tor to .onion pages that host instructions (dead drops), reducing the need for persistent C2 channels.
Command and Control T1102.002 Bidirectional Communication Two-way communication channels are established using web services, allowing command issuance and response retrieval. Tor provides encrypted, anonymous communication between infected systems and their controller using hidden services.
Command and Control T1572 Protocol Tunneling Malicious traffic is encapsulated within another protocol, such as HTTPS, to evade detection mechanisms. Communication is tunneled through Tor using standard protocols like HTTPS or SOCKS to blend with legitimate activity.
Command and Control T1001 Data Obfuscation Traffic is modified or disguised to make it more difficult to analyze or detect. Tor’s encrypted routing layers hide both the content and the destination of communications, helping obscure intent.
Exfiltration T1041 Exfiltration Over C2 Channel Data is embedded within command and control traffic for covert transmission out of the environment. Tor-based C2 channels are frequently used to exfiltrate stolen data along with commands due to encryption and anonymity.
Exfiltration T1567.002 Exfiltration to Cloud Storage Data is exfiltrated using cloud storage or web services, often over encrypted channels. Tor is used to anonymize the transfer of stolen data to attacker-controlled storage or .onion servers.
Resource Development T1583.006 Acquire Infrastructure: Web Services Web infrastructure such as domains or servers is obtained for later operational use. .onion domains and hidden services are registered and deployed over Tor to host malware, C2 servers, or phishing kits anonymously.
Defense Evasion T1027 Obfuscated Files or Information Code or data is hidden or encoded to prevent detection by security tools. Traffic routed over Tor benefits from inherent encryption and anonymization, making it harder to inspect or attribute.
Discovery T1595 Active Scanning Target networks are scanned to gather information such as open ports, services, or potential vulnerabilities. Scanning activities are conducted over Tor to mask the source of probes against target infrastructure.
Discovery T1595.001 Scanning IP Blocks Large address spaces are scanned to locate accessible systems and services. Tor exit nodes are used to scan wide IP ranges, identifying exposed assets while remaining anonymous.
Discovery T1595.002 Vulnerability Scanning Specific systems are scanned to identify known vulnerabilities or misconfigurations. Vulnerability scanning tools route traffic through Tor to identify weaknesses in targets without revealing the attacker’s origin.
Credential Access T1110 Brute Force Repeated login attempts are made to gain unauthorized access by guessing or using common passwords. Login brute-force attacks are launched via Tor to bypass IP restrictions and avoid detection.
Credential Access T1110.004 Credential Stuffing Previously leaked credentials are used to attempt logins across services. Tor is used to distribute these login attempts across many IPs, increasing stealth and success while avoiding rate limits.
Reconnaissance T1589.003 Gather Victim Identity Information: Credentials Username and password data is collected from public or breached sources to inform follow-on targeting. Tor is used to scrape credential leaks from forums, dumps, or pastes while hiding the requester’s identity.

Defensive Applications of Tor Exit Node Intelligence

There are multiple defensive use cases for tracking and leveraging Tor exit node IPs in a security program:

  1. Blocking Tor Exit Traffic

Many security teams choose to block inbound or outbound traffic involving known Tor exit nodes, especially in environments that do not serve anonymous users. This can be done via:

  • Firewall rules
  • Web application firewalls (WAFs)
  • DNS-based filtering
  • SIEM correlation rules

Keep in mind, this approach may generate false positives if your service intentionally serves Tor users.

  1. Threat Hunting and Monitoring

By monitoring network traffic to and from Tor exit nodes you can uncover suspicious or malicious behavior such as:

  • Beaconing to C2 infrastructure
  • Unauthorized data transfers
  • Anonymized access attempts

This is particularly useful in SOC environments that log DNS queries, proxy traffic, or NetFlow/Zeek logs.

  1. Threat Intelligence Enrichment

Ingesting and enriching alert data with Tor exit node intelligence can improve triage workflows. For example:

  • Flagging alerts from exit node IPs with a higher risk score
  • Adding context during incident investigations
  • Enhancing SOAR playbooks with automated risk annotations

Where to Get Reliable Tor Exit Node Data

There are a few trustworthy sources for up-to-date Tor exit node information:

Considerations and Cautions

Blocking or monitoring Tor exit traffic is not always the right choice. For organizations supporting user privacy, activism, or global accessibility, outright blocking could limit service availability or raise ethical concerns. Any implementation should be aligned with your organization’s risk posture and user profile. Also, IP addresses of Tor exit nodes can change frequently. This means real-time updates and automation are essential if you’re maintaining blocklists or alerts.

Here are a few good resources for advice about developing a Tor security policy:

Final Thoughts

Using Tor exit node IPs as part of your threat intelligence strategy adds visibility into a common vector for anonymous, and potentially malicious, traffic. Whether you’re blocking, monitoring, or enriching alerts, Tor exit node intelligence is a flexible and valuable tool, but it should be used thoughtfully and in context. Not all Tor traffic is malicious, and indiscriminate blocking can lead to unintended consequences. Instead, aligning Tor intelligence with your organization’s risk tolerance and use cases ensures it contributes meaningfully to detection, response, and threat hunting efforts.

For our customers, Tor exit node data can also be integrated directly into existing threat intelligence subscriptions upon request. Contact your account manager to learn more about integration options or additional enrichment.

As part of our commitment to empowering defenders, we offer several free OSINT feeds, one of which includes a regularly updated list of active Tor exit nodes. Click below to sign up for free access.

Leslie Dawn

Technical Account Manager

Leslie Dawn is a Technical Account Manager / Threat Intelligence Analyst at Malware Patrol. Her background of nearly a decade in cyber threat intelligence provides her with a nuanced understanding of threat landscapes and client security needs.

 

?

Malicious Domains: A Cybersec Foundation

Insights

Malicious domains are a foundational layer of threat intelligence and provide critical visibility into where attackers operate online. You can integrate domain-based intelligence across your security stack to: enhance prevention with DNS filtering and firewall rules, improve detection via IDS/IPS systems, guide SOAR-driven response playbooks, and support retrospective threat hunting. Their versatility makes them valuable for organizations of any size because they serve as both a frontline defense and an investigative asset.

Why Domains (Not Just IPs) Matter

Blocking domains offers a more precise and effective way to deny access to malicious infrastructure compared to blocking at the IP-level. Unlike IP addresses, which are often shared across many services and tenants (e.g., cloud providers), domains tend to be unique to the threat actor’s campaign or infrastructure. Blocking a malicious IP risks affecting legitimate services; blocking a malicious domain is more targeted and typically less prone to false positives.

Where to Get Domain Blocklists

There are several sources for malicious domain blocklists:

  • Commercial Threat Intelligence Vendors – They offer curated, regularly updated feeds, often enriched with context like first-seen dates, associated malware families, or related indicators (IPs, hashes, etc.).
  • Open Source Intelligence (OSINT) – Communities such as Abuse.ch, PhishTank, and threat-sharing platforms publish free lists. While useful, they can vary in accuracy, timeliness, and depth of context.
  • Internal Sources – Your organization’s own detection systems (e.g., sandboxing, phishing reports) can be a powerful generator of high-confidence domains worth adding to local blocklists.

Of course, not all feeds are created equal. Freshness, coverage, and enrichment are key to determining how useful a feed is in real-world defensive operations.

The Importance of Freshness and Context

Threat actors continuously evolve their infrastructure. Domains can be registered and weaponized within minutes. That’s why static or infrequently updated lists are of limited use. A quality feed should not only be updated frequently, ideally hourly or daily, but also provide context: Why is this domain flagged? Is it linked to a specific malware family? Was it part of a known phishing kit? When was it first detected?

Rich metadata and context allow security teams to make informed decisions. For example, knowing a domain is associated with a known command-and-control server for a particular ransomware strain might justify more aggressive response actions than if it were merely flagged for spam.

How to Use Malicious Domain Feeds

You can integrate domain intelligence into your environment in several ways:

  • Network Controls – Feed domains into firewalls, DNS security tools, or secure web gateways to block access in real time.
  • IDS/IPS Systems – Tools like Suricata or Snort can inspect DNS traffic for requests to known bad domains and generate alerts or drop packets.
  • SIEMs and SOARs – Enrich alerts with domain context to improve triage speed and accuracy.
  • EDR and XDR – Use domain feeds to flag suspicious outbound connections from endpoints and correlate with other malicious activity.
  • Threat Hunting – Historical DNS logs or proxy logs can be cross-referenced against the feed to identify prior compromise.
Best Practices for Operational Use
  1. Use Multiple Feeds – Every source has limitations in coverage, geography, etc. Selecting feeds from multiple vendors and publicly available offers help to maximize coverage.
  2. Automate Ingestion and Updates – Integrate feeds into your tech stack with automation tools or platforms.
  3. Monitor for Overblocking – Even with domain-level granularity, verify false positives and build feedback loops to tune your blocklists.
  4. Use Enriched Feeds for Decision Making – Context reduces alert fatigue and helps prioritize incident response.

Final Thoughts

Malicious domain feeds are a tried and true foundational element of threat prevention, detection, and response. From stopping phishing attempts to flagging command-and-control activity, domain-level intelligence provides a tactical advantage in defending against today’s fast-moving threats.

Malware Patrol offers domain intelligence designed to meet the needs of security teams who require both breadth and depth. We cover a wide range of threats, from phishing and malware to emerging threats, cryptomining, DGAs, and C2 infrastructure. Our feeds are also enriched with the metadata that helps turn alerts into action. For ease of use, we format the feeds for compatibility with the most popular security tools and platforms.

Ready to add precision and power to your defenses? Contact us to learn more or to request a free trial.

?

How big are your threat data gaps?

See for yourself.

Free Data Evaluation
?

Over 14,000 Ollama Instances Exposed to the Internet

Insights

?

Thousands of Ollama Servers Publicly Accessible

A recent scan conducted by the Malware Patrol team revealed over 14,000 Ollama server instances publicly accessible on the Internet, opening the door to unauthorized use of the models and exploitation of known vulnerabilities. From a sample of 4400, we have found that the top Ollama versions include many outdated releases: 0.5.7 – 13% 0.5.10 – 11.5% 0.5.11 – 7.4% 0.9.0 – 7.0% 0.5.12 – 5.8% Other old versions like 0.6.2, 0.6.5, 0.6.8, and 0.7.0 also make up a significant share. Notably, only ~7% of scanned instances run the latest stable release.

Ollama vulnerabilities

Several real-world vulnerabilities have plagued older Ollama releases:

• CVE-2024-28224 (versions < 0.1.29): A DNS rebinding flaw that lets attackers issue unauthenticated API calls, including file exfiltration, model deletion, or resource exhaustion.
• CVE-2024-7773 (versions < 0.3.13): A ZipSlip RCE that permits arbitrary file write via crafted zip archives, potentially enabling full remote code execution.
• CVE-2024-39721 (versions < 0.1.34): A resource exhaustion attack using /dev/random to cause infinite blocking via the CreateModelHandle.
• CVE-2024-39720 (versions < 0.1.46): An out-of-bounds memory read caused by malformed GGUF model uploads that could crash the service or impact availability.
• CVE-2024-39722 (versions < 0.1.46): A path traversal vulnerability during /api/push that reveals internal file paths to an attacker.
• Model poisoning/theft (version 0.1.34): /api/pull and /api/push lack authentication, enabling injection or theft of entire models

These flaws reinforce the urgent need to update Ollama to its latest version and shield endpoints behind authentication and firewalls.

Model Inventory and Safety Risks

From the same sample, the most common LLMs in use were:

  • deepseek-r1:1.5b – 38.1%
  • deepseek-r1:7b/14b/32b/70b – 33%
  • llama3.2:3b-instruct-q5_K_M – 24.7%
  • nomic-embed-text: latest – 23.6%
  • bge-m3:latest – 15.2%
  • smollm2:135m – 13%

Some of these models, particularly deepseek-r1, are highly vulnerable to jailbreaks. Cisco–Robust Intelligence tests found a 100% jailbreak success rate on DeepSeek R1 across harmful prompt sets.

While these are not Ollama flaws, publicly exposed LLMs that lack proper restrictions can be misused for prompt injection, data leakage, or the generation of malicious content.

GPU or CPU?

While Ollama doesn’t expose hardware metadata directly, we can guess that:

  • Large models like deepseek-r1:70b or llama3.1:8b-instruct likely require GPU-backed hardware.
  • Smaller models like smollm2:135m are likely running on CPU-only systems.
Exposed Computational Power – A Platform for Abuse

The scale of public exposure, over 14,000 Ollama instances, represents a vast amount of accessible compute power. Even if many run on CPUs, that’s a massive distributed network of LLM inference capacity available to anyone. Malicious actors could exploit this to run unauthorized workloads, generate phishing, disinformation, or deep fake content, or carry out automated prompt injection testing.

Exposed AI infrastructure isn’t just a misuse risk; it’s a potential vector for scalable, automated abuse. Much like unsecured WordPress and Joomla instances once powered large botnets in the mid-2010s, open LLM endpoints may soon become the next soft target.

Final Takeaways

Publicly exposing Ollama instances without strong safeguards leaves them vulnerable to:

  1. Software-level exploits in outdated releases.
  2. Model-level failures that compromise safety and data security.
  3. Infrastructure-level inference hardware leakage that may reveal system architecture.
  4. Resource misuse to produce malicious/harmful content at scale.

Recommendations:

  • Update Ollama to the latest stable version
  • Lock down endpoints behind firewalls, authentication, or private networks.
  • Monitor usage to prevent abuse and model misuse

 

Andre Correa

CEO, Malware Patrol

Free Data Evaluation

Start Now
?

The Evolution of C2 Communication: Custom TCP Protocols

Insights

?????

tunneling abuse

Introduction

 

Command-and-control (C2, C&C or CNC) servers are used to remotely manage, control, and communicate with compromised systems within a network. They enable attackers to execute commands, exfiltrate and/or encrypt data for ransom, and coordinate other malicious activities. The effectiveness and reach of malware are significantly hindered, if not altogether eliminated, without C2 communication. According to some industry estimates, 60% to 70% of malware variants rely on C2 servers for communication. This statistic alone should give us an idea of how critical it is for security teams, and their tools, to be able to block and hunt for C2 traffic.

HTTP/HTTPS have traditionally been the go-to protocols for C2 communications over TCP because nearly all organizations rely on web traffic for legitimate purposes. The fact that HTTP/S traffic typically uses common ports (80 for HTTP and 443 for HTTPS), which are often permitted through firewalls, increases the chances of bypassing perimeter security.

Increasingly sophisticated detection methods are helping us to more easily identify well-known C2 communication methods. Unsurprisingly, attackers have adapted in response to our advances. Some of the tools in their updated arsenal include impersonating legitimate protocols, as well as using custom protocols, non-standard protocol/port pairings, and non-application layer protocols. One such technique our Malware Patrol team has noticed is the move toward the use of non-HTTP/S communication over TCP.

In this blog post, we’ll focus specifically on this trend seen in our data by exploring the implications for threat detection & response and providing mitigation strategies. For more general information about C2s, check out our previous blog post and MITRE ATT&CK’s Command and Control tactic topic. 

Command-and-Control Channels: Many, Many TCP Options

 

Attackers’ ingenuity has brought about an impressive variety of C2 communication tactics. Their use varies depending on the capabilities of the malware being deployed, as well as the sophistication of the threat actor, their specific goals, the environment they’re targeting, and the need to avoid detection.

Below is an overview of the most common methods to establish C2 channels. Whenever applicable, we have included details about how TCP might be used to facilitate communication.

Most Used Protocols

  1. HTTP/HTTPS:
    • HTTP/HTTPS are among the most common protocols used by C2 servers.
    • HTTPS adds encryption, making it more challenging to detect malicious activity without decryption and deep packet inspection.
    • TCP-related: HTTP/HTTPS traffic is transmitted over the Transmission Control Protocol (TCP), which ensures reliable delivery of data packets between the client (infected host) and the server (C2 server). TCP’s connection-oriented nature allows for proper sequencing of the communication stream, making it suitable for C2 communications that require reliable data transmission.
  2. DNS:
    • DNS (Domain Name System) is often used for C2 communication because DNS queries and responses are typically allowed by firewalls and proxies. Threat actors can encode commands and data in DNS queries or responses, using techniques such as DNS tunneling.
    • TCP-related: While DNS queries typically use UDP (User Datagram Protocol) port 53 for quick and stateless connections, DNS can also operate over TCP, especially for larger queries and zone transfers. When DNS over TCP is used for C2 communication, it benefits from TCP’s reliability but might be easier to detect due to the less common use of DNS over TCP.
  3. IRC (Internet Relay Chat):
    • Although less common now, IRC was historically popular for C2 communication, especially with early botnets. IRC’s simplicity and ease of use made it a favored choice, but its predictable traffic patterns have led to a decline in its use as defenders became more adept at detecting it.
    • TCP-related: IRC operates over TCP port 6667, providing a reliable connection for the C2 server to send and receive commands and data. The TCP connection ensures that messages are delivered in order, which is critical for maintaining the session’s integrity during the C2 communication.
  4. FTP (File Transfer Protocol):
    • FTP is occasionally used to establish a C2 channel, especially in older or less sophisticated malware. It’s often employed for uploading stolen data from the infected host to the C2 server.
    • TCP-related: FTP uses TCP for establishing connections and transferring files. It typically operates over TCP ports 20 and 21. The reliable data transfer that TCP provides is essential for the successful upload and download of files between the infected host and the C2 server.
  5. Email Protocols (SMTP/IMAP/POP3):
    • Email is used by some C2 frameworks, where commands are delivered via email messages, and the infected host sends its responses back via SMTP, IMAP, or POP3.
    • TCP-related: Email protocols such as SMTP, IMAP, and POP3 rely on TCP for reliable message delivery. TCP’s connection-oriented nature ensures that email messages, including those carrying C2 commands, are transmitted reliably and in order.

Additional Communication Methods

  1. Social Media Platforms:
    • C2 traffic has been observed over social media platforms like Twitter, Facebook, and LinkedIn. Malware can embed commands in social media posts, hashtags, or comments, and the infected host can check these posts for instructions.
  2. Steganography:
    • Steganography involves hiding commands or data within images, videos, or other files, which are then transferred via standard protocols (like HTTP or HTTPS). This method makes detection significantly harder since the payload is hidden within legitimate-looking content.
  3. Peer-to-Peer (P2P) Networks:
    • P2P networks allow infected hosts to communicate with each other or with the C2 server without relying on a centralized server. This decentralization makes takedown efforts more complex and resilient to single points of failure.
    • TCP-related: P2P networks often rely on TCP to establish communication channels between nodes. TCP’s ability to provide error-checking and flow control is beneficial for maintaining stable connections in a decentralized P2P C2 infrastructure.
  4. Tor and Other Anonymity Networks:
    • Tor and similar anonymity networks provide a layer of obfuscation for C2 traffic, making it more difficult to trace the source or destination of the communication.
    • TCP-related: Tor operates over TCP, providing a reliable and encrypted communication channel that obfuscates the source and destination of the C2 traffic. TCP’s role is crucial in ensuring the integrity of the hidden service connections within the Tor network.
  5. Cloud Services:
    • Cloud services like Google Drive, Dropbox, and other legitimate file-sharing services have been exploited for C2 purposes. Commands and exfiltrated data can be stored or transferred through these services, blending in with normal, legitimate use.
  6. Custom Protocols:
    • Advanced threat actors sometimes develop custom protocols specifically designed for their malware. These protocols can be tailored to evade detection by traditional security tools and often use encryption or obfuscation techniques to further complicate analysis.
    • TCP-related: Some custom protocols developed by advanced threat actors may be built on top of TCP to leverage its reliability and connection-oriented features. This allows for stable and dependable C2 communication while evading detection by traditional security tools.
  7. Beaconing:
    • Beaconing is a method where an infected system periodically sends out signals (often very short and difficult to detect) to a C2 server to check in and await further instructions. These beacons can be transmitted via common protocols like HTTP/HTTPS, DNS, or even custom protocols.
    • TCP-related: Beaconing often uses TCP-based protocols like HTTP/HTTPS or DNS over TCP to ensure that the short, periodic signals sent by the infected system reach the C2 server reliably, despite their low visibility.

 

Emerging Trends in C2 Infrastructure

Emerging trends include the use of cloud-based serverless architectures by attackers for C2 infrastructure. This method enhances scalability and complicates the attribution of attacks to specific threat actors. Additionally, some advanced threat groups are experimenting with blockchain technology for C2 communication. Thanks to its decentralized nature, it helps attackers achieve greater resilience and anonymity. 

The Shift to TCP

 

The use of TCP for C2 communications is driven by several factors. It is often chosen due to its lower visibility and detection risks. Attackers exploit TCP’s flexibility to create custom protocols or mimic benign services like SSH or FTP, making it harder for traditional security mechanisms to detect malicious activity. Additionally, using raw TCP helps attackers bypass web proxies that typically monitor HTTP/S traffic for suspicious domains or payloads. TCP also supports the implementation of custom, often encrypted, communication protocols, which further obfuscate the attackers’ activities and complicate defenders’ efforts to analyze and decode the traffic. And last but not least, TCP’s inherent reliability, with error-checking and recovery features, ensures persistent and stable connections, even over unreliable networks.

Real World Examples

It’s easy to speak in generalities about how to improve security, but seeing real world examples brings a much better understanding. They offer specifics that can be applied to security efforts and tools. To this end, we found resources related to how some malware families are making use of TCP, among other behaviors.

APT Groups

Several APT groups have been observed using TCP-based C2 communications. For instance:

  1. APT29 (Cozy Bear)
    • Related Malware Families: WellMess, WellMail
    • C2 Communication: Both WellMess and WellMail are known to use custom TCP protocols to communicate with C2 servers. WellMess can use HTTP, HTTPS, and DNS for its C2 communication, and it supports mutual TLS (mTLS) for secure communications, which is atypical for many malware strains. The mTLS implementation requires both the server and the client to have certificates signed by the same Certificate Authority, making the traffic difficult to detect. Additionally, WellMail has been observed using TCP port 25 (typically associated with SMTP) for C2 communication, though it does not use the SMTP protocol, making it a non-standard use of this port, which can help evade detection.
  2. APT41 (Winnti Group)
    • Malware Family: ShadowPad
    • C2 Communication: ShadowPad is a modular backdoor employed by APT41 that utilizes custom TCP protocols for C2 communication. This malware can operate across multiple protocols, including TCP, HTTP, HTTPS, UDP, and DNS, allowing it to blend in with normal network traffic and evade detection. The flexibility and modularity of ShadowPad make it a potent tool in APT41’s arsenal, enabling the group to perform various operations such as data exfiltration and lateral movement within compromised networks.
  3. APT34 (OilRig)
    • Malware Family: Karkoff
    • C2 Communication: Karkoff, a backdoor used by APT34, employs custom TCP protocols to communicate with its C2 servers. The malware’s use of these protocols, often paired with encryption, allows it to operate under the radar of many network-based detection systems, complicating efforts to intercept or analyze the C2 traffic.

Malware Analyses: A Deep Dive

The following linked articles offer an analysis of the malware family, including its C2 communication methods.

– DBatLoader
– Gafgyt
– NanoCore RAT
– njRAT
– QuasarRAT
– Risepro
– Socks5systemz
– SystemBC
– Tsunami (Muhstik) 

What the Data Says

 

Malware Patrol has been offering a C2 servers addresses data feed for well over a decade. This lengthy history gives us a unique and authoritative perspective on the landscape of C2 communications. For this post, we used our data from August 2024, as well as some historical data, to make observations about the current landscape.

TCP is by far the most prevalent protocol being used. C2 Protocol

The most common ports are the following:

To learn more about these ports, including the services and malware that use them, the resources provided by SANS ISC and SpeedGuide.net are very informative.

We regularly resolve DNS for command-and-control servers and the resulting IPs are added to our Malicious IPs feed. In August 2024, the following IPs were found to be hosting multiple (75+) C2s:

For a big picture view of C2 protocol trends, we looked at Malware Patrol’s data from the last decade (charted below). This visual representation clearly demonstrates the steadily increasing use of the TCP protocol, along with a decrease in the use of HTTP/S. UDP use remains minimal, and FTP so negligible that it didn’t show up in the numbers once they were rounded up.

an image showing the C2 Server Communication Protocol Since 2014 plotted in a colorful graph

 

Further breaking down the data, we see that many of the most active and well-known malware families are predominantly using TCP, with just a few exceptions.

An image of a chart depicting the malware families that are predominantly using TCP

 

For the following families, we have only TCP-based C2 server addresses as of August 2024:

 

Monitoring and Detecting TCP-Based C2 Communications

 

Detecting TCP-based C2 traffic requires some shifts in monitoring strategies, but first of all, and as always, the foundational basics of security should be well implemented. Then, security teams must enhance their visibility into network traffic and apply more sophisticated analysis techniques to identify potential threats. Here are some strategies to consider:

  1. Broaden Network Traffic Monitoring: Ensure that all network traffic, not just HTTP/HTTPS, is subject to scrutiny. This includes monitoring for unusual activity on non-standard ports and paying attention to any TCP connections that do not align with normal network behavior.
  2. Network Segmentation: Implement network segmentation to limit the lateral movement of attackers within the network. By segmenting critical assets and enforcing strict access controls, you can reduce the impact of a compromised system establishing a TCP-based C2 channel.
  3. Strict Egress Filtering: Apply egress filtering on firewalls to restrict outbound traffic. Only allow necessary TCP connections and restrict connections to known IP addresses and ports. This can prevent compromised systems from establishing C2 connections to external servers.
  4. Behavioral Analysis: Implement network behavioral analysis (NBA) tools to detect anomalies in TCP traffic. These tools can identify unusual patterns, such as long-duration TCP connections, unexpected data transfer volumes, or irregular communication intervals, which may indicate C2 activity.
  5. Deep Packet Inspection (DPI): Utilize DPI to inspect the contents of TCP packets. Although attackers may use encryption or obfuscation, DPI can help identify suspicious payloads or metadata within TCP streams that deviate from known legitimate traffic.
  6. Endpoint Detection and Response (EDR): EDR solutions can provide visibility into the processes and connections initiated on endpoints. Correlating endpoint activity with network traffic can help identify suspicious TCP connections originating from compromised devices.
  7. Anomaly Detection with Machine Learning: Machine learning-based anomaly detection systems can be trained to recognize deviations in TCP traffic. These systems can learn what normal traffic looks like and flag communications that fall outside the expected parameters, such as unexpected ports or communication patterns.
  8. Threat Intelligence Integration: Incorporate threat intelligence feeds that provide indicators of compromise (IOCs) related to TCP-based C2 activity. These IOCs can include IP addresses, domains, and port numbers associated with known threat actors, helping to identify malicious connections.
  9. Deception Techniques: Deploy deception technologies such as honeypots and honeytokens to lure attackers into revealing their TCP-based C2 channels. These tools can provide valuable insights into attacker behavior and help identify the methods used to establish C2 connections.
  10. Advanced Threat Hunting: Engage in proactive threat hunting to identify and mitigate TCP-based C2 channels. Threat hunters can search for indicators of TCP-based C2 communications by analyzing network logs, correlating endpoint activity, and utilizing threat intelligence.
  11. Regular Security Audits: Conduct regular security audits to assess the effectiveness of your defenses against TCP-based threats. Audits should include testing your ability to detect and respond to TCP-based C2 communications, as well as reviewing network configurations and access controls.
  12. Employee Training and Awareness: Educate employees about the dangers of phishing and other social engineering tactics used to compromise systems. Many TCP-based C2 channels are established after an initial infection, often delivered via email or malicious websites. By raising awareness, you can reduce the likelihood of a successful compromise.

 

Conclusion

 

Ultimately, the key to mitigating the risk posed by TCP-based C2 communications – or any threat – lies in continuous vigilance, adaptability, and a commitment to staying informed about the latest developments in the threat landscape. As C2 communication tactics continue to evolve, organizations that are proactive in their approach to cybersecurity will be best positioned to detect, respond to, and prevent these emerging threats.

For an additional layer of protection, Malware Patrol offers a C2s data feed that covers the latest malware campaigns and families. It is offered in formats compatible with most industry tools and platforms for simple integration with your existing security stack. We offer a free evaluation. Find out more here.

How big are your threat data gaps?

See for yourself.

Free Data Evaluation

Indicators of Compromise

Frequently Seen C2 Server IPs – August 2024

3.64.4.198
3.67.161.133
3.125.188.168
3.126.224.214
18.158.58.205
18.197.239.109
18.229.146.63
35.158.159.254
154.248.27.182
209.25.141.212

Most Popular C2 Communication Ports – August 2024

23
2404
4444
7443
8443
8848
8888
31337
50050
60000

Leslie Dawn

Technical Account Manager

Leslie Dawn is a Technical Account Manager / Threat Intelligence Analyst at Malware Patrol. Her background of nearly a decade in cyber threat intelligence provides her with a nuanced understanding of threat landscapes and client security needs.

 

?

Tunnel Vision: Looking Out for Malicious Tunneling Use

Insights

?

tunneling abuse

The Trend of Malicious Tunnel Use

In this blog, we will explore malicious tunnel use, the types of cyber threats it enables, and provide some mitigation strategies to fortify your defenses.

Tunneling services, also known as “ingress-as-a-service” offers were originally designed to facilitate secure communication over untrusted networks. Over the past several years they have increasingly become tools of choice for cybercriminals. Offering a cloak of anonymity and encrypted pathways, these services have emerged as an option that allows attackers to obfuscate their activities and bypass conventional security measures. 

Ingress-as-a-service vs. reverse proxies vs. tunnel technologies

It is important to understand the difference between ingress-as-a-service, reverse proxies and tunneling technologies to properly understand their features and limitations, as well as to assess the potential security impacts from their usage.

Ingress-as-a-service platforms, exemplified by services like Ngrok, primarily focus on providing external access to internal resources without requiring complex network configurations. These services typically offer temporary URLs or domain names that route traffic to specific ports or applications hosted on local servers.

In contrast, reverse proxies like NGINX act as intermediaries between clients and servers, providing features like load balancing, caching, and SSL termination. They are more configurable and are often used in production environments to enhance performance and security.

On the other hand, tunneling technologies such as GRE (Generic Routing Encapsulation) and IPSec (Internet Protocol Security) create secure pathways for data transmission over untrusted networks. While they can also facilitate external access to internal resources, they are primarily designed for establishing secure connections between networks or hosts and encrypting data in transit.

Each of these technologies serves distinct purposes and should be chosen based on the specific requirements of the network architecture and security needs.

How Do Tunnel Services Work?

Tunneling or Ingress as a Service services such as ngrok, LocalXpose, and Pinggy, provide a secure way to expose local servers behind NAT (Network Address Translation) and firewalls to the public Internet. They create a tunnel between a user’s machine and a publicly accessible endpoint, allowing for secure communication between the two. This facilitates testing and sharing of services hosted on local machines without the need to register domain names, acquire web hosting services, or go through complex network configurations.

Here’s how the process typically works with a service like Ngrok as “service provider”, its users as “customers,” and an Internet end-user as “Internet user”:

  • The customer installs a command line client software provided by the service provider on their computer or server. This client software allows the service customer to customize their services;
  • Upon installation, the customer must provide credentials to authenticate themselves on the service provider’s platform. These credentials are used anytime the customer requests changes to their service configurations;
  • The customer uses the command line software to configure local ports and protocols to be exposed to the Internet through the service provider’s platform. For example, they can make their port TCP/3306 available to computers outside their private network through the tunneling service;
  • The service provider receives the configuration request and allocates resources that may include a FQDN, protocol and port on its infrastructure;
  • Traffic directed to the allocated FQDN and port over the expected protocol is automatically forwarded to the customer’s computer;
  • The service provider relays data between Internet users and the customer. This traffic can be encrypted using TLS, for example, depending on the customer’s preferences;
  • The real network and geographical location of the customer is hidden and never disclosed to Internet users;
  • Multiple Internet users can access resources exported by the customer at the same time;
  • The service provider also allows for authentication, traffic control and other fine grain configurations by the customer.

 

Tunnel Features and Providers

The primary selling point of the commercial versions of these services . Most claim that the process only takes minutes, sometimes with no download required. Other touted features include system-generated or custom domains, support for multiple protocols, traffic and account logging, GUI or CLI interfaces, and instant SSL certificates. A free option is common, though, these usually only offer a self-expiring domain (15-60 minutes) and may have other limitations related to supported protocols and bandwidth. Paid plans are very affordable, with prices ranging from US$2.50 to $20 per month, depending on the provider and features.

A simple Google search returns results for companies both new and well-established that have entered this ingress-as-a-service market. There is also an abundance of open source do-it-yourself-hosting options. The top result for the term tunneling services is the very popular awesome-tunneling GitHub repository by user anderspitman described as “List of ngrok/Cloudflare Tunnel alternatives and other tunneling software and services. Focus on self-hosting.” The repository lists more than 60 alternatives.

What’s the point of these details? To demonstrate that the options for tunneling are so numerous and technically varied that there is no way to track or block them all. This is why understanding how these services operate is essential for effectively safeguarding networks against potential threats.

Legitimate Use Cases for Tunneling Services

Tunneling services offer a wide range of use cases across various industries and scenarios. Here are some examples:

Development and Testing: Developers can expose their work-in-progress web applications, APIs, and other services to collaborators or clients for feedback and testing without needing to deploy it to a production server.

Remote Access: Enable remote access to devices, such as cameras, IoT devices, or home servers, that are located behind firewalls or NAT routers.

Bypassing Network Restrictions: Tunneling services can bypass censorship or other restrictions by routing traffic through encrypted tunnels, allowing users to access restricted content and services securely.

Penetration Testing and Security Research: Security professionals or security research to simulate attacks, test security controls, or analyze network traffic.

File Transfer and Data Sharing: Facilitate secure file transfer and data sharing between parties by creating encrypted tunnels for transmitting files and data over the Internet.

Not-So-Legitimate Tunneling Use Cases

Over the years, this tool has garnered notoriety for its role in facilitating data exfiltration, phishing, ransomware attacks, and covert communication channels. Here are some threats that can be hosted or assisted via malicious tunnel use:

Command and Control (C2) Servers: Tunnels establish secure communication channels between compromised systems and their command-and-control servers.

Phishing: Phishing websites are hosted on a bad actor’s local machine and exposed to the Internet via a tunnel.

Data Exfiltration: Tunneling services provide a secure and encrypted channel for exfiltrating sensitive data from compromised systems.

Malware Distribution: Attackers can distribute malware by hosting malicious payloads on their local machines and exposing them through a tunnel.

A Current Trend to Watch: C2s Hosted by Ngrok

The inspiration for this blog was an uptick in the number of C2s found hosted at Ngrok domains (*.ngrok-free.app and * ngrok.io) since Q4 2023. The formats vary, but become easily recognizable once you have seen some of the URLs:

tcp://ed0c-2604-a880-800-10-00-bf8-8001[.]ngrok.io:18237/

tcp://ssh.6be0b042ac77[.]ngrok.io:19599/

tcp://4.tcp.eu[.]ngrok.io:11855/

tcp://mailgate.6be0b042ac77[.]ngrok.io:18335/

tcp://pop.2b287b46[.]ngrok.io:18335/

tcp://mailgate.9f50d37b[.]ngrok.io:17888/

tcp://panther-tender-ghost[.]ngrok-free.app:17888/

tcp://4118-209-105-242-243[.]ngrok-free.app:17888/

tcp://4271-1-10-161-113[.]ngrok-free.app:17888/

Two specific malware families collectively account for more than 96% of all observed Command and Control (C2) URLs: njRAT and Nanocore RAT. When looking at activity from October 2023 to April 2024, we noticed a significant decrease in activity in January 2024.

C2 Detections by Month 2023-2024 chart used in the malicious tunneling use blog post 

Malware Family

Percent of Ngrok C2s

 Associated Threat Actor(s), per malpedia
AsyncRAT 0.23% Various, publicly available
DCRAT 0.23% Various, sold on underground forums
Ghost RAT 2.60% EMISSARY PANDA, Hurricane Panda, Lazarus Group, Leviathan, Red Menshen, Stone Panda
Nanocore RAT 29.75% APT33, The Gorgon Group
njRAT 67.08% AQUATIC PANDA, Earth Lusca, Operation C-Major, The Gorgon Group
Remcos 0.11% APT33, The Gorgon Group, UAC-0050

 

To explore options for combatting malicious tunnel use, we submitted some of these C2 URLs to Ngrok for the first time. They have a couple of options for reporting abuse:

  1. Via an email address found on their abuse page
  2. An abuse reporting API introduced on their abuse page: “If you are an institutional fraud prevention firm, we have made reporting content for removal easier and more efficient by providing a direct API integration for filing reports. If you expect to report a significant volume of abuse, please reach out to us directly to inquire about access to integrate directly with our abuse reporting API.”

Their response and subsequent removal were almost immediate. They also followed up to provide details about the API and to welcome more submissions. This speedy, proactive approach to minimizing abuse of their service was impressive and refreshing.

Tightening Your Defenses Against Tunneling Abuse

Organizations can significantly reduce the risk posed by this and similar tools when they understand how malicious actors can exploit tunneling. Protecting against this threat requires a multi-faceted approach that encompasses proactive measures and consistent monitoring:

  1. Network Monitoring and Analysis
    • Implement comprehensive network monitoring to detect unusual outbound connections.
    • Employ network analysis tools that can identify patterns indicative of tunneling or data exfiltration attempts. This includes sudden spikes in data transfer to unfamiliar external addresses.
    • If your organization doesn’t use these services, tagging traffic or totally blocking it can be an effective measure.
  1. Endpoint Detection and Response (EDR)
    • Utilize EDR solutions to detect and respond to suspicious activities on endpoints, including the unauthorized installation or execution of tunneling tools.
    • Configure EDR systems to alert administrators of attempts to modify firewall settings or establish connections that are indicative of a tunneling service being used.
  1. Application Whitelisting
    • Enforce application whitelisting policies to prevent the execution of unauthorized applications unless it is approved for legitimate use cases within the organization.
    • Regularly update whitelists to include new legitimate tools and review the list to remove any that are no longer needed or pose a security risk.
  1. User Awareness and Training
    • Educate employees about the risks associated with tunneling services and the potential for their misuse. Include information on how to recognize phishing attempts or social engineering tactics that could lead to the installation of such tools.
    • Conduct regular training sessions to improve the security awareness of staff, focusing on the importance of reporting suspicious activities.
  1. Strict Access Controls
    • Implement strict access controls and segment networks to limit the ability of an attacker to move laterally, even if they manage to establish a tunnel.
    • Use multi-factor authentication (MFA) and strong password policies to reduce the risk of credential theft and unauthorized access to systems that could be used to deploy a tunneling tool for malicious purposes.
  1. Regular Security Audits and Penetration Testing
    • Conduct regular security audits and penetration testing to identify vulnerabilities that could be exploited to install and use these tools maliciously. This should include assessments of both internal and external defenses.
    • Review and update incident response plans to include procedures for detecting, isolating, and removing unauthorized tunneling services.
  1. Collaboration and Sharing of Threat Intelligence
    • Participate in industry-specific threat intelligence sharing platforms to stay informed about the latest tactics, techniques, and procedures (TTPs) used by threat actors, including the misuse of tunneling services. Share insights and indicators of compromise (IoCs) related to unauthorized services use with peers and cybersecurity communities to aid in collective defense efforts.

In Conclusion

As the digital landscape continues to evolve, malicious tunnel use remains a persistent and evolving threat. However, by taking the time to learn about this threat, remaining vigilant, implementing robust security measures, and fostering a culture of cybersecurity awareness, businesses can safeguard their networks and data against the clandestine activities of malicious actors.

While various methods exist to counter this threat, the use of threat intelligence offers an immediate, proactive approach to detection and mitigation. IOCs can help teams swiftly identify tunneling connections and associated activity of known phishing campaigns and C2 infrastructure. For more information about Malware Patrol’s threat data feeds that cover this kind of activity, click here.

 

Leslie Dawn

Technical Account Manager

Leslie Dawn is a Technical Account Manager / Threat Intelligence Analyst at Malware Patrol. Her background of nearly a decade in cyber threat intelligence provides her with a nuanced understanding of threat landscapes and client security needs.

 

How big are your threat data gaps?

See for yourself.

Free Data Evaluation
?

Honeypots: Simple Tools that Supercharge Cybersecurity

Insights

?

honeypots

Using Honeypots for Threat Intelligence Collection

Staying ahead of malicious actors is a constant challenge. As threats continue to increase in complexity and sophistication, organizations must adopt innovative approaches to safeguard their digital assets and sensitive information. One such approach is the use of threat intelligence derived from honeypots. These deception technology tools offer a unique and invaluable insight into the tactics, techniques, and procedures employed by cybercriminals, providing organizations with the upper hand in the ongoing battle against attackers.

Honeypots are virtual or physical decoy systems designed to mimic legitimate services or applications. They can be strategically placed within an organization’s network to attract cyber attackers, diverting their attention away from actual critical assets. Another option, for research and threat intelligence gathering, is setting them up in distinct geographies via various service providers. No matter how they are deployed, the beauty of honeypots lies in their ability to capture and analyze timely data about incoming attacks without putting actual systems at risk. This data, often referred to as “honey data,” sheds light on emerging attack vectors.

1. Real-time Visibility into Attacks: Using honeypots for threat intelligence offers a front-row seat to ongoing cyber attacks. By emulating vulnerable systems and services, these traps attract a wide range of attackers attempting to exploit perceived weaknesses. The interactions between attackers and honeypots yield a wealth of information about attack methodologies, malware variants, and even potential zero-day vulnerabilities. This instant visibility enables security teams to detect and respond to threats swiftly, reducing the window of exposure and potential damage.

2. Understanding Attack Tactics: Through honeypots, organizations gain an intricate understanding of the tactics, techniques, and procedures (TTPs) employed by threat actors. Analyzing the behavior of attackers within the controlled environment of honeypots unveils their strategies, tools, and evasion techniques. This knowledge is crucial for anticipating future attacks and enhancing cybersecurity measures.

3. Prioritization and Resource Allocation: With the data derived from honeypots, organizations can effectively prioritize their cybersecurity efforts. By identifying the most prevalent attack vectors and targeting vulnerable systems, security teams can allocate resources where they are needed most. This strategic approach ensures that cybersecurity investments are optimized to mitigate the highest risks, leading to a more resilient defense posture.

Types of Honeypot Attacks

There are many different kinds of honeypots. They range from low interaction to high interaction, and can mimic just about anything: IOT devices, SSH, WordPress, databases, ICS, and APIs, to name a few. By emulating vulnerable systems, services, and applications, honeypots attract attackers and capture their activities in a controlled environment. Here are some of the key types of attacks that you can effectively detect by utilizing honeypots for threat intelligence:

  1. Break-In Attempts: Honeypots are adept at capturing break-in attempts, where attackers try to gain unauthorized access to systems or networks. By mimicking enticing entry points, such as open ports or weakly protected services, honeypots can lure attackers and record their attempts to exploit vulnerabilities.
  2. Malware Propagation: Honeypots can also detect attempts to spread malware across networks. Attackers often use compromised systems as launchpads for distributing malware to other targets. Honeypots, acting as seemingly vulnerable hosts, attract malware propagation attempts and allow researchers to analyze the behavior and characteristics of the malicious code.
  3. Port Scanning and Reconnaissance: Cybercriminals often perform port scanning to identify potential entry points into a network. Honeypots, configured with various open ports and services, can capture these scanning activities. The data collected provides insights into the attacker’s scanning techniques and the extent of their reconnaissance efforts.
  4. Credential Theft and Brute Force Attacks: Honeypots can mimic login pages and services to attract attackers attempting to steal credentials through phishing or brute force attacks. By capturing these login attempts, organizations can gain insights into the attackers’ methods and strategies for credential theft.
  5. Botnet Activities: Honeypots can act as alluring targets for botnets seeking to recruit new compromised hosts. By engaging with these botnets, researchers can gain insights into command and control mechanisms, as well as the scale and distribution of the botnet infrastructure.
  6. Distributed Denial of Service (DDoS) Reconnaissance: Attackers often conduct reconnaissance to identify potential targets for DDoS attacks. Honeypots can capture these reconnaissance activities, shedding light on the attacker’s infrastructure and the potential targets they are assessing.
  7. Exploitation of Vulnerabilities: Honeypots can replicate systems with known vulnerabilities, inviting attackers to exploit these weaknesses. This allows security teams to analyze the techniques used by attackers to compromise systems and the specific vulnerabilities they target.
  8. Insider Threat Detection: Honeypots can also be used to detect insider threats, where authorized individuals misuse their privileges to compromise systems or steal sensitive data. By tracking unusual activities within the controlled environment of a honeypot, organizations can identify potential insider threats.
  9. Zero-Day Exploits: Honeypots can be configured to mimic specific software versions and configurations that may be vulnerable to zero-day exploits. Detecting attackers attempting to exploit unknown vulnerabilities provides crucial insights into emerging threats.
  10. Command and Control (C2) Communications: Honeypots can capture communications between compromised systems and command and control servers. This helps researchers understand the communication protocols, techniques, and infrastructure used by attackers to control compromised hosts.

Introducing Malware Patrol’s Intrusion Insights Feed

Our newest offering, Intrusion Insights Data Feed, is derived from honeypots strategically deployed across the globe. Until now, our decade-old honeynet has been used for internal purposes only. We are thrilled to finally be sharing this information with our customers. The JSON-formatted data feed, updated every 15 minutes and spanning the last 36 hours of activity, provides a treasure trove of insights into live, ongoing attacks against cyber infrastructure.

Conclusion

At Malware Patrol, we believe that some of cyber security’s most mature and commonly used tools still offer high ROI and impacts well beyond those of their contemporary, super-hyped counterparts. The use of honeypots for threat intelligence collection is a dependable classic. The basics are always in style around here!

With their ability to attract, capture, and analyze attacks, honeypots provide a unique and incomparable vantage point into the strategies employed by malicious actors. Embrace the power of using honeypots for threat intelligence and request a free evaluation of our Intrusion Insights feed today.

Leslie Dawn

Technical Account Manager

Leslie Dawn is a Technical Account Manager / Threat Intelligence Analyst at Malware Patrol. Her background of nearly a decade in cyber threat intelligence provides her with a nuanced understanding of threat landscapes and client security needs.

 

?

Finding the Best Threat Intelligence Vendor

Insights

?

Everyone in our line of business wants to be considered the best threat intelligence vendor. The task of gathering and producing top-notch cyber threat intelligence (CTI) is harder than you might think, however. Here are a few reasons why:

(1) It’s literally impossible to gather information about every threat, so, CTI vendors have to accept a suspense-ridden level of imperfection. All this while knowing that it takes only one incident to cause great damage to our customers.

(2) The proper – or at least, consistent – attribution and categorization of threats is a mindblowingly-tedious-bordering-on-futile task. (Have you seen how many aliases there are for the Lazarus Group?) But without some attempt of doing so, crucial context, like TTPs, is lost.

(3) Known, active indicators number in the billions. And threat actors constantly swap out their infrastructure. Keeping this amount of data current and false positive-free is a never-ending job that requires a delicate balance of automation and human quality control.

As for #1, we threat intelligence vendors can only strive to do our best, and avoid false advertising because no one likes a liar. The second item on this list requires a MacGyver-like skillset, a super knowledgeable cybersecurity team, and a LOT of lookup tables. Number three, while challenging, is an area where threat intelligence vendors can have some control and differentiate themselves.

For example, at Malware Patrol, our systems visit each indicator at least once per day to verify its status. Inactive = Bye-Bye. And as a rule, we have never included publicly available data in our feeds unless it can be verified by our own proprietary systems. While this limits our data feed sizes, as far as we’re concerned, a random list of malicious IPs is just that. Without confirmation or context, there is no confidence. The result of applying our “quality over quantity” mantra is Malware Patrol’s actionable, high-confidence threat intelligence feeds.

Quality over Quantity or It’s a Numbers Game?

Here’s where we are going to contradict ourselves, a little. Or maybe it’s more of a tangent.

Even though our team works hard to make Malware Patrol one of the best threat intelligence vendors out there, we have been repeatedly forced to concede that cyber criminals are as determined, resourceful, and intelligent as we are. New campaigns, threat actors, and TTPs are disclosed daily. Each advance on our side is met with one on theirs. It is the ultimate Olympic table tennis match.

The “constantly changing threat landscape” reality forces cybersecurity companies to re-evaluate, innovate, and evolve our offerings probably more frequently than in any other industry. Malware Patrol is no exception.

During a recent brainstorming session, our team decided to “play the numbers game” in order to increase our threat coverage. To accomplish this without risking the quality of our data, we added a separate open source intelligence offering, described below. Our reasoning was that there is really no match for the breadth and timeliness of data gathered and shared by a global community. With some caveats, of course! Keep reading.

 

OSINT: You (Don’t) Get What You (Don’t) Pay For

There are several undeniable benefits of using OSINT as a threat intelligence vendor and practioner. It can help to improve the completeness and speed of threat intelligence. This is particularly important in the case of rapidly evolving threats, where timely intelligence can be critical. By leveraging the knowledge and work of many people, OSINT can help to fill in gaps and provide insights that would otherwise be unavailable.

However, there are some major challenges that come with using open source intelligence. The most obvious of these is the vast amount of data available. It can be mission impossible to sift through so much information, i.e., looking for a needle in a haystack. And who has time for that these days?

And when OSINT collectors are not looking for specific pieces of information or indicators, but rather trying to gain general insights into a particular topic or issue, the data set is potentially even bigger and without a doubt more complex to analyze. It requires being able to quickly scan large amounts of data and identify patterns or trends.

As we have previously mentioned, it is difficult to find reliable sources of information and OSINT is no exception. Because anyone can contribute to an open source, the quality of the information can vary greatly. There is no guarantee of accuracy and no support.

It can also be difficult to access the information contained within some OSINT sources. Often, the data is stored behind paywalls or requires special login credentials. Additionally, some types of data (such as video or audio) may not be easily accessible without specialized software or hardware.

As a cybersecurity professional, it is your job to protect your organization using your team’s technical abilities paired with your finite financial resources. As such, it behooves you to thoroughly evaluate everything used in your cybersecurity efforts, from outsourced services to tools and OSINT.

You may have guessed this next part already: paid threat intelligence services help eliminate these challenges. As a threat intelligence vendor, we specialize in and dedicate resources to the challenges listed above. That makes them our problems, not yours. Put simply, it is our job to “make” CTI and try to be the best threat intelligence vendor.

 

Open Source Intelligence (OSINT) the Malware Patrol Way

So, now it is time to (re)introduce our three new OSINT-based data feeds. They contain curated data derived from our geographically diverse network of honeypots as well as trusted third-party sources. And to be clear, these feeds will remain SEPARATE from our commercial data feeds.

  • High Risk IPs: Addresses involved in a range of malicious activities, such as spam, break-in attempts, malware distribution, botnets, and command-and-control communications.
  • Risk Indicators: A variety of threat related IoCs, including: MD5, SHA1, and SHA256 hashes, email addresses, cryptocurrency addresses, and CVEs.
  • Tor Exit Nodes: Addresses of active Tor exit nodes as reported by the Tor Project. Frequently involved in malicious activities, it is advisable to monitor, if not block, traffic from these IPs.

Here’s how we are doing OSINT the Malware Patrol way:

  • We enrich the feeds with decision-enhancing context that may include the associated malware family, threat actor, article links, and any other available metadata.
  • Entries are removed at regular intervals to make sure the data stays fresh.
  • Our team manages the data quality and sources closely.

Register for Malware Patrol’s OSINT feeds here.

 

Conclusion

To bring this all to a conclusion, we believe that being the best threat intelligence vendor does not simply mean having more indicators than the competition. Instead, an organization that provides an honest, accurate assessment of their data’s coverage upfront is less likely to over promise and under deliver. A laser focus on the quality of their threat intelligence is also crucial.

When combined with the willingness to constantly and creatively adapt, the likelihood is much higher that the provider can be a real partner in your organization’s cybersecurity efforts. Using OSINT or other less traditional collection methods to improve threat coverage is just one example of the kind of dynamic, adaptable threat intelligence vendor you should look for in sea of options now available in our industry’s market.

?

New OSINT Feeds: High Risk IPs – Risk Indicators – Tor Exit Nodes

Insights

?????

OSINT feed

Sharing is Caring

To our industry’s credit, there are many good OSINT feeds and data sharing platforms. Even better, they are relatively easy to find. A simple Google search for open source intelligence (OSINT) threat feeds or open source cybersecurity tools will yield many, many results. This is really a testament to the goodwill and collaborative spirit of the cybersecurity community.

Some examples of data sharing options include DHS CISA AIS, AlienVault OTX, and Abuse.ch, just to name a few. High quality open source security tools (TIP, SIEM, SOAR), such as MISP, are also readily available to help your organization utilize intelligence of all kinds.

Avoid Analysis Paralysis

As usual, there is a however to this good news: the number of available resources can be overwhelming. When faced with so many options, it can be difficult, or time consuming at the very least, to select, evaluate, and implement free intelligence and tools in your organization. Without some parameters or pre-defined goals, your research efforts may fall short.

If you are about to embark on this journey, we would like to offer a few suggestions about how to structure and organize your OSINT search process:

1) Determine your organization’s intelligence needs and priorities.

    • Review current goals or roadmaps related to threat intelligence to clarify and prioritize your needs.
    • Ask your security team – and other relevant stakeholders – for their input:
      • What are your data gaps? For example, what caused your last incident, and could it have been prevented with some additional type of data?
      • Do you know the tactics, techniques and procedures (TTPs) of threat actors targeting your organization’s industry and could OSINT help prepare for these specific kinds of attacks?
      • Is there a paid intelligence resource or tool you are unable to afford but really want? Maybe it is worth looking for a free/open source alternative?
      • Also consider other topics specific to your organization, industry, security environment, geopolitical events, and so on

2) Research and compile a list of potential sources.

    • Use one of the industry’s go-to OSINT resources as a starting point.
    • Ask around – nothing beats a firsthand recommendation.
    • Search for curated lists of OSINT feeds/sources. (Be mindful of the age and potential bias of the information source.) We found these helpful articles during our research: SOCRadar, Spiderfoot, Sunny Valley Networks and SENKI. GitHub rarely disappoints.

3) Evaluate and rate the sources for final decision making.

    • Criteria to consider:
      • Data quality – Are you familiar with the organization that generates it? Or how a crowd-sourced data community is managed, members vetted? Is the data rated or otherwise confirmed by group members in some way? How is it aged?
      • Update frequency (if applicable) – Hourly, Daily, Monthly, Other?
      • Coverage – Geography? Market vertical?
      • Aggregation/Efficiency – Does the provider aggregate multiple sources into one?
      • Ease of integration/retrieval – Do your tools ingest data in the formats provided? Can collection be easily automated or otherwise added to your team’s tasks without being burdensome?
      • Context – Does the data include context on the incident or campaign?
      • Licensing – Does it allow for your intended use of the data? Open source does not automatically mean the data can be used freely for commercial purposes.
    • Check for overlap with your current resources to prevent overloading your tools with repetitious data. For example, MISP has a Feed overlap analysis matrix. Other tools offer similar functionality.
    • Consider the reputation of the provider and any other applicable factors from your research to determine the confidence level you feel comfortable applying to the data:
      • High confidence – Decisions and alerts will be based on this data source
      • Medium confidence – Indicator must be confirmed by another source before acted upon
      • Low or N/A confidence – Not used for alerts or blocking, but useful for research and as a confirmation of an indicator’s maliciousness
    • Use all the above information to make a final list. Review and decide.

4) Decide which tool(s) and/or process(es) will use the OSINT feed or unstructured data and for what purpose. (Use details from step 1 to help with this.)

    • Integrate the threat data into your security tool(s) and processes. Set up automatic downloads and/or assign manual tasks.
    • Update documentation/SOPs to include your new resources.
    • Inform security teams and provide any necessary training on how to use/interpret the data.
    • Schedule a review (30, 60, 90 days) to evaluate the usefulness and quality of the data.
    • Wash, rinse, repeat to keep expanding your OSINT at regular intervals.

OSINT Feeds from Malware Patrol

If acquiring open source intelligence is a goal for your organization, we invite you to check out Malware Patrol’s free OSINT feeds. The curated data is derived from our internal research well as trusted third-party sources.

  • High Risk IPs: Addresses involved in a range of malicious activities, such as spam, malware distribution, botnets, and command-and-control communications.
  • Risk Indicators: A variety of threat related IoCs, including: MD5, SHA1, and SHA256 hashes, email addresses, cryptocurrency addresses, and CVEs.
  • Tor Exit Nodes: Addresses of active Tor exit nodes as reported by the Tor Project. Frequently involved in malicious activities, it is advisable to monitor, if not block, traffic from these IPs.

Here’s how Malware Patrol does OSINT:

  • We enrich the feeds with decision-enhancing context such as the associated malware family, threat actor, article links, and any other available metadata.
  • Entries are aged and removed at regular intervals to make sure the data stays fresh.
  • Our team manages the data quality and sources closely.

To find out more about our OSINT feeds, visit our Enterprise page.

 

OSINT feed
?

Malware Hashes and Hash Functions

Insights

???

An Introduction to Malware Hashes and Hash Functions

Malware hashes are found everywhere in our industry. And for a good reason. They very efficiently help identify malware samples and standardize the exchange of information among researchers, to name a couple of use cases.

The topic of hash functions is an enormous and complex one. There are dozens of them, if not more, with significant variations in base computation methods, applications, security, and outputs. So, for time and sanity’s sake, we will only discuss hashes in the context of information security and cybersecurity.

What is a Hash Function?

A hash function is an algorithm that takes an arbitrary input of bits of any size and produces a unique, fixed-size output. The output is known as a hash, hash code, hash sum, hash value, checksum, digital fingerprint, or message digest. A hash calculated for a malware file is a malware hash.

The hashing process is mathematically guaranteed to only work in one direction – from a string of bits of varied size to a fixed-size output – and cannot be reversed. And the output’s uniqueness is meant to be absolute, that means no two distinct inputs can generate the same output; modifying only one bit of the input generates a completely different hash sum.

It Takes All Kinds

The most common hash functions are MD5, SHA-1, SHA-256, and SHA-512. Their main purpose in cybersecurity is to generate unique identifiers for their inputs, such as malware files, that can be cataloged, shared or (re)searched with relative ease.

Other types of hash functions are used for granular identification, grouping, comparison, and analysis of malware. For example, fuzzy hashes were developed to identify files that share characteristics or have been modified only slightly. One common type of fuzzy hash is SSDEEP.

Are Hashes Really Secure?

It depends. Some hashes once believed unbreakable are now considered to be insecure. This can mean that it’s possible to reverse, generate a collision (create the same hash value for two different inputs) or otherwise manipulate the algorithm and/or its output.

Of the hashing functions previously mentioned, the MD5 is no longer considered secure. According to some sources, the SHA-1, SHA-256, and SHA-512 functions can also be considered insecure, depending on the intended use.

For protecting data, like passwords, strong hashing algorithms are necessary. A common-sense best practice is to make sure that any hash function you are considering meets the security requirements of your 1) use case and 2) organization/industry.

How are Hashes Used?

Hash functions have many uses in cybersecurity and elsewhere. Their overall most popular uses are in the areas of data confidentiality and integrity as well as authentication and non-repudiation. The following characteristics make them ideal for the job:

1) They are not reversible
2) The output is unique and of fixed length
3) They significantly – exponentially even – reduce the amount of original data they represent.

A few examples of uses that rely heavily on the features above include:

Hash table – A data structure that utilizes hash values to represent large amounts of data or large files. Both the reduction in the amount of data to query and the quick cross-referencing facilitated by unique identifiers allow for rapid data lookup.

File integrity – A hash is computed and then compared with the stored hash of the original data. If the two values match, the data has not been modified.

Malware Hashes and Hash Functions

Password security – User-created passwords are run through a hashing algorithm and the hash is stored instead of the plaintext version. This protects passwords in the event of unauthorized access. Any password entered for logging in is hashed and compared with the stored hash for verification purposes.

Hashes in Cybersecurity

In the cybersecurity industry, hashes are primarily used to identify, share, and group malware samples. One of the first use cases for them was in antivirus (AV) software. AVs use a database of malware hashes as a sort of blocklist. During the scanning process, the blocklist is compared against the hashes calculated for the executable files on the system. A match indicates a malicious file is present.

A drawback to this detection method is that the list of known malware hashes is already huge and grows larger every day. This amount of data can easily overload the storage and processing capacity of personal computers, IDS/IPS and firewalls. A best practice when using blocklists of any kind is to make sure your threat intelligence is fresh, not full of inactive indicators or false positives. Quality over quantity!

As the industry evolved, security tools began to additionally make use of heuristic/behavioral analysis to detect malware. Without this capability, polymorphic malware, for example, would go undetected.

Beyond the AV

Malware hashes have several uses beyond signature-based detection tools. They standardize and simplify the exchange of IoCs (Indicators of Compromise) among researchers. (And we all know that our malware naming conventions are far from standardized!) This list of hashes from a VirusTotal search result probably looks familiar to you:

malware hashes

And just as AV software uses malware hashes to look for infected machines, threat hunters and SOC teams use them for the same purpose. In fact, being able to search for a hash value instead of looking for evidence of the malware itself saves a lot of time. Having quality malware hashes data in a TIP or SIEM to assist with investigations is invaluable.

Researchers utilize hashes to analyze and compare malware, such as with fuzzy hashes that try to find similarities between samples. Machine learning models can use perceptual hash data from screenshots, for example, to learn how to recognize screenshots of web pages that have similar content, such as phishing sites.

Conclusion

While hashes have limitations when used for perimeter-based malware detection, they are still extremely helpful. It’s all about layered security and not ever depending on one tool or type of indicator to protect your network. As for the exchange of IoCs, threat research, and machine learning, hashes have a multitude of applications. Some of these are still new and very promising.

If you want to learn more about hashes, there are many good resources out there. Some articles we encountered during our research are listed below:

  • Calculate Your Own Hashes with CyberChef: https://gchq.github.io/CyberChef/
  • https://blog.jscrambler.com/hashing-algorithms
  • https://resources.infosecinstitute.com/topic/threat-hunting-for-file-hashes-as-an-ioc/
  • https://www.gdatasoftware.com/blog/2021/09/an-overview-of-malware-hashing-algorithms
  • https://www.sentinelone.com/cybersecurity-101/hashing/
  • https://blog.securitybreak.io/fifty-shades-of-malware-hashing-3783d98df59c

 

Looking for Quality Malware Hashes Data?

Malware Patrol offers the three hashes feeds below. You can request a free evaluation here.

1) Malware Hashes Feed. Includes MD5, SHA-1, and SHA-256 hashes, as well as classification of verified active malware and ransomware samples.

2) Risk Indicators Feed. Composed of a variety of IoCs, including MD5, SHA-1, and SHA-256 hashes, email addresses, cryptocurrency addresses, and CVEs. The curated data in this feed is derived from our network of honeypots as well as trusted third-party sources.

3) Phishing Screenshots & Perceptual Hashes Feed. Malware Patrol collects phishing URLs from various sources – crawlers, emails, spam traps, and more – to ensure coverage of the most current campaigns. We take screenshots of the phishing pages and the corresponding perceptual hashes are calculated. These can later be compared with hashes of other screenshots to determine a match likelihood.

?

MISP Project – A free & robust open source threat intelligence platform

Insights

?????

MISP and Malware Patrol logos on a image with a grey and white background used for the misp blog post

The MISP project is a free open source threat intelligence platform (TIP) that stores, analyzes, and shares information about malware.

It is co-financed by the European Union and a wide variety of organizations, including law enforcement agencies, private companies, and academic institutions, rely on MISP.

The platform has several features that make it an invaluable tool. For example, a searchable database of known malware samples allows organizations to find information on specific threats quickly. In addition, MISP includes a variety of other options such as a collection of OSINT feeds, API access, and integration with other security products.

Another reason why MISP is a crucial tool for malware researchers and security professionals is that it allows them to share information about new threats and samples quickly. This helps researchers keep up with the latest threats and allows them to work together to better understand and protect against new attacks.

MISP Threat Sharing Project Features

“Support” refers to the ability of a software or service to integrate with MISP. This is accomplished through an API or by using a MISP-compatible format. Many different types of industry software and services offer support. These include but are not limited to various SIEMs, TIPs, and incident response tools.

MISP modules are expansion modules that can be used to add new functionality to MISP. They are developed by the MISP community and are available for anyone to use. There are currently over 40 MISP modules available! They cover a wide range of topics, such as malware analysis, incident response, and threat intelligence. For example, the platform can use Splunk for log analysis or TheHive for incident response.

For customization purposes, MISP has flexible taxonomies for describing and tagging events. There is also support for exporting data in the MISP format or in STIX/MAEC formats, as well as an advanced correlation engine to identify relationships between indicators. Hierarchical tag inheritance is yet another feature.

To support its mission of enabling the sharing of information, the tool allows the creation of private groups for sensitive information. This is ideal for sharing information about new threats and vulnerabilities within a company so that everyone can be aware and take appropriate action.

pyMISP

The pyMISP project is an open-source toolbox written in Python 3 and serves as the official library for the MISP project. It is designed to support the MISP threat intelligence platform by providing a flexible and powerful platform for ingests, exports, queries, and analyses. The project is led by Alexandre Dulaunoy (@adulau), who is also the main developer of the MISP software.

pyMISP is released under the GNU Affero General Public License v3.0. The toolbox currently contains 19 different tools, each of which performs a specific function related to MISP.

Some of the more popular tools included in pyMISP are:

  • Ingest: This tool allows you to ingest data from a variety of sources, including text files, JSON files, and even generic SQL databases. Export: This tool allows you to export data from MISP in a variety of formats, including CSV, XML, and HTML.
  • Query: This tool allows you to perform simple queries against the data in MISP. For example, you can use this tool to search for all incidents that contain a specific IP address.
  • Analysis: This tool allows you to perform various analyses on the data in MISP. For example, you can use this tool to generate a timeline of all events in MISP.

Training Options

There are many super thorough training videos on YouTube. The official options, linked below, are provided by the team at CIRCL (Computer Incident Response Center Luxembourg), the creators of the platform. A YouTube search will yield even more results for MISP training sessions and usage tips.

Conclusion

Overall, the MISP Threat Sharing project is a powerful and feature-rich threat intelligence platform. The API and impressively long list of current integrations and services make it a super flexible TIP/tool that any team should consider if they have a need for one.

Malware Patrol offers several feeds formatted for MISP, as well as the option to sync with our MISP servers. The feeds available include:

You can request a free evaluation of our MISP services here. If you’re already a customer using MISP, we have a handy configuration guide available.

?

DNS Sinkholes: Detect and Protect

Insights

?

Bots don’t sleep, ransomware finds new ways to infiltrate systems and yesterday’s defenses may be ineffective tomorrow. Cybersecurity requires vigilance. But vigilance alone won’t suffice. That’s why threat researchers and enterprise security analysts need effective tools to detect malware indicators and protect systems. Luckily, DNS sinkholes do both.

What’s a DNS Sinkhole?

In the Internet’s vast highway of connections, DNS sinkholes redirect network traffic. They intercept packets attempting to reach a certain address and reroute them. Consequently, both good and bad actors use sinkholes.

In cybersecurity, researchers use their power for good.

For example, remember the Wannacry ransomware attack? It affected more than 200,000 computers in 150 countries. Do you know what stopped its spread? A sinkhole. A security company deployed it. That sinkhole slowed the attack’s progress, giving businesses time to install a patch that inoculated their machines.

To be honest, they had a little help. Wannacry had a built-in fault that left it vulnerable. Its creators hardcoded a single static domain name into the malware. It was supposed to be a kill switch if they wanted to stop its spread. One problem: the static domain was left available for registration. So for less than $11 to register the domain and with the infrastructure and bandwidth to support a massive sinkhole, a cybersecurity researcher on vacation flipped the switch and funneled all that traffic into a waiting abyss.

It bought just enough time to get in front of the spread and contain the threat. Most DNS sinkholes operate a bit differently of course. Administrators design them to find a broad array of threats, not just one.

Using DNS sinkholing, threat researchers capture, monitor and analyze malicious Internet traffic in real time. Certainly one of the most obvious indicators of maliciousness is an attempt to connect to a known botnet command and control (C2) server. When users attempt to connect to an identified C2, a false, controlled IP address is returned and the traffic actually goes to a sinkhole, a server that an administrator controls.

Why Use a Sinkhole?

Once traffic goes to a sinkhole, threat researchers can tell which computers may be infected and notify users. Not only that – seeing how machines communicate with a malicious domain allows threat researchers to craft defenses that counter those tactics, techniques and procedures (TTP).

Then they can share the collected intelligence. This effectively neutralizes certain attack TTPs because over time the defense becomes an industry standard. After that, though every company may not adopt the defense straight away, they now have the ability to do so.

Companies differ, but often the strategies used to attack them don’t. It’s one advantage we’d do well to exploit.

For this reason, white hat sinkhole IP addresses are a useful tool for both reactive and proactive cybersecurity. With the valuable data contained in them, threat researchers can detect potential malware, protect their networks and contribute to the safety of the entire Internet.

How Can You Start Using DNS Sinkholes?

If you want to find DNS sinkholes, there are a few tested methods for identifying them. First, try reviewing the WHOIS nameservers information and SSL certificates. These are probably the two most straight-forward sources. Because of this, you’ll probably find more security companies sinkholing for research purposes.

On other side of the spectrum, you can find instructions for setting up a sinkhole with some basic research. Just make sure that you use a trusted source or software solution. Whichever method you choose, DNS sinkholes are an infosec tool worth acquiring to detect, protect, and anticipate the next threat.

By Tenea D. Johnson

Founder, Progress By Design

?

What is Ransomware?

Insights

??

 

Malware Patrol’s CEO Andre Correa was recently interviewed by Dana Mantilia from Identity Protection Planning. They discussed the basics – and more – about ransomware:

  • What is Ransomware?
  • What should a company do in the case of an attack?
  • Why is paying ransom a bad idea?
  • Why has cryptocurrency became the main payment method for ransom?
  • How do you recover from an attack?

This is a worthwhile watch if you have unanswered questions or want to review what you already know. In the event that your organization suffers (or has suffered) an attack, you will have some difficult decisions to make. The more you can prepare yourself and your team for how to respond, the better your recovery will be.

An attack impacts each organization differently, and now double extortion ransomware has complicated the simplistic “never pay” stance that many in the industry take. These considerations make it important to seek information from a variety of sources. You will need to find the solutions that fit your organization’s situation.

Not surprisingly, we want to emphasize the importance of using threat intelligence to help prevent and detect threats in your environment. Securing your organization is simply easier when you know what you are supposed to be blocking or hunting!

Malware Patrol offers three data feeds that specifically cover this threat: 1) URLs known to be hosting ransomware (or the malware that is used to open access to network for the ransomware install), 2) Command & Control Servers and 3) DGAs, the URLs/domains from which malware and ransomware receive their instructions and/or to which they send stolen data.

 

?

Best Practices to Protect Against Ransomware

Insights

???

Everyone wants to know how to protect against ransomware – 2021 is the year of ransomware! The Colonial Pipeline attack shutdown a major oil distribution line and held it for ransom. Kaseya, a software vendor, was targeted with a $70 million ransom in bitcoin on July 5th(1). Both of these incidents and others are still ongoing, but shouldn’t the real focus be on how to not become the next headline?

The cybersecurity industry is robust and varied with many elaborate platforms and tools that promise to protect against ransomware and everything else. Alluring technology, like machine learning and artificial intelligence, are touted to detect zero-days or other undetecables. Unfortunately, as well intentioned as these tools are, the peak effectiveness of a security program is not attainable without the implementation of some basic best practices. 

Seventy five percent of companies infected with ransomware were running up-to-date endpoint protection(2). This demonstrates that it can be the small innocuous things that result in an intrusion, such as outdated devices connected to the network (2), or human errors. It is these holes and similarly simplistic avenues that basic best practices or the most basic features of your cybersecurity defense system are designed to cover. “Basic” in many ways is a misnomer. These are truly the foundations on which an entire cybersecurity system depends. CISA, the United States Cybersecurity and Infrastructure Security Agency’s, guide to ransomware lists these best practices as(3):

  • Update software and operating systems with the latest patches. Outdated applications and operating systems are the target of most attacks.
  • Never click on links or open attachments in unsolicited emails.
  • Back up data on a regular basis. Keep it on a separate device and store it offline.
  • Follow safe practices when using devices that connect to the Internet:
  • Improve password security(3):
      • Create a strong password.
      • Consider using a password manager.
      • Use multi-factor authentication, if available.
      • Use security questions properly.
      • Create unique accounts for each user per device.
    • Choose secure networks.
    • Keep all of your personal electronic device software current.
    • Be suspicious of unexpected emails.

These guidelines should be implemented by both individuals and corporations. Proper foundational tactics can protect against ransomware and its most common vehicles of delivery, such as phishing. Phishing through texts, messaging, or emails is one of the more common avenues in which ransomware is delivered. As recommended by UC Berkley, if you don’t know the sender, then don’t click (6) and consider adding a few checks to ensure you know the sender for familiar contacts or organizations that hackers may hijack, such as Microsoft or one’s own employer(6).

The bulk of these practices are meant to aid prevention of intrusion, but one step is your insurance against loss if an incident happens: data backups. Ransomware is essentially a hostage situation and there is no guarantee that your data and system will be returned in the condition it was seized in. For organizations, it is critical to have backups when auditing and re-uploading their data once they have recovered from the ransom situation. However, if there is a secure backup, then there is no need to pay the ransom at all.

Once these foundational practices are in place, build upon them with some well-known defense tactics, and add a few less well known ones. These include making sure anti-malware software is always enabled, running real-time scanning(5), and restricting privileges within an organization or network(3). These settings and tools can prevent malware from running or at least limit its capacity to spread. Additional practices recommended by CISA are(3):

  • Restrict users’ permissions to install and run software applications, and apply the principle of “least privilege” to all systems and services[…].
  • Use application allow listing to allow only approved programs to run on a network.
  • Enable strong spam filters to prevent phishing emails from reaching the end users and authenticate inbound email to prevent email spoofing.
  • Scan all incoming and outgoing emails to detect threats and filter executable files from reaching end users.
  • Configure firewalls to block access to known malicious IP addresses.

This second layer of best practices to protect against ransomware can be further strengthened with threat intelligence. Armed with a variety of reputable IoC sources, your security tools will be able to recognize traffic to/from as well as to block access to ransomware and its control infrastructure. For example, Malware Patrol offers a feed of malware & ransomware URLs. Additional feeds include DGAs and C2s, which are domains and URLs/addresses that, once accessed, allow the malware or ransomware to establish contact with its control infrastructure.   

A solid foundation in the basic best practices aids in the prevention of ransomware attacks for individuals and organizations. Cybersecurity is not just one singular thing, but is instead many layers that build and support each other. Ingrain these best practices until they’re a rote memory and utilize the tools that support and emphasize them in order to better support the rest of your cybersecurity system. Hacker attacks and ransomware threats aren’t going away, but by being diligent the undertow and its dangers are avoidable.

References

  1. https://www.cnn.com/2021/07/06/tech/kaseya-ransomware-what-we-know/index.html
  2. https://purplesec.us/cyber-security-trends-2021/#Ransomware
  3. https://cisa.gov/ransomware
  4. https://us-cert.cisa.gov/ncas/tips/ST04-003
  5. https://security.berkeley.edu/resources/best-practices-how-to-articles/top-10-secure-computing-tips
  6. https://www.techrepublic.com/article/new-phishing-attack-hijacks-email-conversations-how-companies-can-protect-employees/

Shannon Shell

Freelance Writer

?

DoH! Not so great to the Enterprise

Insights

?

A illustrated image of Internet DoH Border Control by Patrick Taylor. The image contains a toll booth with three booths, The toll booths are labeled Cloudflare, Google, and Firefox.

Internet DoH Border Control by Patrick Taylor.

What Is DNS over HTTPS (DoH) and Why It Matters for Security

DoH, or DNS over HTTPS (RFC 8484), is a relatively new protocol that provides increased privacy and security. It does this by encrypting DNS queries and responses, which prevents eavesdropping and man-in-the-middle attacks. Instead of using a regular DNS resolver, queries are encrypted and sent to a DoH-enabled server, Â making them indistinct from web traffic.

Sounds great in theory. Encryption = greater security? Not so fast there.

Pre-DoH, DNS servers were configured at the operating system level. Home users usually trust their ISPs to handle name resolutions and enterprises often run their own internal servers. However, with DoH, servers are configured at the application level – which bypasses the operating system settings.

By circumventing the operating system’s DNS configuration, DoH becomes a big headache for tech support, system administrators, and, most importantly, enterprises that need to control and audit DNS activities for protection or regulatory reasons.

There’s a very interesting Internet Draft that explains in more detail the technical and regulatory challenges presented by DoH: DNS over HTTPS (DoH) Considerations for Operator Networks (5)

Can you afford for your security settings to be bypassed?

DNS firewalls and auditing are easy and popular ways to protect endpoints, apply parent control and detect compromised systems. DoH bypasses the existing security infrastructure and policies, including hardware, software (such as firewalls, AD policies, intrusion detection systems, etc.), training, and resource management. Enterprises have invested A LOT of time and money in all of these.

While DoH is great in theory, organizations will run into all sorts of technical, policy and regulatory issues with its use.

  • Malware is likely to crop up to exploit this new technology avoiding security mechanisms to reach its command and control systems or drop zones. In fact, Godlua was discovered in July 2019 already doing so (1)
  • DNS Firewalls become ineffective. Traffic cannot be filtered at the DNS level, which means bypassing local policies and, for example, allowing employees to access social media or other prohibited resources at work.
  • Regulations like GDPR are impacted as DoH servers may be operated in a jurisdiction distinct from its users. And DNS queries and IP addresses considered PII in some jurisdictions, and therefore subject to data protection and retention regulations, may not be treated the same way at the physical location of the DoH server
  • Split DNS scenarios, where distinct responses are provided depending on the requester location (internal or external enterprise networks, for example), aren’t possible anymore
  • Private/internal DNS names may be leaked
  • Incident response and threat hunting become far more complex
  • Tech support troubleshooting changes significantly as now applications and the operating system use distinct DNS resolvers
  • Network operators won’t be able to perform DNS blocking and filtering to handle take down notices or comply with court orders
  • Access control lists based on threat intelligence data feeds can be circumvented
  • DNS traffic can’t be audited
  • Parental controls are bypassed
  • CDNs that rely on DNS to direct traffic to cache nodes are no longer able to use the same technique
  • Performance may be impacted by TLS setup times and larger RTTs as queries are sent to servers outside of the enterprise or ISP network (3)(4)

And if all that’s not enough to be wary of DoH, consider this: DoH service providers know IP addresses and DNS queries. And it is unclear how this data can be used by them.  Also, there are only so many DoH providers these days, which concentrates the control over DNS responses in only a few companies. That is dangerous and the opposite of what DNS should be – a hierarchical and decentralized system. It is a threat to Net Neutrality. Recently, we wrote about the benefits of using Malware Patrol over free DNS protection services – the same goes with DoH.

A cartoon image of Homer Simpson in front of a computer monitor with a word bubble that says DOH
Even Mozilla, who announced that DoH will be turned on by default on Firefox, knows that it isn’t a good solution for everyone:

While we would like to encourage everyone to use DoH, we also recognize that there are a few circumstances in which DoH can be undesirable (…) (2)

 

What’s the best way to keep enterprise systems secure from DoH?

Instead of trying to roll out DoH configuration and lock down all your systems, it’s easier to supply your firewall and/or IDS with an up-to-date feed of active DoH servers. This protects the investment already made in security mechanisms, policies and procedures.

This is why Malware Patrol has created a data feed of DoH resolvers that our customers can use to prevent access, ensuring their carefully configured and security-compliant environments remain under their control.

While DoH sounds like a good way to remain private while accessing the Internet, it’s best left to people to implement in their homes. For enterprises, it’s simply not a tenable privacy solution at this time.

  1. https://www.zdnet.com/article/first-ever-malware-strain-spotted-abusing-new-doh-dns-over-https-protocol/
  2. ttps://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
  3. https://www.samknows.com/blog/dns-over-https-performance
  4. https://arxiv.org/abs/1907.08089
  5. https://www.ietf.org/archive/id/draft-doh-reid-operator-00.txt

Andre Correa

CEO, Malware Patrol

?

Newly Registered Domains Related to COVID-19

Insights

?

The current outbreak of the COVID-19 created a perfect scenario for all sorts of scammers to monetize through fear, false promises and fraud. Since the beginning of March, tens of thousands of new domains have been registered using the terms “corona”, ‘covid’, ‘epidemic’, ‘pandemic’ and ‘wuhan’.

While some of these are legitimate – and some still point to parking pages – it is fair to assume that many are to be used for malicious purposes. In general, newly registered domains should be approached with caution, and under the current circumstances we should be even more vigilant.

A Coronavirus COVID-19 Suspicious Domains image in the Coronavirus Malware Domains Threat Awareness and Prevention blog postOur team compiled a list of domains containing keywords related to the global pandemic from our Newly Registered Domains feed that can be used to protect your family, employees and customers. The list is based solely on the timeframe and the terms used to register the domains, no other assumptions are made. However, if used with caution, we believe it can help to keep people from falling for scams and to prevent the dissemination of misinformation.

 

 

 

The information is provided as-is, with no warranties and free for any use. We will continue to update these feeds likely in a daily basis, so feel free to automate your downloads using the links below:

For information about other online coronavirus scams, check out these articles:

Coronavirus Scam Alert: Watch Out For These Risky COVID-19 Websites And Emails (Forbes)

Battling online coronavirus scams with facts (Malwarebytes)

Malicious coronavirus map hides AZORult info-stealing malware (SC Magazine)

Coronavirus Used in Spam, Malware, and Malicious Domains (TrendMicro)

?