Help detect this kind of malicious activity in the future by writing some Suricata rules. Work with Dusty Giftwrap in the Tolkien Ring to get some hints.
Let's open the terminal:
Use your investigative analysis skills and the suspicious.pcap file to help develop Suricata rules for the elves!
There's a short list of rules started in suricata.rules in your home directory.
First off, the STINC (Santa's Team of Intelligent Naughty Catchers) has a lead for us.
They have some Dridex indicators of compromise to check out.
First, please create a Suricata rule to catch DNS lookups for adv.epostoday.uk.
Whenever there's a match, the alert message (msg) should read Known bad DNS lookup, possible Dridex infection.
Add your rule to suricata.rules
Once you think you have it right, run ./rule_checker to see how you've done!
As you get rules correct, rule_checker will ask for more to be added.
If you want to start fresh, you can exit the terminal and start again or cp suricata.rules.backup suricata.rules
Good luck, and thanks for helping save the North Pole!
Let's create our first rule according to Suricata Docs, chapter 6.14:
alert dns $HOME_NET any -> any any (msg:"Known bad DNS lookup, possible Dridex infection"; dns_query; content:"adv.epostoday.uk"; nocase; sid:1;)
We run the checker:
elf@755c971f69bd:~$ ./rule_checker
...
First rule looks good!
STINC thanks you for your work with that DNS record! In this PCAP, it points to 192.185.57.242.
Develop a Suricata rule that alerts whenever the infected IP address 192.185.57.242 communicates with internal systems over HTTP.
When there's a match, the message (msg) should read Investigate suspicious connections, possible Dridex infection
Let's create our second bi-directional rule according to Suricata Docs, chapter 6.12:
alert http [192.185.57.242,$HOME_NET] any -> [192.185.57.242,$HOME_NET] any (msg:"Investigate suspicious connections, possible Dridex infection"; flow: established;)
We run the checker:
elf@d905f5900694:~$ ./rule_checker
...
First rule looks good!
Second rule looks good!
We heard that some naughty actors are using TLS certificates with a specific CN.
Develop a Suricata rule to match and alert on an SSL certificate for heardbellith.Icanwepeh.nagoya.
When your rule matches, the message (msg) should read Investigate bad certificates, possible Dridex infection
Let's create our third rule according to Suricata Docs, chapter 6.15. As we get a SC_ERR_DUPLICATE_SIG error, we introduce a newer sid:
alert tls $EXTERNAL_NET any -> $HOME_NET any (msg:"Investigate bad certificates, possible Dridex infection"; flow:established,to_client; tls.cert_subject; content:"CN=heardbellith.Icanwepeh.nagoya";sid:10002;)
We run the checker:
elf@d905f5900694:~$ ./rule_checker
...
First rule looks good!
Second rule looks good!
Third rule looks good!
OK, one more to rule them all and in the darkness find them.
Let's watch for one line from the JavaScript: let byteCharacters = atob
Oh, and that string might be GZip compressed - I hope that's OK!
Just in case they try this again, please alert on that HTTP data with message Suspicious JavaScript function, possible Dridex infection
Let's create our fourth rule:
alert http any any -> any any (msg:"Suspicious JavaScript function, possible Dridex infection"; flow:established,from_server; http.response_body; content:"let byteCharacters = atob"; sid:10003;)
Running the checker once again, we have solved that challenge and recovered the Tolkien Ring.