{% extends base_template %} {% block title_page %}AL - Malware standard{% endblock %} {% block body_param %}data-target=".bs-docs-sidebar" data-scroll-offset="60" data-spy="scroll"{% endblock %} {% block content %}

Yara Signatures

:: {% block sub_title %}MALWARE standard{% endblock %} ::

{% block intro%}

Introduction

The MALWARE standard defines the sets of required and optional meta data fields essential for rule sharing across multiple organisations. It also provides a styling guide for the construction and sharing of consistent of Yara rules.

The MALWARE standard reflects the requirements necessary for successful yara rules sharing amongst each of the collaborating organisations. This standard should evolve and adapt to the shape and nature of the underlying business demands as time progresses.

{% endblock %}
{% block versioning %}

Versioning and revision

Passing a new revision of the MALWARE standard requires input and agreement from each of the contributing organisations.

Version management

The version number indicates breaks down into [major].[minor].[release].

The major number indicates that there were changes applied to the standard which break backwards compatibility with the previous standard.

The minor number indicates changes were made to the standard but still maintain compatibility with the major revision number.

The release number is used for project releases. This is where fixes and enhancements have been applied to the project that do not change the standard in any way.

History

  • 1.0.0 - Initial draft.
  • 1.1.0 - Small changes to rule ID for ALv4 compatibility
{% endblock %}

Sharing

The sharing of rules to anyone not defined by the organisations listed in the required metadata field section organisation is prohibited without acquiring official consent from that organisation’s poc.

Style guide

The following outlines the coding conventions that should be applied when defining a Yara rule.

The aim of this guide is to foster consistency across rule definitions in order to build common look and feel across all rules. As they are only guidelines, they may be ignored if it is absolutely sensible and necessary to do so.

  • Field names will be all lowercase.

  • The meta fields should begin with the rule_group definition.

  • Required fields should be in alphabetical order and grouped together after the rule_group definition.

  • Optional fields should be in alphabetical order and grouped together after the required fields.

  • By convention, comma separated values will be in the format ”, ” where it is comma space instead of just a comma:

    Good: technique = "cryptography, xor"
    	Bad:  technique = "cryptography,xor"

    Whitespace at the start and end of each value will be stripped:

    technique = "xor , shellcode " will resolve to "xor" and "shellcode"

Required metadata fields

This section outlines and defines each of the required metadata fields.

rule_group and [name of rule_group]

The rule_group field must be one of the following:
  • implant
  • exploit
  • technique
  • info
  • tool

Rules are to have only one rule_group definition.

The [rule_group value] field may have multiple comma separated values. Spaces are allowed in these values and by convention should be used (i.e. there is no requirement to use underscores or other substitute characters in place of spaces in names or phrases).

Example of a technique rule:

meta:
    rule_group = "technique"
    technique = "cryptograph, xor"

The remainder of this section will document the concepts and intent behind each of the defined rule_group types.

implant

Name of the implant.

Example values for implant:

  • poison ivy
  • zeus

Example of a implant rule:

meta:
    rule_group = "implant"
    implant = "poison ivy"

exploit

Example values for exploit:

exploit = "rtf, CVE-2010-3333"

or

exploit = "javascript"

info

Signature that identifies an inherently benign functionality or information, but is of interest to an analyst.

The follow are sets of examples to help describe specific information that has been identified by a rule.

An example on how to capture information about an API:

info = "api, socket"

An example on how to capture information on a library:

info = "library, openssl"

An example on how to capture information regarding types of communications. Note that implant labeled communications protocols should go under implant.

info = "communications, http, https, ftp"

An example of labeling different types of files

info = "magic, pdf"

technique

Examples values for technique:

technique = "keylogger"

Other types of techniques may be cryptography, obfuscation, obfuscator, deobfuscator, injector, downloader, etc...

tool

Example values for tool:

tool = "metasploit framework, meterpreter"
{% block extra_1%} {% endblock %}

description

Contains a single sentence description about what the rule hits on. Maximum of 80 characters.

Example:

description = "My blarg blobs foo bar"
{% block organisation %}

organisation

Organisation must be willing to contribute to the sharing of rules and setting of rule standards. Values must be uppercase.

{% endblock %}

poc

This field denotes the main point of contact from the originating organisation for the rule.

The format of the poc must be as follows:

  • Must contain the UserID POC for this signature.
  • Must have the @ symbol followed by the organisation of the indivdual.
  • The organisation in this field must be lowercase.
  • Can have multiple, comma separated list of POCs.

Example:

poc = "bob@org, user@org"

rule_id

This field is a unique rule identifier to be used by organisations as a point of reference.

The format of the rule must be as follows:

  • Must begin with the organisation name from the organisation field.
  • Organisation must be uppercase.
  • Must end with a 6 digit value as determined by the originating organisation.
  • The organisation and numerical value are separated by a single underscore “_”.

Example:

rule_id = "ORG_000459"

rule_version

The rule_version is used to keep track of revisions of a given rule.

The format for rule_version must be as follows:

  • Must belong to the natural number set.
  • Should start at the number “1”.

If the rule is ever modified/edited, the rule_version should be incremented by 1.

Note: When a rule is modified, the modification date should also be changed to reflect the change.

yara_version

The yara library version this rule was designed against.

Example:

yara_version = "3.3"

Optional metadata fields

creation_date

Date the original rule was created. The format must be YYYY-MM-DD.

Example:

creation_date = "2013-09-20" 

exemplar_hash

Hash of a binary representing an exemplar samples for the rule. The supported hash formats are:

  • MD5
  • SHA1
  • SHA256

Example:

exemplar_hash = "00000000000000000000000000000000" 

modification_date

Date the rule was last modified. The format must be YYYY-MM-DD.

Example:

modification_date = "2013-09-22" 

origin

The where, who, or how this rule was acquired or created. The format for this field is freeform text with a maximum of 80 characters.

Example 1:

origin = "John Doe - ORGANISATION" 

Example 2:

origin = "http://code.google.com/yarasigs" 

Example 3:

origin = "COMPANY FOO, Inc. - Description about company" 
{% block extra_2%} {% endblock %}

{{app_name}} specific fields

summary

This is a summary of the description that will generate a summary TAG to be referenced in the executive summary section of a submission.

Example:

summary = "Obfuscated PDF" 

al_score

This is a score override for {{app_name}} scoring. Usually, implant, tool and exploit generate a score of 500 in {{app_name}}. Technique a score of 100 and info a score of zero. If you are not satisfied with these score and you want to bump up the score of a given rule, you can set the score override to a integer value that will replace the default score.

Example:

al_score = "1000"

al_state_change_user (control)

This is a control field. You should not be able to edit it. It contains the name of the last person who changed the al_status field of the rule. This field is only modified by the API.

Example:

al_state_change_user = "user" 

al_state_change_date

This is a control field. You should not be able to edit it. It contains the date at which the al_status field of the rule was last modified. This field is only modified by the API.

Example:

al_state_change_date = "2014-07-23" 

al_status

This is the state of the rule in the system.

These are the different possible states:

  • TESTING => Rule is being created
  • STAGING => Rule is being tested in staging environment
  • DEPLOYED => Rule is deployed in production
  • NOISY => Rule is deployed in production but marked as noisy
  • DISABLED => Rule was disabled
  • INVALID => Rule hash been marked by the Yara service as invalid. See rule comments.

Example:

al_status = "DEPLOYED" 

last_saved_by

This is a control field. You should not be able to edit it. It contains the uid of the user who last modified the rule. This field is only modified by the API.

Example:

last_saved_by = "user" 
{% endblock %}