Archive for June 19th, 2020

Pi Zero HoneyPot , (Sat, Jun 20th)

The ISC has had a Pi honeypot(1) for the last couple of years, but I haven’t had much time to try it on the Pi zero. Recently, I’ve had a chance to try it out, and it works great. 



With the Pi zero($5), it has no network built-in at all. To connect, you need a micro USB wifi adapter or micro USB ethernet. You probably don’t want all that extra traffic on your wifi network, so wired is the best option. 

I’m using the pluggable USB2-E100 with a USB to Micro-USB adaptor. I already had it for another reason but is working well. Here is a list of tested USB adapters for the Pi. (2) Most of these cost around $10-$15. There are some cheap options on the form, but I haven’t tried them. (3)

The Pi zero uses Micro USB for power. If you have an old phone charger lying around, you can use that. You will need a case, micro SD card (at least 8GB), and ethernet. If you have a friend with a 3d printer and an old microSD card, all you need is the Pi zero and USB ethernet.


For the total cost if you have nothing to start with:

Pi zero with power, case, micro sd card ~ $20

USB Ethernet Adapters $1-$15



The Pi3b+ has one ethernet standard USB and lots of other features, but the starter kit is $79 dollars, which is more than double the cost. While you could get the latest Pi4, for the honeypot its way overkill for the price. Also, they run pretty hot and need more cooling, but they do have USB-C for power. 



Johannes has an excellent video that walks you through the whole process. (3) The install takes quite a long time to download and get set up on the Pi zero. I believe it took around an hour or so. Once it’s done, performance has been excellent.

But in short:

1. Download Pi Raspberry Pi OS (32-bit) Lite

2. Burn Image to MicroSD on Windows with Etcher (4)

3. Make config changes

4. Boot Pi and SSH

5. Change default password

6. Run screen or BYOBU

7. Install honeypot

8. Setup ubuntu auto patching


Additional Tweaks for the Pie Zero

Once you get everything set up, you will want to remove the service random sound. This service is supposed to generate entropy but pegs the pi zero CPU at 100 percent.

$sudo apt-get remove randomsound


For performance monitoring over time, use TTYload. It’s a great little tool to make sure your pi is doing ok once you start sending traffic to it. 

#apt-get install ttyload



Most of the data is stored in the /srv folder and here are the location of the key logs.





I wrote a simple bash script(6) that you can cron to send out daily emails of logs for yourself to monitor. These logs are automatically sent to the ISC Storm Center, but you usually do not have visibility from the website for the web application traffic your honeypot gets. 


For a small investment, it’s a great project to set up and play with.


Johannes is going to talk on Tuesday about the honeypot (7) check it out!










Tom Webb


(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) →

Sigma rules! The generic signature format for SIEM systems., (Fri, Jun 19th)

What Snort is to network traffic, and YARA to files, is Sigma to logs. By creating and using Sigma rules you’ll have generic rules which can be shared and run against different targets (e.g. SIEMs).

Sigma solves the issue of everyone working on their own analysis, searches and dashboards of log data they’ve collected by having a standardized format to create rules to be reused and shared with others, supporting many different target systems. Many targets are supported currently: Splunk (plainqueries and dashboards),  ElasticSearch Query Strings,  ElasticSearch Query DSL, Kibana, Elastic X-Pack Watcher, Logpoint, Microsoft Defender Advanced Threat Protection (MDATP), Azure Sentinel / Azure Log Analytics, Sumologic, ArcSight, QRadar, Qualys, RSA NetWitness, PowerShell, Grep with Perl-compatible regular expression support, LimaCharlie, ee-outliers.

Some of the use cases for Sigma are:

  • Describe the detection methods and make it available.
  • Invest in generating rules for Sigma and use on many different (e.g. SIEM) systems.
  • Share the signature as an appendix of your analysis.
  • Use Sigma to share the signature with other threat intel communities.

A Sigma rule consists of a YAML file and the specification can be found here, and contains the following sections:

  • metadata (id, tags, author, title, references, level)
  • status (experimental or normal), the status is being used to filter on experimental or normal rules.
  • the log source, which defines the source of the log data
  • detections (one or more selectors, timeframe and condition)
  • optional tags
  • false positives, describing scenarios where false positives could be triggered as help for the analyst

The detection is the most important part of the rule, defining when the rule will be triggered. It contains one or more selectors, each selector can be a map (all joined with a logical function and) or list (logical function or) and be nested. The map or list will contain the column to test (using wildcards for fields) and a value, with optional transformations (contains, all, base64, startswith, endswith, etc.) or type modifiers (regular expression). An optional timeframe will define the period for the selector to be aggregated on. The condition will tie everything together, evaluating the selectors using an expression that is usually complex. Within the condition, logical functions like and/or, not, one of, any of and aggregations expressions (count, min, max, avg and sum) on selectors (which can use wildcards) can be used.

As an example, this rule detects the removal of immutable file attributes on linux systems logged by auditd. The selection will evaluate logs of type=’EXECVE’, and a0 to content “chattr” and a1 to contain “-i”. If the condition (in this case, if selection evaluates to true) applies, the rule will trigger.

title: Remove Immutable File Attribute
id: a5b977d6-8a81-4475-91b9-49dbfcd941f7
description: Detects removing immutable file attribute
status: experimental
    - attack.defense_evasion
    - attack.t1222
author: Jakob Weinzettl,
date: 2019/09/23
    product: linux
    service: auditd
        type: 'EXECVE'
        a0|contains: 'chattr'
        a1|contains: '-i'
    condition: selection
    - Administrator interacting with immutable files (for instance backups)
level: medium


Selections and conditions can become very sophisticated, allowing fine grained control and evaluations. A more complex detection is given below, where it will trigger if the sum of the question lengths, grouped by src_ip within 1m meeting the “selection” criteria (on each dns query).

        query: '*'
    timeframe: 1m
    condition: selection | sum(question_length) by src_ip > 300000


The Sigma repository contains besides many rules, also sigmac, the sigma compiler. The sigma compiler compiles the Sigma rule to a different target system, e.g. Elasticsearch. If you want to play around with Sigma, it will be easiest to setup a docker container. As an example, we will use sigmac to compile the rule to an elasticsearch query, with as configuration of elk-windows resulting into the following query:

$ git clone
$ docker run -v $(pwd):/work python:3
$ cd /work/sigma
$ python tools/ install
$ tools/sigmac -I -t es-qs -c elk-windows ./rule.yaml
(type:"EXECVE" AND a0.keyword:*chattr* AND a1.keyword:*-i*)


Another way to test and play with Sigma and the results it transforms into, is by using the website (powered by SOC Prime). can convert Sigma (and other rules and queries) to many different formats, allowing easy experimenting.


Remco Verhoef (@remco_verhoef)
ISC Handler – Founder of DutchSec


(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) →