Threat Intelligence

Threats Update

Stamus Central Server provides daily Threat Updates to ensure up to date coverage of recent threats.

Online SCS

If you SCS is able to access Internet over HTTPS, then all you need to do is to configure a Source to get updates from https://ti.stamus-networks.io

Offline SCS

If you are working in a closed environment which prevent SCS from accessing Internet, you will need to regularly update threats definition manually.

First, you need to disable the automatic update of Stamus Threats definition:

1. Go to Probe Management

2. Select Global Appliance Settings under the Stamus Logo dropdown in the header

3. Select Main tab

4. Uncheck the box Enable automatic update of Stamus threats under the Stamus Threat Radar section

5. Submit the changes

Then, you will need to manually download the latests threat definition:

1. Go to Probe Management

2. Select System License under the Stamus Logo dropdown in the header

3. Copy the URL associated to Stamus Threat URL such as https://ti.stamus-networks.io/YOUR_UNIQ_ID/stamus/str-etpro/threats.tar.gz

4. Download the threat definition using a workstation having access to Internet

Finally, you will need to create a custom source to import the threats definition. For that, you can either mirror the previously downloaded tarball to a local HTTP(S) server accessible by the SCS, or, manually upload the file in the source definition.

1. Go to Probe Management

2. Go under Sources

3. In the left side panel, choose Add custom source under the section Actions

4. Set a name to this source, such as Stamus Threats (local)

5. Select the method to use to retrieve the tarball, either a manual upload or a local HTTP(S) server

6. Set the Datatype to Signatures files in tar archive

7. If you chose HTTP URL, set the full URL of the tarball such as https://local-server/threats.tar.gz and adjust the certificate verification to fit your environment

8. If you chose File Upload, select the tarball from your workstation

9. Set to which ruleset(s) this source should be added

10. Validate with Submit

Once completed, you can update/push rulesets to ensure deployment of the threat definition to the Stamus Probes.

Homoglyph Attacks

What are Homoglyph Attacks?

A Homoglyph attack is a deception technique that uses homoglyphs or homographs, in which an attacker abuses the similarities of character scripts to create phony domains of existing brands to trick users into clicking.

Technically speaking, an attacker would replace one or few more characters from a domain name to lure users clicking on malicious links, often delivered through Phishing emails.

For example, an attacker may register the domain name paqe.com to impersonate the domain page.com. The character Q and G looks close enough, in lowercase, for users to get lured.

Other variations of this technique involve changing the characters set used, for example, by replacing a Latin character by a Cyrilic one that really looks like the initial character, hence making the user detection more difficult just by looking at the characters.

Configuring Homoglyph Attacks Detection

When enabling Homoglyph Attacks detection, you will have to choose between monitoring your own domain list, and/or, the Alexa TOP100 domains such as google.com, amazon.com, etc.

To enable Homoglyph Attacks detection:

1. Go to Probe Management

2. Go under Appliances

3. Select the Stamus Probe you want to edit settings from with Edit Probe

4. Open the Threat Radar tab

5. Add your own list of domain names to monitor such as the one reflecting your brand

6. Enable/Disable Alexa TOP100 domains monitoring

7. Submit the changes

Once the configuration in place suit your environment, don’t forget to Apply Changes.

When such attack will be found in your environment, a Declaration of Compromise will be available under Phishing in the Threats Families.

IP Reputation List

To raise an alert from a list of IP addresses, we will need to:

1. Adjust our list of known (bad) IPs to use the keyword iprep from Suricata

2. Create a custom signature that will use iprep and reference our list of IPs

3. Create a special “category” file

4. Package all 3 above files into a tarball

5. Upload that tarball to Stamus Central Server

IP list

To start, let’s adjust our list of IPs to the iprep format.

The expected format is <ip>,<category>,<reputation score>

If we have a list of IPs named mylist.txt with one IP per line, we could simply use the awk command to modify it such as in this example:

awk '{print $1 ",20,30"}' mylist.txt > bad-ips.list

We will end up with a list of IP addresses like this:

192.168.1.23,20,30
172.16.1.4,20,30
192.168.34.43,20,30
...

This example uses “20” for the category identifier and “30” for the reputation score. Please read below to understand what these numbers are and how to choose them.

Finally, make sure that your IP list use the “.list” extension such as “bad-ips.list”

Hint

iprep also allows using subnet with a CIDR notation, for example: 192.168.0.0/24,20,30

Category Identifier

Now that we have our IP list modified, we need to create an appropriate category for Suricata to associate the alerts to.

If you want to use a previously defined category, skip this section, just make sure you use the right identifier in the IP list (previous step).

In the previous example, we used 20 as a category identifier but we can choose any integer from 20 and above.

Note

The category id from 0 to 19 are reserved by/for Stamus Central Server.

If you never created such a category id, you can simply use 20, otherwise, SSH into a Stamus Network Probe and check what categories already exist by looking into the file /etc/suricata/rules/scirius-categories.txt

To create a new category identifier, create a file, next to your modified IP list, named categories.txt with the following structure: <id>,<short name>,<description>

So, in our example, that could be:

20,BadHosts,Known bad hosts

Note

When this file will be uploaded to Stamus Central Server in a later step, Stamus Central Server will merge it automatically.

Create a detection rule

Now, we need to create a Suricata signature that will use iprep to detect any access to the specified list of IPs. To do that, we will use the keyword iprep to:

• set the field on which the matching will be performed (dst in the below example)

• reference our category by using its short name (BadHosts in our example)

• set an “always true” condition (>,10)

alert ip $HOME_NET any -> any any (msg:"internal host talking to a known bad IP address"; flow:to_server; iprep:dst,BadHosts,>,10; sid:1; rev:1;)

The example rule will alert when a system in $HOME_NET acts as a client while communicating with any IP in the BadHosts category that has a reputation score set to greater than 10.

In our current example, all IPs listed in our modified list having a score of 30, the condition “> 10” will always be true so any access to any of these IPs will result in an alert.

Finally, the last piece to adjust from this sample rule is the SID which must be unique amongst all your rules. To do so, set it in the million range (1000000). If the SID isn’t unique when uploading the signature, Stamus Central Server will complain!

Package everything

We now have everything we need:

• The Suricata signature such as signature.rules

• The category.txt file

• The list of IP addresses such as bad-ips.list

All we have to do is to place those 3 files into a directory named rules and create a tarball out of it

mkdir rules
mv signature.rules categories.txt bad-ips.list rules/
tar czf custom-reputation.tar.gz rules

Upload the tarball to Stamus Central Server

The final step is to upload the previously created tarball to Stamus Central Server and assign it the appropriate ruleset.

To do so, go under Probe Management and select Sources from the header’s menu. From the left side menu, click on Add a custom source and fill in the form as follow:

• Name, any name you want such as “Known Bad IPs”

• Method

  • Either it’s a one time thing and you can upload the tarball you generated

  • Either you are hosting this tarball on a local HTTP(S) server for regular updates so choose HTTP URL.

• Datatype, set it to “Signatures files in tar archive”

• Uncheck the option “Use IP reputation for group signatures”

• Set the appropriate ruleset

Finally, update the ruleset to the desired Network Probes from the Appliance page and Apply changes to ensure Suricata reloads to properly load the new category file.