TDL Content Examples
This document shows validated examples of all the content types supported by TDL. As a member, you can use these examples to create valid TDL content in the supported file formats.
YARA rules are patterns or conditions written in the YARA language to identify and classify malware based on specific characteristics. They consist of strings, conditions, and optional actions, enabling the creation of flexible and customizable malware detection signatures. The following YARA rule is an example of successfully validated TDL content. This YARA rule is designed to detect the presence of the BlackHole Exploit Kit (EK) based on specific strings and conditions associated with the kit:
rule blackhole2_jar : EK
{
meta:
author = "John Doe"
date = "2016-06-27"
description = "BlackHole Exploit Kit Detection"
hash0 = "sjhbsvkiusbdosdbvskdvbsd"
sample_filetype = "unknown"
yaragenerator = "https://github.com/Xen0ph0n/YaraGenerator"
strings:
$string0 = "k0/3;N"
$string1 = "g:WlY0"
$string2 = "(ww6Ou"
$string3 = "SOUGX["
$string4 = "7X2ANb"
$string5 = "r8L<;zYH)"
$string6 = "fbeatbea/fbeatbee.classPK"
$string7 = "fbeatbea/fbeatbec.class"
$string8 = "fbeatbea/fbeatbef.class"
$string9 = "fbeatbea/fbeatbef.classPK"
$string10 = "fbeatbea/fbeatbea.class"
$string11 = "fbeatbea/fbeatbeb.classPK"
$string12 = "nOJh-2"
$string13 = "[af:Fr"
condition:
13 of them
}YAML is a human-readable data-serialization language and useful for managing data. YAML is used as a format to create detection rules in the security community and one such example is Sigma rules created in YAML format. Sigma makes it easy to perform content matching based on collected logs to create threat alerts. YAML files are also used to create MITRE Cyber Analytics Repository (CAR) files for detection. The following YAML rule is an example of successfully validated TDL content:
title: Antivirus Hacktool Detection id: fa0c05b6-8ad3-468d-8231-c1cbccb64fba description: Detects a highly relevant Antivirus alert that reports a hack tool or other attack tool status: experimental date: 2021/08/16 author: Florian Roth references: - https://www.nextron-systems.com/2021/08/16/antivirus-event-analysis-cheat-sheet-v1-8-2/ logsource: product: antivirus detection: selection: - Signature|startswith: - 'HTOOL' - 'HKTL' - 'SecurityTool' - 'ATK/' # Sophos - Signature|contains: - 'Hacktool' condition: selection fields: - FileName - User falsepositives: - Unlikely level: high tags: - attack.execution - attack.t1204
A Splunk query is used to run a specific operation within the Splunk software. A Splunk query uses the software’s Search Processing Language to communicate with a database or source of data. This allows data users to perform analysis of their data by querying it. Splunk’s query language is mainly used for parsing log files and extracting reference information from machine-produced data. Splunk query files are saved in .spl format. The following Splunk query is an example of successfully validated TDL content:
index=main earliest=-7d sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" LogName=System EventCode=7009 Message="A timeout was reached*" | table host _time Message
Snort is an open-source intrusion detection and intrusion prevention system (IDS/IPS) that monitors and analyzes network traffic in real-time to help identify and prevent potential security breaches. It analyzes network activity and compares it to predefined Snort rules to identify unusual patterns or behaviors that might indicate an intrusion or attack attempt. Besides, Snort rules can be configured to actively block or prevent malicious traffic from getting to its target, making it an effective tool for intrusion prevention. Snort rule files are saved in .rules format. The following Snort rule is an example of successfully validated TDL content:
# alert tcp $EXTERNAL_NET any -> $TELNET_SERVERS 23 (msg:"PROTOCOL-TELNET RuggedCom default backdoor login attempt"; flow:to_server,established; flowbits:isset,telnet.ruggedcom; content:"factory"; metadata:policy security-ips drop, service telnet; reference:cve,2012-1803; reference:url,www.securityfocus.com/archive/1/522467; classtype:attempted-admin; sid:21938; rev:4;) # alert tcp $TELNET_SERVERS 23 -> $EXTERNAL_NET any (msg:"PROTOCOL-TELNET login failed"; flow:to_client,established; content:"Login failed"; nocase; metadata:ruleset community, service telnet; classtype:bad-unknown; sid:492; rev:15;) # alert tcp $TELNET_SERVERS 23 -> $EXTERNAL_NET any (msg:"PROTOCOL-TELNET login incorrect"; flow:to_client,established; content:"Login incorrect"; metadata:ruleset community, service telnet; classtype:bad-unknown; sid:718; rev:16;)
Suricata is a Network Security Monitoring (NSM) tool that can detect and block attacks against your network. Suricata rules are pluggable intelligence components that are used to detect known threats in network traffic. Suricata rules are also used for sharing and matching threat intelligence against network traffic. Suricata rules are saved in .rules format. The following Suricata rule is an example of successfully validated TDL content:
alert ip any any -> any any (msg:"SURICATA Applayer Mismatch protocol both directions"; flow:established; app-layer-event:applayer_mismatch_protocol_both_directions; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260000; rev:1;) alert ip any any -> any any (msg:"SURICATA Applayer Wrong direction first Data"; flow:established; app-layer-event:applayer_wrong_direction_first_data; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260001; rev:1;) alert ip any any -> any any (msg:"SURICATA Applayer Detect protocol only one direction"; flow:established; app-layer-event:applayer_detect_protocol_only_one_direction; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260002; rev:1;) alert ip any any -> any any (msg:"SURICATA Applayer Protocol detection skipped"; flow:established; app-layer-event:applayer_proto_detection_skipped; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260003; rev:1;) # alert if STARTTLS was not followed by actual SSL/TLS alert tcp any any -> any any (msg:"SURICATA Applayer No TLS after STARTTLS"; flow:established; app-layer-event:applayer_no_tls_after_starttls; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260004; rev:2;) # unexpected protocol in protocol upgrade alert tcp any any -> any any (msg:"SURICATA Applayer Unexpected protocol"; flow:established; app-layer-event:applayer_unexpected_protocol; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260005; rev:1;) #next sid is 2260006
Orchestrate playbooks are a well-defined set of actions that are organized as a workflow to respond to an incident or a threat. You can use playbooks to automate various manual and repetitive tasks, as well as to orchestrate common scenarios including but not restricted to analyzing vulnerabilities, IOCs (Indicators of Compromise), searching for suspicious logs, and more. The following JSON is an example playbook from the Orchestrate application:
{
"title": "Connect the Dots :: Incident to Action",
"start_node": "start",
"nodes": {
"1": {
"type": "REGULAR",
"internal_id": "1",
"title": "incident to action",
"description": null,
"actions": [
{
"action": "update_incident",
"parameter_data_source": {
"status": "open",
"loop_keys": [],
"unique_id": "${event::data::inc_uid}",
"extra_fields": {
"actions": "$LIST[${event::data::action_uids}]",
"__loop_keys__": []
}
},
"action_type": "PREDEFINED",
"code": null,
"app_instances": [],
"playbook": null,
"playbook_data": null,
"action_data": {
"action_identifier": "update_incident",
"app": "cftr_v2",
"app_slug": "cftr_v2_2_4_1",
"app_version": "2.4.1",
"app_title": "Cyware Fusion and Threat Response (CFTR)",
"action_title": "Update Incident details",
"is_system": true
},
"output_params": {},
"save_customized_result": false,
"run_async": false,
"action_run_attempt": 1,
"action_run_buffer_time": 1,
"save_result": true,
"storage_manager_reference": []
}
],
"conditions": [],
"extra_params": {
"position": {
"x": 400,
"y": 200
}
},
"io_params_format": {},
"stop_on_error": true,
"memory_params": {},
"sub_type": "PREDEFINED",
"condition_type": null,
"io_params_email_details": null,
"enable_io_param_email_details": false,
"enable_app_notification": false,
"storage_manager_reference": []
},
"start": {
"type": "START",
"internal_id": "start",
"title": "Start",
"description": null,
"actions": [],
"conditions": [],
"extra_params": {
"position": {
"x": 400,
"y": 50
}
},
"io_params_format": {},
"stop_on_error": true,
"memory_params": {},
"sub_type": "start",
"condition_type": null,
"io_params_email_details": null,
"enable_io_param_email_details": false,
"enable_app_notification": false,
"storage_manager_reference": []
}
},
"edges": [
{
"source_node": "start",
"destination_node": "1",
"label": "DEFAULT_LABEL",
"extra_params": {}
}
],
"type": "UI",
"labels": [],
"tags": [],
"extra_params": {
"current_node": "1"
},
"status": "ACTIVE",
"script_content": "",
"cron_expression": null,
"output_params": {},
"is_runnable": false,
"description": "Incident description",
"auto_terminate": false,
"auto_terminate_interval": null,
"categories": [
"Incident Enrichment"
],
"schedule_info": {
"details": {
"run_count": 0
},
"is_scheduled": false
},
"storage_manager_reference": []
}