Creating Custom Threat signatures from Snort signatures

This document provides a general overview of creating Custom Threat Signatures from SNORT Signatures on the Palo Alto Networks Firewall using three use cases.

1. Alert TA17-318B HIDDEN COBRA – North Korean Trojan: Volgmer

Reference:
https://www.us-cert.gov/ncas/alerts/TA17-318B

IOC List:
https://www.us-cert.gov/sites/default/files/publications/TA-17-318B-IOCs.csv

Snort rule:

alert tcp any any -> any any (msg:"Malformed_UA"; content:"User-Agent: Mozillar/"; depth:500; sid:99999999;)

General Notes:

• Use the IP addresses provided as part of the IOC List to detect if a possible infection already exists by searching the Firewall logs
• The IP addresses provided can be part of an EDL or Address group and added to a Policy to block traffic to and from the suspicious list.
• Use the provided Snort signature and convert it to a custom spyware signature. This signature will become part of the Spyware profile added to the appropriate Policy.

Detailed Steps:

1. Create a Custom Spyware Object
   1. Navigate to Objects tab -> Custom Objects -> Spyware
   2. Click on Add and provide appropriate details as shown in below screenshot

3. Click on Signatures -> Add [Standard Signature option]
4. Create a custom signature as shown below:

5. The pattern “User-Agent: Mozillar/" from the snort signature is used with the “http-req-headers” context to create the Custom Signature.
6. Click OK to create the Spyware Object.
7. Verify the created Spyware Object is part of your Anti-Spyware Profile

2. Create an EDL object

   1. Navigate to Objects tab -> External Dynamic Lists
   2. Click Add
   3. Add the suspicious IP address provided from the IOC list to a previously created EDL or a new EDL as shown below.

3. Add the EDL and Anti-Spyware profiles to appropriate Policy Objects.
4. Test Policy is working per expectation by looking at Threat logs.
5. Change the action for the spyware object from alert to drop/reset after verification. Also change severity of the custom object created as needed.

2. Alert TA17-293A Advanced Persistent Threat Activity

References:
https://www.us-cert.gov/ncas/alerts/TA17-293A
https://www.us-cert.gov/ncas/current-activity/2017/01/16/SMB-Security-Best-Practices

IOC List:
https://www.us-cert.gov/sites/default/files/publications/TA17-293A_TLP_WHITE_CSV.csv

Snort rules:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/aspnet_client/system_web/4_0_30319/update/' (Beacon)"; sid:42000000; rev:1; flow:established,to_server; content:"/aspnet_client/system_web/4_0_30319/update/"; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/img/bson021.dat'"; sid:42000001; rev:1; flow:established,to_server; content:"/img/bson021.dat"; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/A56WY' (Callback)"; sid:42000002; rev:1; flow:established,to_server; content:"/A56WY"; http_uri; fast_pattern; classtype:bad-unknown; metadata:service http;)

alert tcp any any -> any 445 (msg:"SMB Client Request contains 'AME_ICON.PNG' (SMB credential harvesting)"; sid:42000003; rev:1; flow:established,to_server; content:"|FF|SMB|75 00 00 00 00|"; offset:4; depth:9; content:"|08 00 01 00|"; distance:3; content:"|00 5c 5c|"; distance:2; within:3; content:"|5c|AME_ICON.PNG"; distance:7; fast_pattern; classtype:bad-unknown; metadata:service netbios-ssn;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI OPTIONS contains '/ame_icon.png' (SMB credential harvesting)"; sid:42000004; rev:1; flow:established,to_server; content:"/ame_icon.png"; http_uri; fast_pattern:only; content:"OPTIONS"; nocase; http_method; classtype:bad-unknown; metadata:service http;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP Client Header contains 'User-Agent|3a 20|Go-http-client/1.1'"; sid:42000005; rev:1; flow:established,to_server; content:"User-Agent|3a 20|Go-http-client/1.1|0d 0a|Accept-Encoding|3a 20|gzip"; http_header; fast_pattern:only; pcre:"/\.(?:aspx|txt)\?[a-z0-9]{3}=[a-z0-9]{32}&/U"; classtype:bad-unknown; metadata:service http;)

alert tcp $EXTERNAL_NET [139,445] -> $HOME_NET any (msg:"SMB Server Traffic contains NTLM-Authenticated SMBv1 Session"; sid:42000006; rev:1; flow:established,to_client; content:"|ff 53 4d 42 72 00 00 00 00 80|"; fast_pattern:only; content:"|05 00|"; distance:23; classtype:bad-unknown; metadata:service netbios-ssn;)

General Notes:

• Use the IP addresses provided as part of the IOC List to detect if a possible infection already exists by searching the Firewall logs
• The IP addresses, domains and URL’s provided can be part of an EDL and added to a Policy to block traffic to and from the suspicious list.
• Blocking SMB application traffic from trust to untrust zones is a recommended best practice. This policy can be used as a workaround for the limitations in converting netbios-ssn related snort signatures to Custom Threat Signatures.
• Use the other provided Snort signatures and convert them to custom spyware signatures. These signatures will become part of the Anti-Spyware profile added to an appropriate Policy.

Detailed Steps:

1. Create a Custom Spyware Object
   1. Navigate to Objects tab -> Custom Objects -> Spyware
   2. Click on Add and provide appropriate details as shown in below screenshot

3. Click on Signatures -> Add [Standard Signature option]
4. Create a custom signature as shown below:

5. Sig-1: The pattern "/aspnet_client/system_web/4_0_30319/update/" in the snort signature is used with the “http-req-uri-path” context to create the custom spyware signature as shown below:

6. Sig-2: The pattern “/img/bson021.dat” in the snort signature is used with the “http-req-uri-path” context to create the custom spyware signature as shown below:

7. Sig-3: The pattern “/A56WY" in the snort signature is used with the “http-req-uri-path” context to create the custom spyware signature. Since there is no 7 byte anchor we include GET and POST request methods along with the trailing space in the pattern as shown below:

8. Sig-4: The pattern “/ame_icon.png" in the snort signature is used with the “http-req-uri-path” context and “http-method: OPTIONS” qualifier to create the custom spyware signature as shown below:

9. Sig-5 deep dive:
   1. Snort Signature:

2. Actual HTTP Request:

3. Custom Spyware Signature Explanation:

• The pattern “User-Agent|3a 20|Go-http-client/1.1” is used part of the “http-req-headers” context. Here the hex 3a and 20 corresponds to colon and space characters.
• The pattern “Accept-Encoding|3a 20|gzip” is used part of the “http-req-headers” context. Here the hex 3a and 20 corresponds to colon and space characters.
• The pattern “DefaultForm\.((aspx)|(txt))\?” is used as part of the “http-req-uri-path” context. This is used since there is no 7 byte anchor provided in the pcre section of the snort signature.
• The final resulting Custom Spyware Signature is an AND of all the above signatures as seen below:

10. Click OK to create the new Spyware Object
    1. Verify the created Spyware Object is part of your Anti-Spyware Security Profile

2. Create a policy to block SMB application from internal to external zone or vice versa. This is a recommended best practice and addresses the “netbios-ssn” related snort signatures

3. Create an EDL object for suspicious IP addresses in IOC List
   1. Navigate to Objects tab -> External Dynamic Lists
   2. Click Add
   3. Add the suspicious IP addresses from the IOC list to a previously created EDL or a new EDL as shown below:

4. Create an EDL object for suspicious URL’s in IOC List
   1. Navigate to Objects tab -> External Dynamic Lists
   2. Click Add
   3. Add the suspicious URL’s from the IOC list to a previously created EDL or a new EDL as shown below.
   4. This can now be included with appropriate action under the URL Filtering Security Profile:

5. Create an EDL object for suspicious domains in IOC List
   1. Navigate to Objects tab -> External Dynamic Lists
   2. Click Add
   3. Add the suspicious domains from the IOC list to a previously created EDL or a new EDL as shown below.
   4. For the list of domains included in the External Dynamic List, the firewall creates a set of custom signatures of type spyware and medium severity, so that you can use the sinkhole action for a custom list of domains:

 

6. Add the EDL’s and Anti-Spyware profiles to appropriate Policy Objects.
7. Test Policy is working per expectation by looking at Threat logs.
8. Change the action for the spyware object from alert to drop/reset after verification. Also change severity of the custom object created as needed

Other useful information:

• Example GET Request-1:

• Example GET Request-2:

3. CVE-2018-4878

References:
https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=26998
https://www.flashpoint-intel.com/blog/targeted-attacks-south-korean-entities/
http://blog.talosintelligence.com/2018/02/group-123-goes-wild.html
https://threatpost.com/adobe-flash-player-zero-day-spotted-in-the-wild/129742/

Snort rule:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”Possible CVE-2018-4878 check-in alert”; flow:established,to_server; http_uri; content:”?id=”; http_uri; content:”&fp_vs=”; http_uri; content:”&os_vs=”; http_uri; reference: source, Vitali Kremez-Flashpoint; classtype:Trojan-activity; rev:1;)

IOC:
hxxp://www[.]1588-2040[.]co[.]kr/conf/product_old.jpg
hxxp://www[.]1588-2040[.]co[.]kr/design/m/images/image/image.php
hxxp://www[.]korea-tax[.]info/main/local.php
hxxp://www[.]dylboiler[.]co[.]kr/admincenter/files/board/4/manager.php

General Notes:

• Use the URL’s provided as part of the IOC to detect if a possible infection already exists by searching the Firewall logs.
• The URL’s provided can be made part of an EDL or a Custom URL Category Object that is added to a Policy as a URL filtering Profile.
• Use the provided Snort signature and convert it to a custom vulnerability signature. This signature will become part of the Vulnerability profile added to an appropriate Policy.

Detailed Steps:

1. Create a Custom Vulnerability Object
   1. Navigate to Objects tab -> Custom Objects -> Vulnerability
   2. Click on Add and provide appropriate details as shown in below screenshot

3. Click on Signatures -> Add [Standard Signature option]
4. The patterns ”id=”, “&fp_vs=” and ”&os_vs=” are used with the “http-req-params” context to create the custom vulnerability signature. This is done to overcome the 7 byte anchor restriction.
5. Also path in a HTTP request header upto and including the ‘?’ is part of the “http-req-uri-path” context and query string as well as parameters in the HTTP request is part of the “http-req-params” context.

6. Click OK to create the new Vulnerability Object.
7. Verify the created Vulnerability Object is part of your Vulnerability Protection Security Profile

2. Create a custom URL Category Object
   1. Navigate to Objects -> Custom Objects -> URL Category and add the suspicious URL’s part of the IOC list

2. Also add the URL Category Object to the appropriate URL Filtering Security Profile

3. Add the Vulnerability Security Profile and the URL Filtering Profile to the appropriate Policy
4. Test Policy is working per expectation by looking at Threat logs.
5. Change the action for the vulnerability object from alert to drop/reset after verification. Also change severity of the custom object created as needed

 Other Useful Information:

•  A snippet of the decompiled Flash object is shown below:

Recommendations

When deploying vulnerability protection and anti-spyware profile based policies, special care should be taken to avoid a negative impact on the protected traffic. While these signatures are developed with great care and are submitted to extensive regression tests, some of the signatures are generic in nature and can trigger on traffic coming from misconfigured services or faulty applications.

This is also true for any 3rd party content being used to build Custom Threat Signatures since they often have not been through the same number of extensive tests as the Palo Alto Networks developed threat signatures. Because of this, it is generally not a good idea to simply turn on blocking for Custom Threat Signatures without prior examination of those signatures and the potential impact they may have on the network.

If time and circumstances permit, it is advised to include an analysis phase in the vulnerability protection deployment timeline. In particular for environments where service availability is critical, such a phase will be required to assure proper functionality of the infrastructure once vulnerability protection and anti-spyware policies are made fully operational.

In general, it is advised to start with a profile that uses the default action for each signature. Especially for Custom threat signatures it is advised to start with a default action of “alert” for each created signature. Alternatively, it is possible to deploy a custom vulnerability protection profile in alert-only or monitoring mode first, to obtain a clear picture on how blocking-mode may affect the infrastructure. Such a profile will have the action set to ‘alert’ for each signature.

The following steps will help you determine the correct profile settings for a given location or host.

• Configure an ‘alert-only’ protection profile.
• Configure the necessary firewall rules for hosts and segments you want to protect.
• Apply the ‘alert-only’ protection profile to each rule.
• Monitor the threat logs for a representative period of time (e.g. 1 week, 1 month).
• Investigate any potential false positives.
• Use the gathered analysis information to build and fine-tune a block-enabled protection profile.

Additional Article Resources:

• TIPS & TRICKS: CUSTOM VULNERABILITY
• 5 STEPS TO A CUSTOM THREAT SIGNATURE
• CREATING A CUSTOM COMBINATION (BRUTE FORCE) SIGNATURE
• HOW TO GET HELP DEVELOPING CUSTOM APP, THREAT OR DATA FILTERING SIGNATURES

Additional links with other use cases and useful information:

• Custom vulnerability signature to detect FTP active mode
• Custom vulnerability signature for identifying WindowsXP
• List of different User-Agent strings
• Testing Pattern Performance Impact