The threat hunting process that currently exists can be used in parallel with another process called indicator life cycle.

Both cycles are based on the same, aiming at proactive detection of threats and behaviors in corporate networks, leaving aside the reactive approach which is increasingly being avoided.

This is because traditional incident response processes have a methodology based on working on an event that has taken place, whereas the indicator lifecycle and threat hunting process work from the perspective of working to prevent something from happening.

During this blog I will explain the indicator lifecycle and how it can be used in parallel with the threat hunting process, also presenting a case study at the end.

Indicator life cycle

Indicator life cycle is not intended to define how long an indicator is valid or not, since this depends on a large number of variables not controlled by analysts.

The objective of this cycle is to proactively use certain indicators to mature them and then automate new searches that may reveal other related indicators.

Although the concept may initially seem a bit confusing, this cycle makes a lot of sense to apply it to threat hunting activities, as it is in these activities that maximum value can be derived.

Before going into detail about the explanation of this cycle, it is important to know what kind of indicators are valid for these operations, because nowadays, the term indicator is too ambiguous, not everyone understands the same thing by indicator.

Personally, I find the three differentiated concepts presented in the Lockheed Martin Corporation paper very useful. These concepts are as follows.

• Atomic indicators: Atomic indicators are obtained based on the context of an intrusion that has taken place. The “problem” with this type of indicators is that they do not have to be exclusive activity of a specific adversary, i.e. an atomic indicator can be identified in several intrusions of different adversaries. Some examples of these indicators are IP addresses, domains, the name of a path of a domain…
• Computed indicators: The concept of a calculated indicator is quite confusing. These indicators are developed from attributes that occur in an incident. For example, a hash of a file that has been seen in an incident can be calculated, so its MD5, SHA1… are calculated indicators. Another example could be a regular expression, which we can develop to detect something specific.
• behavioral indicators: These indicators are composed of a combination of the two types described above. For example, within this category we could state the following; “Adversaries established a C&C [IP and/or C&C domain] with the machine compromised by the [MD5 Hash] malware. Communications were executed at an interval of [Time interval] between client and server. They could be identified by searching for the regular expression [Identifying regular expression] in the proxy logs.”

As you can imagine, this last type of indicator is the most valuable, as it has an associated context of what has happened and combines the atomic and calculated indicators. In addition, it is also easy to extract possible MITRE techniques and tactics to better understand what actions are being taken.

Now that we know the types of indicators that can be used in the indicator life cycle process, it is time to explain how the indicator life cycle works.

It consists of three main phases or stages, being the phases of developed, matured and used. In addition, this process is essential to involve people, processes and technology, which makes it really dynamic and useful in different operations, such as threat hunting.

Applying this model to our threat hunting activities will provide us with the following capabilities:

1. Generate internal threat intelligence
2. Implement a stable pivoting process
3. Identify new indicators from other indicators

From revealed to mature

This first phase has different sources as input. In the image above, some of the sources that could be a source of information to start the cycle are shown. For example, external (or internal) reports, intelligence sources, SIEM or any other monitoring tool, such as an IDS.

The above mentioned sources will carry with them indicators, which should be subjected to an examination, which will consist of historically searching our available internal data sources to see whether or not such an indicator was observed in the past (see my post about collection management framework). In case the result is positive, further investigation is required to determine whether the activity was malicious or not.

With a positive result, countermeasures for detection (in case the indicator becomes active again) and mitigation must be implemented internally, i.e., we not only want to detect but also actively prevent it from achieving its objectives.

An indicator is considered mature when malicious activity has been retrospectively identified and detection and mitigation countermeasures have been implemented.

From mature to utilized

An indicator is utilized when the detection countermeasures are positive, i.e. the indicator has been identified by performing some action and is considered to have been used to detect a possible scenario that in principle should be malicious.

It is therefore important that the indicators have detection countermeasures in place, otherwise they can never be considered used, thus breaking the cycle completely and being unable to identify new indicators.

From utilized to revealed

This stage of the cycle requires a great deal of interaction from the analysts as they will have to carry out an analysis of the events that have been detected in the previous stage. The reason is simple, the indicator itself is only a small portion of what could be an intrusion or attempt, i.e., it will be necessary to investigate the whole context of what could be happening and build a complete picture of the operation that the adversaries are carrying out.

During this analysis, it is very likely that new indicators will appear that were not previously known, so these indicators will have to be moved to the disclosed state again to start the cycle.

In those cases where a large number of new indicators are identified, or regardless of the quantity, quality should be prioritized. This means that there will be indicators that have more impact and more clearly detect malicious activity. An example could be a domain path, assuming that a malware communicates with baddomain.com/data?systeminfo=value, it is possible that we have seen another domain communicating with the same path, either because the malware incorporates several hardcoded domains in its code or any other reason, so it would be important to mature indicators to detect new behavior of other communications with /data?systeminfo=.

Applying the cycle in threat hunting activities

The entire life cycle of the indicators explained so far has a place in the famous threat hunting process, where the team first performs hypothesis generation by prioritizing the threats that could have the greatest impact on its activity. The next step is the pure hunting activity, where the other cycle can be implemented to structure the work even more and achieve objectives in a more effective way.

The discovery phase could also be framed within the life cycle of the indicators, more specifically with the mature stage, which would be those cases where some past behavior has been detected with the hunt being carried out by the team.

Case study

Let’s imagine that we are generating different scenarios internally to carry out hunting activities.

#1 — Hypothesis generation

We are interested in identifying the creation of scheduled tasks in the systems in the past, because an adversary who has special motivation in our company’s sector could materialize an incident.

Objective: Identify suspicious scheduled tasks in the systems.

Searches: Windows events 4698 and 4702.

#2 — Hunting

The team begins to perform threat hunting activities on the systems using whatever technology is available, be it EDR consoles, opensource tools, SIEM, etc…

A positive is identified in a system, where a scheduled task is checked.

#3 — Revealed to mature

The finding in this case can be verified as a scheduled task masked with a name of “Mozilla Firefox Update” has been enabled by launching via command line a file named “jstnk.exe” found in the AppData directory.

At this point we would have two indicators, a calculated one and a behavioral one.

Computed indicator: MD5 hash of the file jstnk.exe

behavioral Indicator: An adversary sets the scheduled task “Mozilla Firefox Update” (T1053.005) which executes the file jstnk.exe [MD5].

With both indicators, it is necessary to check retrospectively whether similar persistence has been performed on other systems in the corporate network, either with the same malware called jstnk.exe or using the same scheduled task technique.

If new computers are detected where persistence has been performed using T1053.005, countermeasures for detection and mitigation are therefore implemented.

Detection countermeasures: Execution of the command “schtasks /create “, focusing on files referenced in Appdata. A sigma rule similar to the following might be helpful -> https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/win_susp_schtask_creation.yml

Mitigation countermeasures: Establish a policy to limit the use of schtasks in the system.

#4 — Mature to utilized

In this case, let’s imagine that the detection countermeasure mentioned above has worked, and new findings of scheduled task creation are appearing on other systems.

These detections therefore mean that the indicator has been utilized.

#5 — Utilized to revealed

Analysts are starting to conduct research for alerts that have tested positive for creating scheduled tasks. What this triggers is that, it is becoming evident that the malware used for the persistence of this technique is different in all cases, but when the behavior is analyzed, many of the samples share infrastructure for communication with the C&Cs.

All these new indicators will go through the life cycle again to automate new detections and behaviors that may be related to the hunting being performed.

#6 — Discovery

As the findings are aligned with the hypotheses that were generated in the first step, this stage of the threat hunting process means that as much information about the TTPs that have been used at a low level as possible will need to be collected in order to automate or document the findings.

#7 — Report and enrichment

Finally, the threat hunting process requires automating as much as possible the hunt mission carried out, so that the team does not waste time running the same mission every X amount of time and can focus their efforts on developing new missions for other techniques that may be being used in the corporate networks.

Twitter: https://twitter.com/Joseliyo_Jstnk

LinkedIn: https://www.linkedin.com/in/joseluissm/

El proceso de threat hunting que existe actualmente puede ser utilizado en paralelo con otro llamado ciclo de vida de los indicadores.

Ambos ciclos se basan en lo mismo, teniendo como objetivo la detección proactiva de amenazas y comportamientos en la redes corporativas, dejando de lado el enfoque reactivo el cual cada vez más se intenta evitar.

Esto se debe a que los procesos de incident response tradicionales tienen una metodología basada en trabajar sobre un hecho que ha tenido lugar, cuando el ciclo de vida de los indicadores y el proceso de threat hunting lo hacen desde la perspectiva de trabajar para evitar que suceda algo.

Durante este blog explicaré el ciclo de vida de los indicadores y cómo puede utilizarse en paralelo con el proceso de threat hunting, exponiendo también un caso práctico al final.

Ciclo de vida de los indicadores

El ciclo de vida de los indicadores no tiene como objetivo definir cuanto tiempo un indicador es válido o no, ya que eso depende de una gran cantidad de variables no controladas por los analistas.

El enfoque que recibe este ciclo tiene como objetivo que a partir de ciertos indicadores, sean utilizados de manera proactiva para madurarlos y posteriormente, automatizar nuevas búsquedas que puedan revelar otros indicadores relacionados.

Aunque el concepto de manera inicial puede parecer un poco confuso, este ciclo tiene mucho sentido aplicarlo en actividades de threat hunting, ya que será en dichas actividades en donde se le pueda sacar el máximo valor.

Antes de entrar en detalle sobre la explicación de este ciclo, es importante conocer que tipo de indicadores son válidos para estas operaciones, ya que a día de hoy, el término indicador es demasiado ambiguo, no todo el mundo entiende lo mismo por indicador.

Personalmente, me resulta muy útil los tres conceptos diferenciados que exponen en el paper de Lockheed Martin Corporation. Dichos conceptos son los siguientes.

• Indicadores atómicos (atomic): Los indicadores atómicos son obtenidos en base al contexto de una intrusión que ha tenido lugar. El “problema” de este tipo de indicadores, es que no tiene por qué ser actividad exclusiva de un adversario en concreto, es decir, un indicador atómico puede ser identificado en varias intrusiones de diferentes adversarios. Algunos ejemplos de estos indicadores son direcciones IP, dominios, el nombre de un path de un dominio…
• Indicadores calculados (computed): El concepto de indicador calculado es bastante confuso. Estos indicadores son desarrollados a partir de atributos que tienen lugar en un incidente. Por ejemplo, un hash de un archivo que se ha visto en un incidente puede ser calculado, por lo que su MD5, SHA1… Son indicadores calculados. Otro ejemplo podría ser una expresión regular, la cual podemos desarrollar para detectar algo específico.
• Indicadores de comportamiento (behavioral): Estos indicadores están compuestos de una combinación de los dos tipos anteriores descritos. Por ejemplo, dentro de esta categoría podríamos declarar lo siguiente; “Los adversarios establecieron un C&C [IP y/o dominio del C&C] con el equipo comprometido por el malware [Hash MD5]. Las comunicaciones se ejecutaban en un intervalo de [Intervalo de tiempo] entre cliente y servidor. Podían identificarse mediante la búsqueda de la expresión regular [Expresión regular de identificación] en los logs del proxy.”

Como podrá imaginarse, este último tipo de indicador es el que más valor presenta, ya que tiene un contexto asociado de lo que ha sucedido y combina los indicadores atómicos y calculados. Además, es sencillo también extraer posibles técnicas y tácticas de MITRE para poder conocer mejor que acciones se están realizando.

Una vez conocemos los tipos de indicadores que podemos utilizar en el proceso del ciclo de vida de los indicadores, es momento de explicar cómo funciona dicho ciclo.

Consta de tres fases o etapas principales, siendo estas las fases de revelado, madurado y utilizado. Además, este proceso es indispensable que involucre personas, procesos y tecnología, lo que lo hace realmente dinámico y útil en diferentes operaciones, como por ejemplo el threat hunting.

Aplicando este modelo a nuestras actividades de threat hunting, nos va a proveer de las siguientes capacidades:

1. Generar inteligencia de amenazas internas
2. Implementar un proceso de pivoting estable
3. Identificar nuevos indicadores a partir de otros indicadores

De revelado a madurado

Esta primera fase tiene como input diferentes fuentes. En la imagen anterior, se muestran algunas de las que podrían ser un origen de información para empezar el ciclo. Por ejemplo, reportes externo (o internos), fuentes de inteligencia, SIEM o cualquier otra herramienta de monitorización, como podría ser un IDS.

Las anteriores fuentes mencionadas llevarán consigo indicadores, los cuales, deben de ser sometidos a una examinación, que consistirá en buscar históricamente en nuestras fuentes de datos internas disponibles si dicho indicador se observó o no en el pasado (ver entrada sobre CMF). En caso de que el resultado fuese positivo, se debe de investigar más a fondo para determinar si la actividad fue maliciosa o no.

Con un resultado positivo, deben de implementarse de manera interna contramedidas de detección (por si volviese a existir actividad del indicador) y mitigación, es decir, no sólo queremos detectar sino que de manera activa no permitir que consiga sus objetivos.

Un indicador se considera madurado cuando de manera retrospectiva se ha identificado actividad maliciosa y se han implementado contramedidas de detección y mitigación.

De madurado a utilizado

Un indicador es utilizado cuando las contramedidas de detección dan un positivo, es decir, el indicador ha sido identificado realizando alguna acción y se considera que ha sido usado para detectar un posible escenario que en principio debería de ser malicioso.

Es importante por lo tanto, que los indicadores tengan aplicadas contramedidas de detección, de lo contrario nunca podrán considerarse utilizados, rompiendo así el ciclo completamente y siendo incapaces de identificar nuevos indicadores.

De utilizado a revelado

Esta etapa del ciclo requiere gran interacción de los analistas ya que tendrán que llevar a cabo un análisis de los sucesos que hayan sido detectados en la anterior etapa. El motivo es sencillo, el indicador por si sólo es una pequeña porción de lo que podría ser una intrusión o intento de, es decir, habrá que investigar todo el contexto de lo que podría estar ocurriendo y construir una imagen completa de la operación que los adversarios están llevando en ejecución.

Durante este análisis es muy probable que aparezcan nuevos indicadores de los cuales no se tenía conocimiento antes, por lo que dichos indicadores deberán de pasar al estado de revelado nuevamente y empezar así el ciclo.

En aquellos casos donde se identifiquen gran cantidad de nuevos indicadores, o sin importar la cantidad, habrá que priorizar la calidad. Esto quiere decir que existirán indicadores que tengan más impacto y detecten de una manera más clara la actividad maliciosa. Un ejemplo podría ser un path de un dominio, suponiendo que un malware se comunica con baddomain.com/data?systeminfo=value, cabe la posibilidad de que hayamos visto otro dominio realizando la comunicación con el mismo path, ya sea porque el malware incorpora varios dominios hardcodeados en su código o cualquier otro motivo, por lo que sería importante madurar indicadores para detectar nuevo comportamiento de otras comunicaciones con /data?systeminfo=.

Aplicando el ciclo en las actividades de threat hunting

Todo el ciclo de vida de los indicadores que se ha explicado hasta el momento tiene cabida en el famoso proceso de threat hunting, donde en primer lugar el equipo realiza la generación de hipótesis priorizando las amenazas que podrían llegar a tener más impacto contra su actividad. Siendo el siguiente paso la actividad pura de hunting, donde se puede implementar el otro ciclo para estructurar el trabajo aún más y conseguir objetivos de una manera más eficaz.

La fase de descubrimiento también podría estar enmarcada dentro del ciclo de vida de los indicadores, más concretamente con la etapa de madurado, que sería aquellos casos donde se ha detectado algún comportamiento pasado con el hunt que está llevando el equipo a cabo.

Caso práctico

Imaginemos que estamos generando diferentes escenarios de manera interna para llevar a cabo actividades de hunting.

#1 — Generación de hipótesis

Tenemos interés en identificar creaciones de tareas programadas en los sistemas durante el pasado, porque un adversario que tiene especial motivación en el sector de nuestra empresa podría materializar algún incidente.

Objetivo: Identificar tareas programadas sospechosas en los sistemas.

Búsquedas: Eventos de Windows 4698 y 4702.

#2 — Hunting

El equipo empieza a realizar actividades de threat hunting en los sistemas mediante la tecnología que se disponga, ya sea consolas EDR, herramientas opensource, SIEM, etc…

Se identifica un positivo en un sistema, donde se verifica una tarea programada.

#3 — Revelado a madurado

El hallazgo en este caso se puede comprobar como se ha habilitado una tarea programada enmascarada con un nombre de “Mozilla Firefox Update” lanzando por línea de comandos un archivo llamado “jstnk.exe” que se encuentra en el directorio de AppData.

En este punto tendríamos dos indicadores, uno calculado y otro de comportamiento.

Indicador calculado: Hash MD5 del archivo jstnk.exe

Indicador de comportamiento: Un adversario establece la tarea programada “Mozilla Firefox Update” (T1053.005) la cual ejecuta el archivo jstnk.exe [MD5].

con ambos indicadores, hay que verificar de manera retrospectiva si en otros sistemas de la red corporativa se ha realizado persistencia similar, ya sea con el mismo malware llamado jstnk.exe o mediante la misma técnica de tarea programada.

Imaginando que se detectan nuevos equipos donde se ha hecho la persistencia mediante T1053.005, se procede por lo tanto a implementar contramedidas de detección y mitigación.

Contramedida de detección: Ejecución del comando “schtasks /create “, poniendo foco en archivos referenciados en Appdata. Una regla sigma parecida a la siguiente podría servirnos -> https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/win_susp_schtask_creation.yml

Contramedida de mitigación: Establecer una política para limitar el uso de schtasks en el sistema.

#4 — Madurado a Utilizado

En este caso, imaginemos que la contramedida de detección mencionada anteriormente ha funcionado, y están apareciendo nuevos hallazgos de creación de tareas programadas en otros sistemas.

Estas detecciones por lo tanto significan que el indicador ha sido utilizado.

#5 — Utilizado a revelado

Los analistas empiezan a realizar labores de investigación para las alertas que han dado positivo en la creación de tareas programadas. Esto lo que desencadena es que, se está evidenciando que el malware usado para la persistencia de esta técnica es diferente en todos los casos, pero cuando se analiza el comportamiento, muchas de las muestras comparten infraestructura para la comunicación con los C&C.

Todos esos nuevos indicadores pasarán por el ciclo de vida de nuevo para automatizar nuevas detecciones y comportamientos que pudiesen estar relacionados con el hunting que se está realizando.

#6 — Descubrimiento

Como los hallazgos están alineados con las hipótesis que se generaron en el primer paso, esta etapa del proceso de threat hunting quiere decir que habrá que recopilar la mayor información sobre los TTPs que han utilizado a bajo nivel para poder automatizar o documentar los hallazgos.

#7 — Reporte y enriquecimiento

En último lugar, el proceso de threat hunting requiere automatizar al máximo posible la misión de hunt llevada a cabo, de esta manera, conseguiremos que el equipo no pierda tiempo nuevamente ejecutando la misma misión cada X tiempo y puedan centrar sus esfuerzos en elaborar nuevas misiones de otras técnicas que pudiesen estar siendo utilizadas en las redes corporativas.

Twitter: https://twitter.com/Joseliyo_Jstnk

LinkedIn: https://www.linkedin.com/in/joseluissm/

TL;DR

Lately I am analyzing many malware samples from different families written in C#, C++ and other languages based on the .NET framework (.NET assembly).

This has led me to find a problem when correlating different samples using hashing techniques, and that is that the imphash in a high percentage was always the same, even with different malware families, however, using other fuzzy hashing techniques I couldn’t find any similarity.

The problem is due to the fact that during the compilation of the .NET programming languages, the source code is converted into Microsoft Intermediate Language (MSIL), which causes the same imphash to always exist, corresponding in some cases to the import of the mscoree.dll DLL and the _CorExeMain function.

I have solved this problem by using another hashing tool called TypeRef Hasher developed by the folks at G Data CyberDefense. This tool provides a solution to imphash only for .NET malware samples.

Taking advantage of the CLI they have available on GitHub, I have developed a small solution that implements and complements it.

Problem

During the last months, analyzing malware samples that were compiled by some programming language in .NET, I always ran into the same imphash, which in many cases made me believe that I was crazy.

I was seeing correlations where there weren’t simply because imphash was always the same. For this reason, I started to investigate to see if imphash could really have some kind of bug and I could develop something to fix it, since imphash is one of the indicators I use (from a long list) to correlate malware and to help me later in the attribution processes.

The top part of the above image is an AsyncRAT sample which, as you can see, has the same imphash as the AgentTesla sample at the bottom (f34d5f2d4577ed6d9ceec516c1f5a744).

Remembering how imphash works, the hash it produces is based on the DLLs, functions and the order of them in a PE. This fact was what definitely helped me to think that I was not crazy.

Both malware samples contain the same imported DLL (mscoree.dll) and the same function (_CorExeMain), which must have a reason for this behavior.

Looking for information about the _CorExeMain function imported from the DLL in the Microsoft Documentation Center they indicate that it has the following functionality:

1. Initialize the CLR (Common Language Runtime)
2. Finds the entry point in the CLR header of the executable
3. Normal PE execution begins

To summarize, a PE that has been compiled with .NET will have its Entry Point to the _CorExeMain() function of the mscoree.dll DLL, which will ensure that the CLR is loaded to execute the rest of the code.

Later, at runtime, on demand, the PE will load the rest of the DLLs it needs, that is why in the first instance, the DLLs are not listed in the IAT.

Solution

The folks at G Data CyberDefense ran into the same problem as I did recently and came up with a very interesting development to solve this problem.

They have created a hash called TypeRefHash that is based on the TypeRef Table of PEs in .NET.

This table stores references to the imported namespaces, having a behavior very similar to that of the DLLs and their functions. For example, if in a PE the DLL Kernel32.dll is imported to make use of the WriteFile function, in a .NET PE the FileStream class of the System.IO namespace can be used.

In the previous image you can see part of the TypeRef table of the same AsyncRAT sample above, illustrating as an example how it performs the import of the System.IO namespace and the FileStream class.

All this table is finally used to build a hash (TypeRefHash) with the names and namespaces imported by the PE, something very similar to what imphash does with the DLLs.

The calculation of the SHA256 hash that they do is based on the following three steps that they indicate in their post.

1. They sort the entries by TypeNameSpace and then by TypeName. This is very important, because this way if a new variant of a malware family changes the order of imports, it will not affect the final result of the hash calculation. Empty TypeNameSpaces will be the first to be sorted.
2. Concatenate the TypeNamespace and TypeName with a dash. If the TypeNameSpace is empty, the concatenated string begins with the dash.
3. All comma-separated strings are joined together and the SHA256 of the resulting UTF8 byte string is then calculated.

An example could be the following, which I wanted to illustrate in an image as a summary.

Neossins development

Based on the G Data CyberDefense tool, I have developed a small application called Neossins in its 0.1 Alpha version, which I will be improving and implementing new features over time.

The objective pursued by Neossins is first of all to have a structured and comprehensive dataset of TypeRef Hashes on the main .NET malware families, having so far contemplated three:

1. AsyncRAT
2. Blackshades
3. AgentTesla

Once the information is structured and stored in a database, the next step is to compare malware samples received from different sources with the dataset to identify if there is a match with any TypeRef Hash, and if so, to correlate other samples that have the same hash and that were previously stored in the database.

Ultimately, it is optimal that new matching samples are stored in the dataset, since the idea is to grow the dataset to be able to know as many TypeRef Hashes as possible for a malware family.

The tool has been developed in python3 and has some dependencies such as Cytoscape for the generation of the graph that is displayed in a web application that is raised by Dash.

In a series of tests I have been performing using some downloaded malware samples related to AsyncRAT and AgentTesla, the result was the following.

The red rectangular nodes are all the samples that I deposited in the directory (the starting point) that must be set in the application’s configuration file.

Starting from the left side (blue zone), you can see that there are five nodes that all share the same TypeRef Hash, which could mean that they are variants belonging to the same family.

In the central part (red zone), there are three rectangular nodes of red color that are the samples selected to make a comparison with the AsyncRAT family, one of them is the one that has been seen in this post at the beginning of the whole. Two of the three samples, it can be seen that they have a large number of matches previously stored in the dataset, whose nodes are represented by pink circles. All these relationships between nodes means that they share the same TypeRef Hash.

Finally, on the right side of the screen, seven orphan nodes that have no match with the dataset can be seen, which could be studied to verify if they could be the families mentioned by means of techniques other than TypeRef Hash, and if so, it would be convenient to store the samples in the dataset.

Conclusion

The TypeRef Hash solution is one more feature that can be used to identify malware variants on known families.

As I say and reiterate, it is not a definitive and unique solution to be used for the mentioned task, since it can be perfectly used in parallel with other techniques such as ssdeep, VT vhash, imphash for non-.NET files, etc…

The use of imphash for samples compiled using .NET and incorporating only the mscoree.dll DLL and its corresponding _CorExeMain function, has no value since in most cases it will give a false positive in possible relationships of malware samples.

Little by little I will update Neossins until I have a stable version and incorporate new features that I want to implement in the future.

Twitter: @Joseliyo_Jstnk

Github: https://github.com/jstnk9/neossins

LinkedIn: https://linkedin.com/in/joseluissm/

References

https://github.com/GDATASoftwareAG/TypeRefHasher
https://www.gdatasoftware.com/blog/2020/06/36164-introducing-the-typerefhash-trh
https://gist.github.com/secana/42974cf3536590def7bf09582efca7a8

TL;DR

Últimamente estoy analizando muchas muestras de malware de diferentes familias escritas en C#, C++ y otros lenguajes basados en el framework de .NET (.NET assembly).

Esto me ha llevado a encontrarme con un problema a la hora de poder correlar diferentes muestras mediante técnicas de hashing, y es que el imphash en un alto porcentaje siempre era el mismo, incluso con diferentes familias de malware, sin embargo, mediante otras técnicas de fuzzy hashing no encontraba ningún tipo de similitud.

La problemática se debe a que durante la compilación de los lenguajes de programación .NET, el código fuente es convertido en Lenguaje Intermedio de Microsoft (MSIL, en inglés, Microsoft Intermediate Language), lo que produce que siempre exista el mismo imphash, correspondiente en algunos casos a la importación de la DLL mscoree.dll y la función _CorExeMain.

Este problema lo he solucionado mediante otra herramienta de hashing llamada TypeRef Hasher desarrollada por la gente de G Data CyberDefense. Dicha herramienta, plantea una solución a imphash sólo para las muestras de malware en .NET.

Aprovechando el CLI que tienen disponible en GitHub, he desarrollado una pequeña solución que lo implementa y complementa.

Problemática

Durante los últimos meses, analizando muestras de malware que se encontraban compiladas por algún lenguaje de programación en .NET, siempre me chocaba con el mismo imphash, lo que en muchos casos me hacia creer que estaba loco.

Veía correlaciones donde no las había simplemente porque el imphash siempre era el mismo. Por esta misma razón, empecé a investigar para ver si imphash realmente podría tener algún tipo de fallo y podía desarrollar algo para solucionarlo, ya que imphash es uno de los indicadores que utilizo (de una larga lista) para correlar malware y que me ayude posteriormente en los procesos de atribución.

La parte superior de la imagen anterior se trata de una muestra de AsyncRAT la cual, como se puede apreciar, tiene el mismo imphash que la muestra de AgentTesla que está en la parte inferior (f34d5f2d4577ed6d9ceec516c1f5a744).

Recordando el funcionamiento de imphash, el hash que elabora está basado en las DLLs, funciones y el orden de las mismas en un PE. Este hecho fue el que me ayudo definitivamente a pensar que no estaba loco.

Ambas muestras de malware contienen la misma DLL importada (mscoree.dll) y la misma función (_CorExeMain), lo cual, debe de tener un motivo que explique este comportamiento.

Buscando información sobre la función _CorExeMain importada de la DLL en el Centro de Documentación de Microsoft indican que tiene la siguiente funcionalidad:

1. Inicializa el CLR (Common Language Runtime)
2. Busca el punto de entrada en el encabezado CLR del ejecutable
3. Comienza la ejecución normal del PE

Sintetizando, un PE que se ha compilado con .NET, tendrá su Entry Point a la función _CorExeMain() de la DLL mscoree.dll, la cual, asegurará que el CLR es cargado para ejecutar el resto de código.

Posteriormente, en tiempo de ejecución, bajo demanda, el PE irá cargando el resto de DLLs que vaya necesitando, por eso en primera instancia, las DLLs no son listadas en la IAT.

Solución

La gente de G Data CyberDefense se toparon con el mismo problema que yo recientemente y llevaron a cabo un desarrollo para solventar esta problemática muy interesante.

Han creado un hash llamado TypeRefHash que se basa en la tabla de referencias (TypeRef Table) de los PE en .NET.

Dicha tabla almacena referencias a los namespaces importados, teniendo un comportamiento muy similar al de las DLLs y sus funciones. Por ejemplo, si en un PE se importa la DLL Kernel32.dll para hacer uso de la función WriteFile, en un PE de .NET se puede utilizar la clase FileStream del namespace System.IO

En la imagen anterior se puede apreciar parte de la tabla TypeRef de la misma muestra de AsyncRAT anterior, ilustrando a modo de ejemplo como realiza la importación del namespace System.IO y la clase FileStream.

Toda esa tabla sirve finalmente para construir un hash (TypeRefHash) con los names y namespaces que importan los PE, algo muy similar a como lo hace imphash con las DLLs.

El cálculo del hash SHA256 que hacen se basa en los siguientes tres pasos que indican en su post.

1. Ordenan las entradas por TypeNameSpace y luego por TypeName. Esto es muy importa, ya que de esta manera si una nueva variante de una familia de malware cambia el orden de importaciones, no afectará en el resultado final del cálculo de hash. Los TypeNameSpace vacíos serán los primeros en ordenarse.
2. Concatenan los TypeNamespace y TypeName con un guión. Si el TypeNameSpace está vacío, la cadena concatenada comienza con el guión.
3. Se unen todas las cadenas separadas por comas y se calcula entonces el SHA256 de la cadena de bytes UTF8 resultante.

Un ejemplo podría ser el siguiente que he querido ilustrar en una imagen a modo resumen.

Desarrollo de Neossins

Basado en la herramienta de G Data CyberDefense, he desarrollado una pequeña aplicación llamada Neossins en su versión 0.1 Alfa, que iré mejorando e implementando nuevas funcionalidades a lo largo del tiempo.

El objetivo que persigue Neossins es en primer lugar tener un dataset estructurado y amplio de TypeRef Hashes sobre las principales familias de malware .NET, teniendo hasta el momento contempladas tres:

1. AsyncRAT
2. Blackshades
3. AgentTesla

Una vez estructurada la información y almacenada en una base de datos, el siguiente paso es poder comparar muestras de malware que se vayan recibiendo de diferentes fuentes con el dataset para identificar si existe match con algún TypeRef Hash, y en caso de ser así, correlar otras muestras que tengan el mismo hash y que estuviesen almacenadas en la base de datos previamente.

En último lugar, lo óptimo es que las nuevas muestras que hagan match se vayan almacenando en el dataset, ya que la idea es hacer crecer el conjunto de datos para poder conocer el máximo de TypeRef Hashes posibles de una familia de malware.

La herramienta la he desarrollado en python3 y tiene algunas dependencias como por ejemplo Cytoscape para la generación del grafo que es mostrado en una aplicación web que levanta mediante Dash.

En una serie de pruebas que he estado realizando mediante unas muestras de malware descargadas y relacionadas con AsyncRAT y AgentTesla, el resultado fue el siguiente.

Los nodos rectangulares de color rojo son todas las muestras que deposité en el directorio (el punto de partida) que se debe de establecer en el archivo de configuración de la aplicación.

Empezando por la parte de la izquierda, se puede ver como existen cinco nodos que comparten todos entre si el mismo TypeRef Hash, lo que podría significar que se tratan de variantes pertenecientes a la misma familia.

En la parte central (zona roja), existen tres nodos rectangulares de color rojo que son las muestras seleccionadas para realizar una comparativa con la familia de AsyncRAT, una de ellas, es la que se ha visto en este post al principio del todo. Dos de las tres muestras, puede evidenciarse que tienen una gran cantidad de matches almacenados previamente en el dataset, cuyos nodos son representados mediante círculos de color rosa. Todas esas relaciones entre nodos significa que comparten el mismo TypeRef Hash.

Finalmente, en la parte derecha del todo, se pueden ver siete nodos huérfanos que no tienen ningún match con el dataset, los cuales, podrían ser objeto de estudio para verificar si pudiesen tratarse de las familias mencionadas mediante otro tipo de técnicas diferente a TypeRef Hash, y en caso de ser así, convendría almacenar las muestras en el dataset.

Conclusión

La solución TypeRef Hash es una característica más que puede servir a la hora de identificar variantes de malware sobre familias conocidas.

Como bien digo y reitero, no es una solución definitiva y única que debe de emplearse para el cometido mencionado, ya que perfectamente puede ser utilizada en paralelo junto a otras técnicas como ssdeep, vhash de VT, imphash para archivos no .NET, etc…

El uso de imphash para las muestras compiladas mediante .NET y que incorporan únicamente la DLL mscoree.dll y su correspondiente función _CorExeMain, no tiene ningún valor ya que en la mayor parte de los casos dará un falso positivo en posibles relaciones de muestras de malware.

Poco a poco iré actualizando Neossins hasta que tenga una versión estable e incorpore nuevas funcionalidades que quiero implementar en el futuro.

Twitter: @Joseliyo_Jstnk

Github: https://github.com/jstnk9/neossins

LinkedIn: https://linkedin.com/in/joseluissm/

Referencias

https://github.com/GDATASoftwareAG/TypeRefHasher
https://www.gdatasoftware.com/blog/2020/06/36164-introducing-the-typerefhash-trh
https://gist.github.com/secana/42974cf3536590def7bf09582efca7a8

TL;DR

Often DFIR teams must perform threat hunting actions to proactively identify anomalous behaviors in our networks or customers. However, on many occasions we do not know where to search or directly do not know which technologies we have to collect this information.

A Collection Management Framework (CMF) can help us in these situations. This is based on which information each data source gives us and which of these sources are available for hunting.

Objective

Before talking about what is a CMF, it is important to explain in summarized form the real meaning, because the main job of the CMF is to support this work.

Threat hunting is that activity that aims to proactively discover malicious activity of an actor or group of actors after the previous generation of hypotheses. Due to its a complex process, there are different maturity models to carry it out.

Without going into much more detail about threat hunting because it is not the objective, more information about this activity and what each degree of maturity consists of can be found in the next entry in Sqrrl.

Having already, organizations must be able to generate a CMF on that technology that they have and that the threat hunting team can consume to identify threats on the network. Otherwise, discovering threats will be such a tiring task that the team will not be able to meet the intelligence requirements that have been demanded of them.

A CMF must be able to answer many of the questions that threat hunters ask themselves during their activity, such as:

• Where do I get the data for hunting?
• What data is available?
• For how long is such data stored?
• How can I consume the data?

Workflow

On many occasions, to carry out the threat hunting activity it is necessary to know what we are going to look for. In order to do this, you can generate hypotheses and work on them. However, in order to generate the hypotheses, we must know the threats that we face.

If we do not follow the last comments, we will be looking for something that we ourselves do not know about any generic threat that could not carry a risk for the company.

As an example, a possible flow to carry out threat hunting activities correctly with defined objectives would be the following:

First of all, it is important to know our adversaries and prioritize those who may have more activity and motivations in the sector that the organization operates, since they pose more risk. This work is done by Cyber Threat Intelligence teams.

Something that can help us in this case is a Threat Modeling, getting to see in a structured way those potential groups that could have interaction with us at any time. More information on threat modeling here.

Some of the information that we will obtain in the knowledge phase about the adversary could be the following:

TTPs

Tactics, techniques and procedures used by the actor or group of actors that we intend to carry out hunting activities later.

Obtaining this information at a low level will later help the next two phases, therefore, it is highly recommended to map the tactics and techniques with the MITRE ATT&CK knowledge base in any of its variants (Enterprise, Mobile and PRE), in addition, they have just launch a beta that incorporates very comprehensive sub-techniques, more information about this here.

Tradecraft

When we talk about tradecraft we mean the techniques, methods and technologies used by an adversary during an intrusion. Although it may seem very similar to TTPs, tradecraft gives a different and more specific vision, but TTPs partially abstract us from the behavior.

An example of tradecraft could be when we talk about an adversary using spearphishing with an attached Word document and embedded macros. After the download and subsequent execution, it drops a RAT from the FlawedAmmyy family.

All this mentioned above, if we were to talk about TTPs, would remain in the MITER tactics and techniques at a high level, without going into detail of families.

Malware

These are all malicious capabilities developed by the actor or, failing that, reused from existing ones. Know them is important, since it will later help in the generation of the scenario and execution by a red team. It is also possible to extract tactics and techniques from malware individually.

Software

Like malware, when we refer to software, we are talking about those capabilities that actors use during their intrusion but that are not considered malware, since many of these capabilities are features that are incorporated into operating systems today (LOLBINs). To make this category clear, an example might be wscript.exe or cmd.exe.

Generation of hypotheses based on the selected adversaries would be the next activity that should be carried out and, as in the previous case, it is the responsibility of the Cyber Threat Intelligence team.

Once you are able to know what your adversaries are, what TTPs they carry out during their operations, what malware and/or software they use and what motivations and objectives they are folllowing, you have the ability to create a scenario to carry out against your organization.

These scenarios can be very similar to campaigns that have been carried out in the past, but above all, they must be realistic so that the red team can emulate them in a satisfactory way.

All this information should be collected in a report that will be subsequently delivered to the red team to execute it, precisely in the next phase, which is the scenario execution.

Nowadays there are many tools that make the task of scenario emulation and detection easier in an automated way. From paid products like Cymulate to open source tools like Caldera and Mordor can help us in this case.

Any execution that is carried out will be under the responsibility of the red team, which is in charge of carrying out the operations and subsequently testing the threat hunting team for detection.

Lastly, we are in the hunting phase, where the team must identify malicious activities that have been carried in the network with the support of a previously generated CMF, thus achieving to know where to obtain the information they are looking for and what type of information is.

Hunting activities are completely linked to active defenses and it is important to know that there is a very significant factor here, humans, which means that automating this phase completely is not possible, however, there are certain aspects that They can help us, such as for example an alert generated by IDS, which could lead to a subsequent hunting process.

Collection Management Framework (CMF)

At this point, is time to start working on a CMF in order to make life easier for the threat hunting team. This work must be the result of a collaboration between different departments such as telecommunications, IT, architecture, security … Depending on each organization, there will be more or less team collaboration for the operations they carry out in their day to day.

The main objective of working at the CMF is to be able to have a list of all the technologies from which information can be obtained to carry out threat hunting activities and detect suspicious activities.

As mentioned before, it is important that the CMF can answer questions such as:

• Where do I get the data for hunting?
• What data is available?
• For how long is such data stored?
• How can I consume the data?

For this, we will define first what information we are interested in knowing for each data source available in the organization to do hunting. The good thing about this is that we can adapt it to our needs and incorporate or eliminate fields that do not interest us.

• Type of data
• Killing chain phase covering
• Observable collection
• Data storage time
• Data storage location
• Department owner
• Data set
• Category

Defined the previous points, that we are going to fill in for each data source, it is time that we begin to identify those sources that during an intrusion, could give us information to be able to look for anomalies in the organization’s network. As an example for this post, we will focus on the following data sources:

• Firewall
• Windows systems
• IDS
• Web logs

Defined the fields that we are going to fill in and the data sources, it is time to get down to work and make a simple table that can help us like the following:

Simply with the information we have filled in in the table above, we can answer many questions in the event of an intrusion.

In case they have exploited a vulnerability of the web application, we will only have information to investigate 60 days ago, everything that happened after those days, the threat hunting team will not be able to satisfy an intelligence requirement.

On the contrary, if it has caused a network intrusion and establishes some type of communication with a C2, we could detect that behavior 90 days ago at best.

Other information that the table can give us in this case is about those phases within the kill chain where we have less visibility. In this example, due to the type of data sources that we have collected, if an infection were to occur in an endpoint system and it were to persist, we would only have the logs of the Windows systems to cover the “installation” phase, since the rest of Data sources do not cover this phase.

So far, all the information we have discussed can be integrated into a platform that the people of Rabobank have developed called DeTTECT.

As they say, the objective of the tool is to help blue teams based on a scoring established in ATT & CK to identify the quality, visibility and detection that an organization has in its registered data sources. At this point, with the information from the CMF, we could start working on this tool.

To better understand how this application works, I recommend watching the presentation and presentation by Ismael Valenzuela where he gives practical examples of DeTTECT.

LinkedIn: https://linkedin.com/in/joseluissm/

References

Threat Hunting and Hunting Maturity Models — https://medium.com/@sqrrldata/the-cyber-hunting-maturity-model-6d506faa8ad5

Adversary Emulation Plans — https://attack.mitre.org/resources/adversary-emulation-plans/

Collection Management Frameworks — Beyond Asset Inventories for Preparing for and Responding to Cyber Threats — https://dragos.com/resource/collection-management-frameworks-beyond-asset-inventories-for-preparing-for-and-responding-to-cyber-threats/

TL;DR

A menudo los equipos de DFIR debemos de realizar acciones de threat hunting para identificar comportamientos anómalos de manera proactiva en nuestras redes o de clientes. Sin embargo, en muchas ocasiones no sabemos donde buscar o directamente desconocemos que tecnologías tenemos para recabar dicha información.

Un Collection Management Framework (CMF) nos puede ayudar en estas situaciones. Este se basa en qué información nos da cada data source y cuales de estas fuentes están disponibles para hacer hunting.

Objetivo

Antes de comenzar a hablar sobre qué es el CMF, es importante explicar de manera resumida que es aquello que llamamos threat hunting, ya que la principal labor del CMF es apoyar a esta labor.

Threat hunting es aquella actividad que tiene como meta descubrir de manera proactiva actividad maliciosa de un actor o grupo de actores tras la generación previa de hipótesis. Debido a que es un proceso complejo, existen diferentes modelos de madurez para llevarlo a cabo.

Sin entrar mucho más en detalle del threat hunting porque no es el objetivo, se puede ampliar más información sobre esta actividad y en que consiste cada grado de madurez en la siguiente entrada de Sqrrl.

Dicho esto, las organizaciones deben de ser capaces de generar un CMF sobre aquella tecnología que disponen y que el equipo de threat hunting puede consumir para identificar amenazas en la red. De lo contrario, descubrir amenazas será una tarea tan fatigosa que el equipo no podrá conseguir los requerimientos de inteligencia que les hayan demandado.

Un CMF debe de ser capaz de responder a muchas de las preguntas que los threat hunters se hacen durante su actividad como por ejemplo:

• De donde obtengo los datos para hacer hunting?
• Qué datos están disponibles?
• Durante cuanto tiempo son almacenados dichos datos?
• Cómo puedo consumir los datos?

Flujo de trabajo

En muchas ocasiones, por no decir prácticamente en todas, para llevar a cabo la actividad de threat hunting es necesario saber qué es lo que vamos a buscar. Para ello, se puede generar hipótesis y trabajar en base a ellas. Sin embargo, para poder generar las hipótesis, debemos de conocer las amenazas a las que nos enfrentamos.

Si no seguimos lo último comentado, estaremos buscando algo que nosotros mismos desconocemos sobre cualquier amenaza genérica que podría no llevar un riesgo para la compañía.

Sirviendo como ejemplo, un posible flujo para llevar a cabo actividades de threat hunting de manera correcta con objetivos definidos sería el siguiente:

En primer lugar, es importante conocer nuestros adversarios y priorizar aquellos que puedan tener más actividad y motivaciones sobre el sector que opera la organización, ya que estos suponen más riesgo. Este trabajo es realizado por los equipos de Cyber Threat Intelligence.

Algo que puede ayudarnos en este caso es un Threat Modeling, consiguiendo ver de manera estructurada aquellos potenciales grupos que pudiesen tener interacción en algún momento con nosotros. Más información del threat modeling aquí.

Alguna de la información que obtendremos en la fase de conocimiento sobre el adversario podría ser la siguiente:

TTPs

Tácticas, técnicas y procedimientos utilizados por el actor o grupo de actores que pretendemos realizar actividades de hunting posteriormente.

Conseguir esta información a bajo nivel ayudará después a las siguientes dos fases, por ello, es extremadamente recomendable mapear las tácticas y técnicas con la base de conocimiento de Mitre ATT&CK en cualquiera de sus variantes (Enterprise, Mobile y PRE), además, acaban de lanzar una beta que incorpora sub-técnicas muy completa, más información sobre esto aquí.

Tradecraft

Cuando hablamos de tradecraft nos referimos a las técnicas, métodos y tecnologías usadas por un adversario durante una intrusión. Aunque pueda parecer muy similar a los TTPs, el tradecraft da otra visión diferente más específica, sin embargo los TTPs nos abstraen en parte del comportamiento.

Un ejemplo de tradecraft podría ser cuando hablamos de que un adversario utiliza spearphishing con un documento Word adjunto y macros embebidas. Tras la descarga y ejecución posterior, dropea un RAT de la familia FlawedAmmyy.

Todo esto mencionado anteriormente, si hablásemos de TTPs, quedaría en las tácticas y técnicas de MITRE a alto nivel, sin entrar en detalle de familias.

Malware

Se trata de todas las capacidades maliciosas desarrolladas por el actor o en su defecto, reutilizadas de otras ya existentes. Conocerlas es importante, ya que posteriormente ayudará en la generación del escenario y ejecución por parte de un red team. También es posible extraer tácticas y técnicas del malware de manera individual.

Software

Al igual que el malware, cuando nos referimos a software, hablamos de aquellas capacidades que los actores utilizan durante su intrusión pero que no es considerado como malware, ya que muchas de estas capacidades se tratan de funcionalidades que incorporan los sistemas operativos a día de hoy (LOLBINs). Para que quede claro esta categoría, un ejemplo podría ser wscript.exe o cmd.exe.

La generación de hipótesis en base a los adversarios seleccionados sería la siguiente actividad que debería de realizarse y, al igual que en el caso anterior, es responsabilidad del equipo de Cyber Threat Intelligence.

Una vez eres capaz de conocer cuales son tus adversarios, que TTPs llevan a cabo durante sus operaciones, que malware y/o software utilizan y que motivaciones y objetivos persiguen, tienes la capacidad de generar un escenario para llevar a cabo contra tu organización.

Estos escenarios pueden ser muy similares a campañas que hayan ejecutado en el pasado, pero sobre todo, deben de ser realistas de cara a que el red team puede emularlos de manera satisfactoria.

Toda esta información debería de quedar recogida en un reporting que será posteriormente entregado al equipo de red team para ejecutarlo, justamente en la siguiente fase que es la de ejecución de escenario.

Hoy en día existen muchas herramientas que permiten facilitar la tarea de emulación de escenario y detección de manera automatizada. Desde productos de pago como Cymulate hasta herramientas open source como Caldera y Mordor pueden ayudarnos en este caso.

Toda ejecución que se realice estará bajo la responsabilidad del equipo de red team, el cual es el encargado de llevar a cabo las operaciones para posteriormente poner a prueba al equipo de threat hunting de cara a la detección.

Por último, nos encontramos en la fase de hunting, donde el equipo debe de identificar actividades maliciosas que se han llevado a cabo en la red con el apoyo de un CMF generado previamente, consiguiendo de esta manera saber donde obtener la información que buscan y que tipo de información es.

Las actividades de hunting están completamente ligadas a defensas activas y, es importante saber que existe un factor muy significativo aquí, siendo el humano, lo que quiere decir que automatizar esta fase por completo no es posible, sin embargo, si que hay ciertos aspectos que pueden ayudarnos como puede ser por ejemplo una alerta generada por IDS, lo que podría desembocar en un proceso de hunting posterior.

Collection Management Framework (CMF)

Llegados a este punto, es hora de empezar a trabajar en un CMF para poder facilitar la vida al equipo de threat hunting. Este trabajo debe de ser el resultado de una colaboración entre diferentes departamentos como pueden ser telecomunicaciones, sistemas, arquitectura, seguridad… Dependiendo de cada organización, existirá mayor o menor colaboración de equipos por las operaciones que llevan en su día a día.

El principal objetivo de trabajar en el CMF es poder tener censado todas las tecnologías desde las cuales, se puede obtener información para realizar actividades de threat hunting y detectar actividades sospechosas.

Tal y como se ha comentado antes, es importante que el CMF pueda responder a preguntas como:

• De donde obtengo los datos para hacer hunting?
• Qué datos están disponibles?
• Durante cuanto tiempo son almacenados dichos datos?
• Cómo puedo consumir los datos?

Para ello, definiremos primero que información nos interesa conocer por cada data source disponible en la organización para hacer hunting. Lo bueno de esto, es que podemos adaptarlo a nuestras necesidades e incorporar o eliminar campos que no nos interese.

• Tipo de datos
• Fase del kill chain que cubre
• Colección de observable
• Tiempo de almacenamiento de datos
• Lugar de almacenamiento de datos
• Departamento que lo gestiona
• Data set
• Categoría

Definidos los puntos que vamos a rellenar por cada data source, es hora de que empecemos a identificar aquellas fuentes que durante una intrusión, pudiesen darnos información para poder buscar anomalías en la red de la organización. A modo de ejemplo para este post, nos vamos a centrar en los siguientes data sources:

• Firewall
• Sistemas Windows
• IDS
• Web logs

Definidos los campos que vamos a rellenar y los data sources, es hora de ponerse manos a la obra y realizar una simple tabla que pueda ayudarnos como la siguiente:

Simplemente con la información que hemos rellenado en la anterior tabla, podemos responder muchas preguntas en caso de que se lleve a cabo una intrusión.

En caso de que hayan explotado una vulnerabilidad de la aplicación web, sólo tendremos información para investigar 60 días atrás, todo lo que haya pasado después de esos días, el equipo de threat hunting no podrá satisfacer un requerimiento de inteligencia.

Por el contrario, si ha producido una intrusión en la red y establece algún tipo de comunicación con un C2, podríamos detectar ese comportamiento 90 días atrás en el mejor de los casos.

Otra información que la tabla puede darnos en este caso se trata de aquellas fases dentro del kill chain donde tenemos menos visibilidad. En este ejemplo, por el tipo de data sources que tenemos recogidos, si se produjera una infección en un sistema endpoint y realizase persistencia, tendríamos únicamente los logs de los sistemas de Windows para cubrir la fase de “installation”, ya que el resto de data sources no cubren dicha fase.

Hasta aquí, toda la información que hemos tratado puede ser integrada en una plataforma que la gente de Rabobank ha desarrollado llamada DeTTECT.

Tal y como dicen, el objetivo de la herramienta es ayudar a los blue teams en base a un scoring establecido en ATT&CK para identificar la calidad, visibilidad y detección que tiene una organización en sus data sources registrados. Llegados a este punto, con la información del CMF podríamos empezar a trabajar en esta herramienta.

Para entender mejor como funciona dicha aplicación, recomiendo ver la ponencia y presentación de Ismael Valenzuela donde pone ejemplos prácticos de DeTTECT.

LinkedIn: https://linkedin.com/in/joseluissm/

Referencias

Threat Hunting and Hunting Maturity Models — https://medium.com/@sqrrldata/the-cyber-hunting-maturity-model-6d506faa8ad5

Adversary Emulation Plans — https://attack.mitre.org/resources/adversary-emulation-plans/

Collection Management Frameworks — Beyond Asset Inventories for Preparing for and Responding to Cyber Threats — https://dragos.com/resource/collection-management-frameworks-beyond-asset-inventories-for-preparing-for-and-responding-to-cyber-threats/

Gracias al threat modeling (en español modelado de amenazas), se puede dar una visión estratégica de las principales amenazas con el objetivo de enfocar los esfuerzos de priorización en aquellos puntos donde más riesgo pueda existir.

Desde una visión de Cyber Threat Intelligence, el foco se centra en la identificación de actores y eventos junto a los TTPs y Tradecraft utilizados en los mismos, relacionándolo de esta manera a la actividad de nuestra organización.

El modelo tiene una ventaja y es que puede ser tan flexible como lo deseemos, lo cual ayuda a adaptarse a nuestras necesidades de inteligencia.

Objetivo

El principal objetivo del threat modeling, es conocer aquella información y/o activos que se consideran críticos para el negocio de la organización, después de esto, se podrá relacionar con potenciales amenazas que pudieran llevar a cabo algún ataque para conseguir sus objetivos finales.

Teniendo claro lo anterior, lo primero es conocer esa información o activos que pensamos que son importantes para la organización. Para conseguir esto, podríamos hacernos la siguiente pregunta:

¿Qué información y/o activos críticos para la organización tengo para ser objetivo de un ataque?

Para poder responder bien a esta pregunta, debemos de ponernos desde el punto de vista de un actor malicioso que tuviera como objetivo nuestra organización. Por supuesto, la respuesta de esta pregunta variará en función de sector al que pertenezca nuestra organización y las actividades que realice, ya que si fuésemos un banco, uno de los claros objetivos por parte de un actor malicioso, sería acceder a información relacionada con transacciones, sin embargo, si nuestra organización se trata de una infraestructura crítica, uno de los objetivos podría ser acceder y controlar los HMIs.

Una vez conozcamos el objetivo que motivaría a un actor malicioso atacarnos, es hora de realizar un modelo para nuestra organización.

Elaboración

Antes de empezar a trabajar sobre nuestro modelo, es importante mencionar que es aconsejable que se actualice de manera periódica, ya sea porque la organización introduce nueva información crítica o porque existen nuevas amenazas y capacidades diferentes (también puede haber amenazas que dejen de impactar a las operaciones de la organización).

Lo primero que se tiene que realizar tal y como se comentaba en el punto anterior, es identificar aquella información o activos críticos para la organización. En este ejemplo, nuestra empresa se llamará ACME y estará relacionada por su actividad al sector de media.

Llega el momento de hacernos la pregunta del punto anterior.

¿Qué información y/o activos críticos para la organización tengo para ser objetivo de un ataque?

Teniendo claro que el sector de ACME se trata de media y únicamente a modo de ejemplo, se pondrá a continuación tres puntos críticos de la organización que pueden ser susceptibles de ataques:

· Propiedad intelectual de ACME sobre un bien generado.

· Producción TV, refiriéndose de esta manera a la red de producción donde se encuentran los directos de televisión.

· Futuros estrenos que estén acordados pero que no sean públicos por el momento.

En primera instancia y siendo lo más importante, se ha conseguido identificar aquello que la organización trata como lo más crítico. En muchos casos, para conseguir esta información, se requerirá y se recomienda interacción con diferentes departamentos para evaluar aquello que creen que pueda parecerle importante para los servicios y funcionamiento de la organización.

Llegados a este punto y dentro de los tres bloques que se han definido en el modelo, se podría pensar que tipos de amenazas aplicarían a esta casuística por sus motivaciones y objetivos. Es muy importante hacer especial hincapié en los objetivos y motivaciones, ya que no todas las amenazas buscan lo mismo.

Para el bloque de futuros estrenos, podría ser válido un actor con motivaciones de espionaje industrial o espionaje en general, que tenga como objetivo conocer nuevos estrenos televisivos de series en la cadena. ¿Sería posible que un actor desplegara capacidades para espiar a la organización ACME? Probablemente, sí.

Para el bloque de propiedad intelectual, podría valer también un actor con motivaciones de espionaje, pero en este caso, en vez de querer conocer nuevos estrenos, su objetivo podría ser el de exfiltrar información de propiedad intelectual al público o venderla y obtener beneficios económicos por ella.

Por último, para el bloque de producción TV, podría existir una motivación hacktivista que tenga como objetivo algún tipo de protesta. Este tipo de actividades, por lo general pueden dejar sin servicio o mostrar mensajes personalizados en los canales que se emiten en directo por televisión.

Una vez se han definido las posibles motivaciones que podrían existir sobre aquello que se ha definido como crítico, puede incorporarse al modelo y relacionarlo.

El siguiente paso que hay que tomar para que siga cogiendo forma el árbol, es relacionar esas amenazas que se han introducido a alto nivel como son “hacktivistas” y “actores con motivación de espionaje” a un nivel más bajo dándole nombres y apellidos.

En esta parte entran en juego los analistas de Cyber Threat Intelligence, que con su conocimiento sobre el panorama de las amenazas que existe a día de hoy junto a sus herramientas de trabajo, podrán relacionar todos aquellos actores que lleven a cabo campañas con estas motivaciones.

Para seguir, existen dos caminos, pudiéndose tomar uno de los dos, o los dos incluso, son los siguientes.

1. Relacionar las amenazas de alto nivel con los APTs que tengan las motivaciones y actividades que hemos descrito anteriormente.

2. Relacionar las amenazas de alto nivel con actores que se hayan tratado en incidentes internos pasados. (Este punto no hay que obviarlo ya que, la inteligencia generada de manera interna con los incidentes pasados, puede dar un mejor entendimiento de las amenazas que impactan de manera directa nuestra organización)

Tal y como se ve, y a modo de ejemplo para que pueda servir de referencia, se han añadido tres APTs diferentes que han tenido como objetivo el sector Media y que además, una de sus motivaciones ha sido el espionaje, teniendo como un nivel más superior la propiedad intelectual y futuros estrenos.

Por otro lado, tenemos aquellas amenazas vinculadas con actividades hacktivistas, donde se ha relacionado con un grupo que ha realizado ataques contra nuestra organización, concretamente los incidentes número 41 y 52, para tener una mayor referencia.

El modelo crece en forma de árbol por sí sólo y de manera muy ágil, ayudando a tener una idea con simplemente un vistazo de todo aquello que puede ser un riesgo para la organización, y todo esto, con un contexto bajado a la tierra que se trata de la información crítica manejada por ACME.

El modelo puede crecer tanto como nosotros queramos hacerlo crecer. Por ejemplo, en el punto en el que se encuentra, podríamos agregar aquellas herramientas que han utilizado los diferentes actores para llevar a cabo sus ataques. De esa manera, se podrían realizar simulaciones de ataque con las mismas herramientas para ver las capacidades de detección que tiene el equipo correspondiente que identifica e investiga este tipo de sucesos.

Es cierto que si tenemos una gran cantidad de actores podría convertirse en un modelo muy grande e inmanejable, es por ello que en este punto la figura del CISO toma un papel fundamental, donde tiene que priorizar los requerimientos de inteligencia haciendo foco en un actor o dos en primer lugar, de esta manera se avanza progresivamente hasta conseguir el objetivo de minimizar al máximo posible los riesgos. Supongamos que en este caso, existe un requerimiento de obtener información sobre el APT Sofacy.

En este caso, se añaden tres bloques de capacidades utilizadas por el APT Sofacy (por supuesto, habría que añadirlas todas). De cara a una mejor simulación de actividad, es interesante añadir LOLBINS (Living Off The Land Binaries and Scripts) utilizados en sus campañas para no quedarnos únicamente en aquellas herramientas que han desarrollado por si mismo o aprovechado código de otras.

También, como se puede apreciar existe un evento vinculado donde se realizó un ataque a la cadena de televisión internacional TV5Monde de lengua francesa. Este ataque nos puede dar contexto de las motivaciones y objetivos que tuvo el grupo a nivel estratégico y, brindarnos información como puede ser TTPs y Tradecraft a nivel operacional.

Por supuesto, tal y como se comentó un poco más arriba, el modelo podría seguir creciendo si fuese necesario. Imaginando que existe un requerimiento táctico de inteligencia para realizar las operaciones lo más real posible por un red team, se solicita agregar las tácticas y técnicas de una de las capacidades que ejecuta Sofacy, quedando el modelo de la siguiente manera que se muestra a continuación.

Todo lo visto hasta aquí, se realizará en función de las necesidades de cada organización. Por lo general, no existen dos modelos iguales, incluso de dos organizaciones del mismo sector ya que, lo que para una puede resultar crítico para la otra podría no serlo.

Si el objetivo es ser proactivo ante las amenazas que puedan afectar a los intereses de una organización, el threat modeling puede ayudar a minimizar los riesgos y priorizar lo verdaderamente importante.

Espero que os haya gustado mi primera entrada!

LinkedIn: https://linkedin.com/in/joseluissm/