Phishing alert button

Your users are the first line of defence against threats, especially for what concerns phishing. One of the ways to get more involvement is offering a simple and easy way to report suspicious messages, such as phishing e-mails. You can do this via a phishing alert button that allows users to notify the helpdesk of a suspicious message. The technology behind such a button is straightforward:

• Forward the message;
• Remove the message from the inbox.

Instead of starting from scratch you can use the -free- Phish Alert Button (PAB) from KnowBe4.

Pipeline to handle phishing e-mails

The pipeline to handle phishing e-mail notifications from users is as follows.

1. A user reports a suspicious message via the phish alert button. This button is integrated in Outlook.
2. The message is send to the helpdesk. The mail flow to the helpdesk must be unfiltered, in the sense that you do not want your security controls to mangle the message you’re about to investigate. If these controls detect it, that’s good. It means your users are protected (and they shouldn’t have received the message in the first place) but you don’t want to investigate mangled URLs or attachments. Mails for the helpdesk are stored in a dedicated mailbox, accessible via IMAP.
3. The mails in that IMAP mailbox are read with a tool from Xavier Mertens: IMAP2TheHive. This tool transforms the phishing e-mail to a security case in the case handling system TheHive. Cases are created according to a phishing handling playbook.
4. The investigation is done with the playbook, and automated enrichments of observables is done via Cortex. This enrichment allows your helpdesk staff to investigate if a specific URL in the phishing e-mail is found on a list of known malicious sites, or if an attachment is known at Virustotal.
5. From TheHive a threat event is created in MISP. The threat data in MISP is then used to automatically update the block list for the proxy server.

Phish Alert Button (PAB) by KnowBe4 in Outlook

The first step is to create the button. You can use this video as a guide. I did these modifications.

• 1 – Recipient / Helpdesk : the address used to forward the notices;
• 2 – E-mail prefix : the e-mail prefix;
• 3 – Button text : the button text to display in Outlook.

Apart from these settings, there’s really nothing more that you need to configure. If you save your changes you can then download the button as an installable MSI file. After the installation of the MSI and restarting Outlook you’ll notice the button in the Outlook ribbon.

Users can then report a suspicious e-mail by clicking on the button. They are prompted to confirm the action, given a thank you message afterwards and then the e-mail is forwarded to the helpdesk and removed from their inbox.

Case creation in TheHive

The IMAP2TheHive tool from Xavier Mertens does the heavy lifting. This tool reads the IMAP folder that receives the phishing notices and then creates individual security cases in TheHive. These changes have been done to the configuration file.

• the IMAP server address, user and password
• the URL and API for TheHive
• the case configuration is done with TLP:Amber (2) and according to a phishing template (playbook). An important note. The Phish Alert Button sends the phishing messages as attachments. To make sure that the original phishing e-mail is included in the case verify that the files directive in the script contains application/pdf,application/octet-stream.
• The whitelist is extended with the URLs from w3.org and Microsoft.

[case]
tlp: 2
tags: email
template: Phishing
files: application/pdf,application/octet-stream

I run the IMAP2TheHive script via cron and it’s executed every 15 minutes. Afterwards you’ll see a new case created in TheHive. The new cases contains a number of tasks, which have been defined in the phishing handling playbook.

One of the observables in the security case in TheHive contains the original e-mail. This allows the analysts to review for example additional e-mail headers.

The import script automatically extracts useful indicators such as URLs found in the phishing e-mail. You can then use Cortex to verify if these (phishing?) URLs exist with Google SafeBrowsing or if the purpose or goal of these links is known with Virustotal.

Export to MISP and create block lists

I described in another post how to create a block list from data in MISP, see Feed honeypot data to MISP for blocklist and RPZ creation. The integration of MISP with TheHive is explained in detail in a post from TheHive : TheHive, Cortex and MISP: How They All Fit Together.

Happy filtering!

IOC / APT scanner

An antivirus solution is an indispensable component in your defence arsenal but it does not protect you against all threats. Complimentary to an antivirus is Loki, an open-source IOC scanner. Loki is a scanner that allows you to search for intrusion activity such as

• Network connections to C2 servers or malicious domains;
• Presence of files related to APT activity;
• Process anomalies such as malicious implants or patches in memory ;
• Credential dump activities;
• Checks for Reginfs (Regin malware) or DoublePulsar.

The most common use case is a “Triage” or “APT Scan” scenario in which you scan all your machines to identify threats that haven’t been detected by common antivirus solutions. What makes Loki different to common antivirus solutions is that you can provide it your own set of detection rules. Why is this important? Organisations such as ICS CERT, Kaspersky ICS CERT and ESET publish on regular basis detection rules. In addition to this, if you are part of a threat sharing group (fe. see MISP communities) you receive frequent updates on the new threats targeting your sector. You can leverage this information with Loki to hunt for malicious activity. Loki supports

• File hashes (MD5, SHA1, SHA256);
• Hard and soft indicator filenames based on regular expressions;
• C2 IOCs in the form of IP addresses and domain names;
• YARA rules.

YARA rules are a flexible way to detect various types of -malicious- activity by combining detection elements with some logic.

Use case

My use case was

• Collect threat information for specific sectors;
• Use this information to create detection rules for specific target environments;
• Make these rules available for Loki and have Loki scan the systems;
• Collect and process the logs and make the results accessible in a dashboard.

Get the threat data!

The easiest way to collect threat data is by setting up MISP, an Open Source Threat Intelligence Platform and connecting your instance with those of CSIRTs, vendors and threat sharing groups. The next step is to extract the data from MISP and make it available in a format that can be used by Loki. The signatures of Loki are provided via a separate Github repository, which also allows contains tooling to fetch threat data from MISP. Unfortunately, the connector was outdated and didn’t support MISP warning lists (lists of well-known indicators that can be associated to potential false positives, errors or mistakes) or selection of threat data based on a taxonomy (fe. via MISP tagging). I submitted a pull request with a new version of get-misp-iocs.py.

Using the threat connector is easy

/var/www/MISP/venv/bin/python3 ./get-misp-iocs.py -t '["PAP:GREEN", "Target:CIIP", "Target:ICS"]' -w 1

The above command collects threat data and writes these in the files iocs/misp-<item>-iocs.txt

• Classified with PAP:Green (Permissible Actions Protocol) and target sectors CIIP or ICS;
• And make sure that most likely false positives are removed.

When all is done, your set of custom detection rules will be available in the folder IOCS.

Client scanning with Loki

Loki does not require an installation and can be run directly from the command line. You do need to take some preparatory actions.

• Extract the latest release of Loki on a trusted system;
• Run loki-upgrader;
• Copy the folder with IOCS collected in the previous step to the folder signature-base/iocs;
• Make the folder loki available to the other systems. For isolated environments it’s best to copy them to individual USB drives (one drive per system).

Loki requires administrator privileges to execute properly. A full system scan can take quite a while (on moderate systems, easily up to an hour).

loki.exe --reginfs --pesieveshellc

This will start Loki and have it scan for APT threat data based on your detection rules. In addition to this it will also scan for the presence of the Regin file system and attempt to detect shell code (memory regions that are not a part of any module, but contain executable code). Loki stores its output in a text log file in the directory where it was executed (you can change this with the option –logfolder). Loki also supports export to CSV (option –csv) but for the further process I’ll use the default log format.

Loki logs dashboard

Once Loki has finished scanning and you have collected the individual log files you can process and present them in an easy accessible format. I use the Elastic stack and rely on a previous project for analysing Linux logs : a setup of an Elastic DFIR cluster.

The cluster configuration contains an updated Logstash configuration file to process Loki log files and a patterns file for the timestamp. The docker-compose file is also changed to make the patterns directory available for the Logstash docker containers.

Importing the log files can be done by first copying the log files in the directory logs and then by running Filebeat from the ~/elastic-dfir-cluster directory.

docker run -d --net=elastic-dfir-cluster_elastic --name=filebeat --volume="$(pwd)/filebeat/filebeat.docker.yml:/usr/share/filebeat/filebeat.yml:ro" --volume="$(pwd)/logs:/volume/:ro" -e -strict.perms=false docker.elastic.co/beats/filebeat:7.9.2 filebeat

The logs are available in Kibana once Logstash has finished processing them all. I created a number of dashboards and visualisations that you can use as inspiration to set up your own dashboards. One of the extra outcomes of this approach is that the processing of the Loki log files gives you a detailed view on

• The running processes on each system;
• The active and listening network connections on each system.

UPDATE 20201114: I added an export of the Kibana dashboard in the Github repository. You can import this dashboard directly to get visualisations as the ones below.

curl -X POST "<hostname>:5601/api/kibana/dashboards/import" -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d'
... paste here everything from loki-dashboard.json
'

EDR

Some of the features from Loki are also available via EDR tools to detect and respond to security incidents. However not all organisations have an EDR tools and they are certainly very rare in isolated (not connected to the Internet) environments.

A walkthrough of Watcher

One of the nice things of working in infosec is that there is always a new tool available to make your work easier. It can also cause a lot of frustration, as there is yet another new tool that you need to master. A tool I recently discovered is Watcher, a platform for discovering new cybersecurity threats targeting your organisation. Some of its key features include

• Detecting emerging trends via social networks and RSS feeds;
• Monitor for information leaks, for example in Pastebin;
• Monitor domains for changes;
• Detect potentially malicious domain names targeting your organisation.

As I’m already using the AIL framework I was interested to see if Watcher is complimentary or could replace AIL. My use case is pretty straightforward. For a number of organisations (in fact keywords relevant for organisation asset descriptions) I want to receive notifications if

• A new certificate is issued;
• The keyword turns up in a phishing database;
• A potential information leak with reference to the keyword was found;
• New domains resembling a keyword are registered (cybersquatting/typosquatting);

I created my own tooling (Digital Footprint Light) for the first two cases and I’m using AIL to cover the third. For the new domains I use dnstwist with manual post-processing. Based on its feature list, Watcher might be an answer to both my third and fourth case. Hence a walkthrough of Watcher.

Getting started with Watcher

Watcher is available as a Docker instance, which makes it very easy to evaluate. Clone the Github directory and make sure you have Docker and Docker Compose installed. Before starting the Docker containers, edit the .env file. This file also allows you to configure the integration with TheHive and MISP.

TZ=timezone
DJANGO_SECRET_KEY=the secret key 
ALLOWED_HOST=set this to the FQDN of your server

After these changes you can start the containers with

docker-compose up    

If succesfull, create an admin user and populate your database, as described in the installation notes.

Watcher

Monitoring trends

The start page of Watcher presents you a tag-cloud of trending topics. Note that the tag cloud will only contain relevant information after running Watcher for a couple of hours.

You can then select one of the items in the tag cloud and get a list of articles related to the term, together with a trending graph of the term.

The tag cloud is based on the monitoring of a set of sources, defined in the administration interface.

The tag cloud and user interface for the trend monitoring is very simple and easy to use but the quality of the monitoring entirely depends on the sources that you provide it. This feature can prove very valuable if you want to watch a limited set of websites for new topics, but it’s maybe less useful for a more ‘global’ trend watching. Out of the box Watcher includes more than 100 sources.

Data leak alerts

The second option is monitoring for potential data (or information) leaks. You have to provide a number of keywords in which you’re interested and then Watcher will alert you if a hit is found. Apart from the web interface, Watcher can also send you e-mail notifications.

In the background Watcher uses a Docker image of Searx, a privacy-respecting, hackable metasearch engine. The straightforward user interface of Watcher allow you to easily add new terms, but it does not have additional filtering (for example exclude specific combinations). In order to use Watcher Pastebin API feature, you need to subscribe to a Pastebin pro account and whitelist the Watcher public IP.

Website monitoring

The third feature in Watcher is monitoring websites for changes. These changes can either be on the website itself, a change in the IP address or a change in the e-mail records. When you add the website, you can give an RTIR ticket number as reference.

When Watcher has detected a change it supports the option to export the details of that change to either TheHive or MISP.

Dnstwist

The last feature is a graphical layer on top of Dnstwist. Dnstwist allows you to discover permutations of domainnames, ideal to spot cybersquatting. As before, Watcher makes it easy to add new domains to monitor.

The output of Watcher will indicate the fuzzer, the discovered domain name and the domain to which it relates. A very nice feature is that you can immediately send the discovered domain to the list of websites to monitor. This makes a great chain.

1. Dnstwist discover a new potential cybersquatting domain;
2. You can then monitor the domain until it gets live;
3. And then create a case in TheHive or an event in MISP.

Conclusion

During this walkthrough of watcher, I found the user interface and the ease of use of Watcher very good, it is very easy to add an item you’d like to have monitored. I very much like to web interface around the Dnstwist feature. In some cases having the domain monitored is a very valid solution, in other cases I’d like to report this directly to TheHive/MISP (see: Issue 16). The website monitoring is certainly useful but has room for improvement. For example monitoring changes in the web server environment (see: issue 17) or included libraries would be an interesting addition. Partially this can be covered by integrating with services such as Urlscan.io. And finally, compared to the AIL framework, the leak detection options are limited. This shouldn’t be a problem as such (also see AIL integration) but it still does require running multiple tools.

I’m now primarily using the website monitoring and twisted dns features of Watcher, pending the further integration with the AIL framework.