Malware Attribute Enumeration and Characterization (MAEC™) is a structured language for encoding and communicating high fidelity information about malware based upon attributes such as behaviors, artifacts, and attack patterns.
MAEC is pronounced as “mike.” This pronunciation stems from classical Latin, in which the diphthong ‘ae’ is pronounced as a long ‘i’. Examples of other words that use the same pronunciation are maestro and alumnae.
MAEC was developed to eliminate the ambiguity and inaccuracy that currently exists in malware descriptions. By reducing reliance on signatures, MAEC aims to improve human-to-tool, tool-to-tool, and tool-to-human communication about malware; allow for faster development of countermeasures by enabling the ability to leverage responses to previously observed malware instances; and reduce potential duplication of malware analysis efforts by researchers.
MAEC is a community-developed effort and has received input from members of various communities, including those from industry, academia, and government. The MITRE Corporation maintains MAEC and its public website presence and provides impartial technical guidance to the MAEC Community throughout the process to ensure MAEC serves the public interest. MAEC is sponsored by the office of Cybersecurity and Communications at the U.S. Department of Homeland Security.
MAEC is not currently being pursued in a formal standards body. However, once an appropriate level of maturity, stability, and use is achieved, international standardization will be sought.
NOTE: The MAEC Community is actively working on MAEC 5.0, the next version of the Malware Attribute Enumeration and Characterization (MAEC™) Language. Community members are encouraged to participate by joining in on our MAEC Community teleconference working call meetings.
The current version of the Malware Attribute Enumeration and Characterization (MAEC™) Language is available on the Current Release page. In addition, the current MAEC schema, as well as example files, schematron rules, and related documentation, are available in the MAEC Schemas in the MAECProject repository on GitHub.com.
Both PDF and Word versions of the current MAEC Language Specifications are available.
Examples can be found in the MAEC Schemas MAECProject repository on GitHub.com.
MAEC can be manipulated manually or programmatically. If using MAEC manually, such as to capture malware analysis results, no tools are currently provided, but use of an XML editor is recommended.
For programmatic development and use, some MAEC scripts and translator utilities are hosted in separate MAECProject GitHub repositories. In addition, a Python API for parsing, manipulating, and generating MAEC content is hosted in the MAECProject Python-MAEC GitHub repository.
A GUI is not available at this time, but such a tool could be available in the future.
Visit the MAEC Version 5.0 Roadmap for additional information.
Visit the Current Release page for examples.
At present, there are no public repositories of MAEC data, nor are there plans by MITRE to establish one. However, community members interested in hosting a MAEC data repository are strongly encouraged to do so.
A MAEC release includes individually-versioned MAEC schemas (i.e., Bundle, Package, and Container schemas) and the latest versions of the independently-versioned MAEC vocabulary schemas.
MAEC releases are packaged in two different ways:
Some of the FAQs in this section are somewhat technical in nature. Please refer to the MAEC Language Specifications for further information.
The MAEC schema was developed to enable analysts to capture a full gamut of information about malware. However, a MAEC Bundle is valid with very little information: it is only necessary to define a unique identifier and to specify the MAEC schema version. All other fields are optional.
Aside from a unique identifier and the MAEC schema version, all objects are optional in MAEC. This was done to make the language as flexible as possible: a user is able to capture exactly what they want and nothing more.
The xsi:type XML schema extension mechanism works by allowing for the substitution of types that are created as derivatives of an existing abstract type. As such, one must simply include the xsi:type attribute on an element that uses the parent abstract type, and accordingly specify the name of the type that one wishes to substitute for this element inside this attribute. For example, if one wishes to use the FileObj:FileObjectType type from Cyber Observables Expression (CybOX™) in the Properties element (which uses the abstract cyboxCommon:ObjectPropertiesType) of the Malware Instance Object Attributes in a MAEC Bundle, they would specify the xsi:type attribute on this element with the name of the object type inside:
<maecBundle:Malware_Instance_Object_Attributes> <cybox:Properties xsi:type="FileObj:FileObjectType"> <FileObj:File_Name>dg003_improve_8080_V132.exe</FileObj:File_Name> <FileObj:Size_In_Bytes>196608</FileObj:Size_In_Bytes> </cybox:Properties> </maecBundle:Malware_Instance_Object_Attributes>
MAEC is very flexible and can accommodate custom fields and objects. For example, one can use the Custom Properties/Property fields at the root level of the larger Cyber Observables Expression (CybOX™) ObjectType specify a set of custom attributes that are not defined elsewhere. Accordingly, it is possible to define a new type of CybOX Object that can then be plugged into the Property field of the CybOX ObjectType using the xsi:type extension mechanism (e.g., xsi:type=”CustomObj:CustomObjectType”).
In addition, the MAEC development team encourages the community to engage in the ongoing discussion so that new fields can be defined and integrated into future versions of MAEC as necessary. Please consider participating in the MAEC Community to help with the development of MAEC.
Yes. MAEC is very flexible and there are often a multiple places that the same characterized information, e.g., a particular Action or Behavior, can be captured.
Cyber Observable eXpression (CybOX™) provides a structured language for describing elements within the cyber operational environment. MAEC uses components of the CybOX language for characterizing cyber observables associated with malware. In particular, MAEC makes use of CybOX’s Object and Action fields (which are extended in MAEC’s MalwareActionType type) to characterize malware-related system artifacts and low-level behaviors, respectively.
Structured Threat Information eXpression (STIX™) characterizes a rich set of cyber threat information in a standardized and structured manner. STIX can describe malware using MAEC characterizations through use of the MAEC schema extension for the TTP schema and can also characterize indicators in a fashion similar to MAEC’s Candidate Indicators.
STIX is used to describe high-level cyber threat information to include indicators, as well as information about threat actors, campaigns, incidents, and other related entities. On the other hand, MAEC is used to describe malware attributes of one or more malware instances at various levels of abstraction. Certainly, there is overlap between the two languages, particularly when it comes to capturing indicator information (e.g., file sizes, file hashes) through the common use of Cyber Observable eXpression (CybOX™).
While there are no definite rules for what is most appropriately captured with MAEC versus STIX, MAEC will typically be used to capture malware information that is gathered through the analysis process, and STIX will be used to capture information related to the interpretation of the analysis results in a broader, threat-based context. For example, while MAEC would capture the particular details of the behaviors and artifacts associated with a malware instance, STIX would be used to capture additional details regarding the particular threat actors that may make use of the malware instance. Thus, when malware analysis information beyond simple indicator information is to be captured by STIX, the STIX schema extension for MAEC should be used to leverage the MAEC data model.
Trusted Automated eXchange of Indicator Information (TAXII™) defines a set of services and message exchanges for securely sharing automated cyber threat information. TAXII uses Structured Threat Information eXpression (STIX™) to represent cyber threat information in a standardized and structured manner (STIX characterizes what is being shared, while TAXII defines how the STIX payload is shared). STIX is one payload that TAXII can convey, and STIX can describe malware using MAEC.
The MAEC Community includes representatives from antivirus vendors, operating system vendors, software vendors, IT users, security services providers, and others from across the international cyber security community who have come together to help build this growing, open-source industry effort.
There are multiple options available for involvement including participating in the conversations on our dedicated email discussion list, contributing to the MediaWiki on MITRE’s collaboration website, contributing to the development of MAEC tools and utilities on GitHub, and/or joining us on the working calls to help develop MAEC Version 5.0.
The MITRE Corporation (MITRE) manages and maintains the development of the MAEC Language, MAEC website, community engagement, and discussion lists to enable open and public collaboration with all stakeholders and provides neutral guidance throughout the process to ensure that MAEC serves the public interest.
In accordance with its mission, MITRE has traditionally acted in the public interest. Its unique role allows it to provide an objective perspective to this effort. MITRE will maintain MAEC as long as it serves the community to do so.
MAEC is a DHS-led and sponsored effort of the office of Cybersecurity and Communications at the U.S. Department of Homeland Security (DHS). MITRE, operating as DHS’s Federally Funded Research and Development Center (FFRDC), manages the development of the MAEC Language, this MAEC website, community engagement, and discussion lists to enable open and public collaboration with all stakeholders.