[et_pb_section fb_built=”1″ _builder_version=”3.22″][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”4.4.2″ hover_enabled=”0″]<\/p>\n
A long time ago I’ve noticed that there is no single best YARA rule for a given sample, but different best solutions depending on the user’s requirements and use case. I noticed that I often create 2 to 3 YARA rules for a single sample that I process, while each of them serves a different purpose.<\/p>\n
In this blog post, I’d like to describe the three most common rule types.<\/p>\n
In the following example I’ll use the\u00a0malware sample with hash\u00a07415ac9d4dac5cb5051bc0e0abff69fbca4967c7 (VirusBay<\/a>, Hybrid-Analysis<\/a>)<\/p>\n While looking at the strings extracted by yarGen, you’ll notice that it contains a lot of interesting strings. In my past tutorials (1<\/a>, 2<\/a>, 3<\/a>) I’ve always distinguished between “Highly Specific” and “Suspicious” strings (see Part 3<\/a> of the blog post series). Today I’d like to show you a more purpose oriented approach.\u00a0<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”3.25″][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_image src=”https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2019\/01\/Screenshot-2019-01-02-at-15.11.25.png” align_tablet=”center” align_last_edited=”on|desktop” _builder_version=”4.4.2″ hover_enabled=”0″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”3.25″][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″]<\/p>\n The following screenshots shows what types of strings I see while looking at these strings:<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”3.25″][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_image src=”https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2019\/01\/what_i_see-yara.png” align_tablet=”center” align_last_edited=”on|desktop” _builder_version=”4.4.2″ hover_enabled=”0″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”3.25″][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″]<\/p>\n The strings that are marked with yellow look very specific. I’d use them as “Highly Specific” strings ($x*) of which only a single one is required to trigger the rule:\u00a01 of ($x*)<\/span><\/p>\n The strings marked green will be used in combination with other green strings. A reasonable set of these strings is required to trigger the rule:\u00a0$u1 and 1 of ($f*)<\/p>\n The strings marked with red color could serve in a rule that tracks the C2 addresses used by this sample and the strings marked blue could be used for a generic detection of malicious samples that can be completely unrelated.<\/p>\n The different rule categories are:<\/p>\n The following table describes these three different types of rules and gives some string examples.<\/span>\u00a0<\/span><\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_image src=”https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2019\/01\/Screenshot-2019-01-02-at-14.42.29.png” show_in_lightbox=”on” align_tablet=”center” align_last_edited=”on|desktop” _builder_version=”4.4.2″ hover_enabled=”0″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”3.25″][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″]<\/p>\n In the case of the “Regular Rules” I distinguish between two different flavors:\u00a0<\/p>\n The difference between these flavors is based on a different level of strictness in the conditions and not on the different selection of strings. While a “threat detection” rule may require “6 of them”, a “threat hunting” rule may be satisfied with “3 of them”, accepting some false positives.\u00a0<\/p>\n The reason why someone distinguishes between “threat detection” and “threat hunting” rules is that the response to matches can be very different. Antivirus solutions that respond to matches with “delete” or “disinfect” reactions do not accept false positives and avoid false positives by any means.<\/p>\n In “threat hunting” use cases which include direct destructive reactions to signatures matches are rare. Typically analysts investigate such an event, classify and react to it manually. In “threat hunting” scenarios analysts try to avoid “false negatives” by all means.\u00a0<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”3.25″][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_image src=”https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2019\/01\/tweeten-1546448328008.jpg” align_tablet=”center” align_last_edited=”on|desktop” _builder_version=”4.4.2″ hover_enabled=”0″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”3.25″][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″]<\/p>\n (Source: Chris Gerritz @gerritzc<\/a>)\u00a0<\/p>\n Threat Intel Tracking<\/span><\/p>\n In threat intel, we can use YARA rules to track the activity of certain actors in cases in which there are certain characteristics or keywords that persist over longer periods and campaigns.\u00a0<\/p>\n A very convenient form of tracking without having access to the telemetry data of OS and AV vendors is offered in the form of YARA match notification services as provided by VirusTotal<\/a> or ReversingLabs<\/a>.\u00a0<\/p>\n During the past year I focussed on the last rule type “Method Detection” whenever I had the opportunity as it allows me to provide very generic rules that produce amazing results with a minimum of false positives.<\/p>\n However, those rule matches lack a reference like a malware name or an adversary group that used the detected method in their samples. Here is an example with one of the few public YARA rules published in the “<\/span>signature-base<\/a>” repository:<\/span><\/p>\n Sample:\u00a0fc18bc1c2891b18bfe644e93c60a2822ad367a697bebc8c527bc9f14dad61db5<\/span><\/a>\u00a0<\/span><\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”3.25″][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_image src=”https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2019\/01\/Screenshot-2019-01-02-at-17.52.30.png” align_tablet=”center” align_last_edited=”on|desktop” _builder_version=”4.4.2″ hover_enabled=”0″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”3.25″][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″]<\/p>\n\n
Regular Rules<\/h1>\n
\n
Method Detection Rules<\/h1>\n