Archive for June 30th, 2020

Elastalert with Sigma, (Wed, Jul 1st)

A couple of weeks ago, Remco wrote a post about Sigma(1). I’ve also been spending a good bit of time setting up Elastalert rules with Sigma and wanted to expand on his great post. We are going to set up an elastalert rule for sigma_zeek_smb_converted_win_atsvc_task(2).


Convert Rule

Sigmac -t elastalert -c ./elastic_schema_config_file.yml /tmp/sigma/rules/sigma_zeek_smb_converted_win_atsvc_task >>/etc/elastalert/rules/sigma_zeek_smb_converted_win_atsvc_task.yml


Let’s see what this rule is doing

This rule is looking at the bro_smb_files events where IPC$ and atsvc show up.



– debug

description: Detects remote task creation via at.exe or API interacting with ATSVC namedpipe


– query:


      query: (event_type:”bro_smb_files” AND path.keyword:\*\IPC$ AND name:”atsvc”)

index: ‘*:logstash-bro-*’

name: f6de6525-4509-495a-8a82-1f8b0ed73a00_0

priority: 3


  minutes: 0

type: any


query_key: [“source_ip”, “destination_ip”]


Test it

On Security onion they have a command builtin called so-elastalert-test. 

#sudo so-elastalert-test -r /etc/elastalert/rules/sigma_zeek_smb_converted_win_atsvc_task.yml


1. Is the query running too slow?

2. Is it looking at the right data?

3. Are the results as expected?


elastalert_status – {‘rule_name’: ’66a0bdc6-ee04-441a-9125-99d2eb547942_0′, ‘endtime’: datetime.datetime(2020, 5, 29, 14, 51, 13, 474764, tzinfo=tzutc()), ‘starttime’: datetime.datetime(2020, 5, 28, 14, 51, 13, 474764, tzinfo=tzutc()), ‘matches’: 0, ‘hits’: 183990, ‘@timestamp’: datetime.datetime(2020, 5, 29, 14, 53, 2, 609529, tzinfo=tzutc()), ‘time_taken’: 109.09370565414429}


If you are not getting any hits for the rule, expand the search to see if you have any true/false positives. On security onion manually, call the rule test and use the –days option. 


#docker exec -it so-elastalert bash -c ‘elastalert-test-rule /etc/elastalert/rules/sigma_zeek_smb_converted_win_atsvc_task.yml –days 25’


You may have false positives from your administrator’s desktops talking to other systems, and you will need to adjust the alert to not match on these IP’s. Once you are happy with the results, we need to add it to our alert/IR platform. In this case, we are going to send it to TheHive.


At the bottom of sigma_zeek_smb_converted_win_atsvc_task.yml you want to add TheHive config. The MITRE Tags are not being transferred to the elastalert rule, and we’ll add them manually.




  hive_host: https://ip

  hive_port: 9443




  title: ‘ Sigma Remote Task Creation via ATSVC Named Pipe {match[source_ip]} — {match[destination_ip]}’

  type: ‘alarm’

  source: ‘Sigma’

  description: ‘Alert : {match[source_ip]}


  tags: [‘elastalert’, ‘attack.lateral_movement’, ‘attack.persistence’, ‘attack.t1053′,’car.2013-05-004′,’car.2015-04-001’, ‘sigma’]

  tlp: 1

  status: ‘New’

  follow: True

  sourceRef: ‘{match[source_ip]}{match[destination_ip]}’



  – ip: ‘{match[source_ip]}’

  – ip: ‘{match[destination_ip]}’



Now restart elastalert service and you should start getting alerts on any of these matches.






(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

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

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 You can run this on any log file that contains timestamps and IP-addresses, just change the path, pattern and field names accordingly.

| 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., 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. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →