Il 9 luglio alle 20 ora italiana si aprirà la finestra di lancio per il nuovo Ariane6, che dallo spazioporto di Kourou, nella Guyana francese, ripartirà in orbita l’Europa. Prima però di celebrare il nuovo lanciatore europeo con un articolo dedicato, celebriamo l’ultimo lancio del Delta IV Heavy della ULA. Il 9 aprile scorso alle 18:53 ora italiana, il lanciatore statunitense e’ decollato per l’ultima volta portando in orbita un carico riservato per conto del National Reconnaissance Office. Questo lancio ci fornisce l’occasione per raccontare una storia poco conosciuta, una storia che ha per protagonisti spie, satelliti in orbita e galassie lontanissime nello spazio e nel tempo.

Il Delta IV Heavy era una lanciatore non riutilizzabile della azienda ULA (United Launch Alliance, un consorzio formato da Lockheed-Martin e Boeing), fu lanciato per la prima volta nel 2004 anche se il primo lancio non fu propriamente un successo: infatti a causa di alcuni malfunzionamento e del conseguente dello stadio principale non permisero il raggiungimento dell’orbita programmata.

Il Delta IV Heavy aveva delle dimensioni considerevoli, l’altezza era 72 metri e il diametro di 5, con 4 motori alimentati da idrogeno ed ossigeno liquido. Questa 4 motori in configurazione Heavy gli consentirono prestazioni facendolo essere il lanciatore, sulla carta, più potente per l’orbita bassa: da specifiche presentava una capacità di carico di 29 tonnellate (il Falcon Heavy di SpaceX sulla carta è più potente, ma solo se usato in configurazione expendable).

Tra i lanci più notevoli sicuramente troviamo il lancio di qualifica della capsula Orion della NASA, e il lancio della sonda Parker Solar Probe, che dal 2025 raggiungerà la distanza minima dal Sole (circa 7 milioni di chilometri) e che, anche grazie al lancio operato dal Delta IV Heavy, è l’oggetto più veloce mai costruito dell’uomo: raggiungerà nel periodo di massimo avvicinamento alla nostra stella, una velocità di 690000 km/h!

Ma la nostra storia non riguarda il lanciatore, bensì il payload, il carico che lanciatore porta in orbita. Dando un’occhiata alla lista della missioni operate con un Delta IV Heavy, notiamo che 12 lanci su 16 hanno la sigla NROL-xx con un numero progressivo; la sigla sta per National Reconnaissance Office Launch, cioè lanci eseguiti con un carico gestito dalla NRO l’agenzia federale statunitense incaricata di progettare, costruire, lanciare e gestire i satelliti da ricognizione per attività’ di intelligence (principalmente IMINT, SIGINT E MASINT).

L’ultimo lancio di cui il Delta IV Heavy è stato protagonista ha messo in orbita un satellite siglato come Orion, una classe di satelliti spia come destinati alla SIGINT, cioè la raccolta di informazioni mediante l’intercettazione di segnali (intesi sia come comunicazioni dirette tra persone sia come segnali elettromagnetici non usati direttamente nelle comunicazioni vocali). Tra i carichi che compaiono nella lista dei payload messi in orbita con il Delta IV Heavy troviamo anche i satelliti KH-11 Kennen, e sono quelli per noi più interessanti. Questi satelliti hanno un disegno molto familiare per gli appassionati di attività spaziali. Anche se il design e i dettagli tecnici delle varie classi di satelliti spia sono ovviamente classificati, dai grafici trapelati possiamo vedere che i KH-1 Kennen… sono essenzialmente l’Hubble Space Telescope. L’aspetto è davvero molto simile, e non è un caso.

Possibile layout dei satelliti KH-11 Kennen
Integrazione di Hubble presso i laboratori Lockheed

Hubble Space Telescope

L’Hubble Space Telescope, fu lanciato nel 1990, e ci ha dato modo di fare grandiose scoperte: grazie alle sue osservazioni fu prodotto l’Hubble Deep Field una delle fotografie più profonde dell’Universo. Hubble inquadrò per dieci giorni consecutivi, dal 18 al 28 dicembre 1995, una regione di cielo nella costellazione dell’Orsa Maggiore ritenuta libera da “interferenze” che potessero compromettere l’elevata risoluzione di Hubble.

In questo minuscolo angolo di cielo (2.6 minuti d’arco, equivalente ad una pallina da tennis vista a 100 metri di distanza) Hubble scoprì più di 3000 galassie, alcune distanti 12 miliardi di anni luce! Questa prima osservazione (a cui seguirono altri campi profondi, il più recente Hubble eXtreme Deep Field del 2012) si rivelò una pietra miliare nello studio dell’universo primordiale e fu possibile grazie alle straordinarie caratteristiche tecniche dell’Hubble.
Hubble Deep Field

La prima idea di un telescopio spaziale si fa risalire al 1923 quando Hermann Oberth, uno dei padri dell’astronautica, propose nel suo volume Die Rakete zu den Planetenräumen (The Rocket into Planetary Space) l’’idea di un telescopio portato nello spazio per mezzo di un missile.

Il progetto del telescopio spaziale Hubble prese forma ufficialmente con lo stanziamento dei fondi da parte del Congresso americano nel 1978, con lancio previsto per il 1983. Dopo vari sforamenti di budget e ritardi, il lancio di Hubble avvenne il 24 aprile 1990 a bordo dello Shuttle Discovery (STS-31). Dalle immagini del lancio si vede benissimo che Hubble entrava perfettamente nella baia di carico dello space shuttle. Anche questo non è un caso.

Il progetto dello Space Shuttle iniziò alla fine degli anni ’60, quando ormai il programma Apollo era avviato alla sua conclusione dopo aver raggiunto gli obiettivi tecnologici ma soprattutto politici per cui era nato: dimostrare la superiorità nei confronti dell’Unione Sovietica. L’obiettivo era la costruzione di un sistema di volo che fosse riutilizzabile almeno in parte, per poter mettere in orbita bassa carichi scientifici e non solo. Il primo volo fu quello dell’Enterprise nel 1977, e la prima missione orbitale fu la STS-1 del 12 aprile 1981 con il Columbia.

Hubble fu messo in orbita nel 1990 e come dicevamo si adattava perfettamente alla baia di carico del Columbia; questo perché il dipartimento della Difesa partecipò e “incoraggiò” moltissimo la progettazione dello Space Shuttle. In base agli accordi, il Dipartimento della Difesa contribuì con fondi, personale e conoscenza al progetto ma in cambio ottenne dalla NASA che la baia di carico dell’orbiter (la componente riutilizzabile, il velivolo che per sineddoche chiamiamo Space Shuttle) avesse caratteristiche specifiche e si adattasse alle esigenze della NRO. L’agenzia e lo spionaggio in generale furono anche protagonisti nel design di Hubble: infatti lo specchio da 2.4 m di Hubble fu ridotto dai 3 metri iniziali proprio per venire incontro alle esigenze operative della NRO, sempre in cambio di fondi e conoscenze tecniche.

La “donazione” del 2012 e i piani futuri

La “collaborazione” tra NASA e NRO è proficua, non solo relativamente alla progettazione dei KH-11 Kennen ed Hubble, ma anche per i futuri telescopi spaziali. E’ necessario però un passo indietro di una decina di anni.

Ormai in servizio dal 1990 e oggetto di numerose missioni di manutenzione (la più famosa nel 1993, per correggere difetti all’ottica) Hubble andava incontro ad un degrado di performance. Anche se la vita media operativa e le prestazioni fossero andate ben oltre le aspettative, tuttavia nei primi anni 2000 appariva chiaro che l’elettronica e i sistemi in generale non avrebbero resistito a lungo alle condizioni estreme dello spazio e le prestazioni erano in calo. Nel corso del 2011 l’NRO rese noto alla NASA la disponibilità di due satelliti spia considerati dall’agenzia troppo obsoleti per l’osservazione della Terra a fini strategici, e li mise a disposizione a patto che le ottiche non fossero usate per l’osservazione della Terra e che a Houston si pensasse in autonomia a ripristinare la parte elettronica, che per motivi facilmente intuibili fu rimossa dai satelliti.

I due satelliti furono ufficialmente donati nel 2012 e la NASA decise così di costruire sulla base di quei due satelliti i futuri telescopi per l’osservazione del cosmo. Uno dei due al momento non è stato ancora utilizzato ma si sa che l’altro è stato usato come base, in particolare le ottiche, per il telescopio rinominato Nancy Grace Roman Space Telescope (precedente noto come Wide-Field Infrared Survey Telescope o WFIRST).

Render del Nancy Grace Roman Space Telescope
Questo satellite, il cui lancio è previsto per il 2027 avrà come come obiettivo quello di rispondere ad una vasta gamma di domande tra cui la ricerca di pianeti extra solari, la scoperta eventuale dell’energia oscura, testare con maggiore precisione la Relatività Generale. Neanche a dirlo Nancy Grace Roman fu tra le principali sostenitrici del progetto Hubble: ben prima che diventasse un progetto ufficiale della NASA, Nancy Roman teneva conferenze pubbliche promuovendo il valore scientifico del telescopio. Dopo l’approvazione del progetto, divenne la scienziata responsabile del programma, organizzando il comitato direttivo incaricato di rendere fattibili le esigenze degli astronomi e scrivendo numerosi report per il Congresso americano nel corso degli anni ’70 per sostenere il continuo finanziamento del telescopio.

L'articolo Dal Delta IV Heavy allo spazio profondo. Tra spie, satelliti e galassie! proviene da il blog della sicurezza informatica.

Un ricercatore indipendente di sicurezza informatica ha rilasciato un exploit Proof-of-Concept (PoC) per sfruttare la vulnerabilità RCE CVE-2024-22274. Tale bug di sicurezza affligge la popolare utility di gestione di macchine virtuali e nodi ESXi conosciuto come VMware vCenter Server.

Panoramica della vulnerabilità

L’exploit consente ad un attore malintenzionato autenticato sulla shell dell’appliance vCenter di sfruttare questa vulnerabilità per eseguire comandi arbitrari sul sistema operativo sottostante con privilegi di “root”. Pertanto alla vulnerabilità viene assegnato un livello di gravità alto (7.2 punti sulla scala CVSSv3).

Il documento descrive la vulnerabilità CVE-2024-22274 nel software VMware vCenter. Questa vulnerabilità critica permette a un attaccante remoto non autenticato di eseguire codice arbitrario sul sistema target, sfruttando una falla nell’autenticazione del servizio vSphere Web Client. La compromissione può portare al controllo completo del sistema, con gravi implicazioni per la sicurezza dell’infrastruttura IT. Si consiglia vivamente di applicare le patch di sicurezza fornite da VMware per mitigare questa minaccia e proteggere i sistemi vulnerabili.

Mitigazione

In linea con le dichiarazioni del Vendor, si consiglia di aggiornare alla versione 7.0 U3q per quanto riguarda vCenter Server 7.0 ed alla versione 8.0 U2b per quanto riguarda vCenter Server 8.0, già sanate dallo stesso nel bollettino di sicurezza VMSA-2024-0011 pubblicato nel mese di Maggio 2024.

Attualmente non è previsto alcun workaround per mitigare la minaccia.

Si consiglia inoltre di non esporre pubblicamente le interfacce di gestione dei sistemi e di adottare il principio del privilegio minimo ,quindi di esporre solo ed esclusivamente i servizi necessari.

L'articolo L’exploit POC per l’RCE di VMware vCenter Server è ora disponibile Online! proviene da il blog della sicurezza informatica.

Detection is a traditional type of cybersecurity control, along with blocking, adjustment, administrative and other controls. Whereas before 2015 teams asked themselves what it was that they were supposed to detect, as MITRE ATT&CK evolved, SOCs were presented with practically unlimited space for ideas on creating detection scenarios.

With the number of scenarios becoming virtually unlimited, another question inevitably arises: “What do we detect first?” This and the fact that SOC teams forever play the long game, having to respond with limited resources to a changing threat landscape, evolving technology and increasingly sophisticated malicious actors, makes managing efforts to develop detection logic an integral part of any modern SOC’s activities.

The problem at hand is easy to put into practical terms: the bulk of the work done by any modern SOC – with the exception of certain specialized SOC types – is detecting, and responding to, information security incidents. Detection is directly associated with preparation of certain algorithms, such as signatures, hard-coded logic, statistical anomalies, machine learning and others, that help to automate the process. The preparation consists of at least two processes: managing detection scenarios and developing detection logic. These cover the life cycle, stages of development, testing methods, go-live, standardization, and so on. These processes, like any others, require certain inputs: an idea that describes the expected outcome at least in abstract terms.

This is where the first challenges arise: thanks to MITRE ATT&CK, there are too many ideas. The number of described techniques currently exceeds 200, and most are broken down into several sub-techniques – MITRE T1098 Account Manipulation, for one, contains six sub-techniques – while SOC’s resources are limited. Besides, SOC teams likely do not have access to every possible source of data for generating detection logic, and some of those they do have access to are not integrated with the SIEM system. Some sources can help with generating only very narrowly specialized detection logic, whereas others can be used to cover most of the MITRE ATT&CK matrix. Finally, certain cases require activating extra audit settings or adding selective anti-spam filtering. Besides, not all techniques are the same: some are used in most attacks, whereas others are fairly unique and will never be seen by a particular SOC team. Thus, setting priorities is both about defining a subset of techniques that can be detected with available data and about ranking the techniques within that subset to arrive at an optimized list of detection scenarios that enables detection control considering available resources and in the original spirit of MITRE ATT&CK: discovering only some of the malicious actor’s atomic actions is enough for detecting the attack.

A slight detour. Before proceeding to specific prioritization techniques, it is worth mentioning that this article looks at options based on tools built around the MITRE ATT&CK matrix. It assesses threat relevance in general, not in relation to specific organizations or business processes. Recommendations in this article can be used as a starting point for prioritizing detection scenarios. A more mature approach must include an assessment of a landscape that consists of security threats relevant to your particular organization, an allowance for your own threat model, an up-to-date risk register, and automation and manual development capabilities. All of this requires an in-depth review, as well as liaison between various processes and roles inside your SOC. We offer more detailed maturity recommendations as part of our SOC consulting services.

MITRE Data Sources

Optimized prioritization of the backlog as it applies to the current status of monitoring can be broken down into the following stages:

• Defining available data sources and how well they are connected;
• Identifying relevant MITRE ATT&CK techniques and sub-techniques;
• Finding an optimal relation between source status and technique relevance;
• Setting priorities.

A key consideration in implementing this sequence of steps is the possibility of linking information that the SOC receives from data sources to a specific technique that can be detected with that information. In 2021, MITRE completed its ATT&CK Data Sources project, its result being a methodology for describing a data object that can be used for detecting a specific technique. The key elements for describing data objects are:

• Data Source: an easily recognizable name that defines the data object (Active Directory, application log, driver, file, process and so on);
• Data Components: possible data object actions, statuses and parameters. For example, for a file data object, data components are file created, file deleted, file modified, file accessed, file metadata, and so on.

MITRE Data Sources

Virtually every technique in the MITRE ATT&CK matrix currently contains a Detection section that lists data objects and relevant data components that can be used for creating detection logic. A total of 41 data objects have been defined at the time of publishing this article.

MITRE most relevant data components

The column on the far right in the image above (Event Logs) illustrates the possibilities of expanding the methodology to cover specific events received from real data sources. Creating a mapping like this is not one of the ATT&CK Data Sources project goals. This Event Logs example is rather intended as an illustration. On the whole, each specific SOC is expected to independently define a list of events relevant to its sources, a fairly time-consuming task.

To optimize your approach to prioritization, you can start by isolating the most frequent data components that feature in most MITRE ATT&CK techniques.

The graph below presents the up-to-date top 10 data components for MITRE ATT&CK matrix version 15.1, the latest at the time of writing this.

The most relevant data components (download)

For these data components, you can define custom sources for the most results. The following will be of help:

• Expert knowledge and overall logic. Data objects and data components are typically informative enough for the engineer or analyst working with data sources to form an initial judgment on the specific sources that can be used.
• Validation directly inside the event collection system. The engineer or analyst can review available sources and match events with data objects and data components.
• Publicly available resources on the internet, such as Sensor Mappings to ATT&CK, a project by the Center for Threat-Informed Defense, or this excellent resource on Windows events: UltimateWindowsSecurity.

That said, most sources are fairly generic and typically connected when a monitoring system is implemented. In other words, the mapping can be reduced to selecting those sources which are connected in the corporate infrastructure or easy to connect.

The result is an unranked list of integrated data sources that can be used for developing detection logic, such as:

• For Command Execution: OS logs, EDR, networked device administration logs and so on;
• For Process Creation: OS logs, EDR;
• For Network Traffic Content: WAF, proxy, DNS, VPN and so on;
• For File Modification: DLP, EDR, OS logs and so on.

However, this list is not sufficient for prioritization. You also need to consider other criteria, such as:

• The quality of source integration. Two identical data sources may be integrated with the infrastructure differently, with different logging settings, one source being located only in one network segment, and so on.
• Usefulness of MITRE ATT&CK techniques. Not all techniques are equally useful in terms of optimization. Some techniques are more specialized and aimed at detecting rare attacker actions.
• Detection of the same techniques with several different data sources (simultaneously). The more options for detecting a technique have been configured, the higher the likelihood that it will be discovered.
• Data component variability. A selected data source may be useful for detecting not only those techniques associated with the top 10 data components but others as well. For example, an OS log can be used for detecting both Process Creation components and User Account Authentication components, a type not mentioned on the graph.

Prioritizing with DeTT&CT and ATT&CK Navigator

Now that we have an initial list of data sources available for creating detection logic, we can proceed to scoring and prioritization. You can automate some of this work with the help of DeTT&CT, a tool created by developers unaffiliated with MITRE to help SOCs with using MITRE ATT&CK for scoring and comparing the quality of data sources, coverage and detection scope according to MITRE ATT&CK techniques. The tool is available under the GPL-3.0 license.

DETT&CT supports an expanded list of data sources as compared to the MITRE model. This list is implemented by design and you do not need to redefine the MITRE matrix itself. The expanded model includes several data components, which are parts of MITRE’s Network Traffic component, such as Web, Email, Internal DNS, and DHCP.

You can install DETT&CT with the help of two commands: git clone and pip install -r. This gives you access to DETT&CT Editor: a web interface for describing data sources, and DETT&CT CLI for automated analysis of prepared input data that can help with prioritizing detection logic and more.

The first step in identifying relevant data sources is describing these. Go to Data Sources in DETT&CT Editor, click New file and fill out the fields:

• Domain: the version of the MITRE ATT&CK matrix to use (enterprise, mobile or ICS).
• This field is not used in analytics; it is intended for distinguishing between files with the description of sources.
• Systems: selection of platforms that any given data source belongs to. This helps to both separate platforms, such as Windows and Linux, and specify several platforms within one system. Going forward, keep in mind that a data source is assigned to a system, not a platform. In other words, if a source collects data from both Windows and Linux, you can leave one system with two platforms, but if one source collects data from Windows only, and another, from Linux only, you need to create two systems: one for Windows and one for Linux.

After filling out the general sections, you can proceed to analyzing data sources and mapping to the MITRE Data Sources. Click Add Data Source for each MITRE data object and fill out the relevant fields. Follow the link above for a detailed description of all fields and example content on the project page. We will focus on the most interesting field: Data quality. It describes the quality of data source integration as determined according to five criteria:

• Device completeness. Defines infrastructure coverage by the source, such as various versions of Windows or subnet segments, and so on.
• Data field completeness. Defines the completeness of data in events from the source. For example, information about Process Creation may be considered incomplete if we see that a process was created, but not the details of the parent process, or for Command Execution, we see the command but not the arguments, and so on.
• Defines the presence of a delay between the event happening and being added to a SIEM system or another detection system.
• Defines the extent to which the names of the data fields in an event from this source are consistent with standard naming.
• Compares the period for which data from the source is available for detection with the data retention policy defined for the source. For instance, data from a certain source is available for one month, whereas the policy or regulatory requirements define the retention period as one year.

A detailed description of the scoring system for filling out this field is available in the project description.

It is worth mentioning that at this step, you can describe more than just the top 10 data components that cover the majority of the MITRE ATT&CK techniques. Some sources can provide extra information: in addition to Process Creation, Windows Security Event Log provides data for User Account Authentication. This extension will help to analyze the matrix without limitations in the future.

After describing all the sources on the list defined earlier, you can proceed to analyze these with reference to the MITRE ATT&CK matrix.

The first and most trivial analytical report identifies the MITRE ATT&CK techniques that can be discovered with available data sources one way or another. This report is generated with the help of a configuration file with a description of data sources and DETT&CT CLI, which outputs a JSON file with MITRE ATT&CK technique coverage. You can use the following command for this:
python dettect.py ds -fd <data-source-yaml-dir>/<data-sources-file.yaml> -l
The resulting JSON is ready to be used with the MITRE ATT&CK matrix visualization tool, MITRE ATT&CK Navigator. See below for an example.

MITRE ATT&CK coverage with available data sources

This gives a literal answer to the question of what techniques the SOC can discover with the set of data sources that it has. The numbers in the bottom right-hand corner of some of the cells reflect sub-technique coverage by the data sources, and the colors, how many different sources can be used to detect the technique. The darker the color, the greater the number of sources.

DETT&CT CLI can also generate an XLSX file that you can conveniently use as the integration of existing sources evolves, a parallel task that is part of the data source management process. You can use the following command to generate the file:
python dettect.py ds -fd <data-source-yaml-dir>/<data-sources-file.yaml> -e
The next analytical report we are interested in assesses the SOC’s capabilities in terms of detecting MITRE ATT&CK techniques and sub-techniques while considering the scoring of integrated source quality as done previously. You can generate the report by running the following command:
python dettect.py ds -fd <data-source-yaml-dir>/<data-sources-file.yaml> --yaml
This generates a DETT&CT configuration file that both contains matrix coverage information and considers the quality of the data sources, providing a deeper insight into the level of visibility for each technique. The report can help to identify the techniques for which the SOC in its current shape can achieve the best results in terms of completeness of detection and coverage of the infrastructure.

This information too can be visualized with MITRE ATT&CK Navigator. You can use the following DETT&CT CLI command for this:
python dettect.py v -ft output/<techniques-administration-file.yaml> -l
See below for an example.

MITRE ATT&CK coverage with available sources considering their quality

For each technique, the score is calculated as an average of all relevant data source scores. For each data source, it is calculated from specific parameters. The following parameters have increased weight:

• Device completeness;
• Data field completeness;
• Retention.

To set up the scoring model, you need to modify the project source code.

It is worth mentioning that the scoring system presented by the developers of DETT&CT tends to be fairly subjective in some cases, for example:

• You may have one data source out of the three mentioned in connection with the specific technique. However, in some cases, one data source may not be enough even to detect the technique on a minimal level.
• In other cases, the reverse may be true, with one data source giving exhaustive information for complete detection of the technique.
• Detection may be based on a data source that is not currently mentioned in the MITRE ATT&CK Data Sources or Detections for that particular technique.

In these cases, the DETT&CT configuration file techniques-administration-file.yaml can be adjusted manually.

Now that the available data sources and the quality of their integration have been associated with the MITRE ATT&CK matrix, the last step is ranking the available techniques. You can use the Procedure Examples section in the matrix, which defines the groups that use a specific technique or sub-technique in their attacks. You can use the following DETT&CT command to run the operation for the entire MITRE ATT&CK matrix:
python dettect.py g
In the interests of prioritization, we can merge the two datasets (technique feasibility considering available data sources and their quality, and the most frequently used MITRE ATT&CK techniques):
python dettect.py g -p PLATFORM -o output/<techniques-administration-
file.yaml> -t visibility
The result is a JSON file containing techniques that the SOC can work with and their description, which includes the following:

• Detection ability scoring;
• Known attack frequency scoring.

See the image below for an example.

Technique frequency and detection ability

As you can see in the image, some of the techniques are colored shades of red, which means they have been used in attacks (according to MITRE), but the SOC has no ability to detect them. Other techniques are colored shades of blue, which means the SOC can detect them, but MITRE has no data on these techniques having been used in any attacks. Finally, the techniques colored shades of orange are those which groups known to MITRE have used and the SOC has the ability to detect.

It is worth mentioning that groups, attacks and software used in attacks, which are linked to a specific technique, represent retrospective data collected throughout the period that the matrix has existed. In some cases, this may result in increased priority for techniques that were relevant for attacks, say, from 2015 through 2020, which is not really relevant for 2024.

However, isolating a subset of techniques ever used in attacks produces more meaningful results than simple enumeration. You can further rank the resulting subset in the following ways:

• By using the MITRE ATT&CK matrix in the form of an Excel table. Each object (Software, Campaigns, Groups) contains the property Created (date when the object was created) that you can rely on when isolating the most relevant objects and then use the resulting list of relevant objects to generate an overlap as described above:
  python dettect.py g -g sample-data/groups.yaml -p PLATFORM -o
  output/<techniques-administration-file.yaml> -t visibility
• By using the TOP ATT&CK TECHNIQUES project created by MITRE Engenuity.

TOP ATT&CK TECHNIQUES was aimed at developing a tool for ranking MITRE ATT&CK techniques and accepts similar inputs to DETT&CT. The tool produces a definition of 10 most relevant MITRE ATT&CK techniques for detecting with available monitoring capabilities in various areas of the corporate infrastructure: network communications, processes, the file system, cloud-based solutions and hardware. The project also considers the following criteria:

• Choke Points, or specialized techniques where other techniques converge or diverge. Examples of these include T1047 WMI, as it helps to implement a number of other WMI techniques, or T1059 Command and Scripting Interpreter, as many other techniques rely on a command-line interface or other shells, such as PowerShell, Bash and others. Detecting this technique will likely lead to discovering a broad spectrum of attacks.
• Prevalence: technique frequency over time.

MITRE ATT&CK technique ranking methodology in TOP ATT&CK TECHNIQUES

Note, however, that the project is based on MITRE ATT&CK v.10 and is not supported.

Finalizing priorities

By completing the steps above, the SOC team obtains a subset of MITRE ATT&CK techniques that feature to this or that extent in known attacks and can be detected with available data sources, with an allowance for the way these are configured in the infrastructure. Unfortunately, DETT&CT does not offer any way of creating a convenient XLSX file with an overlap between techniques used in attacks and those that the SOC can detect. However, we have a JSON file that can be used to generate the overlap with the help of MITRE ATT&CK Navigator. So, all you need to do for prioritization is to parse the JSON, say, with the help of Python. The final prioritization conditions may be as follows:

• Priority 1 (critical): Visibility_score >= 3 and Attacker_score >= 75. From an applied perspective, this isolates MITRE ATT&CK techniques that most frequently feature in attacks and that the SOC requires minimal or no preparation to detect.
• Priority 2 (high): (Visibility_score < 3 and Visibility_score >= 1) and Attacker_score >= 75. These are MITRE ATT&CK techniques that most frequently feature in attacks and that the SOC is capable of detecting. However, some work on logging may be required, or monitoring coverage may not be good enough.
• Priority 3 (medium): Visibility_score >= 3 and Attacker_score < 75. These are MITRE ATT&CK techniques with medium to low frequency that the SOC requires minimal or no preparation to detect.
• Priority 4 (low): (Visibility_score < 3 and Visibility_score >= 1) and Attacker_score < 75. These are all other MITRE ATT&CK techniques that feature in attacks and the SOC has the capability to detect.

As a result, the SOC obtains a list of MITRE ATT&CK techniques ranked into four groups and mapped to its capabilities and global statistics on malicious actors’ actions in attacks. The list is optimized in terms of the cost to write detection logic and can be used as a prioritized development backlog.

Prioritization extension and parallel tasks

In conclusion, we would like to highlight the key assumptions and recommendations for using the suggested prioritization method.

• As mentioned above, it is not fully appropriate to use the MITRE ATT&CK statistics on the frequency of techniques in attacks. For more mature prioritization, the SOC team must rely on relevant threat data. This requires defining a threat landscape based on analysis of threat data, mapping applicable threats to specific devices and systems, and isolating the most relevant techniques that may be used against a specific system in the specific corporate environment. An approach like this calls for in-depth analysis of all SOC activities and links between processes. Thus, when generating a scenario library for a customer as part of our consulting services, we leverage Kaspersky Threat Intelligence data on threats relevant to the organization, Managed Detection and Response statistics on detected incidents, and information about techniques that we obtained while investigating real-life incidents and analyzing digital evidence as part of Incident Response service.
• The suggested method relies on SOC capabilities and essential MITRE ATT&CK analytics. That said, the method is optimized for effort reduction and helps to start developing relevant detection logic immediately. This makes it suitable for small-scale SOCs that consist of a SIEM administrator or analyst. In addition to this, the SOC builds what is essentially a detection functionality roadmap, which can be used for demonstrating the process, defining KPIs and justifying a need for expanding the team.

Lastly, we introduce several points regarding the possibilities for improving the approach described herein and parallel tasks that can be done with tools described in this article.

You can use the following to further improve the prioritization process.

• Grouping by detection. On a basic level, there are two groups: network detection or detection on a device. Considering the characteristics of the infrastructure and data sources in creating detection logic for different groups helps to avoid a bias and ensure a more complete coverage of the infrastructure.
• Grouping by attack stage. Detection at the stage of Initial Access requires more effort, but it leaves more time to respond than detection at the Exfiltration stage.
• Criticality coefficient. Certain techniques, such as all those associated with vulnerability exploitation or suspicious PowerShell commands, cannot be fully covered. If this is the case, the criticality level can be used as an additional criterion.
• Granular approach when describing source quality. As mentioned earlier, DETT&CT helps with creating quality descriptions of available data sources, but it lacks exception functionality. Sometimes, a source is not required for the entire infrastructure, or there is more than one data source providing information for similar systems. In that case, a more granular approach that relies on specific systems, subnets or devices can help to make the assessment more relevant. However, an approach like that calls for liaison with internal teams responsible for configuration changes and device inventory, who will have to at least provide information about the business criticality of assets.

Besides improving the prioritization method, the tools suggested can be used for completing a number of parallel tasks that help the SOC to evolve.

• Expanding the list of sources. As shown above, the coverage of the MITRE ATT&CK matrix requires diverse data sources. By mapping existing sources to techniques, you can identify missing logs and create a roadmap for connecting or introducing these sources.
• Improving the quality of sources. Scoring the quality of data sources can help create a roadmap for improving existing sources, for example in terms of infrastructure coverage, normalization or data retention.
• Detection tracking. DETT&CT offers, among other things, a detection logic scoring feature, which you can use to build a detection scenario revision process.

securelist.com/detection-engin…

Nel luglio 2024, Field Effect ha scoperto una campagna di attacchi “Adversary-in-the-Middle” (AiTM) rivolta a Microsoft 365 (M365). Questo tipo di attacco compromette le email aziendali (BEC) utilizzando tecniche avanzate per intercettare e dirottare le credenziali degli utenti durante il processo di autenticazione.

Metodo di Attacco

1. Osservazione Iniziale: L’analisi ha rivelato l’uso sospetto della stringa user agent ‘axios/1.7.2’, associata a tentativi di accesso da ISP noti per attività malevole.
2. Strumento Utilizzato – Axios: Axios è un client HTTP legittimo per browser e node.js, sfruttato dagli attaccanti per imitare le richieste di login degli utenti legittimi. Axios permette di intercettare, trasformare e cancellare richieste e risposte HTTP, facilitando il furto delle credenziali.
3. Origine degli Attacchi: Molte richieste provenivano da Hostinger International Limited e Global Internet Solutions LLC, spesso utilizzati da attori malevoli russi.
4. Compromissione MFA: Gli attaccanti hanno superato l’autenticazione a più fattori (MFA), suggerendo l’accesso non solo alle password ma anche ai codici MFA degli utenti. Questo è stato possibile tramite l’intercettazione dei token di autenticazione durante il processo di login.

Catena di Attacco

1. Phishing: Le vittime ricevevano email di phishing che le inducevano a visitare domini malevoli. Questi domini presentavano pagine di login M365 fasulle costruite con Axios, progettate per apparire autentiche.
2. Raccolta delle Credenziali: Quando l’utente inseriva le proprie credenziali sulla pagina fasulla, Axios le intercettava e le utilizzava per autenticarsi sulla vera pagina M365 in tempo reale.
3. Dirottamento delle Sessioni: Gli attaccanti utilizzavano le credenziali raccolte e i token di sessione per accedere agli account delle vittime, aggirando l’MFA. Questo permetteva loro di accedere alle email e ai dati sensibili dell’azienda.

Tecniche Specifiche Utilizzate

1. Imitazione delle Richieste HTTP: Gli attaccanti utilizzavano Axios per creare richieste HTTP che imitavano quelle degli utenti legittimi, consentendo loro di intercettare le credenziali senza destare sospetti.
2. Intercettazione in Tempo Reale: Axios permetteva agli attaccanti di intercettare le credenziali in tempo reale, facendole passare dalla pagina fasulla al sito legittimo di M365. Questo includeva anche la cattura dei token MFA, permettendo loro di autenticarsi come se fossero l’utente legittimo.
3. Utilizzo di ISP Malevoli: Gli attaccanti sfruttavano ISP noti per attività malevole per mascherare la loro origine e rendere più difficile l’identificazione delle attività sospette.
4. Phishing Avanzato: Le email di phishing erano progettate per sembrare comunicazioni legittime da M365, aumentando la probabilità che le vittime inserissero le proprie credenziali senza sospetti.

Indicatori di Compromissione (IoC)

• User Agent Strings:
  
  • axios/1.7.2
  • axios/1.7.1
  • axios/1.6.8
  • BAV2ROPC

  
  

• Fornitori di Hosting:
  
  • Hostinger International Limited (AS47583)
  • Global Internet Solutions LLC (AS207713)

  
  

• Domini di Phishing:
  
  • lsj.logentr[.]com
  • okhyg.unsegin[.]com
  • ldn3.p9j32[.]com

  
  

• Indirizzi IP:
  
  • 141.98.233[.]86
  • 154.56.56[.]200
  • e molti altri elencati nel rapporto.

  
  

Mitigazione e Difesa

1. Monitoraggio dei Log: Ricercare tentativi di login con gli IoC sopra elencati.
2. Rotazione delle Credenziali: Uscire dai sistemi compromessi e cambiare le credenziali.
3. Implementazione MFA: Assicurarsi che MFA sia attivo su tutti gli account e monitorare le anomalie.
4. Formazione sul Phishing: Educare i dipendenti a riconoscere email di phishing e a non inserire credenziali in siti sospetti.

Conclusione

Questa campagna di attacchi AiTM su M365 dimostra la crescente sofisticazione delle tecniche di BEC. La difesa richiede un approccio integrato che includa il monitoraggio continuo delle attività sospette e l’educazione degli utenti sulle minacce di phishing. Implementare rigorose misure di sicurezza e rimanere vigili sono essenziali per proteggere le infrastrutture aziendali da tali minacce.

L'articolo Attacco “Adversary-in-the-Middle” su Microsoft 365 proviene da il blog della sicurezza informatica.

NetScaler ADC (precedentemente Citrix ADC) e il NetScaler Gateway (precedentemente Citrix Gateway) sono soluzioni consolidate per la distribuzione di applicazioni e l’accesso sicuro alle risorse aziendali. Questi dispositivi sono ampiamente utilizzati per migliorare le prestazioni delle applicazioni e garantire un accesso controllato e sicuro ai dati sensibili.

Sono state identificate due vulnerabilità critiche in NetScaler ADC e NetScaler Gateway. Le Versioni Interessate Le seguenti versioni supportate di NetScaler ADC e NetScaler Gateway sono vulnerabili:

• NetScaler ADC e NetScaler Gateway 14.1 prima della versione 14.1-25.53
• NetScaler ADC e NetScaler Gateway 13.1 prima della versione 13.1-53.17
• NetScaler ADC e NetScaler Gateway 13.0 prima della versione 13.0-92.31
• NetScaler ADC 13.1-FIPS prima della versione 13.1-37.183
• NetScaler ADC 12.1-FIPS prima della versione 12.1-55.304
• NetScaler ADC 12.1-NDcPP prima della versione 12.1-55.304

Nota: La versione 12.1 di NetScaler ADC e NetScaler Gateway è ora End Of Life (EOL) e pertanto vulnerabile. Si consiglia ai clienti di aggiornare i loro dispositivi alle versioni supportate.

Sommario delle Vulnerabilità NetScaler ADC e NetScaler Gateway presentano le seguenti vulnerabilità:

• CVE-2024-5491: Vulnerabilità di Denial of Service che colpisce gli appliance ADC o Gateway configurati con SNMP (NSIP/SNIP).
  
  • CWE: Improrer restriction delle operazioni all’interno dei limiti di un buffer di memoria
  • Punteggio Base CVSS v4.0: 7.1

  
  

• CVE-2024-5492: Vulnerabilità di reindirizzamento aperto che consente a un attaccante remoto e non autenticato di reindirizzare gli utenti verso siti web arbitrari.
  
  • CWE: Reindirizzamento URL verso siti non attendibili (‘Open Redirect’)
  • Punteggio Base CVSS v4.0: 5.1

  
  

Azioni Consigliate per i Clienti Cloud Software Group consiglia vivamente ai clienti interessati di NetScaler ADC e NetScaler Gateway di installare immediatamente le versioni aggiornate pertinenti:

• NetScaler ADC e NetScaler Gateway versione 14.1-25.53 e successive
• NetScaler ADC e NetScaler Gateway versione 13.1-53.17 e successive di 13.1
• NetScaler ADC e NetScaler Gateway versione 13.0-92.31 e successive di 13.0
• NetScaler ADC versione 13.1-FIPS 13.1-37.183 e successive
• NetScaler ADC versione 12.1-FIPS 12.1-55.304 e successive
• NetScaler ADC versione 12.1-NDcPP 12.1-55.304 e successive

Cloud Software Group desidera esprimere gratitudine nei confronti di Nanyu Zhong di VARAS@IIE e di Mauro Dini per il loro prezioso contributo nel garantire la sicurezza dei clienti Citrix.

Nel frattempo, Citrix sta informando attivamente i propri clienti e partner riguardo a queste importanti questioni di sicurezza tramite un bollettino pubblicato sul Citrix Knowledge Center, accessibile al seguente indirizzo: support.citrix.com/securitybul….

L'articolo Citrix Netscaler ADC e Gateway afflitti da una grave falla di DOS e Open Redirect proviene da il blog della sicurezza informatica.

@Notizie dall'Italia e dal mondo

A Rio de Janeiro si è recentemente svolto il corso “I Caschi Blu della Cultura. Il Patrimonio Culturale in caso di catastrofe: rischi e interventi di sicurezza””. La giornata conclusiva si è tenuta il 2 luglio al Paço Imperial (Palazzo Imperial).

I "caschi blu della cultura" sono una idea italiana, sviluppatasi sin dal 2016 nell’ambito della campagna #Unite4Heritage. Il governo italiano e l’Unesco siglarono un memorandum d’intesa per la creazione di una task force di sessanta unità, composta da carabinieri, storici dell’arte, studiosi e restauratori, pronti a intervenire per salvaguardare il patrimonio culturale in zone di crisi. Con Decreto firmato il 31 marzo 2022 dal Ministro della Cultura pro–tempore Franceschini fu perfezionata la Task Force, formalmente denominata “Caschi Blu della Cultura”, unità operativa concepita per intervenire in aree colpite da emergenze, quali calamità o crisi prodotte dall’uomo, in una cornice di sicurezza, al fine di: – salvaguardare i siti archeologici, i luoghi della cultura ed i beni culturali; – contrastare il traffico internazionale di beni culturali illecitamente sottratti; – supportare l’Autorità dei Paesi esteri richiedenti, nella predisposizione di misure atte a limitare i rischi che situazioni di crisi o emergenziali potrebbero arrecare al patrimonio culturale di quella Nazione. L' #Armadeicarabinieri – con personale tratto dal Comando Tutela Patrimonio Culturale (#TPC) assegnato al Ministero della Cultura – hanno la gestione operativa–logistica delle missioni.

Tornando al corso in Brasile, questo è stato realizzato dall’Organizzazione Internazionale Italo-Latino Americana (#IILA), con il finanziamento della Direzione Generale per la Cooperazione allo Sviluppo del Ministero degli Affari Esteri e della Cooperazione Internazionale (#MAECI), in collaborazione con il Ministero della Cultura italiano (#MIC), il Comando Carabinieri Tutela Patrimonio Culturale e, da parte brasiliana, con il Ministério das Relações Exteriores, Ministerio da Cultura, Centro Lucio Costa, IPHAN – Instituto do Patrimônio Histórico e Artístico Nacional, SBM – Sistema Brasiliero de Museus, IBRAM – Instituto Brasileiro de Museus, Instituto Guimarães Rosa, #PoliciaFederal e #INTERPOL Brasil. Hanno partecipato 55 funzionari pubblici latinoamericani, provenienti da forze di polizia, forze armate, protezione civile e vigile del fuoco, Ministero della Cultura oltre a restauratori e conservatori di beni culturali, per formare di una task force italo-latinoamericana per la protezione del patrimonio culturale

Tra gli altri intervenuti alla giornata finale il Generale D. Francesco Gargaro, Comandante Carabinieri Tutela Patrimonio Culturale; Paolo Iannelli, Rappresentante del MIC – Caschi Blu della Cultura; Marcos Moreira Nizio, Capo del Settore Protezione del Patrimonio storico e culturale della Polizia Federale brasiliana.

Il Generale Gargaro (foto sopra) ha dichiarato nella circostanza:“Il corso che oggi si conclude è stato concepito per dotarvi degli strumenti necessari per affrontare queste sfide. Attraverso questo confronto tra diverse esperienze si sono volute trasmettere competenze tecniche e operative che permetteranno di intervenire sempre più efficacemente in situazioni di emergenza. Avete imparato l’importanza dell’identificazione e catalogazione dei beni culturali anche in situazioni emergenziali, della collaborare con le comunità locali e con le diverse istituzioni in contesti complessi. In un’epoca in cui i conflitti, crisi e catastrofi naturali minacciano di cancellare la memoria storica e culturale dei popoli, l’importanza del nostro lavoro non può essere sottovalutata. La distruzione di beni culturali non è solo una perdita per le comunità direttamente coinvolte, ma per tutta l’umanità.
È la cancellazione della nostra storia condivisa, delle nostre identità e dei valori che ci uniscono come esseri umani”.

La missione addestrativa, tenuta dal 24 giugno al 2 luglio 2024 da esperti italiani del Ministero della Cultura e del Comando Carabinieri Tutela del Patrimonio Culturale, ha voluto trasmettere ai paesi partecipanti quali Brasile, Cile, Colombia e Paraguay il modello italiano di tutela del patrimonio culturale attraverso sessioni teoriche ed esercitazioni pratiche, tra cui la simulazione di una inondazione e un focus rivolto alla sicurezza di beni archivistici e librari in ragione delle esigenze di tutela del territorio ospitante.

Durante la consegna dei diplomi, la Segretaria Generale dell'Organizzazione internazionale italo-latino americana Cavallari, nel ringraziare tutte le istituzioni partners che hanno reso possibile il successo del corso, ha sottolineato che l’obiettivo principale dell’IILA è proprio quello di stimolare la reciproca conoscenza e integrazione fra i paesi membri. Il programma addestrativo di quest’anno, come quello realizzato nel giugno 2023 a Città del Messico con la partecipazione di esperti di Bolivia, Costa Rica, Ecuador, Guatemala, Messico, Perù e Repubblica Dominicana, ha conseguito l’obiettivo di promuovere la condivisione di esperienze e buone pratiche per la possibile creazione di Caschi Blu della Cultura in Brasile, Colombia, Cile e Paraguay.

Importante infine sottolineare come la partecipazione dei carabinieri esalta il loro ruolo nella difesa a livello internazionale del patrimonio culturale italiano e mondiale: ruolo che l’Arma svolge nella protezione dei beni culturali da più di cinque decenni .

@Notizie dall'Italia e dal mondo

Anche la #PoliziadiStato italiana (a mezzo del Servizio Polizia Postale e per la Sicurezza Cibernetica) ha partecipato al Referral Action Day di #Europol mirato ad identificare e combattere i contenuti antisemiti online (a sua volta mediante l'Unità europea per le segnalazioni su Internet denominata EU IRU - Internet Referral Unit - che rileva e indaga sui contenuti dannosi presenti su Internet e nei social media).

Si è trattato di una operazione coordinata, guidata dalle autorità di Svizzera e Regno Unito, svoltasi il 27 giugno scorso, che ha coinvolto le forze dell'ordine di 18 paesi (leggi nora a conclusione), che hanno lavorato in tandem come cennato all'Unità EU IRU di Europol e i principali fornitori di servizi online.

Il Referral Action Day ha preso di mira un'ampia gamma di contenuti antisemiti, tra cui incitamento all'odio, negazione dell'Olocausto e glorificazione della violenza contro la comunità ebraica. L'obiettivo principale era rimuovere i contenuti illegali e garantire che le piattaforme online aderissero alle normative europee in materia di incitamento all'odio e discriminazione.

In totale, sono stati identificati e segnalati circa 2.000 contenuti antisemiti ai fornitori di servizi online per la rimozione.

Il focus del Referral Action Day nasce dall'aumento di un antisemitismo diffuso, giustificato e coltivato nelle sfere jihadiste e nei gruppi estremisti di destra e di sinistra online. Questo contenuto antisemita viene diffuso anche da individui non affiliati su varie piattaforme online. A quanto è risultato la ondata di discorsi d'odio è stata innescata dall'attacco del 7 ottobre dell'organizzazione terroristica Hamas contro Israele e dalla successiva risposta militare israeliana.

Le National Internet Referral Unit e le unità di polizia specializzate dei seguenti paesi hanno preso parte a questo Referral Action Day: Albania, Austria, Bosnia-Erzegovina, Danimarca, Francia, Germania, Ungheria, Irlanda,Italia, Lituania, Malta, Portogallo, Romania, Spagna, Svezia, Svizzera, Ucraina e Regno Unito.
#EUIRU