If you missed the previous parts in this article series please read:
- Analyzing a Hack from A to Z (Part 1)
- Analyzing a Hack from A to Z (Part 2)
- Analyzing a Hack from A to Z (Part 3)
We saw in part three of this article series that Snort logged pretty much all of the activity that happened over the course of the webserver being exploited by the hacker. That said, it did miss the usage of a key program that was transferred there by the hacker. Much as I mentioned in part three is that an IDS is not a device which guarantees network security. An IDS is at its heart a pattern matching program. Those patterns are the signatures that have been written for it, and continue to get updated over time. While IDS vendors make a pretty decent attempt at generating a fairly broad set of signatures, there is still room for improvement.
There exists a large array of malware out there that the network security analyst should be aware of and worried about. One such example are rootkits, and in the case of this article, the FU rootkit. Other examples would be Trojans, and backdoors such as netcat. The problem is however is that not every IDS out there has signatures for them. It would really make sense therefore to develop signatures for malware such as the ones just discussed. On that note, we will learn how to write a Snort IDS signature. As you will soon see, it really isn’t all that hard to do.
Writing Snort signatures
The best way to learn something is by doing it, and also to have an example at hand to learn from, and use as a baseline of what works. With that in mind let’s take a look at the Snort signature below, which I have taken from the default ruleset.
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN ipEye SYN scan"; flow:stateless; flags:S; seq:1958810375; reference:arachnids,236; classtype:attempted-recon; sid:622; rev:7;)
Let’s go over the above signature in some detail as it will help us build our own if we understand the guts of it as it were. The very first field is simple enough as this simply says alert.
tcp this relates to the protocol type in use
$EXTERNAL_NET is used to state traffic coming in from an external source ie: Internet
any this says that any port applies ie: no specific port stated
--> the director symbol show the flow of traffic in this case from external to internal
$HOME_NET is used to identify the person’s network
(msg:”SCAN ipEye……….) will be the message printed out when the signature fires
flow:stateless is used to have the signature fire regardless of the state of the session
flags:S is used to specify exact TCP flags or flag combinations
seq:1958810375 is used to look for a specific TCP sequence number
reference:arachnids,236 is used to identify a specific signature in the Arachnids IDS database
classtype:attempted-recon is used to denote what classtype the signature belongs to
sid:622 is a value used to uniquely identify Snort signatures
rev:7 is used to identify the revision number for the signature
So with this information in hand we are now ready to take a shot at building our own custom Snort signature, and then test it in order to confirm its usability. A good signature to develop would be one for the FU rootkit that was used in this article series. What to build it on though? Well does it have any defining features? Does it use a hardcoded port, or does it have a unique TCP sequence number? In essence anything that appears to be unique to it. With that in mind about all that is unique to it is the name it has fu.exe. That is good enough to start building our Snort signature.
Let’s build our very own Snort signature
We will use some of the same fields in our sample signature as seen above though we will not use all of them.
alert ip any any -> any any (msg:"FU rootkit transfer or usage"; content:”fu.exe”; rev;1)
Shown above is a pretty barebones signature for the FU rootkit. We know that the binary file fu.exe was TFTP’d over to the victim webserver during the hack. That really is about all that identified it, beyond the actual usage of it. Shown in the packet below is the ASCII string of fu.exe.
15:06:12.109375 IP (tos 0x0, ttl 128, id 451, offset 0, flags [none], proto: UDP (17), length: 43) 192.168.111.23.1032 > 192.168.111.17.69: 15 RRQ "fu.exe" octet
0x0000: 4500 002b 01c3 0000 8011 d985 c0a8 6f17 E..+..........o.
0x0010: c0a8 6f11 0408 0045 0017 c560 0001 6675 ..o....E...`..fu
0x0020: 2e65 7865 006f 6374 6574 0000 0000 .exe.octet....
I did not put in the external_net or home_net here in an attempt to make this as simple as possible. The contents of people’s snort.conf file can vary so sometimes keeping things simple is the best policy, at least until you get more comfortable with signature writing. You will note as well that there are no port numbers, flow statement, flag combination, and other such fields in my signature. While this makes the signature fairly loose as it were, it should still be effective. Furthermore, the payload content of fu.exe should be unique enough to cut down on any false positives that may occur on random hits of ASCII in the payloads of other legitimate packets. On that note let’s go ahead and insert our rule in with the other ones, and parse the binary packet file of the hack.
[**] [1:0:1] FU rootkit transfer or usage [**]
[Priority: 0]08/09-15:40:58.171875 192.168.111.23:1029 -> 192.168.111.17:4321
TCP TTL:128 TOS:0x0 ID:665 IpLen:20 DgmLen:742 DF
***AP*** Seq: 0xAA205B6C Ack: 0x2039E4DD Win: 0xFA2D TcpLen: 20
Success! Our Snort signature has worked. Now as mentioned earlier this is a fairly lean signature with not a whole lot of other fields in it in order to try and cut down on false positives. Should you want to try and incorporate other Snort rule fields in it then I would suggest that you play with the FU rootkit itself a bit more and then study the resulting packet trace. That will allow you to look for any further defining features. Should any be found then you can incorporate them into the above signature, or allow you to write other specific signatures in regards to the FU rootkit.
What we did over the course of this four part article series is look at how a hacker could potentially profile your network. With that information in hand was how that very same hacker could then exploit your network, and then further their post-exploitation strategies. What all that activity has in common though is that it will leave tell-tale marks at the packet level. Those very same marks can be leveraged to build IDS signatures. It is not every network hack that will use well known tools such as Nmap, and known rootkits such as the FU rootkit. What one should then do is try and come up with some signatures that will catch typical hacker activity.
Writing signatures is only half the battle though, you also need to ensure that they work, and will also not cause too many false positives. Should a signature trigger too many false instances then it will likely be ignored by the analyst. Learning how to write good signatures is a learning process and will take time and practice. Don’t be discouraged though, for as you have seen, it is not overly difficult to write them. I sincerely hope this article series was of use to you, and as always welcome your feedback. Till next time.
If you missed the previous parts in this article series please read: