THOR 10 Fusion – Major Changes

THOR 10 Fusion – Major Changes

In anticipation of our new scanner THOR 10 Fusion, we would like to show you some of the exciting new features and upcoming changes. 

Modes and Feature Cleanup

We’ve reviewed and reworked all scan modes in order to clarify the overview of active modules and features for the user. 

In the past, it wasn’t always clear which module and feature has been auto-deactivated and auto-activated during the scan runs. 

We’ve dropped the “–fast” mode, which was rarely used intentionally but auto-activated on Workstations.

Most of the modules have been completely rewritten. 

Due to higher scan speeds we didn’t have to make many compromises. The “default” scan should take roughly as long as with THOR 8 but is much more intensive. 

Modules like the “Rootkit” module have been split up in two different sections, one with important and less dangerous checks and one with less relevant checks that could lead to an Antivirus intervention (e.g. Double Pulsar check).

This refactoring allows us to activate the module in “Soft” scan mode and set e.g. “Double Pulsar” as extra feature for that module, which is activated in “Default”, “Quick” and “Intense” scan mode. 

Separate Program and Signature Updates

Former versions of THOR have been shipped and upgraded as a complete package.

The new thor-util allows you to upgrade program files and signatures separately.

We’ll try to publish new signature packs as fast as new YARA signatures get published in VALHALLA 

Time Stamp Harmonization

The timestamps in all the different modules have been harmonized to ANSIC standard.

This was an important step to allow the creation of meaningful timelines of the discovered events. 

Configuration Files Become Scan Templates

THOR 10 uses so-called scan templates in YAML format, instead of the old config file format.

The parameters in these scan templates reflect 1:1 the command line parameters. With these new scan templates it is easy to define a set of parameters for your scan and ship them as the default scan template. 

You can even mix the configurations from multiple scan templates, e.g. define a default template and separate templates with different syslog targets for each branch office.  

 

JSON and Key/Value Output

You can choose from multiple options to influence the output format of the log files and SYSLOG messages sent to  remote servers. 

We handle log messages internally as objects and can easily render JSON or Key/Value pair outputs. 

This greatly simplifies the SIEM integration of all output streams. 

 

Difference Scan

The difference scan makes use of the THOR DB and checks only elements on disk that have been created or changed since the last scan start.

This is a new ultra fast scan mode, albeit susceptible to timestomping attacks. 

Sigma Scanning

THOR 10 inherits the Sigma scanning feature from SPARK and can now apply Sigma rules to local Eventlog entries (Windows) or log files (Windows, Linux and macOS). 

Find more information on the Sigma scanning feature in this older blog post

 

Better Process Memory Matches

Process memory matches now show the matching strings or code sequences found in the memory of scanned processes. 

Tagged Matches

Since our YARA rules are tagged during the integration into VALHALLA, all of them have tags including the MITRE ATT&CK tags, that help your analysts putting matches into context. 

ASGARD Integration

THOR 10 integrates seamlessly with ASGARD and shows up as third scanner next to THOR 8 and SPARK. 

The “Updates” section will show separate update settings for the scanner’s program components and signatures. 

The ASGARD menu to create new THOR 10 hunts contains all command line options dynamically extracted from the current executable.

This way it adapts to all future features and command line options that will be integrated into THOR 10 over time. 

These are only some of the changes coming with THOR 10 Fusion.

We are in schedule and excited to release it in July.

THOR 10 Fusion – Major Changes

Upcoming : THOR 10 “Fusion”

We are proud to announce the upcoming release of THOR 10 code named “Fusion”.

It will replace our scanners THOR 8 and SPARK before the end of this year. Both of the current scanners will still receive updates until the end of this year. 

THOR 10 “Fusion” combines the advantages of our current scanners, the intensive analysis capabilities of THOR with the unmatched flexibility and speed of SPARK.

It features all modules of THOR 8, including Registry, SHIM Cache, Eventlog, Mutex, WMI, Service and Autoruns analysis.   

It runs on all major operating systems – Windows, Linux and macOS.

With THOR 10 “Fusion” you will not have to decide between an intense or fast scan anymore. THOR 10 provides the best of both worlds. 

We plan to release THOR 10 in July this year. Follow us on twitter or subscribe to the newsletter for updates.

Customers will get a separate notification with changes and instructions for an upgrade.  

MASTER ASGARD – One ASGARD to Rule Them All

We are glad to announce our new product MASTER ASGARD, a central control for a set of ASGARD systems.

MASTER ASGARD is designed to control multiple instances of ASGARD, which itself supports up to 10,000 endpoint agents. Using MASTER ASGARD you are able to control more than 100,000 end points from a single central location. 

This control includes:

  • Run distributed THOR and SPARK scans
  • Schedule distributed THOR and SPARK scans
  • Manage and distribute IOCs
  • Collect files and memory from Windows and Linux end systems

 

 

Here are some screenshots:

Management of multiple ASGARDs

Evidence Collection

Distributed Scans

MASTER ASGARD will be available for BETA program customers at the end of February and to the full customer base in May 2019.  

THOR Util Replaces THOR-Upgrade

We are currently upgrading our update infrastructure in many different ways.

We have added 2 new dedicated update servers – update1 (Karlsruhe, Germany) and update2 (Lenexa, USA). The old update locations will still be supported for a few months but have to be regarded as obsolete.

As a customer, please make sure to allow the following update servers in your proxy / firewall:

  • update1.nextron-systems.com (443/tcp)
  • update2.nextron-systems.com (443/tcp)

In this regard, our old utility called “thor-upgrade.exe” will be out-of-support by the end of July 2018.Please make sure to use the “THOR util” for all update tasks.

Major changes:

  • Supports all download types (THOR, SPARK for Windows, Linux, macOS)
  • Verifies Download via RSA signature
  • Runs on all platforms (Windows, Linux, macOS)
  • Allows updates and the download of a full program packages with config files
  • No support for proxy NTLM authentication

It is already part of all download packs.

Since THOR v8.46.9 and SPARK v1.11 all binaries are signed with a 2048 bit RSA key. The signatures are integrated in the download packs as separate “*.sig” files.

The new version 1.1.6 of THOR util checks the signatures during the upgrade / download and interrupts the process if an invalid signature is found.

You can verify the signatures yourself, by using the the new “verify” function.
These changes make our updates more reliable and secure.

If you have any question, don’t hesitate to contact us via support@nextron-systems.com

How to Write Sigma Rules

Sigma is an open standard for rules that allow you to describe searches on log data in generic form. These rules can be converted and applied to many log management or SIEM systems and can even be used with grep on the command line.

In this article I’d like to give you a brief practical introduction into the rule creation process. I’ll recommend some tools and draft a guide that helps you to write Sigma rules as quick and sound as possible.

1. Get the Repository

First download or clone our Sigma repository from Github.

It contains the rule base in the folder “./rules” and the Sigma rule compiler “./tools/sigmac”. We will use the existing rules as examples and create a new rule based on a similar existing one. We will then test that rule by using “sigmac”.

Sigma Github Repository

2. Copy and Edit YAML Files

My personal favorite editor for YAML is VSCode. It is free and runs on all major platforms. (alternatively you can use Atom with ‘language-yaml’ and ‘linter-js-yaml’ packages)

Visual Studio Code

I used the following extensions but I don’t know if they are still necessary. VSCode has improved a lot over the last 12 months and it is possible that it supports YAML highlighting and syntax checks by default now.

YAML Extensions for VSCode

We open the Sigma repository folder with “Open …” and see all existing rules.

Sigma Rules

3. Create a Sigma Rule

I selected an example in which we will create a Sigma rule from one of @JPCERT‘s findings in their awesome “Tool Analysis Result Sheet“.

We open the results for “Quarks PWDump“, a password dumper often used by Chinese threat groups. It creates temporary files that we want to detect in our SysInternals Sysmon log data. To collect the needed events we use Sysmon with @SwiftOnSecurity‘s Sysmon config file, Windows Event Forwarding or NXlog.

Quarks PWDump Analysis Results

So, what we do is to find a Sigma rule in the repository that we can use as a template for our new rule. We use the ‘search’ function to find a rule that looks for “File Creation” events (EventID 11) in Sysmon log data.

Sigma Example Rule

We find a rule that has a special format. It is a so-called “rule-collection“, which allows us to define a global section in the YAML file marked with “action: global” that will be applied to all other sections in that file during the search query generation process. This way you can define and create multiple search queries from a single YAML file.

In the case of our QuarksPwDump example we don’t need a rule collection, so we reduce the rule to a standard rule that contains a detection expression looking Sysmon Events with Event ID 11 and save it as “sysmon_quarkspw_filedump.yml” to a new file in the folder “./rules/windows/sysmon/”.

Simple Sysmon Sigma Rule

After that, we modify several fields of that rule:

  • We give the rule a correct “title” and “description”
  • We leave the status “experimental” to inform everyone that this is a new and untested rule
  • We add the correct reference to the source from which we derived that rule
  • We change the author of the rule
  • We set the level of that rule to one of “low”, “medium”, “high” or “critical”
  • We adjust the date (of last modification) and use the format %Y/%m%d (strftime)
  • We check if the log source is correct, which is important for the field mappings used by “sigmac”

New Sigma Rule Header

Before we create the new “detection” section, we review the analysis report in detail.

Details: QuarksPwDump Temporary Files

We add a string with wildcards that matches on the ‘TargetFileName’ field in the Sysmon events of type 11. That’s what the new rule looks like:

QuarksPwDump Sigma Rule

4. Test the Rules

We test our newly created rule with “sigmac”, which requires python3. It is located in the “./tools” folder. It features several targets for which we can create searches/configurations from our rules.

Currently supported targets (10.02.2018):

  • es-qs (Elastic Search Query Language)
  • kibana
  • xpack-watcher
  • logpoint
  • splunk
  • grep
  • fieldlist (only used to show all fields that require mapping in a config file)

Running “python3 sigmac -h” shows a help:

$ python3 sigmac -h
usage: sigmac [-h] [--recurse] [--filter FILTER]
              [--target {es-qs,kibana,xpack-watcher,logpoint,splunk,grep,fieldlist}]
              [--target-list] [--config CONFIG] [--output OUTPUT]
              [--backend-option BACKEND_OPTION] [--defer-abort]
              [--ignore-not-implemented] [--verbose] [--debug]
              [inputs [inputs ...]]

Convert Sigma rules into SIEM signatures.

positional arguments:
  inputs                Sigma input files

optional arguments:
  -h, --help            show this help message and exit
  --recurse, -r         Recurse into subdirectories (not yet implemented)
  --filter FILTER, -f FILTER
                        Define comma-separated filters that must match (AND-
                        linked) to rule to be processed. Valid filters:
                        level<=x, level>=x, level=x, status=y, logsource=z. x
                        is one of: low, medium, high, critical. y is one of:
                        experimental, testing, stable. z is a word appearing
                        in an arbitrary log source attribute. Multiple log
                        source specifications are AND linked.
  --target {es-qs,kibana,xpack-watcher,logpoint,splunk,grep,fieldlist}, -t {es-qs,kibana,xpack-watcher,logpoint,splunk,grep,fieldlist}
                        Output target format
  --target-list, -l     List available output target formats
  --config CONFIG, -c CONFIG
                        Configuration with field name and index mapping for
                        target environment (not yet implemented)
  --output OUTPUT, -o OUTPUT
                        Output file or filename prefix if multiple files are
                        generated (not yet implemented)
  --backend-option BACKEND_OPTION, -O BACKEND_OPTION
                        Options and switches that are passed to the backend
  --defer-abort, -d     Don't abort on parse or conversion errors, proceed
                        with next rule. The exit code from the last error is
                        returned
  --ignore-not-implemented, -I
                        Only return error codes for parse errors and ignore
                        errors for rules with not implemented features
  --verbose, -v         Be verbose
  --debug, -D           Debugging output

We test our new rule with “sigmac” and the target “splunk”.

$ python3 sigmac -t splunk ../rules/windows/sysmon/sysmon_quarkspw_filedump.yml
(EventID="11" TargetFileName="*\AppData\Local\Temp\SAM-*.dmp*")

Now the rule is ready for a pull request. Follow me or contact me on Twitter: @cyb3rops

Welcome to Our New Website

We welcome you to our new website and encourage you to review our ‘products’ and ‘services’ sections.

From now on we will publish news about our products, articles about incident response, YARA rules, detection methods, IOCs and other interesting topics on this blog page.

Incident Response Consulting

In den vergangenen Monaten konnten wir mehrere Kunden bei der Bewältigung und Behandlung massiver Angriffe unterstützen. Zufällige Entdeckungen im Kundennetz zeigten in allen Fällen nur die “Spitze es Eisbergs” größerer und länger andauernder Attacken.
Nachdem ein Security Incident als solcher bestätigt wird, ist die erste Frage, die sich stellt, die nach dem Umfangs des Angriffs oder dem Ausmaß der Infektion.
Um diese Frage beantworten zu können bedarf es eines hinreichenden Security Monitorings – also der Überwachung und Analyse sicherheitsrelevanter Ereignisse im Netzwerk und auf Systemen. Nur so ist es möglich, vergangene Ereignisse aufzuarbeiten und miteinander in Verbindung zu bringen. Auch wenn Kunden über kein oder nur ein sehr eingeschränktes Security Monitoring verfügten, war es innerhalb weniger Wochen möglich, erste Erfolge zu erzielen. Neben der reinen Erhebung und Weiterleitung der Daten sind in den meisten Fällen dazu auch Abstimmungen mit BR und Datenschutz  notwendig.
Für die Analyse eines Hackerangriffs relevante Protokolle sind u.a.:

  • Windows Eventlog der Clients und Server
  • Antivirus Logs
  • Proxy Logs
    (Logdaten der Proxy Appliance)
  • Firewall Logs
  • DNS Server Logs

Die richtige Wahl der Mittel wirkt sich erheblich auf die Zeitdauer aus, nach der erste Ergebnisse erzielt werden können und bestimmt letztlich auch die Basis für weitere Entwicklungen. Moderne Werkzeuge wie z.B. Splunk erlauben es, Datenquellen in wenigen Minuten anzubinden und wenige Handgriffe später auch ausgezeichnet analysieren zu können. Wir verwendeten in unseren Umgebungen ein Set aus folgenden Werkzeugen, um die Vorfälle umfassend zu analysieren und zu klären:

  • Syslog-NG
    (zur Sammlung, Filterung und geordneter Ablage von Logdaten)
  • Splunk
    (Indizierung, Aufbereitung und Analyse von Logdaten)
  • Splunk Forwarder
    (Weiterleitung von Logdaten – z.B. an Syslog-NG)
  • TH0R Incident Response Scanner
    (Eigenentwicklung zur Erkennung von Angreifer-Tools und Aktivitäten auf Windows Serversystemen)

Während wir im Security Monitoring Echtzeitalarme definierten, die uns vor neuen Angriffen innerhalb von Sekunden in Kenntnis setzten, konnten wir gleichzeitig unser Incident Response Tool TH0R einsetzen, um die Systeme auf Spuren der Angreifer zu untersuchen. Auf diese Weise ergibt sich ein umfassendes Bild über den Zustand der Systeme bzw. den Grad der Kompromittierung.

SIEM Security Monitoring mit Splunk

SIEM Security Monitoring mit Splunk


Hackerabwehr Scanner

Incident Response Scanner TH0R


 

Links

Im hier verlinkten Blogbeitrag wird die Arbeit mit dem Werkzeug TH0R genauer erläutert. Auf der Produktseite werden die Eigenschaften und Funktionen genauer erläutert. Das eingesetzte SIEM Werkzeug Splunk wird hier in einem kurzen Überblick vorgestellt.

Unterstützung

Sollten Sie Unterstützung bei der Behandlung von Hacker-Angriffen benötigen oder Interesse an den eingesetzten Werkzeugen haben, können Sie jederzeit gerne über unsere Kontakt-Seite Verbindung mit uns aufnehmen.

Security Monitoring Dienstleistung

Security Monitoring Dienstleistung

Einer der Schwerpunkte von BSK Consulting liegt im Feld des Security Monitorings. Wir setzen auf Produkte namhafter Hersteller aber auch Eigenentwicklungen, die meist im Kundenauftrag für Umgebungen vor Ort entwickelt werden.
Neue von uns entwickelte Werkzeuge für die Intergration in unsere Mosaic Plattform erzeugen ein übersichtliches Bild  statistischer Informationen mit Hilfe von sogenannten “Heat Maps”. Dabei werden Häufigkeiten in Tabellenform dargestellt und vergleichbar gemacht. Die Färbung wird je nach Werkzeug auf unterschiedlichem Wege erzeugt.
Im unten abgebildeten Report werden alle an das Security Monitoring liefernde Systeme und Typen von Meldungen analysiert. Anomalien werden mit Hilfe der Berechnung von Mittelwert und Standardabweichung sichtbar gemacht. Außerdem werden Wochenenden in der Betrachtung gesondert betrachtet. Auffällig hohe Werte werden “rot”, auffallend niedrige Werte “blau” markiert. Durch die Berechnung der Standardabweichung wird erreicht, dass Logs, in denen die Anzahl an Meldungen häufig stark unterschiedlich ausfällt, nicht zu zahlreichen False Positivs führt, die dann den Nutzen der Darstellung in Frage stellen.
Der Screenshot zeigt eine anoymisierte Analyse des Werkzeugs “Hector NG”, welches große Logfiles von mehreren Gigabyte Größe verarbeitet und an Hand von regulären Ausdrücken “System” und “Typ” extrahiert. Es pflegt dabei eine Datenbank, die diese statistischen Informationen sammelt und bei jedem neuen Durchlauf neu berechnet.
Security Monitoring Heat Map

Security Monitoring Heat Map


Auf diese Weise ergibt sich ein übersichtliches Bild, in dem Abweichungen direkt ins Auge fallen. Es handelt sich hier um kumulierte Werte. Nach dem Erkennen einer Anomalie möchte man gerne leicht nachforschen können, um was es sich nun genau gehandelt hat. Dazu ist jeder der Werte mit einem Link hinterlegt, der eine passende Suche in dem von uns präferierten Log Analyse Werkzeug namens “Splunk” absetzt.
Splunk Diensleistung

Splunk Suche aus dem Hector-NG Report


Die Folgende Übersicht zeigt ein anderes von uns entwickeltes Werkzeug zur Analyse von Checkpoint Firewall Fehlerzuständen. Es setzt auch auf die Darstellung in Form von Heat Maps. Für diese kleine Auswertung wurde nur ein Set von Demo-Logs mit einigen Minuten Inhalt verwendet. Sie vermittelt jedoch einen Eindruck, wie das Skript arbeitet und welche hilfreiche Übersicht es generiert, wenn es darum geht, das Logaufkommen in der Gesamtheit zu verstehen.
Den Artikel zu diesem speziellen Werkzeug findet sich hier.
Checkpoint FW1 Analysis

Checkpoint Peek Analyse Kopf – Systeme mit Gesamtzahl der Verbindungen und dazugehörige “Actions” (Demo-Log)


Eine Übersicht der von uns eingesetzten Produkte finden Sie unter “Produkte“. Im Kundenauftrag erstellte Software ist darunter bis auf einige Ausnahmen nicht zu finden.
Bei Interesse an unseren Entwicklungen oder Dienstleistungen können Sie sich gerne jederzeit über die angezeigten Kontaktinformationen mit uns in Verbindung setzen.

Windows Client Security Audit

Das von uns entwickelte “Windows Client Security Audit” wurde auf Grund der neuen Erkenntnisse aus den Vorträgen der DEFCON 20 Konferenz im Juli erweitert. Konkret wurden Tests zur Prüfung der VPN-Konfigurationen und der NTML bzw. Kerberos Authentifizierung hinzugefügt.
Das von uns entwickelte Set von Tests wurde mit der Zielsetzung zusammengestellt, die Gefahrenlage für die im Kundenumfeld eingesetzte Arbeitsstation mit Internetzugang umfassend bewerten zu können.
Die folgende Tabelle gibt eine Übersicht der Untersuchungskategorien:

Kategorie Bemerkung
Schwachstellen an Systemkomponenten Checks, die alle Betriebssystemkomponenten wie Dienste, Treiber und Schnittstellen auf etwaige Schwachstellen prüfen.
Schwachstellen an Softwareprodukten Checks, die installierte Softwareprodukte auf Schwachstellen prüfen, unabhängig davon, ob die Software ein Plugin für den Browser breitstellt oder nicht.Software, die Browser Plugins bereitstellt (Flash Player, Acrobat Reader, Java RE) kann für Drive-By Download Angriffe genutzt werden.Durch Downloads oder Mail-Anhänge können auch Schwachstellen in Software durch einen Angreifer adressiert werden, die nicht durch das reine Ansurfen einer Website ausnutzbar sind.
Sicherheitsrelevante Konfigurationen Checks, die die Konfiguration der Systemkomponenten des lokalen Systems auf sicherheitsrelevante Fehler prüft.
Richtlinien Die Kontrolle der Richtlinien zur Einschränkung des an der Arbeitsstation arbeitenden Benutzers.
Lokale Schutzmechanismen Prüfung der korrekten und hinreichend sicheren Konfiguration lokaler Schutzmechanismen wie z.B. dem Virenscanner, Software-Firewall
Implementierte Schutzmechanismen im
Netzwerk
Prüfung der korrekten Funktionsweise von Schutzmechanismen im Netzwerk, die im direkten Zusammenhang mit dem Web Client stehen, wie z.B. der Web Proxy (Filterung, Antivirus), Mail Server (Filterung, Relaying)
Physische Sicherung Prüfung des Geräts auf Schnittstellen für die Malwareverbreitung (USB-Ports, CD-ROM, USB-Tethering, Boot Reihenfolge, BIOS Schutz)
Sonstiges Sonstige Prüfungen, wie Sprachversionen und die Kombination der verschiedenen Virenscanner

Eine Erläuterung und alle weitere Security Audits finden Sie in der Sektion “Penetration Tests“.