├── LICENSE
├── images
├── roota_logo.png
├── roota_logo_double.png
└── roota_logo_horizontal.png
├── README.md
├── README_Spanish.md
├── README_Ukrainian.md
├── Roota_Specification.md
└── Roota_Specification_Ukrainian.md
/LICENSE:
--------------------------------------------------------------------------------
1 | RootA is a public-domain language
2 |
--------------------------------------------------------------------------------
/images/roota_logo.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/UncoderIO/Roota/HEAD/images/roota_logo.png
--------------------------------------------------------------------------------
/images/roota_logo_double.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/UncoderIO/Roota/HEAD/images/roota_logo_double.png
--------------------------------------------------------------------------------
/images/roota_logo_horizontal.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/UncoderIO/Roota/HEAD/images/roota_logo_horizontal.png
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 |
2 | 
3 |
4 |
5 | # An Open-Source Language for Collective Cyber Defense
6 | :earth_americas: [English](README.md) | [Українська](README_Ukrainian.md) | [Español](README_Spanish.md)
7 |
8 | Roota is a public-domain language for collective cyber defense, created to make threat detection, incident response, and actor attribution simple. It acts as an open-source wrapper on top of most of the existing SIEM, EDR, XDR, and Data Lake query languages. If you learn the basics of Roota, you will be able to contribute to collective defense. And if you have mastered a specific SIEM language, with Roota and Uncoder IO you can speak them all.
9 |
10 | **Table Of Contents:**
11 |
12 | - [Why Roota](#smiling_face_with_three_hearts-why-roota)
13 | - [Writing Roota Rules](#mage-writing-roota-rules)
14 | - [How to Contribute](#cookie-how-to-contribute)
15 | - [Maintainers](#smile_cat-maintainers)
16 | - [Credits](#clap-credits)
17 | - [Licenses](#globe_with_meridians-licenses)
18 | - [Resources & Useful Links](#book-resources--useful-links)
19 |
20 | ## :smiling_face_with_three_hearts: Why Roota
21 | The objective of Roota is to accelerate the global cybersecurity industry collaboration. With Roota acting as a wrapper, cyber defenders can take a native rule or query and augment it with metadata to automatically translate the code into other SIEM, EDR, XDR, and Data Lake languages. Inspired by the success of Yara and Sigma rules, Roota is focused on a broader applicability by a larger community of defenders.
22 |
23 | - Roota is expressed using **YAML**, a widely spread, easy-to-write, human-readable format.
24 | - **Use any query language** for detection, Uncoder IO will take care of the translation.
25 | - **Correlation support.** Common correlations are supported by Roota in order to make detection logic harder to bypass by the attackers, more compute efficient, and future-proof.
26 | - **Log sources** can be explicitly or implicitly defined in the native query itself or in the customizable `logsource` field.
27 | - Roota syntax fully accommodates **OCSF** and **Sigma** as taxonomy, making it fast to learn, easy to read and share, and providing maximum compatibility for Detection Engineers.
28 | - **Threat Actor Timeline.** While Actors change, behaviors often stay the same. Roota supports an additional threat intelligence layer for CERTs, NCSCs, ISACs, MDRs, and Defence Agencies, to coordinate defense faster and with greater precision.
29 | - **Mapping to TTPs.** Link detection logic to related tactics, techniques, and procedures in terms of MITRE ATT&CK®. Use custom tags to make the mapping even more tailored and detailed.
30 | - **Response as Code.** With enough community members and industry adoption, the next step after detection is sharing the code to automate response.
31 |
32 | ## :mage: Writing Roota Rules
33 | You can start writing Roota rules in any code editor that supports YAML.
34 | To translate Roota rules to other languages use Uncoder IO by building it from the source https://github.com/UncoderIO/UncoderIO or hosted online privately by SOC Prime since 2018 at https://uncoder.io
35 |
36 | ### Roota Rule Templates
37 | Roota Rule format has minimal, full, and extended templates.
38 |
39 | **Minimal** template is for keeping rules simple, requiring only a name, description, author, severity, date, MITRE ATT&CK tags, detection query in any specific language, reference, and license.
40 |
41 | **Full** template is for adding alerting context, threat actor campaign timeline, specific log source attributes defined based on Sigma Rules or OCSF taxonomy, and cross-platform correlation section.
42 |
43 | **Extended** template is currently reserved for adding response as code and experimental features.
44 |
45 | #### Minimal Roota rule example:
46 | ```
47 | name: Possible Credential Dumping Using Comsvcs.dll (via cmdline)
48 | details: Adversaries can use built-in library comsvcs.dll to dump credentials on a compromised host.
49 | author: SOC Prime Team
50 | severity: high
51 | date: 2020-05-24
52 | mitre-attack:
53 | - t1003.001
54 | - t1136.003
55 | detection:
56 | language: splunk-spl-query # elastic-lucene-query, logscale-lql-query, mde-kql-query
57 | body: index=* ((((process="*comsvcs*") AND (process="*MiniDump*")) OR ((process="*comsvcs*") AND (process="*#24*"))) OR ((process="*comsvcs*") AND (process="*full*")))
58 | references:
59 | - https://badoption.eu/blog/2023/06/21/dumpit.html
60 | license: DRL 1.1
61 | ```
62 |
63 | #### Full Roota rule example:
64 | ```
65 | name: Possible Credential Dumping Using Comsvcs.dll (via cmdline)
66 | details: Adversaries can use built-in library comsvcs.dll to dump credentials on a compromised host.
67 | author: SOC Prime Team
68 | severity: high
69 | type: query
70 | class: behaviour
71 | date: 2020-05-24
72 | mitre-attack:
73 | - t1003.001
74 | - t1136.003
75 | tram-tags:
76 | NaiveBayes:
77 | - t1136.003
78 | MLPClassifier:
79 | - t1003.001
80 | LogisticRegression:
81 | - t1003
82 | - t1003.005
83 | detection:
84 | language: splunk-spl-query # elastic-lucene-query, logscale-lql-query, mde-kql-query
85 | body: index=* ((((process="*comsvcs*") AND (process="*MiniDump*")) OR ((process="*comsvcs*") AND (process="*#24*"))) OR ((process="*comsvcs*") AND (process="*full*")))
86 | logsource:
87 | product: Windows # Sigma or OCSF products
88 | log_name: Security # OCSF log names
89 | class_name: Process Activity # OCSF classes
90 | #category: # Sigma categories
91 | #service: # Sigma services
92 | audit:
93 | source: Windows Security Event Log
94 | enable: Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking -> Audit Process
95 | timeline:
96 | 2022-04-01 - 2022-08-08: Bumblebee
97 | 2022-07-27: KNOTWEED
98 | 2022-12-04: UAC-0082, CERT-UA#4435
99 | references:
100 | - https://badoption.eu/blog/2023/06/21/dumpit.html
101 | tags: Bumblebee, UAC-0082, CERT-UA#4435, KNOTWEED, Comsvcs, cir_ttps, ContentlistEndpoint
102 | license: DRL 1.1
103 | version: 1
104 | uuid: 151fbb45-0048-497a-95ec-2fa733bb15dc
105 | correlation:
106 | timeframe: 1m
107 | functions: count() > 3
108 | #response: [] # extended format
109 | ```
110 |
111 | ### Fields
112 | [Roota specification](https://github.com/UncoderIO/Roota/blob/main/Roota_Specification.md) includes the list of all fields that can be used to write a Roota rule.
113 |
114 | ## :cookie: How to Contribute
115 | Your contribution really matters in evolving the project and helping us make the Roota language even more useful for the global cyber defender community.
116 |
117 | To submit your pull request with your ideas or suggestions for changes, take the following steps:
118 |
119 | 1. Fork the [Roota repository](https://github.com/UncoderIO/Roota/tree/main) and clone your fork to your local environment.
120 | 2. Create a new feature branch in which you’re going to make your changes.
121 | 3. Then commit your changes to your newly created feature branch.
122 | 4. Push the changes to your fork.
123 | 5. Create a new Pull Request
124 | a. Clicking the New Pull Request button.
125 | b. Select your fork along with a feature branch.
126 | c. Provide a title and a description of your changes. Make sure they are both clear and informative.
127 | d. Finally, submit your Pull Request and wait for its approval.
128 |
129 | Thank you for your contribution to the Roota project!
130 |
131 | ## :smile_cat: Maintainers
132 | - [Roman Ranskyi](https://www.linkedin.com/in/roman-966b91b5/)
133 | - [Alex Bredikhin](https://www.linkedin.com/in/bredikhin/)
134 | - [Adam Swan](https://github.com/acalarch/)
135 | - [Ruslan Mikhalov](https://www.linkedin.com/in/rmikhalov/)
136 | - [Andrii Bezverkhyi](https://www.linkedin.com/in/andriimb/)
137 |
138 | ## :clap: Credits
139 | We are genuinely grateful to security professionals who contribute their time, expertise, and creativity to evolve the Roota open-source project.
140 |
141 | ## :globe_with_meridians: Licenses
142 | The contents of this repo, along with Roota specifications, are in the public domain.
143 |
144 | ## :book: Resources & Useful Links
145 | - [Roota.IO](https://roota.io/) the main website page of the Roota project
146 | - [Uncoder.IO](https://github.com/UncoderIO/UncoderIO/) source code for translation engine Uncoder IO which supports Roota, Sigma, and IOC packaging into specific SIEM, EDR, and Data Lake query formats
147 | - [Uncoder.IO](https://uncoder.io/) private hosted version of Uncoder IO since 2018, operated by SOC Prime, does not track you, does not see your code
148 | - [Roota Discord Channel](https://tdm.socprime.com/zeptolink/5IAokHui2iWUHaB8/) Discord channel to network with Roota enthusiasts
149 |
--------------------------------------------------------------------------------
/README_Spanish.md:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | # Un lenguaje de código abierto para la ciberdefensa colectiva
6 | :earth_americas: [English](README.md) | [Українська](README_Ukrainian.md) | [Español](README_Spanish.md)
7 |
8 | Roota es un lenguaje de dominio público que contribuye a la ciberdefensa colectiva, creado para simplificar la detección de amenazas, la respuesta a incidentes y la atribución de adversarios. Actúa como un contenedor de código abierto sobre la mayoría de los lenguajes de consulta SIEM, EDR, XDR y Data Lake existentes. Si aprendes los conceptos básicos de Roota, podrás contribuir a la defensa colectiva. Y si dominas un idioma SIEM específico, con Roota y Uncoder IO, podrás manejarlos todos.
9 |
10 | **Tabla de Contenidos:**
11 |
12 | - [Porqué Roota](#smiling_face_with_three_hearts-porqué-roota)
13 | - [Escribir reglas Roota](#mage-escribir-reglas-roota)
14 | - [Cómo contribuir](#cookie-cómo-contribuir)
15 | - [Mantenedores](#smile_cat-mantenedores)
16 | - [Créditos](#clap-créditos)
17 | - [Licencias](#globe_with_meridians-licencias)
18 | - [Recursos y link útiles](#book-recursos-y-link-útiles)
19 |
20 | ## :smiling_face_with_three_hearts: Por qué Roota?
21 | El objetivo de Roota es acelerar la colaboración global en la industria de la ciberseguridad. Con Roota actuando como contenedor, los ciber defensores pueden tomar una regla o consulta nativa y potenciarla con metadatos para traducir automáticamente el código a otros lenguajes SIEM, EDR, XDR y Data Lake. Inspirado por el éxito de las reglas de Yara y Sigma, Roota se centra en una aplicabilidad más amplia por parte de una gran comunidad de defensores.
22 |
23 | - Roota se expresa mediante **YAML**, un formato ampliamente difundido, fácil de escribir y legible por humanos.
24 | - **Utilice cualquier lenguaje** de consulta de detección, Uncoder IO se encargará de la traducción.
25 | - **Soporte de correlación.** Roota admite correlaciones comunes para hacer que la lógica de detección sea más difícil de eludir por parte de los atacantes, una alta eficiencia de procesamiento y con durabilidad a largo plazo.
26 | - Las **fuentes de registro** se pueden definir explícita o implícitamente en la propia consulta nativa o en el campo de fuente de registro personalizable.
27 | - La sintaxis de Roota se adapta completamente a **OCSF** y **Sigma** como taxonomía, lo que la hace rápida de aprender, fácil de leer y compartir, y brinda máxima compatibilidad para los ingenieros de detección.
28 | - **Cronología del actor de amenazas.** Si bien los actores cambian, los comportamientos suelen permanecer iguales. Roota admite una capa adicional de inteligencia sobre amenazas para CERT, NCSC, ISAC, MDR y agencias de defensa, para coordinar la defensa más rápido y con mayor precisión.
29 | - **Mapeo a TTP.** Vincular la lógica de detección con tácticas, técnicas y procedimientos relacionados en términos de MITRE ATT&CK®. Utilice etiquetas personalizadas para que el mapeo sea aún más personalizado y detallado.
30 | - **Respuesta como código.** Con una participación suficiente de la comunidad y una aceptación generalizada en la industria, el siguiente paso después de la detección es compartir el código para automatizar la respuesta.
31 |
32 | ## :mage: Escribir reglas Roota
33 | Puedes comenzar a escribir reglas Roota en cualquier editor de código que admita YAML. Para traducir las reglas de Roota a otros lenguajes, utiliza Uncoder IO compilándolo desde la fuente https://github.com/UncoderIO/UncoderIO o alojado en línea de forma privada por SOC Prime desde 2018 en https://uncoder.io
34 |
35 | ### Plantillas de reglas Roota
36 | El formato de regla Roota tiene plantillas mínimas, completas y extendidas.
37 |
38 | La plantilla **mínima** sirve para mantener las reglas simples y solo requiere un nombre, descripción, autor, gravedad, fecha, etiquetas MITRE ATT&CK, consulta de detección en cualquier idioma específico, referencia y licencia.
39 |
40 | La plantilla **completa** sirve para agregar contexto de alerta, cronograma de campaña de actores de amenazas, atributos de origen de registro específicos definidos en función de las reglas Sigma o la taxonomía de OCSF y una sección de correlación multiplataforma.
41 |
42 | Actualmente, la plantilla **extendida** está reservada para agregar respuestas como código y funciones experimentales.
43 |
44 | #### Ejemplo de regla mínima Roota:
45 | ```
46 | name: Possible Credential Dumping Using Comsvcs.dll (via cmdline)
47 | details: Adversaries can use built-in library comsvcs.dll to dump credentials on a compromised host.
48 | author: SOC Prime Team
49 | severity: high
50 | date: 2020-05-24
51 | mitre-attack:
52 | - t1003.001
53 | - t1136.003
54 | detection:
55 | language: splunk-spl-query # elastic-lucene-query, logscale-lql-query, mde-kql-query
56 | body: index=* ((((process="*comsvcs*") AND (process="*MiniDump*")) OR ((process="*comsvcs*") AND (process="*#24*"))) OR ((process="*comsvcs*") AND (process="*full*")))
57 | references:
58 | - https://badoption.eu/blog/2023/06/21/dumpit.html
59 | license: DRL 1.1
60 | ```
61 |
62 | #### Ejemplo de regla completa Roota:
63 | ```
64 | name: Possible Credential Dumping Using Comsvcs.dll (via cmdline)
65 | details: Adversaries can use built-in library comsvcs.dll to dump credentials on a compromised host.
66 | author: SOC Prime Team
67 | severity: high
68 | type: query
69 | class: behaviour
70 | date: 2020-05-24
71 | mitre-attack:
72 | - t1003.001
73 | - t1136.003
74 | detection:
75 | language: splunk-spl-query # elastic-lucene-query, logscale-lql-query, mde-kql-query
76 | body: index=* ((((process="*comsvcs*") AND (process="*MiniDump*")) OR ((process="*comsvcs*") AND (process="*#24*"))) OR ((process="*comsvcs*") AND (process="*full*")))
77 | logsource:
78 | product: Windows # Sigma or OCSF products
79 | log_name: Security # OCSF log names
80 | class_name: Process Activity # OCSF classes
81 | #category: # Sigma categories
82 | #service: # Sigma services
83 | audit:
84 | source: Windows Security Event Log
85 | enable: Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking -> Audit Process
86 | timeline:
87 | 2022-04-01 - 2022-08-08: Bumblebee
88 | 2022-07-27: KNOTWEED
89 | 2022-12-04: UAC-0082, CERT-UA#4435
90 | references:
91 | - https://badoption.eu/blog/2023/06/21/dumpit.html
92 | tags: Bumblebee, UAC-0082, CERT-UA#4435, KNOTWEED, Comsvcs, cir_ttps, ContentlistEndpoint
93 | license: DRL 1.1
94 | version: 1
95 | uuid: 151fbb45-0048-497a-95ec-2fa733bb15dc
96 | correlation:
97 | timeframe: 1m
98 | functions: count() > 3
99 | #response: [] # extended format
100 | ```
101 |
102 | ### Campos
103 | La [especificación Roota](https://github.com/UncoderIO/Roota/blob/main/Roota_Specification.md) incluye la lista de todos los campos que se pueden utilizar para escribir una regla Roota.
104 |
105 | ## :cookie: Cómo contribuir
106 | Tu contribución es realmente importante para hacer evolucionar el proyecto y ayudarnos a hacer que el lenguaje Roota sea aún más útil para la comunidad global de ciber defensores.
107 |
108 | Para enviar tu pull request con tus ideas o sugerencias de cambios, sigue los siguientes pasos:
109 |
110 | 1. Realiza un Fork del repositorio [repositorio Roota](https://github.com/UncoderIO/Roota/tree/main) y clona la misma en tu entorno local.
111 | 2. Crea un nuevo Feature Branch en el que realizarán los cambios.
112 | 3. Luego, confirma tus cambios en el recién creado Feature Branch.
113 | 4. Haz un push de los cambios a tu Fork.
114 | 5. Crea un nuevo Pull Request
115 | a. Al hacer clic en el botón New Pull Request.
116 | b. Selecciona tu Fork junto con tu Feature Branch.
117 | c. Proporciona un título y una descripción de tus cambios. Asegúrate de que sean claros e informativos.
118 | d. Finalmente, envía tu Pull Request y espera su aprobación.
119 |
120 | Gracias por tu contribución al proyecto Roota!
121 |
122 | ## :smile_cat: Mantenedores
123 | - [Roman Ranskyi](https://www.linkedin.com/in/roman-966b91b5/)
124 | - [Alex Bredikhin](https://www.linkedin.com/in/bredikhin/)
125 | - [Adam Swan](https://github.com/acalarch/)
126 | - [Ruslan Mikhalov](https://www.linkedin.com/in/rmikhalov/)
127 | - [Andrii Bezverkhyi](https://www.linkedin.com/in/andriimb/)
128 |
129 | ## :clap: Créditos
130 | Estamos sinceramente agradecidos con los profesionales de la seguridad que aportan su tiempo, experiencia y creatividad para hacer evolucionar el proyecto de código abierto Roota.
131 |
132 | ## :globe_with_meridians: Licencias
133 | El contenido de este repositorio, junto con las especificaciones de Roota, son de dominio público.
134 |
135 | ## :book: Recursos y link útiles
136 | - [Roota.IO](https://roota.io/) la página web principal del proyecto Roota
137 | - [Uncoder.IO](https://github.com/UncoderIO/UncoderIO/) Código fuente para el motor de traducción Uncoder IO que admite el empaquetado Roota, Sigma e IOC en formatos de consulta específicos SIEM, EDR y Data Lake
138 | - [Uncoder.IO](https://uncoder.io/) versión alojada privada de Uncoder.IO desde 2018, operada por SOC Prime, no te rastrea, no ve tu código
139 | - [Canal de Discord Roota](https://tdm.socprime.com/zeptolink/5IAokHui2iWUHaB8/) Canal de Discord para establecer contactos con entusiastas de Roota
140 |
--------------------------------------------------------------------------------
/README_Ukrainian.md:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | # Мова з відкритим кодом для колективного кіберзахисту
6 |
7 | :earth_americas: [English](README.md) | [Українська](README_Ukrainian.md) | [Español](README_Spanish.md)
8 |
9 | Roota – це вільно розповсюджувана мова для колективного кіберзахисту, створена, щоб спростити виявлення загроз, реагування на інциденти та атрибуцію кібератак. Вона виступає обгорткою для мов запитів, що використовуються в різноманітних системах SIEM, EDR, XDR та Data Lake. Вивчивши основи Roota, ви зможете вносити свій вклад у колективний кіберзахист. Володіючи мовою одного SIEM, за допомогою Roota й Uncoder IO ви зможете говорити мовами всіх інших.
10 |
11 | **Зміст:**
12 |
13 | - [Ключові переваги Roota](#smiling_face_with_three_hearts-ключові-переваги-roota)
14 | - [Як писати правила на Roota](#mage-як-писати-правила-на-roota)
15 | - [Як долучитися до проєкту](#cookie-як-долучитися-до-проєкту)
16 | - [Хто веде проєкт](#smile_cat-хто-веде-проєкт)
17 | - [Учасники](#clap-учасники)
18 | - [Ліцензії](#globe_with_meridians-ліцензії)
19 | - [Ресурси та корисні посилання](#book-ресурси-та-корисні-посилання)
20 |
21 | ## :smiling_face_with_three_hearts: Ключові переваги Roota
22 | Мова Roota створена з метою пришвидшити глобальну співпрацю в галузі кібербезпеки. Використовуючи Roota як обгортку, спеціалісти з кібербезпеки можуть взяти нативне правило або запит і доповнити його метаданими, щоб потім автоматично перекласти код на мови інших систем SIEM, EDR, XDR та Data Lake. На створення мови Roota надихнув успіх правил на Yara та Sigma, але ця мова має ширшу сферу застосування й більшу потенційну аудиторію, для якої вона може бути корисною.
23 |
24 | - Для запису Roota використовується **YAML**, поширений формат, який легко читається людиною та зручний у використанні.
25 | - Код для детектування загроз **можна писати будь-якою мовою** – Uncoder IO згенерує автоматичний переклад.
26 | - **Підтримка кореляції.** Roota підтримує поширені функції кореляції, завдяки яким логіку детектування стає важче обійти, вона потребує менше обчислювальних ресурсів, а також не втрачає актуальності з часом.
27 | - **Джерела логів** можуть визначатися самим запитом нативною мовою або зазначатися окремо в полі `logsource`.
28 | - Синтаксис Roota повністю підтримує **OCSF** та **Sigma** як таксономію, завдяки чому цю мову швидко вчити, легко читати і просто використовувати для обміну знаннями, в якому б форматі інженер не писав алгоритми детектування.
29 | - **Хронологія дій зловмисників.** Зловмисники змінюються, але їхні методи часто залишаються такими, як і раніше. Roota підтримує додатковий рівень інформації про загрозу, що допомагає командам реагування на комп'ютерні надзвичайні події (CERT), національним центрам з кібербезпеки (NCSC), центрам обміну й аналізу інформації (ISAC), постачальникам послуг з виявлення та реагування на загрози (MDR) та різноманітним агенціям із кіберзахисту швидше й точніше координувати захисні заходи.
30 | - **Співставлення з тактиками, техніками та процедурами (TTP).** Прив'язуйте алгоритми детектування до відповідних тактик, технік та процедур по системі MITRE ATT&CK®. Використовуйте кастомні теги, щоб робити унікальні прив'язки.
31 | - **Реагування як код.** Коли спільнота виросте й з'явиться галузеве визнання, наступним кроком після алгоритмів детектування буде обмін кодом для автоматизації реагування на кіберзагрози.
32 |
33 | ## :mage: Як писати правила на Roota
34 | Писати правила на мові Roota можна в будь-якому редакторі коду, який підтримує YAML.
35 | Для перекладу правил Roota на інші мови, використовуйте Uncoder IO. Ви можете встановити його локально звідси: https://github.com/UncoderIO/UncoderIO або скористатися онлайн-версією, яку компанія SOC Prime пропонує з 2018 року, за адресою https://uncoder.io
36 |
37 | ### Шаблони правил Roota
38 | Для написання правила на Roota можна взяти мінімальний, повний або розширений шаблон.
39 |
40 | **Мінімальний** шаблон призначений для написання простих правил, де вказуються лише назва, опис, автор, рівень критичності, дата, теги MITRE ATT&CK, запит для детектування нативною мовою, посилання та ліцензія.
41 |
42 | **Повний** шаблон додатково містить поля для того, щоб вказати контекст, необхідний для аналізу сповіщення про загрозу, та хронологію кампанії кіберзловмисників, описати джерела логів за допомогою такономії Sigma або OCSF, а також додати кросплатформенні кореліції.
43 |
44 | **Розширений** шаблон наразі зарезервовано для додавання "реагування як коду" та експериментальних можливостей.
45 |
46 | #### Мінімальний шаблон правила Roota:
47 | ```
48 | name: Possible Credential Dumping Using Comsvcs.dll (via cmdline)
49 | details: Adversaries can use built-in library comsvcs.dll to dump credentials on a compromised host.
50 | author: SOC Prime Team
51 | severity: high
52 | date: 2020-05-24
53 | mitre-attack:
54 | - t1003.001
55 | - t1136.003
56 | detection:
57 | language: splunk-spl-query # elastic-lucene-query, logscale-lql-query, mde-kql-query
58 | body: index=* ((((process="*comsvcs*") AND (process="*MiniDump*")) OR ((process="*comsvcs*") AND (process="*#24*"))) OR ((process="*comsvcs*") AND (process="*full*")))
59 | references:
60 | - https://badoption.eu/blog/2023/06/21/dumpit.html
61 | license: DRL 1.1
62 | ```
63 |
64 | #### Повний шаблон правила Roota:
65 | ```
66 | name: Possible Credential Dumping Using Comsvcs.dll (via cmdline)
67 | details: Adversaries can use built-in library comsvcs.dll to dump credentials on a compromised host.
68 | author: SOC Prime Team
69 | severity: high
70 | type: query
71 | class: behaviour
72 | date: 2020-05-24
73 | mitre-attack:
74 | - t1003.001
75 | - t1136.003
76 | detection:
77 | language: splunk-spl-query # elastic-lucene-query, logscale-lql-query, mde-kql-query
78 | body: index=* ((((process="*comsvcs*") AND (process="*MiniDump*")) OR ((process="*comsvcs*") AND (process="*#24*"))) OR ((process="*comsvcs*") AND (process="*full*")))
79 | logsource:
80 | product: Windows # Sigma or OCSF products
81 | log_name: Security # OCSF log names
82 | class_name: Process Activity # OCSF classes
83 | #category: # Sigma categories
84 | #service: # Sigma services
85 | audit:
86 | source: Windows Security Event Log
87 | enable: Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking -> Audit Process
88 | timeline:
89 | 2022-04-01 - 2022-08-08: Bumblebee
90 | 2022-07-27: KNOTWEED
91 | 2022-12-04: UAC-0082, CERT-UA#4435
92 | references:
93 | - https://badoption.eu/blog/2023/06/21/dumpit.html
94 | tags: Bumblebee, UAC-0082, CERT-UA#4435, KNOTWEED, Comsvcs, cir_ttps, ContentlistEndpoint
95 | license: DRL 1.1
96 | version: 1
97 | uuid: 151fbb45-0048-497a-95ec-2fa733bb15dc
98 | correlation:
99 | timeframe: 1m
100 | functions: count() > 3
101 | #response: [] # extended format
102 | ```
103 |
104 | ### Поля
105 | [Специфікація мови Roota](https://github.com/UncoderIO/Roota/blob/main/Roota_Specification_Ukrainian.md) описує всі поля, які можна використовувати в цій мові.
106 |
107 | ## :cookie: Як долучитися до проєкту
108 | Ми вдячні кожному, хто допомагає розвивати цей проєкт і робити мову Roota більш корисною для глобальної спільноти спеціалістів з кіберзахисту.
109 |
110 | Щоб зробити пул-реквест з ідеями або пропозиціями, виконайте такі дії:
111 |
112 | 1. Зробіть форк [репозиторія Roota](https://github.com/UncoderIO/Roota/tree/main) і створіть його локальну копію.
113 | 2. Створіть гілку, в якій ви вноситимете зміни.
114 | 3. Зробіть коміт зі внесеними змінами в створену вами гілку.
115 | 4. Відправте зміни у свій форк.
116 | 5. Створіть пул-реквест.
117 | a. Натисніть кнопку New Pull Request (Новий пул-реквест).
118 | b. Виберіть свій форк з гілкою, яка містить зміни.
119 | c. Зазначте назву та опис змін. Вони мать бути чіткими й інформативними.
120 | d. Відправте пул-реквест і очікуйте на його схвалення.
121 |
122 | Дякуємо за ваш внесок в проєкт Roota!
123 |
124 | ## :smile_cat: Хто веде проєкт
125 | - [Roman Ranskyi](https://www.linkedin.com/in/roman-966b91b5/)
126 | - [Alex Bredikhin](https://www.linkedin.com/in/bredikhin/)
127 | - [Adam Swan](https://github.com/acalarch/)
128 | - [Ruslan Mikhalov](https://www.linkedin.com/in/rmikhalov/)
129 | - [Andrii Bezverkhyi](https://www.linkedin.com/in/andriimb/)
130 |
131 | ## :clap: Учасники
132 | Ми щиро вдячні всім спеціалістам з кіберзахисту, які застосовують свої знання, проявляють кмітливість і докладають час для розвитку відкритого проєкту Roota.
133 |
134 | ## :globe_with_meridians: Ліцензії
135 | Вміст цього репозиторія, зокрема специфікація мови Roota, є суспільним надбанням (public domain).
136 |
137 | ## :book: Ресурси та корисні посилання
138 | - [Roota.IO](https://roota.io/) основна вебсторінка проєкту Roota
139 | - [Uncoder.IO](https://github.com/UncoderIO/UncoderIO/) вихідний код рушія перекладів Uncoder IO, який підтримує автоматичний переклад Roota й Sigma, а також генерацію запитів з індикаторами компрометації (IOC) на мовах різних SIEM, EDR та Data Lake
140 | - [Uncoder.IO](https://uncoder.io/) онлайн-версія Uncoder IO, яка з 2018 року підтримується компанією SOC Prime і надає повну приватність: ніхто не відстежує ні ваші дії, ні ваш код
141 | - [Канал Roota в Discord](https://tdm.socprime.com/zeptolink/5IAokHui2iWUHaB8/) для спілкування з іншими, кого цікавить і надихає Roota
142 |
--------------------------------------------------------------------------------
/Roota_Specification.md:
--------------------------------------------------------------------------------
1 | # Roota Specification
2 | :earth_americas: [Українська](Roota_Specification_Ukrainian.md)
3 | * Version 1.0.0
4 | * Release date 2023-10-06
5 |
6 | # Contents
7 | - [Format](#format)
8 | - [Structure](#structure)
9 | - [Fields](#fields)
10 | - [name](#name)
11 | - [details](#details)
12 | - [author](#author)
13 | - [severity](#severity)
14 | - [type](#type)
15 | - [class](#class)
16 | - [date](#date)
17 | - [mitre-attack](#mitre-attack)
18 | - [detection](#detection)
19 | - [language](#language)
20 | - [body](#body)
21 | - [logsource](#logsource)
22 | - [product](#product)
23 | - [log_name](#log_name)
24 | - [class_name](#class_name)
25 | - [category](#category)
26 | - [service](#service)
27 | - [audit](#audit)
28 | - [source](#source)
29 | - [enable](#enable)
30 | - [timeline](#timeline)
31 | - [references](#references)
32 | - [tags](#tags)
33 | - [license](#license)
34 | - [version](#version)
35 | - [uuid](#uuid)
36 | - [correlation](#correlation)
37 | - [timeframe](#timeframe)
38 | - [functions](#functions)
39 | - [response](#response)
40 |
41 | # Format
42 | Roota is structured in the YAML format
43 |
44 | # Structure
45 | ```
46 | name: Rule Name
47 | details: Rule description
48 | author: Rule author
49 | severity: high
50 | type: query
51 | class: behaviour
52 | date: 2020-05-24
53 | mitre-attack:
54 | - t1003.001
55 | - t1136.003
56 | detection:
57 | language: splunk-spl-query # elastic-lucene-query, logscale-lql-query, mde-kql-query
58 | body: index=* ((((process="*comsvcs*") AND (process="*MiniDump*")) OR ((process="*comsvcs*") AND (process="*#24*"))) OR ((process="*comsvcs*") AND (process="*full*")))
59 | logsource:
60 | product: Windows # Sigma or OCSF products
61 | log_name: Security # OCSF log names
62 | class_name: Process Activity # OCSF classes
63 | #category: # Sigma categories
64 | #service: # Sigma services
65 | audit:
66 | source: Windows Security Event Log
67 | enable: Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking -> Audit Process
68 | timeline: # for Actors and campaigns only
69 | 2022-04-01 - 2022-08-08: Bumblebee
70 | 2022-07-27: KNOTWEED
71 | 2022-12-04: UAC-0082, CERT-UA#4435
72 | references:
73 | - https://badoption.eu/blog/2023/06/21/dumpit.html
74 | tags: Bumblebee, UAC-0082, CERT-UA#4435, KNOTWEED, Comsvcs, cir_ttps, ContentlistEndpoint
75 | license: DRL 1.1
76 | version: 1
77 | uuid: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
78 | #correlation: [] # extended format
79 | #response: [] # extended format
80 | ```
81 |
82 | # Fields
83 |
84 | ## name
85 | Format: `text (max 1024 characters)`
86 |
87 | Required: *mandatory*
88 |
89 | Description: The name of the rule which reflects the goal and the method used in the rule.
90 |
91 | Example: `name: Possible Credential Dumping using comsvcs.dll`
92 |
93 |
94 | ## details
95 | Format: `text (max 8192 characters)`
96 |
97 | Required: *optional*
98 |
99 | Description: A short description of the rule that should give more context to the detection and threats that can be detected with this rule.
100 |
101 | Example: `details: Adversaries can use the built-in library comsvcs.dll to dump credentials on a compromised host.`
102 |
103 |
104 | ## author
105 | Format: `text (max 256 characters)`
106 |
107 | Required: *optional*
108 |
109 | Description: The name of the creator. It is recommended to use the same name for all your rules. Comma-separated value.
110 |
111 | Example: `author: SOC Prime Team`
112 |
113 |
114 | ## severity
115 |
116 | Format: `text (max 16 characters)`
117 |
118 | Required: *optional*
119 |
120 | Description: The severity of the rule which indicates the level of the rule's importance and investigation priority.
121 |
122 | Possible Values:
123 | - `critical` - When critical severity rules are triggered, immediate action is required. Critical rules have a very low probability of false positives, or are highly sensitive actions that must always be deconflicted.
124 | - `high` - When high severity rules are triggered, an investigation/case should be created and completed with a high priority. Low probability of false positives after minimal tuning.
125 | - `medium` - Medium severity rules will likely require tuning in an average environment. After tuning, when medium security rules are triggered, a case should be generated with medium priority.
126 | - `low` - Low severity rules should be used as part of correlations, or to support triage and enrich the analysis environment. Some of these rules may be used as case generators after a significant amount of tuning.
127 |
128 | Example: `severity: medium`
129 |
130 |
131 | ## type
132 | Format: `text (max 16 characters)`
133 |
134 | Required: *optional*
135 |
136 | Description: The type of the rule that indicates whether the rule is intended as a threat hunting 'query' (may generate false positives) or a real-time detection 'alert' (rarely generates false positives).
137 | An alert can be defined as a rule that in the majority of environments will cause a low false positive or true positive - benign rate. For instance, if a rule requires for someone to add domain controllers to filter out benign events, it would NOT be considered an alert.
138 | A query can be defined as any rule that can be expected to require tuning in most environments.
139 |
140 | Possible Values:
141 | - `query`
142 | - `alert`
143 |
144 | Example: `type: query`
145 |
146 | ## class
147 |
148 | Format: `text (max 128 characters)`
149 |
150 | Required: *optional*
151 |
152 | Possible Values:
153 | - `campaign`
154 | - `behavioral`
155 | - `tool`
156 | - `generic`
157 | - `exploit`
158 | - `ioc`
159 |
160 | Description:
161 | - `Exploit Rules`
162 | These are rules meant to identify the exploitation or probing of a vulnerability (e.g. CVE, General SQL-I / XSS Rules). Many of these rules would qualify as "alerts". An example would be a rule built for Log4j detection. These rules are useful indefinitely.
163 |
164 | - `Behavioral Rules`
165 | These rules are meant to identify behaviors that may match an adversary's behavior based on known reporting. Many of these rules would qualify as "queries". An example of a behavioral rule would be a rule that identifies a remote login of a local administrator account. These rules will NOT include information specific to a campaign. These rules are useful retroactively, and on average have a 12+ month expectancy of usefulness.
166 |
167 | - `Campaign Rules`
168 | These rules would be tied to a specific campaign. Many of these rules would qualify as "alerts". For instance, a rule that identifies a campaign by the name of the service that is installed on a Windows host. These rules should help customers identify if they have been the target of a specific campaign. These rules are useful retroactively, and have on average a 3-12 month expectancy of usefulness.
169 |
170 | - `Tool Rules`
171 | These rules identify the usage of a specific tool (offensive, or living off the land). For instance, a rule meant to identify psexec specifically would be a "tool" rule. A rule meant to identify psexec and any similar tool, without explicitly identifying attributes that are unique to those tools would be considered a behavioral rule.
172 |
173 | - `IOC Rule`
174 | Rules that are created for urgent adversary activity that has little to no other detection measures (e.g. wannacry, notpetya, mass & urgent exploitation). Mostly for IOCs like domains, IPs, hashes, URLs.
175 |
176 | - `Generic Rules`
177 | These rules are meant to identify potential weaknesses in an environment. For instance, a rule that identifies weak encryption in Kerberos (RC4_HMAC_MD5). Rules that provide only information that has a very small chance of being a true-positive but is good for customers to keep an eye on. For instance, the root user account of AWS being utilized.
178 |
179 | Example: `class: campaign`
180 |
181 |
182 | ## date
183 |
184 | Format: `YYYY-MM-DD`
185 |
186 | Required: *optional*
187 |
188 | Description: The date of rule creation.
189 |
190 | Example: `date: 2022-10-31`
191 |
192 |
193 | ## mitre-attack
194 |
195 | Format: `text (max 1024 characters)`
196 |
197 | Required: *optional*
198 |
199 | Description: List of MITRE ATT&CK (r) Techniques, Subtechniques, Groups, Software IDs. All IDs should be in lowercase.
200 |
201 | Example:
202 | ```
203 | mitre-attack:
204 | - t1136.003
205 | - t1087.004
206 | - t1069
207 | ```
208 |
209 |
210 | ## detection
211 |
212 | Required: *mandatory*
213 |
214 | Description: This section contains the fields that specify the detection logic and the language used to express it. See the specifications of the fields below.
215 |
216 |
217 | ### language
218 |
219 | Format: `text (max 128 characters)`
220 |
221 | Required: *mandatory*
222 |
223 | Description: The field should specify the name of the SIEM/EDR/XDR in the appropriate format. See the list of supported platforms in the Possible Values section.
224 |
225 | Possible Values:
226 |
227 | - `sentinel-kql-query` for Microsoft Sentinel Query
228 | - `splunk-spl-query` for Splunk Query
229 | - `crowdstrike-spl-query` for CrowdStrike Query
230 | - `elastic-lucene-query` for Elasticsearch Query
231 | - `opensearch-lucene-query` for AWS OpenSearch Query
232 | - `logscale-lql-query` for Falcon LogScale Query
233 | - `mde-kql-query` for Microsoft Defender for Endpoint Query
234 | - `qradar-aql-query` for IBM QRadar Query
235 | - `athena-sql-query` for AWS Athena Query (Security Lake)
236 | - `chronicle-yaral-query` for Chronicle Security Query
237 | - `fortisiem-rule` for FortiSIEM Rule
238 | - `axon-ads-rule` for LogRhythm Axon Rule
239 | - `axon-ads-query` for LogRhythm Axon Query
240 |
241 | Example: `language: splunk-spl-query`
242 |
243 |
244 | ### body
245 |
246 | Format: `text (max 8192 characters)`
247 |
248 | Required: *mandatory*
249 |
250 | Description: This section should contain the rule's logic. It should be a SIEM/EDR/XDR query in the native format. The query should be in one line. In case you have a multiline query, you should join lines before adding it to the Roota rule.
251 |
252 | Example: `index=* source="WinEventLog:*" AND (Image="*.exe" OR Image="*.com")`
253 |
254 |
255 | ## logsource
256 |
257 | Required: *optional*
258 |
259 | Description: This section describes log sources required for the rule. It is optional but could be necessary in some cases when the detection logic doesn’t describe which log sources are required.
260 |
261 |
262 | ### product
263 |
264 | Format: `text (max 128 characters)`
265 |
266 | Required: *optional*
267 |
268 | Description: The product that reported the event.
269 |
270 | Example: `product: windows`
271 |
272 |
273 | ### log_name
274 |
275 | Format: `text (max 128 characters)`
276 |
277 | Required: *optional*
278 |
279 | Description: The event log name. For example, syslog file name or Windows logging subsystem: Security.
280 |
281 | Example: `log_name: Security`
282 |
283 |
284 | ### class_name
285 |
286 | Format: `text (max 128 characters)`
287 |
288 | Required: *optional*
289 |
290 | Description: The OCSF event classes. Details: [https://schema.ocsf.io/1.0.0/classes](https://schema.ocsf.io/1.0.0/classes)
291 |
292 | Example: `class_name: Process Activity`
293 |
294 | ### category
295 |
296 | Format: `text (max 128 characters)`
297 |
298 | Required: *optional*
299 |
300 | Description: A category is used when disparate data sources provide the same type of event logging. For instance, Microsoft Windows 4688 & Sysmon Event ID 1 both provide process creation logs and share many of the same fields. Therefore, we can write and consume rules written generally for "process_creation" instead of rules written specifically for exact data sources. The same goes for most firewalls, proxies, etc.
301 |
302 | Example: `category: process_creation`
303 |
304 |
305 | ### service
306 |
307 | Format: `text (max 128 characters)`
308 |
309 | Required: *optional*
310 |
311 | Description: A service is used when a distinct data source exists for the relevant event logs. As an example, Amazon Cloudtrail eventing is specific to AWS. You generally cannot use a rule made for one service against another data source.
312 |
313 | Example: `service: apache`
314 |
315 |
316 | ## audit
317 |
318 | Required: *optional*
319 |
320 | Description: This section describes in detail what logging service should be enabled to have the logs required for the rule.
321 |
322 |
323 | ### source
324 |
325 | Format: `text (max 128 characters)`
326 |
327 | Required: *optional*
328 |
329 | Description: The full name of the logging provider or logging service that logged the event. For example, Microsoft-Windows-Security-Auditing.
330 |
331 | Example: `source: Microsoft-Windows-PowerShell/Operational`
332 |
333 |
334 | ### enable
335 |
336 | Format: `text (max 2048 characters)`
337 |
338 | Required: *optional*
339 |
340 | Description: This section provides detailed instructions on how to enable the required log audit in the source system.
341 |
342 | Example: `enable: 'Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking -> Audit Process Creation'`
343 |
344 |
345 | ## timeline
346 |
347 | Format:
348 |
349 | ```
350 | YYYY-MM-DD - YYYY-MM-DD: Actor1, Actor2, TLP:CLEAR
351 | YYYY-MM-DD: Actor1, Actor3, TLP:GREEN
352 | ```
353 |
354 | Required: *optional*
355 |
356 | Description: It has to include the name of the actor, TLP:key, and dates when the behavior described in the Roota rule was used by the Actor. On the contrary to indicators of compromise, which are Actor specific, behaviors are constant while Actor is a variable. If the TLP:key is not defined, it is perceived as TLP:CLEAR. The period can be defined with two dates (first and last seen) or with one date.
357 |
358 | Example:
359 | ```
360 | timeline:
361 | 2023-01-01 - 2023-03-06: Ducktail, MerlinAgent
362 | 2023-02-04: Lazarus
363 | ```
364 |
365 |
366 | ## references
367 |
368 | Format: `text (max 2048 characters)`
369 |
370 | Required: *optional*
371 |
372 | Description: Links to articles in the media, posts, or other sources that describe the threat, exploit, behavior, etc. that the rule detects.
373 |
374 | Example:
375 | ```
376 | references:
377 | - https://badoption.eu/blog/2023/06/21/dumpit.html
378 | ```
379 |
380 |
381 | ## tags
382 |
383 | Format: `text (max 1024 characters)`
384 |
385 | Required: *optional*
386 |
387 | Description: Comma-separated short words that can label Roota rule for keyword search.
388 |
389 | Example: `tags: MerlinAgent, UAC-0173, UAC-0006, Ducktail, CERT-UA#4753`
390 |
391 |
392 | ## license
393 | Format: `text (max 256 characters)`
394 |
395 | Required: *optional*
396 |
397 | Description: The license of the rule. It can also contain a link to the license file.
398 |
399 | Example: `license: DRL 1.1`
400 |
401 |
402 | ## version
403 | Format: `X.X (major.minor version number)`
404 |
405 | Required: *optional*
406 |
407 | Description: The unique version number of the rule.
408 |
409 | Example: `version: 0.1`
410 |
411 |
412 | ## uuid
413 | Format: `text (32 characters)`
414 |
415 | Required: *optional*
416 |
417 | Description: Unique ID of the rule. UUID version 4 is recommended for use.
418 |
419 | Example: `uuid: 009a001b-1623-4320-8369-95bf0d651e8e`
420 |
421 | ## correlation
422 | Required: *optional*
423 |
424 | Description: The correlation section is responsible for the correlation of query results.
425 |
426 | Example:
427 | ```
428 | correlation:
429 | timeframe: 1m
430 | functions: count() > 10
431 | ```
432 |
433 | ### timeframe
434 | Format: `text (8 characters)`
435 |
436 | Required: *optional*
437 |
438 | Description: A time frame for the functions, which is defined as a span of seconds (s), minutes (m), hours (h), days (d), and weeks(w).
439 |
440 | Example: `timeframe: 1m`
441 |
442 | ### functions
443 | Format: `text (128 characters)`
444 |
445 | Required: *optional*
446 |
447 | Description: Functions can be used for correlation of query results, for example, to trigger only in case certain thresholds of certain fields are met. This is still under development. First functions to be released:
448 |
449 | - `count()` - count of field values
450 | - `by` - group by field
451 | - `dcount` - unique field values
452 |
453 | Example: `functions: count() > 10`
454 |
455 |
456 | ## response
457 | Reserved for future
458 |
--------------------------------------------------------------------------------
/Roota_Specification_Ukrainian.md:
--------------------------------------------------------------------------------
1 | # Специфікація Roota
2 | :earth_americas: [English](Roota_Specification.md)
3 | * Версія 1.0.0
4 | * Дата релізу 2023-10-06
5 | # Зміст
6 | - [Формат](#формат)
7 | - [Структура](#структура)
8 | - [Поля](#поля)
9 | - [name](#name)
10 | - [details](#details)
11 | - [author](#author)
12 | - [severity](#severity)
13 | - [type](#type)
14 | - [class](#class)
15 | - [date](#date)
16 | - [mitre-attack](#mitre-attack)
17 | - [detection](#detection)
18 | - [language](#language)
19 | - [body](#body)
20 | - [logsource](#logsource)
21 | - [product](#product)
22 | - [log_name](#log_name)
23 | - [class_name](#class_name)
24 | - [category](#category)
25 | - [service](#service)
26 | - [audit](#audit)
27 | - [source](#source)
28 | - [enable](#enable)
29 | - [timeline](#timeline)
30 | - [references](#references)
31 | - [tags](#tags)
32 | - [license](#license)
33 | - [version](#version)
34 | - [uuid](#uuid)
35 | - [correlation](#correlation)
36 | - [timeframe](#timeframe)
37 | - [functions](#functions)
38 | - [response](#response)
39 |
40 | # Формат
41 | У Roota використовується формат YAML.
42 |
43 | # Структура
44 | ```
45 | name: Rule Name
46 | details: Rule description
47 | author: Rule author
48 | severity: high
49 | type: query
50 | class: behaviour
51 | date: 2020-05-24
52 | mitre-attack:
53 | - t1003.001
54 | - t1136.003
55 | detection:
56 | language: splunk-spl-query # elastic-lucene-query, logscale-lql-query, mde-kql-query
57 | body: index=* ((((process="*comsvcs*") AND (process="*MiniDump*")) OR ((process="*comsvcs*") AND (process="*#24*"))) OR ((process="*comsvcs*") AND (process="*full*")))
58 | logsource:
59 | product: Windows # Sigma or OCSF products
60 | log_name: Security # OCSF log names
61 | class_name: Process Activity # OCSF classes
62 | #category: # Sigma categories
63 | #service: # Sigma services
64 | audit:
65 | source: Windows Security Event Log
66 | enable: Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking -> Audit Process
67 | timeline: # for Actors and campaigns only
68 | 2022-04-01 - 2022-08-08: Bumblebee
69 | 2022-07-27: KNOTWEED
70 | 2022-12-04: UAC-0082, CERT-UA#4435
71 | references:
72 | - https://badoption.eu/blog/2023/06/21/dumpit.html
73 | tags: Bumblebee, UAC-0082, CERT-UA#4435, KNOTWEED, Comsvcs, cir_ttps, ContentlistEndpoint
74 | license: DRL 1.1
75 | version: 1
76 | uuid: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
77 | #correlation: [] # extended format
78 | #response: [] # extended format
79 | ```
80 |
81 | # Поля
82 |
83 | ## name
84 | Формат: `текст (макс. 1024 символи)`
85 |
86 | Чи є обов'язковим: *обов'язкове*
87 |
88 | Опис: Назва правила, яка показує, що і яким чином воно виявляє.
89 |
90 | Приклад: `name: Possible Credential Dumping using comsvcs.dll`
91 |
92 |
93 | ## details
94 | Формат: `текст (макс. 8192 символи)`
95 |
96 | Чи є обов'язковим: *не обов'язкове*
97 |
98 | Опис: Короткий опис правила, який містить додатковий контекст щодо роботи алгоритму та загроз, які це правило може виявити.
99 |
100 | Приклад: `details: Adversaries can use the built-in library comsvcs.dll to dump credentials on a compromised host.`
101 |
102 |
103 | ## author
104 | Формат: `текст (макс. 256 символів)`
105 |
106 | Чи є обов'язковим: *не обов'язкове*
107 |
108 | Опис: Ім'я того, хто створив правило. Авторам рекомендується використовувати одне й те саме ім'я для всіх своїх правил. Якщо значень декілька, вони подаються через кому.
109 |
110 | Приклад: `author: SOC Prime Team`
111 |
112 |
113 | ## severity
114 |
115 | Формат: `текст (макс. 16 символів)`
116 |
117 | Чи є обов'язковим: *не обов'язкове*
118 |
119 | Опис: Рівень критичності правила, який показує його значимість і пріоритет розслідування у разі його спрацювання.
120 |
121 | Можливі значення:
122 | - `critical` (критичний). Коли спрацьовують правила з рівнем критичності 'critical', необхідно терміново вжити дій. У таких правил дуже низька ймовірність хибнопозитивного спрацьовування, або ж вони пов'язані з надважливими діями, яким завжди треба приділяти першочергову увагу для запобігання негативним наслідкам.
123 | - `high` (високий). Коли спрацьовують правила з високим рівнем критичності, необхідно відкрити й провести розслідування із високим пріоритетом. Такі правила мають низьку ймовірність хибнопозитивного спрацьовування після мінімального додаткового налаштування.
124 | - `medium` (середній). Правила з середнім рівнем критичності зазвичай потребують додаткового налаштування. Якщо після налаштування таке правило спрацьовує, потрібно створювати тікет із середнім пріоритетом.
125 | - `low` (низький). Правила з низьким рівнем критичності слід використовувати в кореляціях або для цілей розслідування й отримання додаткових даних для аналізу. Деякі з таких правил можна використовувати для створення тікетів після суттєвого додаткового налаштування.
126 |
127 | Приклад: `severity: medium`
128 |
129 |
130 | ## type
131 | Формат: `текст (макс. 16 символів)`
132 |
133 | Чи є обов'язковим: *не обов'язкове*
134 |
135 | Опис: Тип правила, який показує його призначення: `query` – запит для трет-хантінгу (може давати хибнопозитивні результати) або `alert` – правило для генерації сповіщень в реальному часі (рідко дає хибнопозитивні результати).
136 | Тип `alert` застосовується до правил, які в більшості середовищ матимуть низький рівень хибнопозитивних спрацьовувань або істинопозитивних спрацьовувань, що викликані нешкідливою активністю. Наприклад, якщо для правила потрібно, щоб хтось додав контроллери доменів для відфільтровування нешкідливих подій, його НЕ можна кваліфікувати як `alert`.
137 | Тип `query` застосовується до будь-якого правила, яке з високою ймовірністю доведеться додатково налаштовувати в більшості середовищ.
138 |
139 | Можливі значення:
140 | - `query`
141 | - `alert`
142 |
143 | Приклад: `type: query`
144 |
145 | ## class
146 |
147 | Формат: `текст (макс. 128 символів)`
148 |
149 | Чи є обов'язковим: *не обов'язкове*
150 |
151 | Можливі значення:
152 | - `campaign`
153 | - `behavioral`
154 | - `tool`
155 | - `generic`
156 | - `exploit`
157 | - `ioc`
158 |
159 | Опис:
160 | - `exploit` – правила для виявлення експлойтів
161 | Ці правила покликані виявляти експлуатацію вразливості або спробу її знайти (наприклад, CVE, загальні правила для виявлення SQL-I / XSS). Багато таких правил можна кваліфікувати як 'alert'. Як приклад, можна навести правило для детектування Log4j. Ці правила залишаються корисними необмежений час.
162 |
163 | - `behavioral` – правила для виявлення поведінки
164 | Ці правила призначені для виявлення патернів поведінки, що збігаються з поведінкою зловмисників, відомою по звітам про минулі інциденти. Багато таких правил можна кваліфікувати як 'query`. Прикладом правила для виявлення поведінки може бути правило, яке виявляє віддалений вхід у систему з локального акаунту адмністратора. Такі правила НЕ включають інформацію, специфічну для певної кампанії. Вони мають користь при ретроспективному застосуванні й у середньому залишаються корисними не менше 12 мсяців.
165 |
166 | - `campaign` – правила для виявлення кампаній
167 | Ці правила прив'язані до конкретної кампанії. Багато таких правил можна кваліфікувати як 'alert'. Як приклад можна навести правило, що виявляє кампанію за назвою сервісу, встановленого на хості Windows. Ці правила мають допомагати клієнтам визначити, чи є вони ціллю певної кампанії. Вони мають користь при ретроспективному застосуванні й у середньому залишаються корисними 3–12 місяців.
168 |
169 | - `tool` – правила для виявлення інструментів
170 | Ці правила виявляють використання конкретного інструмента (призначеного для кібератак або легітимного, який використовується у злочинних цілях). Як приклад можна навести правило, яке виявляє psexec. Правило, покликане виявляти psexec і будь-які подібні інструменти, де напряму не визначено характеристики, унікальні для таких інструментів, кваліфікується як правило для визначення поведінки.
171 |
172 | - `ioc`– правила для визначення індикаторів компрометації
173 | Правила, створені для виявлення новітніх дій зловмисників, для детектування яких не існує або майже не існує інших засобів (наприклад, wannacry, notpetya, масова експлуатація новітніми методами). Більшою частиною для індикаторів компрометації (IOC), таких як домени, IP-адреси, хеші, URL.
174 |
175 | - `generic` – загальні правила
176 | Ці правила призначені для виявлення потенційних слабких місць у середовищі. Як приклад можна навести правило, яке виявляє слабке шифрування в Kerberos (RC4_HMAC_MD5). Ці правила дозволяють отримати інформацію, яка з дуже низькою ймовірністю буде істинопозитивним результатом, але клієнтам корисно її знати. Наприклад, використання акаунта root-юзера в AWS.
177 |
178 | Приклад: `class: campaign`
179 |
180 |
181 | ## date
182 |
183 | Format: `YYYY-MM-DD`
184 |
185 | Чи є обов'язковим: *не обов'язкове*
186 |
187 | Опис: Дата створення правила.
188 |
189 | Приклад: `date: 2022-10-31`
190 |
191 |
192 | ## mitre-attack
193 |
194 | Формат: `текст (макс. 1024 символи)`
195 |
196 | Чи є обов'язковим: *не обов'язкове*
197 |
198 | Опис: перелік ідентифікаторів технік, підтехнік, груп та програмного забезпечення за системою MITRE ATT&CK(r). Усі ідентифікатори мають бути в нижньому регістрі.
199 |
200 | Приклад:
201 | ```
202 | mitre-attack:
203 | - t1136.003
204 | - t1087.004
205 | - t1069
206 | ```
207 |
208 |
209 | ## detection
210 |
211 | Чи є обов'язковим: *обов'язкове*
212 |
213 | Опис: Ця секція містить поля, в яких задано логіку детектування і мову, якою вона написана. Див. специфікацію цих полів нижче.
214 |
215 |
216 | ### language
217 |
218 | Формат: `текст (макс. 128 символів)`
219 |
220 | Чи є обов'язковим: *обов'язкове*
221 |
222 | Опис: Це поле містить назву SIEM/EDR/XDR у відповідному форматі. Див. перелік підтримуваних платформ у розділі "Можливі значення".
223 |
224 | Можливі значення:
225 |
226 | - `sentinel-kql-query` для Microsoft Sentinel Query
227 | - `splunk-spl-query` для Splunk Query
228 | - `crowdstrike-spl-query` для CrowdStrike Query
229 | - `elastic-lucene-query` для Elasticsearch Query
230 | - `opensearch-lucene-query` для AWS OpenSearch Query
231 | - `logscale-lql-query` для Falcon LogScale Query
232 | - `mde-kql-query` для Microsoft Defender for Endpoint Query
233 | - `qradar-aql-query` для IBM QRadar Query
234 | - `athena-sql-query` для AWS Athena Query (Security Lake)
235 | - `chronicle-yaral-query` для Chronicle Security Query
236 | - `fortisiem-rule` for FortiSIEM Rule
237 | - `axon-ads-rule` for LogRhythm Axon Rule
238 | - `axon-ads-query` for LogRhythm Axon Query
239 |
240 | Приклад: `language: splunk-spl-query`
241 |
242 |
243 | ### body
244 |
245 | Формат: `текст (макс. 8192 символи)`
246 |
247 | Чи є обов'язковим: *обов'язкове*
248 |
249 | Опис: Ця секція містить логику правила. Це має бути запит у нативному форматі певної системи SIEM/EDR/XDR. Запит має складатися з одного рядка. Якщо запит складається з декількох рядків, об'єднайте їх, перш ніж додавати в правило Roota.
250 |
251 | Приклад: `index=* source="WinEventLog:*" AND (Image="*.exe" OR Image="*.com")`
252 |
253 |
254 | ## logsource
255 |
256 | Чи є обов'язковим: *не обов'язкове*
257 |
258 | Опис: Ця секція описує джерела логів, потрібні для роботи правила. Вона не обов'язкова, але може бути необхідною у випадках, коли логіка детектування не описує потрібні джерела логів.
259 |
260 |
261 | ### product
262 |
263 | Формат: `текст (макс. 128 символів)`
264 |
265 | Чи є обов'язковим: *не обов'язкове*
266 |
267 | Опис: Продукт, від якого надійшли дані про подію.
268 |
269 | Приклад: `product: windows`
270 |
271 |
272 | ### log_name
273 |
274 | Формат: `текст (макс. 128 символів)`
275 |
276 | Чи є обов'язковим: *не обов'язкове*
277 |
278 | Опис: Назва логу події. Наприклад, назва файлу syslog або підсистеми логування Windows: Security.
279 |
280 | Приклад: `log_name: Security`
281 |
282 |
283 | ### class_name
284 |
285 | Формат: `текст (макс. 128 символів)`
286 |
287 | Чи є обов'язковим: *не обов'язкове*
288 |
289 | Опис: Класи подій за OCSF. Детальний опис можна знайти тут: [https://schema.ocsf.io/1.0.0/classes](https://schema.ocsf.io/1.0.0/classes)
290 |
291 | Приклад: `class_name: Process Activity`
292 |
293 | ### category
294 |
295 | Формат: `текст (макс. 128 символів)`
296 |
297 | Чи є обов'язковим: *не обов'язкове*
298 |
299 | Опис: Категорія використовується, коли різні джерела даних забезпечують той самий тип логування подій. Наприклад, Microsoft Windows 4688 та Sysmon Event ID 1 обидва логують створення процесів і мають багато спільних полів. Тож, можна створювати й використовувати правила, написані під загальну категорію "process_creation", а не конкретне джерело даних. Це також стосується більшості фаєрволів, проксі, тощо.
300 |
301 | Приклад: `category: process_creation`
302 |
303 |
304 | ### service
305 |
306 | Формат: `текст (макс. 128 символів)`
307 |
308 | Чи є обов'язковим: *не обов'язкове*
309 |
310 | Опис: Сервіс використовується, коли для необхідних логів подій існує конкретне джерело даних. Наприклад, події Amazon Cloudtrail логуються лише в AWS. Зазвичай правило, написане під певний сервіс, не можна використати з іншим джерелом даних.
311 |
312 | Приклад: `service: apache`
313 |
314 |
315 | ## audit
316 |
317 | Чи є обов'язковим: *не обов'язкове*
318 |
319 | Опис: Ця секція містить докладний опис того, які сервіси логування необхідно ввімкнути, щоб мати логи, необхідні для даного правила.
320 |
321 |
322 | ### source
323 |
324 | Формат: `текст (макс. 128 символів)`
325 |
326 | Чи є обов'язковим: *не обов'язкове*
327 |
328 | Опис: Повна назва постачальника логів або сервісу логування, які записують подію. Наприклад, Microsoft-Windows-Security-Auditing.
329 |
330 | Приклад: `source: Microsoft-Windows-PowerShell/Operational`
331 |
332 |
333 | ### enable
334 |
335 | Формат: `текст (макс. 2048 символів)`
336 |
337 | Чи є обов'язковим: *не обов'язкове*
338 |
339 | Опис: Ця секція містить докладні вказівки, як увімкнути запис необхідних логів аудиту в системі-джерелі.
340 |
341 | Приклад: `enable: 'Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking -> Audit Process Creation'`
342 |
343 |
344 | ## timeline
345 |
346 | Формат:
347 |
348 | ```
349 | YYYY-MM-DD - YYYY-MM-DD: Актор1, Актор2, TLP:CLEAR
350 | YYYY-MM-DD: Актор1, Актор3, TLP:GREEN
351 | ```
352 |
353 | Чи є обов'язковим: *не обов'язкове*
354 |
355 | Опис: Має включати ім'я актора, маркування за протоколом TLP і дати, коли актор проявляв поведінку, описану в правилі Roota. На відміну від індикаторів компрометації, які є специфічними для актора, одні й ті самі патерни поведінки можуть застосовуватися різними акторами. Якщо маркування за протоколом TLP не задано, то вважається, що воно має значення TLP:CLEAR. Період може задаватися двома датами (перше й останнє проявлення) або однією датою.
356 |
357 | Приклад:
358 | ```
359 | timeline:
360 | 2023-01-01 - 2023-03-06: Ducktail, MerlinAgent
361 | 2023-02-04: Lazarus
362 | ```
363 |
364 |
365 | ## references
366 |
367 | Формат: `текст (макс. 2048 символів)`
368 |
369 | Чи є обов'язковим: *не обов'язкове*
370 |
371 | Опис: Посилання на статті у ЗМІ, публікації або інші джерела, які описують загрозу, експлойт, поведінку, тощо, які виявляє правило.
372 |
373 | Приклад:
374 | ```
375 | references:
376 | - https://badoption.eu/blog/2023/06/21/dumpit.html
377 | ```
378 |
379 |
380 | ## tags
381 |
382 | Формат: `текст (макс. 1024 символи)`
383 |
384 | Чи є обов'язковим: *не обов'язкове*
385 |
386 | Опис: Короткі слова, подані через кому, які позначають правило Roota для пошуку за ключовими словами.
387 |
388 | Приклад: `tags: MerlinAgent, UAC-0173, UAC-0006, Ducktail, CERT-UA#4753`
389 |
390 |
391 | ## license
392 | Формат: `текст (макс. 256 символів)`
393 |
394 | Чи є обов'язковим: *не обов'язкове*
395 |
396 | Опис: Ліцензія правила. Також може містити посилання на файл з ліцензією.
397 |
398 | Приклад: `license: DRL 1.1`
399 |
400 |
401 | ## version
402 | Формат: `X.X (суттєвий.несуттєвий номер версії)`
403 |
404 | Чи є обов'язковим: *не обов'язкове*
405 |
406 | Опис: Унікальний номер версії правила.
407 |
408 | Приклад: `version: 0.1`
409 |
410 |
411 | ## uuid
412 | Формат: `текст (32 символи)`
413 |
414 | Чи є обов'язковим: *не обов'язкове*
415 |
416 | Опис: Унікальний ідентифікатор правила. Рекомендується використовувати UUID версії 4.
417 |
418 | Приклад: `uuid: 009a001b-1623-4320-8369-95bf0d651e8e`
419 |
420 | ## correlation
421 | Чи є обов'язковим: *не обов'язкове*
422 |
423 | Опис: У цій секції виконується кореляція результатів запиту.
424 |
425 | Приклад:
426 | ```
427 | correlation:
428 | timeframe: 1m
429 | functions: count() > 10
430 | ```
431 |
432 | ### timeframe
433 | Формат: `текст (8 символів)`
434 |
435 | Чи є обов'язковим: *не обов'язкове*
436 |
437 | Опис: Період часу для функцій, який задається у секундах (s), хвилинах (m), годинах (h), днях (d) або тижнях (w).
438 |
439 | Приклад: `timeframe: 1m`
440 |
441 | ### functions
442 | Формат: `текст (128 символів)`
443 |
444 | Чи є обов'язковим: *не обов'язкове*
445 |
446 | Опис: Функції можна використовувати для кореляції результатів запиту, наприклад, щоб правило спрацьовувало, лише якщо досягаються певні граничні значення певних полів. Це поле все ще в розробці. Першими будуть реалізовані такі функції:
447 |
448 | - `count()` – кількість значень поля
449 | - `by` – групування по полю
450 | - `dcount` – унікальні значення поля
451 |
452 | Приклад: `functions: count() > 10`
453 |
454 |
455 | ## response
456 | Зарезервовано на майбутнє.
457 |
--------------------------------------------------------------------------------