Category Archives: Security

Wireshark 3.2.5 Released, (Sun, Jul 5th)

This post was originally published on this site

Wireshark version 3.2.5 was released.

It has a vulnerability fix and bug fixes.

A vulnerability in the GVCP dissector (%%cve:2020-15466%%) can be abused to cause an infinite loop.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Happy FouRth of July from the Internet Storm Center, (Sat, Jul 4th)

This post was originally published on this site

For our readers in the United States, the 4th of July is Independence Day. As the 4th, under normal COVID-free circumstances, is typically celebrated with fireworks events, I thought I’d deviate a bit from information security topics and instead share a bit of code to create your own fireworks using R, a language and environment for statistical computing and graphics. My teams and I use R and Python constantly as part of security data analytics, particularly for data science and machine learning to further our detection practices and better identify anomalies of significance. You can follow along at home using RStudio as your IDE, and the latest version of R, 4.0.2 as this is written. All credit is due specifically to Edward Visel of Uptake, this is entirely his code, just modified ever so slightly for our purposes here. Edward was experimenting on his path to the perfect R-generated firework but I like each of them as variants in and of themselves. In the spirit of the old red, white, and blue, I selected three specific patterns, namely his explosion, particles and gnats, and the final firework. This work uses the tidyverse, sf, and gganimate packages, I pulled in magick to manipulate the resulting GIFs a bit. If you just want the TL;DR version, the results of the effort follows immediately, the code is in-line immediately thereafter. Happy 4th of July for those of you who celebrate it, cheers, stay safe and healthy to all!

Russ McRee | @holisticinfosec

Red

library(tidyverse)
library(sf)
library(gganimate)
library(magick)

theme_set(theme_void() + theme(
  panel.background = element_rect(fill = 'black')
))

#Explosion
p1 <- map_dfr(1:10, ~crossing(
  x = runif(30),
  nesting(
    y = seq(1, .x, length.out = 10)^0.5,
    t = 1:10)
)
) %>%
  ggplot(aes(x, y)) +
  geom_point(color = 'red') +
  coord_polar() +
  transition_time(t) +
  shadow_wake(0.5)

p1_gif <- animate(p1, renderer = gifski_renderer(), fps = 50,
                  width = 250, height = 250)

#Particles & Gnats
p2 <- map_dfr(1:10, ~tibble(y = seq(1, .x, length.out = 10), t = 1:10)) %>%
  mutate(x = runif(n())) %>%
  ggplot(aes(x, y)) +
  geom_point(color = 'white') +
  coord_polar() +
  transition_time(t) +
  shadow_wake(0.5)

p2_gif <- animate(p2, renderer = gifski_renderer(), nframes = 70, fps = 50,
                  width = 250, height = 250)

#Firework

p3 <- map_dfr(1:10, ~crossing(
  x = {
    x = seq(30) + 0.6*.x;
    ifelse(x > 30, x - 30, x)
  },
  nesting(
    y = seq(1, .x, length.out = 10)^0.5,
    t = 1:10)
)
) %>%
  ggplot(aes(x, y)) +
  geom_point(color = 'blue') +
  coord_polar() +
  transition_time(t) +
  shadow_wake(0.3)

p3_gif <- animate(p3, renderer = gifski_renderer(), fps = 50,
                  width = 250, height = 250)

p1_mgif <- image_read(p1_gif)
p2_mgif <- image_read(p2_gif)
p3_mgif <- image_read(p3_gif)

image_write(p1_mgif, path = "red.gif", format = "gif", quality = 75)
image_write(p2_mgif, path = "white.gif", format = "gif", quality = 75)
image_write(p3_mgif, path = "blue.gif", format = "gif", quality = 75)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Setting up the Dshield honeypot and tcp-honeypot.py, (Wed, Jul 1st)

This post was originally published on this site

After Johannes did his Tech Tuesday presentation last week on setting up Dshield honeypots, I thought I’d walk you through how I setup my honeypots. I like to combine the Dshield honeypot with Didier Stevens’ tcp-honeypot so I can capture more suspicious traffic. Today, I’ll walk you through my setup using a VM hosted by Digital Ocean, though the steps would work for pretty much any cloud provider.

I’m using Digital Ocean because you can set up a simple VM that is more than adequate as a honeypot for $5/mo. So, let’s get to it.

First off, I’m going to create a new droplet (you may have to create a new project first). It is pretty straight forward. 

As you can see, that gets you a VM with 1 processor and 1GB of RAM, but that will be plenty. Next, you get to choose which datacenter you want this VM running in. For this exercise, I’m choosing London, but my next one might be Bangalore or Singapore or Toronto (you know how those Canadians are).

There a few more decisions you need to make. I highly recommend that you upload an ssh public key rather than setting a root password, but once you’ve done all that, hit the button to create your VM and wait until it comes back with the public IP of said new VM.

Now, from wherever you intend to administer the VM from, slogin root@<ip of your VM>, and one of the first things I would do (assuming you used a public key) is to modify /etc/ssh/sshd_config and change PermitRootLogin to without-password (don’t get me started on what a poor choice that was for the name for enforcing only key-based logins). From this point on, I’ll mostly follow the instructions found on github for installing the Dshield honeypot on Ubuntu. Note, I can skip the step about installing openssh-server since that is already there by default. Before installing the honeypot, let’s get the system current on patches

# apt update && apt full-upgrade -y && init 6

So, we’re now up-to-date on patches. Personally, there are a few other things that I add now to help me administer the honeypot, like installing aide and apticron. I also tweak the settings for unattended-upgrades, and modify /etc/postfix/main.cf to set the interfaces line to loopback-only, but we have a reasonably minimal system, at this point. Next we’ll get the install script from github (git is also already installed) and actually install the Dshield honeypot.

Then you can run dshield/bin/install.sh to do the actual install. A couple of things to beware of in doing the install. First, make sure you include the IP of the system from which you plan to administer the honeypot in the ‘local’ IPs. Trust me, I’ve locked myself out more than once by forgetting that, so learn from my mistakes. Then, I’m going to set this honeypot for manual update for reasons I’ll explain below. Otherwise, I pretty much just take the defaults and paste in my e-mail and API key from my account page at isc.sans.edu. At this point, you actually should have a working Dshield honeypot, but as I mentioned above, I want to add another honeypot tool.

I’ve become a big fan of Didier Stevens’ tcp-honeypot-3.py (he’s going to rename it when he officially releases it sometime soon-ish, because it can also do UDP), but I’m using the 0.1.0 version from Feb 2020. He appears not to have checked into his github beta repo, so if you want to play with the version I’m using, I guess you could contact me or just wait for Didier’s official release whenever that happens. I’ve actually made 2 minor modifications to the 0.1.0 version, the first is that I make it log to /var/log/tcp-honeypot-3/ and I’ve fixed the logging so that it shows src-dst rather than dst-src. The latter fix Didier has already incorporated, and I expect he’ll have a way of doing the former by the time he releases.

I’ve also created a systemd unit file (no, I don’t want to get into the religious wars about how good or awful systemd is, that’s what all the Linux distros are going with, so that is what I’m using to make sure the tcp-honeypot starts up with the system). Again, I’ve shared it with Didier, but if you want to play with it now, I’ve temporarily put it up on my own github (though I will probably remove it if Didier includes it with his release), you can find it here.

So, now I have both the Dshield honeypot on tcp-honeypot on the system, but the tcp-honeypot isn’t actually capturing anything. The problem is, the Dshield honeypot is controlling the iptables rules. So, we’ll need to modify those rules to allow traffic through to the tcp-honeypot. The reason I set the Dshield honeypot to manual updates is that any update to the Dshield honeypot, would wipe out these updates to the iptables rules. Johannes is working on an update to allow the “local” iptables rules to persist, so at some point, I’ll be able to run auto update back on. He’s also working on handling IPv6, too (which the current version of the honeypot disables completely on your VM). No pressure, Johannes, now that others know you are working on it there’s no pressure to get it done soon. πŸ™‚

With the systemd unit file properly placed into /etc/systemd/system/, I can run 

# systemctl enable tcp-honeypot && systemctl start tcp-honeypot 

Now, let’s see what all is listening on my honeypot, I’ll quickly run lsof -Pni and I get the following

So, those python3 lines are the tcp-honeypot, the ones running as the cowrie user are the standard Dshield honeypot processes. I need to update the iptables rules to allow traffic through to the tcp-honeypot. I could do this in a couple of ways, but ultimately, we need to remember that the rules that the Dshield honeypot installed are located in /etc/network/iptables. So, we could modify that file, and then run iptables-restore < /etc/network/iptables. I actually chose to first run iptables-save > /etc/network/iptables, just to make sure that there was no difference between that file and what was live on the system. Then I added the 2 rules in the green box below to allow traffic through to the ports that tcp-honeypot is listening on and then ran the iptables-restore < /etc/network/iptables mentioned above. This way, I was reasonably certain I wouldn’t lock myself out in the process.

And there you have it. My honeypot is now more flexible with both the standard Dshield honeypot and Didier’s tcp-honeypot. Now if I see strange spikes in traffic to unknown ports, I can have tcp-honeypot listen on that port, update the appropriate rule above (for TCP or UDP) do the iptables-restore and I’ll have a log where I can look at that traffic and hopefully figure out what the attackers are looking for.

I hope you found this useful, if you have questions or suggestions, feel free to comment here or e-mail me.

—————
Jim Clausing, GIAC GSE #26
jclausing –at– isc [dot] sans (dot) edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

AA20-183A: Defending Against Malicious Cyber Activity Originating from Tor

This post was originally published on this site

Original release date: July 1, 2020

Summary

This advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) and Pre-ATT&CK framework. See the ATT&CK for Enterprise and Pre-ATT&CK frameworks for referenced threat actor techniques.

This advisory—written by the Cybersecurity Security and Infrastructure Security Agency (CISA) with contributions from the Federal Bureau of Investigation (FBI)—highlights risks associated with Tor, along with technical details and recommendations for mitigation. Cyber threat actors can use Tor software and network infrastructure for anonymity and obfuscation purposes to clandestinely conduct malicious cyber operations.[1],[2],[3]

Tor (aka The Onion Router) is software that allows users to browse the web anonymously by encrypting and routing requests through multiple relay layers or nodes. This software is maintained by the Tor Project, a nonprofit organization that provides internet anonymity and anti-censorship tools. While Tor can be used to promote democracy and free, anonymous use of the internet, it also provides an avenue for malicious actors to conceal their activity because identity and point of origin cannot be determined for a Tor software user. Using the Onion Routing Protocol, Tor software obfuscates a user’s identity from anyone seeking to monitor online activity (e.g., nation states, surveillance organizations, information security tools). This is possible because the online activity of someone using Tor software appears to originate from the Internet Protocol (IP) address of a Tor exit node, as opposed to the IP address of the user’s computer.

CISA and the FBI recommend that organizations assess their individual risk of compromise via Tor and take appropriate mitigations to block or closely monitor inbound and outbound traffic from known Tor nodes.

Click here for a PDF version of this report.

Risk Evaluation

Malicious cyber actors use Tor to mask their identity when engaging in malicious cyber activity impacting the confidentiality, integrity, and availability of an organization’s information systems and data. Examples of this activity include performing reconnaissance, penetrating systems, exfiltrating and manipulating data, and taking services offline through denial-of-service attacks and delivery of ransomware payloads. Threat actors have relayed their command and control (C2) server communications—used to control systems infected with malware—through Tor, obscuring the identity (location and ownership) of those servers.

The use of Tor in this context allows threat actors to remain anonymous, making it difficult for network defenders and authorities to perform system recovery and respond to cyberattacks. Organizations that do not take steps to block or monitor Tor traffic are at heightened risk of being targeted and exploited by threat actors hiding their identity and intentions using Tor.

The risk of being the target of malicious activity routed through Tor is unique to each organization. An organization should determine its individual risk by assessing the likelihood that a threat actor will target its systems or data and the probability of the threat actor’s success given current mitigations and controls. This assessment should consider legitimate reasons that non-malicious users may prefer to, or need to, use Tor for accessing the network. Organizations should evaluate their mitigation decisions against threats to their organization from advanced persistent threats (APTs), moderately sophisticated attackers, and low-skilled individual hackers, all of whom have leveraged Tor to carry out reconnaissance and attacks in the past.

Technical Details

Tor obfuscates the source and destination of a web request. This allows users to conceal information about their activities on the web—such as their location and network usage—from the recipients of that traffic, as well as third parties who may conduct network surveillance or traffic analysis. Tor encrypts a user’s traffic and routes the traffic through at least three Tor nodes, or relays, so that the user’s starting IP address and request is masked from network and traffic observers during transit. Once the request reaches its intended destination, it exits Tor through a public Tor exit node. Anyone conducting monitoring or analysis will only see the traffic coming from the Tor exit node and will not be able to determine the original IP address of the request.

 

Figure 1: Malicious tactics and techniques aided by Tor, mapped to the MITRE ATT&CK framework

Malicious Tactics and Techniques Aided by Tor

Threat actors use Tor to create a layer of anonymity to conceal malicious activity at different stages of network compromise. Their tactics and techniques—illustrated in figure 1 above—include:

Pre-ATT&CK

  • Target Selection [TA0014]
  • Technical Information Gathering [TA0015]
    • Conduct Active Scanning [T1254]
    • Conduct Passive Scanning [T1253]
    • Determine domain and IP address space [T1250]
    • Identify security defensive capabilities [T1263]
  • Technical Weakness Identification [TA0018]

ATT&CK

Key Indicators of Malicious Activity via Tor

While Tor obfuscates a user from being identified through standard security tools, network defenders can leverage various network, endpoint, and security appliance logs to detect the use of Tor, including potentially malicious activity involving Tor, through indicator- or behavior-based analysis.

Using an indicator-based approach, network defenders can leverage security information and event management (SIEM) tools and other log analysis platforms to flag suspicious activities involving the IP addresses of Tor exit nodes. The list of Tor exit node IP addresses is actively maintained by the Tor Project’s Exit List Service, which offers both real-time query and bulk download interfaces (see https://blog.torproject.org/changes-tor-exit-list-service). Organizations preferring bulk download may consider automated data ingest solutions, given the highly dynamic nature of the Tor exit list, which is updated hourly. Network defenders should closely inspect evidence of substantial transactions with Tor exit nodes—revealed in netflow, packet capture (PCAP), and web server logs—to infer the context of the activity and to discern any malicious behavior that could represent reconnaissance, exploitation, C2, or data exfiltration.

Using a behavior-based approach, network defenders can uncover suspicious Tor activity by searching for the operational patterns of Tor client software and protocols. Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports commonly affiliated with Tor include 9001, 9030, 9040, 9050, 9051, and 9150. Highly structured Domain Name Service (DNS) queries for domain names ending with the suffix torproject.org is another behavior exhibited by hosts running Tor software. In addition, DNS queries for domains ending in .onion is a behavior exhibited by misconfigured Tor clients, which may be attempting to beacon to malicious Tor hidden services.

Organizations should research and enable the pre-existing Tor detection and mitigation capabilities within their existing endpoint and network security solutions, as these often employ effective detection logic. Solutions such as web application firewalls, router firewalls, and host/network intrusion detection systems may already provide some level of Tor detection capability.

Mitigations

Organizations can implement mitigations of varying complexity and restrictiveness to reduce the risk posed by threat actors who use Tor to carry out malicious activities. However, mitigation actions can also impact the access of legitimate users who leverage Tor to protect their privacy when visiting an organization’s internet-facing assets. Organizations should evaluate their probable risk, available resources, and impact to legitimate, non-malicious, Tor users before applying mitigation actions. 

  • Most restrictive approach: Block all web traffic to and from public Tor entry and exit nodes. Organizations that wish to take a conservative or less resource-intensive approach to reduce the risk posed by threat actors’ use of Tor should implement tools that restrict all traffic—malicious and legitimate—to and from Tor entry and exit nodes. Of note, blocking known Tor nodes does not completely eliminate the threat of malicious actors using Tor for anonymity, as additional Tor network access points, or bridges, are not all listed publicly. See table 1 for the most restrictive mitigation practices.

Table 1: Most restrictive mitigation practices

Type Level of Effort Technical Implementation

Impact 

Baseline Activity Low/Medium

Require organization to maintain up-to-date lists of known Tor exit and entry node IP addresses.

Public lists are available on the internet, but frequency of updates and accuracy varies depending on the source. The Tor Project maintains an authoritative list

Up-to-date awareness of known Tor nodes to enable blocking
External Policies Medium

Set external policies to block incoming traffic from known Tor exit nodes to prevent malicious reconnaissance and exploit attempts.

Network security tools (e.g., next-generation firewalls, proxies) may have configuration settings to apply these policies.

Block inbound network traffic, both malicious and legitimate, from reaching the organization’s domain from known Tor exit nodes
Internal Policies Medium

Set internal policies to block outgoing traffic to Tor entry nodes to prevent data exfiltration and C2 traffic.

Network security tools (e.g., next-generation firewalls, proxies) may have configuration settings to apply these policies.

Block outbound network traffic, both malicious and legitimate, from leaving the organization’s domain into known Tor entry nodes

 

  • Less restrictive approach: Tailor monitoring, analysis, and blocking of web traffic to and from public Tor entry and exit nodes. There are instances in which legitimate users may leverage Tor for internet browsing and other non-malicious purposes. For example, deployed military or other overseas voters may use Tor as part of the voting process to escape monitoring by foreign governments. Such users may use Tor when visiting elections-related websites, to check voter registration status, or to mark and then cast absentee ballots via email or web portal. Similarly, some users may use Tor to avoid tracking by advertisers when browsing the internet. Organizations that do not wish to block legitimate traffic to/from Tor entry/exit nodes should consider adopting practices that allow for network monitoring and traffic analysis for traffic from those nodes, and then consider appropriate blocking. This approach can be resource intensive but will allow greater flexibility and adaptation of defensive.

Table 2: Less restrictive mitigation practices

Type Level of Effort Technical Implementation Impact
Known Tor Nodes Low/Medium

Require the organization to maintain up-to-date lists of known Tor exit and entry node IP addresses.

The Tor Project maintains an authoritative list

Up-to-date awareness of known Tor nodes to enable baselining/allow blocking
SIEM Correlation Low/Medium Integrate network security and SIEM tools that correlate logs. Enhanced understanding of legitimate/expected Tor use for inbound/outbound traffic
Baseline Medium

Analyze traffic to determine normal patterns of behavior; legitimate vs. anomalous uses of Tor.

Baseline existing Tor traffic to/from known entry/exit nodes over a period of months.

Inspect traffic to understand legitimate traffic; level-set the organization’s risk tolerance for blocking or allowing Tor traffic to/from specific services.

Baseline understanding of legitimate vs. potentially anomalous Tor uses.
Internal / External Policies Medium/High

Institute behavioral signatures/rules to block unexpected/potentially malicious activity and allow legitimate activity.

Examine activity between any ephemeral port and Tor IP—this could be malicious data exfiltration or C2 traffic (except where use of outbound Tor entry nodes is expected).

Monitor for use of TCP/UDP ports 9001, 9030, 9040, 9050, 9051, 9150, and TCP ports 443* and 8443.

Monitor and/or block inbound connections from Tor exit nodes to IP addresses and ports for which external connections are not expected (i.e., other than VPN gateways, mail ports, web ports).

Associated ports are applicable for client -> guard/relay traffic monitoring and analysis but not monitoring for exit node -> a network destination.

Monitor and examine any large dataflows between networks and Tor IP addresses, regardless of port, as this could be unauthorized data exfiltration.

*Since port 443 is the most common port for secure web traffic, generically monitoring 443 may produce a high volume of false positives; network traffic tools can be used to assist in this analysis.

Legitimate traffic via Tor entry/exit nodes is permitted and unexpected/potentially malicious activity via Tor entry/exit nodes is blocked

 

  • Blended approach: Block all Tor traffic to some resources, allow and monitor for others. Given the various licit and illicit uses of Tor, a blended approach may be an appropriate risk mitigation strategy for some organizations (i.e., intentionally allowing traffic to/from Tor only for specific websites and services where legitimate use may be expected and blocking all Tor traffic to/from non-excepted processes/services). This may require continuous re-evaluation as an entity considers its own risk tolerance associated with different applications. The level of effort to implement this approach is high.

Considerations for Blocking Use of Tor

Sophisticated threat actors may leverage additional anonymization technologies—such as virtual private networks (VPNs)—and configurable features within Tor—such as Tor bridges and pluggable transports—to circumvent detection and blocking. Blocking the use of known Tor nodes may not effectively mitigate all hazards but may protect against less sophisticated actors. For example, blocking outbound traffic to known Tor entry nodes could have an appreciable impact in blocking less sophisticated malware from successfully beaconing out to hidden C2 machines obfuscated by Tor. Ultimately, each entity must consider its own internal thresholds and risk tolerance when determining a risk mitigation approach associated with Tor.

Contact Information

To report suspicious or criminal activity related to information found in this Joint Cybersecurity Advisory, contact your local FBI field office at www.fbi.gov/contact-us/field, or the FBI’s 24/7 Cyber Watch (CyWatch) at (855) 292-3937 or by e-mail at CyWatch@fbi.gov. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. To request incident response resources or technical assistance related to these threats, contact CISA at CISAServiceDesk@cisa.dhs.gov.

Disclaimer

This document is marked TLP:WHITE. Disclosure is not limited. Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction. For more information on the Traffic Light Protocol, see http://www.us-cert.gov/tlp/.

References

Revisions

  • July 1, 2020: Initial Version

This product is provided subject to this Notification and this Privacy & Use policy.

AA20-183A: Defending Against Malicious Cyber Activity Originating from Tor

This post was originally published on this site

Original release date: July 1, 2020 | Last revised: July 2, 2020

Summary

This advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) and Pre-ATT&CK framework. See the ATT&CK for Enterprise and Pre-ATT&CK frameworks for referenced threat actor techniques.

This advisory—written by the Cybersecurity Security and Infrastructure Security Agency (CISA) with contributions from the Federal Bureau of Investigation (FBI)—highlights risks associated with Tor, along with technical details and recommendations for mitigation. Cyber threat actors can use Tor software and network infrastructure for anonymity and obfuscation purposes to clandestinely conduct malicious cyber operations.[1],[2],[3]

Tor (aka The Onion Router) is software that allows users to browse the web anonymously by encrypting and routing requests through multiple relay layers or nodes. This software is maintained by the Tor Project, a nonprofit organization that provides internet anonymity and anti-censorship tools. While Tor can be used to promote democracy and free, anonymous use of the internet, it also provides an avenue for malicious actors to conceal their activity because identity and point of origin cannot be determined for a Tor software user. Using the Onion Routing Protocol, Tor software obfuscates a user’s identity from anyone seeking to monitor online activity (e.g., nation states, surveillance organizations, information security tools). This is possible because the online activity of someone using Tor software appears to originate from the Internet Protocol (IP) address of a Tor exit node, as opposed to the IP address of the user’s computer.

CISA and the FBI recommend that organizations assess their individual risk of compromise via Tor and take appropriate mitigations to block or closely monitor inbound and outbound traffic from known Tor nodes.

Click here for a PDF version of this report.

Risk Evaluation

Malicious cyber actors use Tor to mask their identity when engaging in malicious cyber activity impacting the confidentiality, integrity, and availability of an organization’s information systems and data. Examples of this activity include performing reconnaissance, penetrating systems, exfiltrating and manipulating data, and taking services offline through denial-of-service attacks and delivery of ransomware payloads. Threat actors have relayed their command and control (C2) server communications—used to control systems infected with malware—through Tor, obscuring the identity (location and ownership) of those servers.

The use of Tor in this context allows threat actors to remain anonymous, making it difficult for network defenders and authorities to perform system recovery and respond to cyberattacks. Organizations that do not take steps to block or monitor Tor traffic are at heightened risk of being targeted and exploited by threat actors hiding their identity and intentions using Tor.

The risk of being the target of malicious activity routed through Tor is unique to each organization. An organization should determine its individual risk by assessing the likelihood that a threat actor will target its systems or data and the probability of the threat actor’s success given current mitigations and controls. This assessment should consider legitimate reasons that non-malicious users may prefer to, or need to, use Tor for accessing the network. Organizations should evaluate their mitigation decisions against threats to their organization from advanced persistent threats (APTs), moderately sophisticated attackers, and low-skilled individual hackers, all of whom have leveraged Tor to carry out reconnaissance and attacks in the past.

Technical Details

Tor obfuscates the source and destination of a web request. This allows users to conceal information about their activities on the web—such as their location and network usage—from the recipients of that traffic, as well as third parties who may conduct network surveillance or traffic analysis. Tor encrypts a user’s traffic and routes the traffic through at least three Tor nodes, or relays, so that the user’s starting IP address and request is masked from network and traffic observers during transit. Once the request reaches its intended destination, it exits Tor through a public Tor exit node. Anyone conducting monitoring or analysis will only see the traffic coming from the Tor exit node and will not be able to determine the original IP address of the request.

 

Figure 1: Malicious tactics and techniques aided by Tor, mapped to the MITRE ATT&CK framework

Malicious Tactics and Techniques Aided by Tor

Threat actors use Tor to create a layer of anonymity to conceal malicious activity at different stages of network compromise. Their tactics and techniques—illustrated in figure 1 above—include:

Pre-ATT&CK

  • Target Selection [TA0014]
  • Technical Information Gathering [TA0015]
    • Conduct Active Scanning [T1254]
    • Conduct Passive Scanning [T1253]
    • Determine domain and IP address space [T1250]
    • Identify security defensive capabilities [T1263]
  • Technical Weakness Identification [TA0018]

ATT&CK

Key Indicators of Malicious Activity via Tor

While Tor obfuscates a user from being identified through standard security tools, network defenders can leverage various network, endpoint, and security appliance logs to detect the use of Tor, including potentially malicious activity involving Tor, through indicator- or behavior-based analysis.

Using an indicator-based approach, network defenders can leverage security information and event management (SIEM) tools and other log analysis platforms to flag suspicious activities involving the IP addresses of Tor exit nodes. The list of Tor exit node IP addresses is actively maintained by the Tor Project’s Exit List Service, which offers both real-time query and bulk download interfaces (see https://blog.torproject.org/changes-tor-exit-list-service). Organizations preferring bulk download may consider automated data ingest solutions, given the highly dynamic nature of the Tor exit list, which is updated hourly. Network defenders should closely inspect evidence of substantial transactions with Tor exit nodes—revealed in netflow, packet capture (PCAP), and web server logs—to infer the context of the activity and to discern any malicious behavior that could represent reconnaissance, exploitation, C2, or data exfiltration.

Using a behavior-based approach, network defenders can uncover suspicious Tor activity by searching for the operational patterns of Tor client software and protocols. Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports commonly affiliated with Tor include 9001, 9030, 9040, 9050, 9051, and 9150. Highly structured Domain Name Service (DNS) queries for domain names ending with the suffix torproject.org is another behavior exhibited by hosts running Tor software. In addition, DNS queries for domains ending in .onion is a behavior exhibited by misconfigured Tor clients, which may be attempting to beacon to malicious Tor hidden services.

Organizations should research and enable the pre-existing Tor detection and mitigation capabilities within their existing endpoint and network security solutions, as these often employ effective detection logic. Solutions such as web application firewalls, router firewalls, and host/network intrusion detection systems may already provide some level of Tor detection capability.

Mitigations

Organizations can implement mitigations of varying complexity and restrictiveness to reduce the risk posed by threat actors who use Tor to carry out malicious activities. However, mitigation actions can also impact the access of legitimate users who leverage Tor to protect their privacy when visiting an organization’s internet-facing assets. Organizations should evaluate their probable risk, available resources, and impact to legitimate, non-malicious, Tor users before applying mitigation actions. 

  • Most restrictive approach: Block all web traffic to and from public Tor entry and exit nodes. Organizations that wish to take a conservative or less resource-intensive approach to reduce the risk posed by threat actors’ use of Tor should implement tools that restrict all traffic—malicious and legitimate—to and from Tor entry and exit nodes. Of note, blocking known Tor nodes does not completely eliminate the threat of malicious actors using Tor for anonymity, as additional Tor network access points, or bridges, are not all listed publicly. See table 1 for the most restrictive mitigation practices.

Table 1: Most restrictive mitigation practices

Type Level of Effort Technical Implementation

Impact 

Baseline Activity Low/Medium

Require organization to maintain up-to-date lists of known Tor exit and entry node IP addresses.

Public lists are available on the internet, but frequency of updates and accuracy varies depending on the source. The Tor Project maintains an authoritative list

Up-to-date awareness of known Tor nodes to enable blocking
External Policies Medium

Set external policies to block incoming traffic from known Tor exit nodes to prevent malicious reconnaissance and exploit attempts.

Network security tools (e.g., next-generation firewalls, proxies) may have configuration settings to apply these policies.

Block inbound network traffic, both malicious and legitimate, from reaching the organization’s domain from known Tor exit nodes
Internal Policies Medium

Set internal policies to block outgoing traffic to Tor entry nodes to prevent data exfiltration and C2 traffic.

Network security tools (e.g., next-generation firewalls, proxies) may have configuration settings to apply these policies.

Block outbound network traffic, both malicious and legitimate, from leaving the organization’s domain into known Tor entry nodes

 

  • Less restrictive approach: Tailor monitoring, analysis, and blocking of web traffic to and from public Tor entry and exit nodes. There are instances in which legitimate users may leverage Tor for internet browsing and other non-malicious purposes. For example, deployed military or other overseas voters may use Tor as part of the voting process to escape monitoring by foreign governments. Such users may use Tor when visiting elections-related websites, to check voter registration status, or to mark and then cast absentee ballots via email or web portal. Similarly, some users may use Tor to avoid tracking by advertisers when browsing the internet. Organizations that do not wish to block legitimate traffic to/from Tor entry/exit nodes should consider adopting practices that allow for network monitoring and traffic analysis for traffic from those nodes, and then consider appropriate blocking. This approach can be resource intensive but will allow greater flexibility and adaptation of defensive.

Table 2: Less restrictive mitigation practices

Type Level of Effort Technical Implementation Impact
Known Tor Nodes Low/Medium

Require the organization to maintain up-to-date lists of known Tor exit and entry node IP addresses.

The Tor Project maintains an authoritative list

Up-to-date awareness of known Tor nodes to enable baselining/allow blocking
SIEM Correlation Low/Medium Integrate network security and SIEM tools that correlate logs. Enhanced understanding of legitimate/expected Tor use for inbound/outbound traffic
Baseline Medium

Analyze traffic to determine normal patterns of behavior; legitimate vs. anomalous uses of Tor.

Baseline existing Tor traffic to/from known entry/exit nodes over a period of months.

Inspect traffic to understand legitimate traffic; level-set the organization’s risk tolerance for blocking or allowing Tor traffic to/from specific services.

Baseline understanding of legitimate vs. potentially anomalous Tor uses.
Internal / External Policies Medium/High

Institute behavioral signatures/rules to block unexpected/potentially malicious activity and allow legitimate activity.

Examine activity between any ephemeral port and Tor IP—this could be malicious data exfiltration or C2 traffic (except where use of outbound Tor entry nodes is expected).

Monitor for use of TCP/UDP ports 9001, 9030, 9040, 9050, 9051, 9150, and TCP ports 443* and 8443.

Monitor and/or block inbound connections from Tor exit nodes to IP addresses and ports for which external connections are not expected (i.e., other than VPN gateways, mail ports, web ports).

Associated ports are applicable for client -> guard/relay traffic monitoring and analysis but not monitoring for exit node -> a network destination.

Monitor and examine any large dataflows between networks and Tor IP addresses, regardless of port, as this could be unauthorized data exfiltration.

*Since port 443 is the most common port for secure web traffic, generically monitoring 443 may produce a high volume of false positives; network traffic tools can be used to assist in this analysis.

Legitimate traffic via Tor entry/exit nodes is permitted and unexpected/potentially malicious activity via Tor entry/exit nodes is blocked

 

  • Blended approach: Block all Tor traffic to some resources, allow and monitor for others. Given the various licit and illicit uses of Tor, a blended approach may be an appropriate risk mitigation strategy for some organizations (i.e., intentionally allowing traffic to/from Tor only for specific websites and services where legitimate use may be expected and blocking all Tor traffic to/from non-excepted processes/services). This may require continuous re-evaluation as an entity considers its own risk tolerance associated with different applications. The level of effort to implement this approach is high.

Considerations for Blocking Use of Tor

Sophisticated threat actors may leverage additional anonymization technologies—such as virtual private networks (VPNs)—and configurable features within Tor—such as Tor bridges and pluggable transports—to circumvent detection and blocking. Blocking the use of known Tor nodes may not effectively mitigate all hazards but may protect against less sophisticated actors. For example, blocking outbound traffic to known Tor entry nodes could have an appreciable impact in blocking less sophisticated malware from successfully beaconing out to hidden C2 machines obfuscated by Tor. Ultimately, each entity must consider its own internal thresholds and risk tolerance when determining a risk mitigation approach associated with Tor.

Contact Information

To report suspicious or criminal activity related to information found in this Joint Cybersecurity Advisory, contact your local FBI field office at www.fbi.gov/contact-us/field, or the FBI’s 24/7 Cyber Watch (CyWatch) at (855) 292-3937 or by e-mail at CyWatch@fbi.gov. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. To request incident response resources or technical assistance related to these threats, contact CISA at CISAServiceDesk@cisa.dhs.gov.

Disclaimer

This document is marked TLP:WHITE. Disclosure is not limited. Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction. For more information on the Traffic Light Protocol, see http://www.us-cert.gov/tlp/.

References

Revisions

  • July 1, 2020: Initial Version

This product is provided subject to this Notification and this Privacy & Use policy.

AA20-182A: EINSTEIN Data Trends – 30-day Lookback

This post was originally published on this site

Original release date: June 30, 2020

Summary

Cybersecurity and Infrastructure Security Agency (CISA) analysts have compiled the top detection signatures that have been the most active over the month of May in our national Intrusion Detection System (IDS), known as EINSTEIN. This information is meant to give the reader a closer look into what analysts are seeing at the national level and provide technical details on some of the most active threats.

IDS is a network tool that uses sensors to monitor inbound and outbound traffic to search for any type of suspicious activity or known threats, alerting analysts when a specific traffic pattern matches with an associated threat. IDS allows users to deploy signatures on these boundary sensors to look for the specific pattern, or network indicator, associated with a known threat.

The EINSTEIN Program is an automated process for collecting, correlating, analyzing, and sharing computer security information across the federal civilian departments and agencies. By collecting information from participating federal departments and agencies, CISA builds and enhances our Nation’s cyber-related situational awareness.

The signatures CISA created have been included below for analysts across various organizations to use in enhancing their own network defenses. Note: CISA has created and tested these signatures in an environment that might not be the same for all organizations, so administrators may need to make changes or updates before using in the following signatures in their local environments.

Technical Details

Note: the below Snort signatures accounted for over 90 percent of what CISA analysts identified as potential threats using the IDS system for detection.

1. NetSupport Manager RAT

Description

The NetSupport Manager Remote Access Tool (RAT) is a legitimate program that, once installed on a victim’s machine, allows remote administrative control. In a malicious context, it can—among many other functions—be used to steal information. Malicious RATs can be difficult to detect because they do not normally appear in lists of running programs, and they can mimic the behavior of legitimate applications.

Examples

In January 2020, Palo Alto researchers observed the abuse of NetSupport in targeted phishing email campaigns.[1] In November 2019, Zscaler researchers observed “software update-themed” campaigns tricking users into installing a malicious NetSupport Manager RAT.[2] The earliest malicious use of NetSupport was seen in a phishing email campaign—reported by FireEye researchers in April 2018.[3]

Snort Signature

alert tcp any any -> any $HTTP_PORTS (msg:"NetSupportManager:HTTP Client Header contains 'User-Agent|3a 20|NetSupport Manager/'"; flow:established,to_server; flowbits:isnotset,.tagged; content:"User-Agent|3a 20|NetSupport Manager/"; http_header; fast_pattern:only; content:"CMD="; nocase; http_client_body; depth:4; content:"POST"; nocase; http_method; flowbits:set,.; classtype:http-header; reference:url,unit42.paloaltonetworks.com/cortex-xdr-detects-netsupport-manager-rat-campaign/; reference:url,www.pentestpartners.com/security-blog/how-to-reverse-engineer-a-protocol/; reference:url,github.com/silence-is-best/c2db;

2. Kovter

Description

Kovter is a fileless Trojan with several variants. This malware started as ransomware that malicious actors used to trick victims into thinking that they need to pay their local police a fine. Cyber actors have also used Kovter to perform click-fraud operations to infect targets and send stolen information from the target machines to command and control servers. Kovter’s evolving features have allowed this malware to rank among the Center for Internet Security’s most prolific malware year after year.[4] See CISA’s Webinar on Combatting Ransomware for additional information on Kovter.

Snort Signature

alert tcp any any -> any $HTTP_PORTS (msg:"Kovter:HTTP URI POST to CnC Server";; flow:established,to_server; flowbits:isnotset,.tagged; content:"POST / HTTP/1.1"; depth:15; content:"Content-Type|3a 20|application/x-www-form-urlencoded"; http_header; depth:47; fast_pattern; content:"User-Agent|3a 20|Mozilla/"; http_header; content:!"LOADCURRENCY"; nocase; content:!"Accept"; http_header; content:!"Referer|3a|"; http_header; content:!"Cookie|3a|"; nocase; http_header; pcre:"/^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{4})$/P"; pcre:"/User-Agentx3a[^rn]+rnHostx3ax20(?:d{1,3}.){3}d{1,3}rnContent-Lengthx3ax20[1-5][0-9]{2,3}rn(?:Cache-Control|Pragma)x3a[^rn]+rn(?:rn)?$/H";; classtype:nonstd-tcp;; reference:url,www.malware-traffic-analysis.net/2017/06/29/index2.html;

3. XMRig

Description

XMRig is a type of cryptocurrency miner that uses the resources of an unsuspecting infected machine to mine Monero—a type of cryptocurrency. XMRig can cause a victim computer to overheat and perform poorly by using additional system resources that would otherwise not be active.

Snort Signature

alert tcp any any -> any !25 (msg:"XMRIG:Non-Std TCP Client Traffic contains JSONRPC 2.0 Config Data";; flow:established,to_server; flowbits:isnotset; content:"|22|jsonrpc|22 3a 22|2.0|22|"; distance:0; content:"|22|method|22 3a 22|login|22|"; distance:0; content:"|22|agent|22 3a 22|XMRig"; nocase; distance:0; fast_pattern; content:"libuv/"; nocase; distance:0; content:!"|22|login|22 3a 22|x|22|"; flowbits:set,; classtype:nonstd-tcp;; reference:url,malware-traffic-analysis.net/2017/11/12/index.html; reference:url,www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=1101;

Mitigations

CISA recommends using the following best practices to strengthen the security posture of an organization’s systems. Any configuration changes should be reviewed by system owners and administrators prior to implementation to avoid unwanted impacts.

  • Maintain up-to-date antivirus signatures and engines. See Protecting Against Malicious Code.
  • Ensure systems have the latest security updates. See Understanding Patches and Software Updates.
  • Disable file and printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
  • Restrict users’ permissions to install and run unwanted software applications. Do not add users to the local administrators’ group unless required.
  • Enforce a strong password policy. See Choosing and Protecting Passwords.
  • Exercise caution when opening email attachments, even if the attachment is expected and the sender appears to be known. See Using Caution with Email Attachments.
  • Enable a personal firewall on agency workstations that is configured to deny unsolicited connection requests.
  • Disable unnecessary services on agency workstations and servers.
  • Scan for and remove suspicious email attachments; ensure the scanned attachment is its “true file type” (i.e., the extension matches the file header).
  • Monitor users’ web browsing habits; restrict access to sites with unfavorable content.
  • Exercise caution when using removable media (e.g., USB thumb drives, external drives, CDs).
  • Scan all software downloaded from the internet prior to executing.
  • Maintain situational awareness of the latest threats and implement appropriate Access Control Lists (ACLs). Sign up to receive CISA’s alerts on security topics and threats.
  • Sign up for CISA’s free vulnerability scanning and testing services to help organizations secure internet-facing systems from weak configuration and known vulnerabilities. Email vulnerability_info@cisa.dhs.gov to sign up. See https://www.cisa.gov/cyber-resource-hub for more information about vulnerability scanning and other CISA cybersecurity assessment services.

Resources

https://unit42.paloaltonetworks.com/cortex-xdr-detects-netsupport-manager-rat-campaign/
https://threatpost.com/netsupport-manager-rat-nortonlifelock-docs/153387/
https://www.zdnet.com/article/new-lokibot-trojan-malware-campaign-comes-disguised-as-a-popular-game-launcher/
https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/kovter-an-evolving-malware-gone-fileless
https://www.varonis.com/blog/what-is-mimikatz/

References

Revisions

  • June 30, 2020: Initial Version

This product is provided subject to this Notification and this Privacy & Use policy.

AA20-182A: EINSTEIN Data Trends – 30-day Lookback

This post was originally published on this site

Original release date: June 30, 2020

Summary

Cybersecurity and Infrastructure Security Agency (CISA) analysts have compiled the top detection signatures that have been the most active over the month of May in our national Intrusion Detection System (IDS), known as EINSTEIN. This information is meant to give the reader a closer look into what analysts are seeing at the national level and provide technical details on some of the most active threats.

IDS is a network tool that uses sensors to monitor inbound and outbound traffic to search for any type of suspicious activity or known threats, alerting analysts when a specific traffic pattern matches with an associated threat. IDS allows users to deploy signatures on these boundary sensors to look for the specific pattern, or network indicator, associated with a known threat.

The EINSTEIN Program is an automated process for collecting, correlating, analyzing, and sharing computer security information across the federal civilian government. By collecting information from participating federal government agencies, CISA builds and enhances our Nation’s cyber-related situational awareness.

The signatures CISA created have been included below for analysts across various organizations to use in enhancing their own network defenses. Note: CISA has created and tested these signatures in an environment that might not be the same for all organizations, so administrators may need to make changes or updates before using in the following signatures in their local environments.

Technical Details

Note: the below Snort signatures accounted for over 90 percent of what CISA analysts identified as potential threats using the IDS system for detection.

1. NetSupport Manager RAT

Description

The NetSupport Manager Remote Access Tool (RAT) is a legitimate program that, once installed on a victim’s machine, allows remote administrative control. In a malicious context, it can—among many other functions—be used to steal information. Malicious RATs can be difficult to detect because they do not normally appear in lists of running programs, and they can mimic the behavior of legitimate applications.

Examples

In January 2020, Palo Alto researchers observed the abuse of NetSupport in targeted phishing email campaigns.[1] In November 2019, Zscaler researchers observed “software update-themed” campaigns tricking users into installing a malicious NetSupport Manager RAT.[2] The earliest malicious use of NetSupport was seen in a phishing email campaign—reported by FireEye researchers in April 2018.[3]

Snort Signature

alert tcp any any -> any $HTTP_PORTS (msg:"NetSupportManager:HTTP Client Header contains 'User-Agent|3a 20|NetSupport Manager/'"; flow:established,to_server; flowbits:isnotset,.tagged; content:"User-Agent|3a 20|NetSupport Manager/"; http_header; fast_pattern:only; content:"CMD="; nocase; http_client_body; depth:4; content:"POST"; nocase; http_method; flowbits:set,.; classtype:http-header; reference:url,unit42.paloaltonetworks.com/cortex-xdr-detects-netsupport-manager-rat-campaign/; reference:url,www.pentestpartners.com/security-blog/how-to-reverse-engineer-a-protocol/; reference:url,github.com/silence-is-best/c2db;

2. Kovter

Description

Kovter is a fileless Trojan with several variants. This malware started as ransomware that malicious actors used to trick victims into thinking that they need to pay their local police a fine. Cyber actors have also used Kovter to perform click-fraud operations to infect targets and send stolen information from the target machines to command and control servers. Kovter’s evolving features have allowed this malware to rank among the Center for Internet Security’s most prolific malware year after year.[4] See CISA’s Webinar on Combatting Ransomware for additional information on Kovter.

Snort Signature

alert tcp any any -> any $HTTP_PORTS (msg:"Kovter:HTTP URI POST to CnC Server";; flow:established,to_server; flowbits:isnotset,.tagged; content:"POST / HTTP/1.1"; depth:15; content:"Content-Type|3a 20|application/x-www-form-urlencoded"; http_header; depth:47; fast_pattern; content:"User-Agent|3a 20|Mozilla/"; http_header; content:!"LOADCURRENCY"; nocase; content:!"Accept"; http_header; content:!"Referer|3a|"; http_header; content:!"Cookie|3a|"; nocase; http_header; pcre:"/^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{4})$/P"; pcre:"/User-Agentx3a[^rn]+rnHostx3ax20(?:d{1,3}.){3}d{1,3}rnContent-Lengthx3ax20[1-5][0-9]{2,3}rn(?:Cache-Control|Pragma)x3a[^rn]+rn(?:rn)?$/H";; classtype:nonstd-tcp;; reference:url,www.malware-traffic-analysis.net/2017/06/29/index2.html;

3. XMRig

Description

XMRig is a type of cryptocurrency miner that uses the resources of an unsuspecting infected machine to mine Monero—a type of cryptocurrency. XMRig can cause a victim computer to overheat and perform poorly by using additional system resources that would otherwise not be active.

Snort Signature

alert tcp any any -> any !25 (msg:"XMRIG:Non-Std TCP Client Traffic contains JSONRPC 2.0 Config Data";; flow:established,to_server; flowbits:isnotset; content:"|22|jsonrpc|22 3a 22|2.0|22|"; distance:0; content:"|22|method|22 3a 22|login|22|"; distance:0; content:"|22|agent|22 3a 22|XMRig"; nocase; distance:0; fast_pattern; content:"libuv/"; nocase; distance:0; content:!"|22|login|22 3a 22|x|22|"; flowbits:set,; classtype:nonstd-tcp;; reference:url,malware-traffic-analysis.net/2017/11/12/index.html; reference:url,www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=1101;

Mitigations

CISA recommends using the following best practices to strengthen the security posture of an organization’s systems. Any configuration changes should be reviewed by system owners and administrators prior to implementation to avoid unwanted impacts.

  • Maintain up-to-date antivirus signatures and engines. See Protecting Against Malicious Code.
  • Ensure systems have the latest security updates. See Understanding Patches and Software Updates.
  • Disable file and printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
  • Restrict users’ permissions to install and run unwanted software applications. Do not add users to the local administrators’ group unless required.
  • Enforce a strong password policy. See Choosing and Protecting Passwords.
  • Exercise caution when opening email attachments, even if the attachment is expected and the sender appears to be known. See Using Caution with Email Attachments.
  • Enable a personal firewall on agency workstations that is configured to deny unsolicited connection requests.
  • Disable unnecessary services on agency workstations and servers.
  • Scan for and remove suspicious email attachments; ensure the scanned attachment is its “true file type” (i.e., the extension matches the file header).
  • Monitor users’ web browsing habits; restrict access to sites with unfavorable content.
  • Exercise caution when using removable media (e.g., USB thumb drives, external drives, CDs).
  • Scan all software downloaded from the internet prior to executing.
  • Maintain situational awareness of the latest threats and implement appropriate Access Control Lists (ACLs). Sign up to receive CISA’s alerts on security topics and threats.
  • Sign up for CISA’s free vulnerability scanning and testing services to help organizations secure internet-facing systems from weak configuration and known vulnerabilities. Email vulnerability_info@cisa.dhs.gov to sign up. See https://www.cisa.gov/cyber-resource-hub for more information about vulnerability scanning and other CISA cybersecurity assessment services.

Resources

https://unit42.paloaltonetworks.com/cortex-xdr-detects-netsupport-manager-rat-campaign/
https://threatpost.com/netsupport-manager-rat-nortonlifelock-docs/153387/
https://www.zdnet.com/article/new-lokibot-trojan-malware-campaign-comes-disguised-as-a-popular-game-launcher/
https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/kovter-an-evolving-malware-gone-fileless
https://www.varonis.com/blog/what-is-mimikatz/

References

Revisions

  • June 30, 2020: Initial Version

This product is provided subject to this Notification and this Privacy & Use policy.

ISC Snapshot: SpectX IP Hitcount Query, (Tue, Jun 30th)

This post was originally published on this site

SpectX was the subject of an ISC post on SpectX4DFIR back in late April. Raido from SpectX provides us with a query to count hits from IPs during different time intervals.

This can be one way of detecting possible bots and automated queries. Running the query below will tell you:

  1. On how many different days do we have hits from a particular IP (column ‘days’)?
  2. On how many different days did we see this IP every hour, 24 hours in a row (column ‘full_days’)?
  3. During how many different hours did we get hits from this IP? (column ‘hours’)?

I ran the query below, slightly modified from Raido’s original, against the April 2020 log file for holisticinfosec.io. You can run this on any log file that contains timestamps and IP-addresses, just change the path, pattern and field names accordingly.

LIST('file:/C:/logs/holisticinfosec.io-ssl_log-Apr-2020') 
| parse(pattern:$[/user/patterns/apache/apacheLog.sxp])
| select(hour:timestamp[1 hour], clientIp) 
| group(hour, clientIp) 
| select(day:hour[24 hour], clientIp, hours:count(*))
| group(day, clientIp)
| select(clientIp, days:count(*), full_days:count(hours = 24), hours:sum(hours))
| group(clientIp)
| sort(full_days desc)

The results as seen in Figure 1 provided immediate insights.

Figure 1: SpectX IP hitcount query result

As promised, these IPs as noted in the results per Figure 1 are all making constant calls to my site, all day, every day. Each are calling my index.xml file, some appear to be RSS readers or scrapers, which is fairly routine. Seems like a lot of needless connect and compute cycles for a low traffic, static site such as mine.
Some of these IPs are definitely of ill repute however. 173.212.239.212, originating out of Nuremberg, Bavaria scored a near perfect 99 of 100 for fraudulent behavior and malicious activity based on recent actions according to IPQSFigure 2 bears this out.

Figure 2: IPQS declares badness

This is useful little query to quickly detect possible bots and automated queries. Hopefully you’ve already downloaded SpectX and given a try after a last post. Load it back up and feed a log. If you want a copy of the log as utilized for this post, let me know via socials or email.

Cheers…until next time.

Russ McRee | @holisticinfosec

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.