[Emerging-Sigs] `former_category` metadatas

Richard Gonzalez rgonzalez at proofpoint.com
Tue Jun 16 13:00:15 HDT 2020

Thanks Duane - this is a formatting issue within our rule creation engine and how it deals with out internal and external metadata tags.

We're working on making the released rule content a little more 'graceful' for these purposes.



From: Emerging-sigs <emerging-sigs-bounces at lists.emergingthreats.net> on behalf of Duane Howard <duane.security at gmail.com>
Sent: Tuesday, June 16, 2020 3:40 PM
To: emerging-sigs at lists.emergingthreats.net <emerging-sigs at lists.emergingthreats.net>
Subject: [Emerging-Sigs] `former_category` metadatas

Stylistic question:

Is it intended that `former_category` metadata tags are independent of the other metadata tag in a given rule? Why not merge them into a single one?

For example:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET CURRENT_EVENTS SunDown EK RIP Landing M1 B641"; flow:established,from_server; file_data; content:"|4a694270626e525562314e30636968685a4752794b|"; metadata: former_category CURRENT_EVENTS; classtype:trojan-activity; sid:2024353; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, affected_product Web_Browser_Plugins, attack_target Client_Endpoint, deployment Perimeter, tag Exploit_Kit_Sundown, signature_severity Major, created_at 2017_06_07, malware_family Exploit_Kit, updated_at 2017_06_07;)

It also seems that this particular meta has a space following the `metadata` keyword where the later ones do not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20200616/a921e1b2/attachment.html>

More information about the Emerging-sigs mailing list