Monero Mining Pool FQDNs

Malware that deploys crypto mining software has become more and more popular and annoying. It’s not always possible to scan every device in your network with our free or commercial compromise assessment scanners.

The good news is that the mining pools for the most popular crypto currency Monero (Symbol: XMR) are limited.

Therefore we’ve decided to compile a list of these mining pools that you can use to monitor your firewall or DNS servers.

For a very generic approach, your could try using the following patterns:

*xmr.*
*pool.com
*pool.org
pool.*

Our customers can use THOR to scan for scripts, executables, DNS cache, process connections, log entries and other elements for traces of crypto mining activity.

Monero Mining Pool Addresses

pool.minexmr.com
fr.minexmr.com
de.minexmr.com
sg.minexmr.com
ca.minexmr.com
us-west.minexmr.com
pool.supportxmr.com
mine.c3pool.com
xmr-eu1.nanopool.org
xmr-eu2.nanopool.org
xmr-us-east1.nanopool.org
xmr-us-west1.nanopool.org
xmr-asia1.nanopool.org
xmr-jp1.nanopool.org
xmr-au1.nanopool.org
xmr.2miners.com
xmr.hashcity.org
xmr.f2pool.com
xmrpool.eu
pool.hashvault.pro
moneroocean.stream
monerocean.stream

Antivirus Event Analysis Cheat Sheet v1.8.2

The analysis of Antivirus events can be a tedious task in big organizations with hundreds of events per day. Usually security teams fall back to a mode of operation in which they only analyze events in which a cleanup process has failed or something went wrong. 

This is definitely the wrong approach for a security team. You should instead focus on highly relevant events. 

This cheat sheet helps you select these highly relevant Antivirus alerts.  

Download the Antivirus Event Analysis Cheat Sheet version 1.8.2 here.

Web Proxy Event Analysis Cheat Sheet

The “Web Proxy Event Analysis Cheat Sheet” can help SOCs and security analysts classify proxy events (blocks, alerts) and is based on my ideas and many ideas from experts that helped me collect detection ideas for this document.

You can download version 1.0 here.

We also recommend checking Sigma’s “proxy” section for detection rules that can be used to detect threats in web proxy or similar logs as long as they contain web connection information (EDR, HIDS etc.).

 

Web Proxy Event Analysis Cheat Sheet

Antivirus Event Analysis Cheat Sheet v1.7

We’ve just released an updated version of our Antivirus Event Analysis cheat sheet. You can download version 1.7 here.

The major changes are:

  • Updated AV signature lists
  • Split AV signature cells into two columns to save space
  • Fixed and added some directory names
  • Extended file extension list
  • Google filename search
  • More Virustotal checks

SPARK uses Sigma Rules in Eventlog Scan

Sigma is a rule format for threat detection in log files. It is for log data what “Snort rules” are for network traffic or “YARA signatures” are for file data. It is easy to write and read. Writing a Sigma rule is a matter of minutes.

On the right you can see a simple Sigma rule that checks the “System” eventlog for traces of password dumper activity. The detection section contains 1+ identifiers (selection, keywords, quarkspwdump) that can be defined freely by the rule author. These selectors are used in the condition to build the rule.

It also contains a description, references, possible false positives and a level.

Analysts use Sigma to generate search queries for their SIEM or log management solution. The Sigma repo contains a converter that allows to convert the generic rules to ElasticSearch, Splunk, QRadar, Logpoint, Windows Defender ATP (WDATP) and ArcSight.

Wouldn’t it be great if you could apply Sigma rules on the endpoint?

Well, the upcoming version 1.14 of SPARK, which will be released at the end of July,  does that. It applies Sigma rules to the local Eventlog. This way you’re able to apply searches that you have once defined for your SIEM to the local Eventlogs.

This way you are able “query” the standalone systems that are not connected to your SIEM and uncover otherwise common blind spots in your environment.

 

We ship the current rule set, which is part of the public Sigma repository and contains more than 200 rules with our SPARK program package in an encrypted form. (*.yms)

You can add your own Sigma rules to the “./custom-signatures/sigma/” folder in the SPARK program directory.

To activate Sigma scanning, use the new “–sigma” parameter.

Currently only SPARK supports this feature and there are no plans to implement this in THOR as well.

The feature is currently free for all customers but may become a premium feature that has to be licensed separately by the end of the year depending on the customer’s plan. 

See the comparison table for a complete overview on all features.

New Antivirus Event Analysis Cheat Sheet Version 1.2

Today we release a new version of our “Antivirus Event Analysis” Cheat Sheet that helps you with the analysis of Antivirus events by providing a clear decision matrix.

We’ve updated many of the sections, added new VirusTotal online analysis checks and brought it in a new format.

You can download the PDF version here.

The Best Possible Monitoring with Sigma Rules

Some of you may already have heard of Sigma, a generic approach for signatures used in SIEM systems. Its main purpose is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others.
Today I would like to describe another use case that helps us build the best possible signatures for any application.
In typical security monitoring projects, people integrate different log sources and threats/use cases they want to monitor in these logs. The selection of the log sources is determined by importance, availability and operational requirements. The central question is:

“What do I want to detect?”

There are several white papers and guides for the most common log sources like the Windows Eventlog. What you have to do is to read the documents, extract the interesting detection methods and define searches, panels and dashboards in your SIEM system. One of the main purposes of Sigma is to relieve you from this time consuming process. These public descriptions of detection methods are already part of Sigma or will be integrated by one of the contributors.
But today I’d like to point out a different use case that is less obvious but very useful.

The Best Possible Monitoring

Security analysts try to define useful searches and statistical analyses on the log data from all different log sources. They typically follow the public guides and create many different “failed logon” rules for all kinds of operating systems and applications.
But what happens when start integrating log sources and types that are not covered by public guidelines?
There are different approaches to this problem:

  • Cover failed authentication attempts
  • Monitor any failure event (with a base-lining)
  • Use statistic deviations (many new events of a certain type)
  • Look through the log data and select interesting messages
  • Talk to the application owners / administrators (often rather disappointing)
  • Talk with the application developers (in case of inhouse development)

All of these methods are valid and can help you setup useful searches on the available data. However, in order to create the best possible signatures we have to consider the following:

  • The most interesting and relevant fault conditions do not happen under normal conditions and therefore do not appear in everyday log data (the log data we have to select interesting events from)
  • Developers know the rarest or most relevant error conditions and the corresponding error IDs and messages
  • All possible error messages of that application appear in its source code

Imagine that we can extract the most interesting messages that the application is able to generate and define rules for these conditions. Imagine that this process is an easy task that any developer is able to perform.
Well, we have at our fingertips all the tools that are needed.

An Example: vsftpd

Let’s make this approach clearer. Under optimal conditions we ask the developers to extract the most relevant or abnormal error messages that the applications produces under conditions that indicate a manipulation or attack. Alternatively, we can do it ourselves and cross-check the results with the available log data to avoid false positives.
I checked the source code of the FTP server ‘vsftpd’ for error messages that indicate rare error conditions and fatal failures.

The resulting Sigma rule looks like this:

title: Suspicious VSFTPD error messages
description
: Detects suspicious VSFTPD error messages that indicate a fatal or suspicious error that could be caused by exploiting attempts
reference
: https://github.com/dagwieers/vsftpd/
author
: Florian Roth
date
: 2017/07/05
logsource
:
    product
: linux
    service
: vsftpd
detection
:
    keywords
:
        - 'Connection refused
: too many sessions for this address.'
        - 'Connection refused
: tcp_wrappers denial.'
        - 'Bad HTTP verb.'
        - 'port and pasv both active'
        - 'pasv and port both active'
        - 'Transfer done (but failed to open directory).'
        - 'Could not set file modification time.'
        - 'bug
: pid active in ptrace_sandbox_free'
        - 'PTRACE_SETOPTIONS failure'
        - 'weird status:'
        - "couldn't handle sandbox event"
        - 'syscall * out of bounds'
        - 'syscall not permitted:'
        - 'syscall validate failed:'
        - 'Input line too long.'
        - 'poor buffer accounting in str_netfd_alloc'
        - 'vsf_sysutil_read_loop'
    condition
: keywords
falsepositives
:
   - Unknown
level
: medium

After some testing we can now share the rule with the world in order to build a large signature database for the all different types of applications and services.
We could also try to convince developers to provide Sigma rules with their applications to help organisations establish the best possible monitoring of their software. I was thinking about an error message extractor that would parse a software project and extract error message strings that contain certain keywords like “failure”, “fatal”, “permission denied”, “refused” and others to facilitate this process for the rule writer.
If you want to support the project, create a pull request or send me your rules as gists or via pastebin to @cyb3ops. You could also become a contributor by providing a new backend for the rule converter “Sigmac” or become a member of our Slack team for threat hunters (references required).

Not All IOC Scanning Is the Same

In the recent months I had several talks with friends and coworkers about IOC scanning and how to integrate IOCs from threat intel feeds into our scanners or other products that our customers already use. People often tell me that EDR or client management product X already does IOC scanning and that we don’t need to check for these indicators a second time. Especially when it comes to network wide sweeps for traces of activity due to an ongoing incident I recommend scanning a second time with one of our scanners or a tool of similar quality.
This blog post explains why.
People usually spend a fair amount of time on selecting threat intel feeds and interesting indicators for their scans. However when it comes to the actual application of these indicators they seem to be satisfied with the simplest form of checks.
Especially when we look at C2 or Filename IOCs I can easily explain the difference between the “compulsory” and “freestyle” methods of IOC scanning.
IOC scanning automation
A plain “compulsory” filename IOC check would walk the disk or query a database looking for a certain filename, right?
However if you think about it for a second and ask yourself “where else could we check for that filename?” you’ll realize that the following elements could also contain the malicious filename:

  • Eventlog entries (e.g. process starts, service installs with image path, access failures …)
  • Log files (local Antivirus log file, access to file in web root > web server access log, backup errors, PowerShell history …)
  • Registry (recently opened files, shell bags, service image path, other caches …)
  • MFT (deleted entry)
  • Archive content (packed in ZIP file)
  • WMI (scripts – e.g. see this PoC by Matt Graeber)
  • Crash dumps
  • Windows Error Report (WER – file names and content)
  • Free disk space (filename as content of batch files or other scripts, scheduled tasks …)

Actually we often see that during lateral movement attackers access systems, run their tools remotely, copy the output, delete the output files and leave no file system traces behind. We use the locations that I mentioned above and others to detect them using their tools although all the files have been removed from disk. That’s the “freestyle” method.
The same counts for the C2 IOCs. The “compulsory” plain method would check the system’s network connections. The “freestyle” method also includes checking for these C2 IOCs in the following locations:

  • Process memory (C2 strings loaded and decrypted in process memory)
  • Log files (web server access logs, Windows firewall log file, AV module log file …)
  • Hosts file
  • Files (in backdoor config files on disk)
  • Registry (hard coded C2 server in registry key)

I am sure that digital forensics experts would come up with other fruitful locations. It is just sad to see those great indicators feed into tools that do “IOC scanning” only to get another check mark in a product comparison table – aka the “compulsory” way.

If all you have is a hammer, everything looks like a nail.

So – the next time when someone tells you that their tool checks for IOCs on the endpoint, your question should be “How and where do you check for these IOCs?”.

WordPress Cookie Plugin by Real Cookie Banner