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.

Around 2010 or so, Samsung cameras came with an online service: Social Network Services. It enabled pictures to be unloaded wirelessly to social media with minimum hassle, which back then wasn’t quite as easily accomplished as it is today. Sadly they shuttered the service in 2021, leaving that generation of cameras, like so many connected devices, orphaned. Now along comes [Ge0rG] with a replacement, replicating the API on a $20 LTE dongle.

The dongle in question is one we featured a couple of years ago, packing a Linux-capable computer of similar power to a Raspberry Pi Zero alongside its cell modem. The camera can connect to the device, and a photo can be sent in a Mastodon post. It’s something of a modern version of the original, but for owners of the affected cameras it’s a useful recovery of a lost service.

It’s surprising in a way that we’ve not heard more of these dongles, as they do represent a useful opportunity. That we haven’t should be seen as a measure of the success of the Raspberry Pi and other boards like it, just as it’s no longer worth hacking old routers for Linux hardware projects, so there’s less of a need to do the same here.

On 22 May, the Coalition for Open Digital Ecosystems (CODE) hosted "CODE Talks: A More Competitive Europe Starts with Open Digital Ecosystems."

euractiv.com/section/digital/v…

Gli esperti del centro di ricerca sulle minacce informatiche Solar 4RAYS del Solar Group hanno parlato di una serie di attacchi da parte del gruppo di hacker filogovernativo Lifting Zmiy, mirati ad agenzie governative russe e aziende private. Gli aggressori hanno posizionato i loro server di controllo su apparecchiature hackerate che fanno parte dei sistemi SCADA utilizzati, ad esempio, per controllare gli ascensori.

Gli esperti si sono imbattuti per la prima volta in questo gruppo alla fine del 2023, quando uno dei canali Telegram filo-ucraini ha pubblicato informazioni sull’hacking di un’organizzazione statale russa. Gli esperti hanno partecipato alle indagini su questo attacco contro un anonimo appaltatore IT di un’organizzazione governativa russa e nei sei mesi successivi hanno studiato altri tre incidenti, anch’essi associati alle attività di Lifting Zmiy.

Lo schema degli hacker si ripete di attacco in attacco: la penetrazione iniziale è stata effettuata indovinando le password, poi gli aggressori hanno preso piede nel sistema e hanno sviluppato l’attacco principalmente utilizzando vari strumenti open source, tra cui:

• Reverse SSH – shell inversa per la gestione dei sistemi infetti e la fornitura di payload aggiuntivi;
• Backdoor SSH – per intercettare le password per le sessioni di accesso remoto;
• GSocket – un’utilità per creare una connessione remota a un sistema attaccato, aggirando alcune soluzioni di sicurezza.

Strumenti e tattiche di Lifting Zmiy in diversi attacchi
L’utilizzo di questo software accomuna tutti gli attacchi Lifting Zmiy studiati, nonché l’ubicazione dei server di controllo: gli aggressori li hanno posizionati sui controller del produttore russo Tekon-Avtomatika, che servono al controllo e all’invio, comprese le apparecchiature degli ascensori.

In totale sono stati scoperti più di una dozzina di dispositivi infetti e al momento della pubblicazione dello studio otto di essi erano ancora in uno stato di compromissione. Il firmware per questi dispositivi è universale e funziona sul kernel Linux che, insieme alla possibilità di scrivere plugin LUA personalizzati, offre agli aggressori ampie opportunità di sfruttamento.

“Crediamo che durante l’attacco Lifting, Zmiy abbia approfittato delle informazioni pubblicate pubblicamente sulle imperfezioni di sicurezza dei dispositivi Tekon-Avtomatika e abbia sfruttato le vulnerabilità esistenti del sistema per ospitare su di essi una parte del server C2, che è stata utilizzata in ulteriori attacchi contro i loro obiettivi principali, ” scrivono gli esperti.

I ricercatori scrivono che l’obiettivo principale di Lifting Zmiy sono i dati riservati delle organizzazioni attaccate. E dopo aver raggiunto l’obiettivo, o se è impossibile penetrare più in profondità nell’infrastruttura dell’organizzazione vittima, gli hacker intraprendono azioni distruttive: cancellano i dati nei sistemi a loro disposizione.

È interessante notare che nella maggior parte degli incidenti il ​​gruppo si è collegato a sistemi infetti da indirizzi IP di diversi provider di hosting, ma nell’attacco a un’azienda informatica, su cui gli esperti hanno indagato nell’inverno del 2024, la loro tattica è cambiata. Hanno utilizzato indirizzi IP di un pool di proprietà del provider Starlink. Secondo i dati pubblici, questi indirizzi IP sono utilizzati dai terminali Starlink che operano in Ucraina.

In generale, sulla base di una serie di indizi, gli esperti di Solar 4RAYS ritengono che il gruppo Lifting Zmiy sia originario dell’Europa dell’Est.

“Al momento della nostra ricerca, Lifting Zmiy è ancora molto attiva: utilizzando i nostri sistemi troviamo costantemente nuovi elementi della loro infrastruttura. Pertanto, raccomandiamo alle organizzazioni che utilizzano sistemi SCADA simili a quelli attaccati dagli aggressori di prestare la massima attenzione nel garantire la propria sicurezza informatica. Inoltre, in tutti i casi esaminati, l’accesso all’infrastruttura è stato ottenuto tramite la consueta attacco di forza bruta nelle password, quindi le aziende dovrebbero verificare ancora una volta l’affidabilità delle loro politiche relative alle password e, come minimo, introdurre l’autenticazione a due fattori”, commenta Dmitry. Marichev, un esperto del centro di ricerca sulle minacce informatiche Solar 4RAYS.

L'articolo Lifting Zmiy: il gruppo che colpisce i sistemi SCADA e controlla gli ascensori proviene da il blog della sicurezza informatica.

Rare earth elements are used to produce magnets with very high strength that also strongly resist demagnetization, their performance is key to modern motors such as those in electric vehicles (EVs). The stronger the magnets, the lighter and more efficient a motor can be. So what exactly does it take to break up with rare earths?

Rare earth elements (REEs) are actually abundant in the Earth’s crust, technically speaking. The problem is they are found in very low concentrations, and inconveniently mixed with other elements when found. Huge amounts of ore are required to extract useful quantities, which requires substantial industrial processing. The processes involved are ecologically harmful and result in large amounts of toxic waste.

Moving away from rare earth magnets in EV motors would bring a lot of benefits, but poses challenges. There are two basic approaches: optimize a motor for non-rare-earth magnets (such as iron nitrides), or do away with permanent magnets entirely in favor of electromagnets (pictured above). There are significant engineering challenges to both approaches, and it’s difficult to say which will be best in the end. But research and prototypes are making it increasingly clear that effective REE-free motors are perfectly feasible. Breaking up with REEs and their toxic heritage would be much easier when their main benefit — technological performance — gets taken off the table as a unique advantage.

Il King Faisal Specialty Hospital and Research Center ( KFSH&RC ) in Arabia Saudita ha raggiunto un traguardo significativo nel suo programma di chirurgia cardiaca robotica. Dal suo lancio nel febbraio 2019, sono state eseguite 400 operazioni con un tasso di sopravvivenza del 98%, rafforzando la posizione dell’ospedale come leader mondiale nel settore.

KFSH&RC riporta miglioramenti significativi nei risultati del trattamento rispetto ai metodi tradizionali. La chirurgia robotica ha ridotto la necessità di trasfusioni di sangue e i tempi di ventilazione meccanica, consentendo ai pazienti di riprendersi più rapidamente e di riscontrare meno complicazioni.

La natura minimamente invasiva delle procedure ha ridotto la durata della degenza ospedaliera di oltre il 50%, riducendo i costi complessivi del 40%. I pazienti possono tornare alla vita quotidiana più velocemente.

Il programma di cardiochirurgia robotica KFSH&RC tratta con successo un’ampia gamma di condizioni cardiache complesse, comprese le sostituzioni multiple di valvole e altre procedure. L’ospedale esegue anche interventi chirurgici su pazienti ad alto rischio, compresi bambini sotto i 18 anni di età, persone con obesità patologica e coloro che necessitano di procedure ripetute. KFSH&RC è l’unico ospedale al mondo che esegue interventi di cardiochirurgia robotica sui bambini.

Lo sviluppo della chirurgia robotica corrisponde a uno spostamento globale verso un’assistenza sanitaria basata sul valore, in cui si dà la priorità a migliori risultati per i pazienti e al rapporto costo-efficacia. La tecnologia sta guadagnando terreno, con un’azienda indiana che ha recentemente lanciato un robot medico basato sull’intelligenza artificiale per la chirurgia ortopedica e AiM Medical Robotics che ha svelato un robot chirurgico compatibile con la risonanza magnetica per la pianificazione intraoperatoria.

Nonostante gli elevati costi iniziali, i benefici a lungo termine della chirurgia robotica sotto forma di riduzione delle complicanze, degenze ospedaliere più brevi e miglioramento della qualità della vita sono inestimabili. Gli ospedali continuano ad adottare la tecnologia robotica, stabilendo nuovi standard per la cura dei pazienti e l’eccellenza chirurgica, aprendo la strada a un futuro più sano.

L'articolo La Chirurgia Robotica è Realtà! Un Ospedale Esegue 400 Operazioni Cardiache Robotiche con Tasso di Sopravvivenza del 98%! proviene da il blog della sicurezza informatica.

Benvenuti nella rubrica dedicata alla sicurezza informatica e alle TOP 10 OWASP for Dummies.

L’obiettivo è rendere accessibile a sviluppatori e appassionati la comprensione delle dieci vulnerabilità più critiche secondo l’OWASP (Open Web Application Security Project). Attraverso una trattazione chiara e pratica, vi guideremo nel comprendere come funzionano queste minacce e come proteggere le vostre applicazioni web.

A09: Security Logging and Monitoring Failures

Immaginate di essere il responsabile della sicurezza di un edificio. Ogni giorno, centinaia di persone entrano ed escono, e il vostro compito è monitorare tutto ciò che accade per assicurare che nessuno violi le regole.

Se il sistema di sorveglianza non funziona correttamente o nessuno controlla le registrazioni, non vi accorgerete mai se qualcuno entra di nascosto o compie attività sospette. Questo è ciò che accade quando un sistema informatico non registra correttamente le attività o non le monitora in modo efficace.

Punti Chiave:

• Registrazione di login, accessi, e fallimenti nella convalida dell’input.
• Contesto utente sufficiente per identificare account sospetti.
• Conservazione dei log per consentire l’analisi forense ritardata.

Per ulteriori dettagli, è possibile consultare la pagina di OWASP Foundation.

La sicurezza informatica è una preoccupazione crescente per molte aziende, e la mancanza di logging e monitoraggio adeguati rappresenta uno dei rischi più significativi. Il fallimento nel loggare e monitorare correttamente gli eventi di sicurezza può impedire il rilevamento di violazioni in corso. Questo problema di sicurezza rientra nella categoria A09 delle vulnerabilità OWASP Top 10 del 2021. Senza un’efficace registrazione degli eventi critici, come accessi non riusciti e transazioni di alto valore, è impossibile reagire tempestivamente a possibili minacce.

Inoltre, non monitorare attivamente i log di sicurezza per rilevare attività sospette significa lasciare la propria rete vulnerabile agli attacchi. La configurazione corretta e l’uso adeguato degli strumenti di sicurezza sono essenziali per identificare intrusioni e anomalie. Ogni evento significativo deve essere registrato e analizzato per garantire che eventuali violazioni vengano rilevate e affrontate in modo rapido ed efficace.

Implementare un sistema di logging e monitoraggio robusto non solo aiuta a proteggere le risorse aziendali, ma migliora anche la capacità dell’azienda di rispondere agli incidenti di sicurezza. Analizzare esempi pratici di carenze di sicurezza nei log può fornire un quadro chiaro di come evitare e mitigare tali rischi.

Key Takeaways

• Il loggare correttamente gli eventi di sicurezza è cruciale.
• Un monitoraggio attivo previene violazioni non rilevate.
• Configurazioni adeguate e strumenti di sicurezza sono essenziali.

Comprensione delle Mancanze di Logging e Monitoraggio

youtube.com/embed/x92MNJTPIiM?…

Le mancanze di logging e monitoraggio rappresentano vulnerabilità critiche che possono mettere a rischio la sicurezza delle applicazioni. È essenziale capire cosa comporta il logging e perché il monitoraggio è fondamentale.

Definizione di Logging

Il logging consiste nella registrazione di eventi significativi all’interno di un sistema informatico. Questi eventi includono accessi, errori, transazioni importanti e altre attività rilevanti.

• Le registrazioni permettono di avere un tracciamento storico.
• Log insufficienti possono lasciare invisibili attività dannose.

Ad esempio, il mancato logging dei tentativi di accesso falliti può impedire il rilevamento di tentativi di intrusione. Questo riduce la capacità di rispondere tempestivamente a potenziali attacchi.

Importanza del Monitoraggio

Il monitoraggio implica l’osservazione continua dei log per individuare eventuali anomalie o comportamenti sospetti. Questo processo è essenziale per mantenere la sicurezza e l’integrità delle applicazioni.

• Il monitoraggio aiuta a rilevare e risolvere problemi in tempo reale.
• Allarmi non adeguati o inesistenti possono compromettere la sicurezza.

Ad esempio, se i log degli accessi non sono monitorati, un accesso non autorizzato potrebbe rimanere non rilevato. Monitorare regolarmente permette di individuare e rispondere rapidamente a tali situazioni.

Implicazioni delle Mancanze di Logging e Monitoraggio

Le mancanze nel logging e monitoraggio possono comportare gravi rischi alla sicurezza e pose conseguenze legali e di conformità per un’azienda. È essenziale capire le potenziali implicazioni per adottare misure preventive adeguate.

Rischi di Sicurezza

Le carenze nel logging e monitoraggio possono lasciare le organizzazioni vulnerabili agli attacchi. Senza una registrazione adeguata, è difficile rilevare attività sospette o intrusioni. Questo significa che i cybercriminali potrebbero accedere e muoversi nei sistemi senza essere scoperti.

Queste vulnerabilità aumentano il rischio di perdita di dati sensibili. Quando un attacco passa inosservato, gli intrusi possono rubare informazioni aziendali critiche, compromettere database o diffondere malware. L’assenza di segnalazioni tempestive riduce anche la capacità di rispondere rapidamente agli incidenti.

Implementare pratiche di monitoraggio efficaci è fondamentale per proteggere le risorse digitali. Utilizzare strumenti avanzati può aiutare a identificare e mitigare le minacce in modo proattivo, riducendo il rischio di danni estesi.

Conseguenze Legali e di Conformità

Le mancate attività di logging e monitoraggio possono portare a violazioni normative. Molte leggi richiedono alle aziende di mantenere registri dettagliati delle attività di sicurezza per garantire la protezione dei dati. La non conformità può comportare multe salate e sanzioni legali.

Oltre alle sanzioni economiche, la reputazione dell’azienda può soffrire enormemente. I clienti e i partner commerciali devono poter fidarsi che le loro informazioni siano protette. Un incidente di sicurezza non rilevato può minare questa fiducia e danneggiare le relazioni commerciali.

Per evitare tali rischi legali, è importante seguire le migliori pratiche e standard di sicurezza. Implementare procedure di audit regolari e formazione continua del personale garantirà che le normative vengano rispettate e che i dati siano protetti in modo efficace.

Implementazione del Logging e Monitoraggio Efficace

L’implementazione di un logging e monitoraggio efficaci previene intrusioni e anomalie. Utilizzare le giuste linee guida, strumenti e migliori pratiche è essenziale per la sicurezza.

Linee Guida di Implementazione

Le linee guida per un’efficace implementazione del logging includono la definizione di quali eventi devono essere registrati. È cruciale loggare tentativi di accesso non autorizzati, modifiche ai sistemi, e errori di applicazione.

Il logging deve essere centralizzato per facilitare l’analisi e la correlazione degli eventi. Utilizzare formati di log standardizzati migliora la leggibilità e l’integrazione con altri strumenti di monitoraggio.

Infine, occorre progettare un ciclo di vita per la gestione dei log, comprendendo la loro conservazione e distruzione sicura.

Strumenti e Tecnologie

Esistono numerosi strumenti di logging e monitoraggio. Tra i più utilizzati vi sono Splunk, Graylog, e Elasticsearch. Questi strumenti sono progettati per raccogliere, analizzare, e visualizzare i log in modo efficiente.

Splunk è noto per le sue potenti capacità di ricerca e visualizzazione. Graylog offre una soluzione open source con un’interfaccia intuitiva. Elasticsearch, spesso usato in combinazione con Kibana, permette ricerche veloci e analisi dettagliate.

La scelta dello strumento giusto dipende dalle specifiche esigenze dell’organizzazione e dal budget a disposizione.

Migliori Pratiche

Adottare le migliori pratiche di logging e monitoraggio è fondamentale. Assicurarsi che i log siano protetti, implementando controlli di accesso appropriati.

È importante mantenere una politica di revisione regolare dei log. Questo aiuta a identificare rapidamente attività sospette e a intraprendere azioni correttive.

Automatizzare il monitoraggio con strumenti di allerta e notifiche in tempo reale può migliorare notevolmente la reattività.

Infine, formare il personale sulla rilevanza dei log di sicurezza e su come interpretarli correttamente contribuisce a una cultura aziendale più consapevole e sicura.

Esempio pratico

In un’azienda, un team di sviluppatori ha implementato un sistema di logging per monitorare l’accesso ai server.

Problema:

Un utente malevolo tenta di accedere senza autorizzazione.

Logging inadeguato:

def login(user):
if authenticate(user):
print("Login successful")
else:
print("Login failed")

Questo codice non fornisce informazioni sull’identità dell’utente o sui dettagli del tentativo di accesso.

Logging adeguato:

import logging

logging.basicConfig(filename='app.log', level=logging.INFO)

def login(user):
if authenticate(user):
logging.info(f"Login successful for user: {user.username}")
else:
logging.warning(f"Login failed for user: {user.username}")

In questo esempio, le informazioni dell’utente e il risultato del tentativo di accesso vengono registrate.

Vantaggi del logging adeguato:

• Identificazione rapida: È possibile identificare rapidamente utenti sospetti.
• Analisi post-incidente: Gli amministratori possono analizzare i log per comprendere come è avvenuto l’accesso non autorizzato.
• Conformità: Rispetto delle normative di sicurezza che richiedono una documentazione accurata delle attività di sistema.

Strategie utili:

• Implementazione di un sistema di logging completo: Registrazione dettagliata di tutte le attività rilevanti.
• Monitoraggio continuo: Utilizzo di strumenti per analizzare i log in tempo reale.
• Protezione dei log: Proteggere i log da modifiche e accessi non autorizzati.
• Revisione periodica: Analizzare regolarmente i log per individuare potenziali vulnerabilità.

Consulta OWASP per ulteriori informazioni su Security Logging and Monitoring Failures.

Esempi di Mancanze di Sicurezza nei Log

Le mancanze di sicurezza nei log possono avere conseguenze gravi, come la perdita di dati o l’accesso non autorizzato a informazioni sensibili. Questo può avvenire a causa di configurazioni errate o di attacchi mirati sui sistemi di logging e monitoraggio.

Studi di Caso

Uno studio noto riguarda il ransomware LockBit 2.0. Questo malware è noto per cancellare i log di sicurezza e evento prima di disabilitare ulteriori registrazioni. Questo impedisce alle organizzazioni di rilevare e rispondere efficacemente agli attacchi.

Un altro caso coinvolge un fornitore di servizi cloud che ha subito un attacco interno. L’attacco è stato facilitato dalla mancanza di log adeguati, che ha reso difficile rilevare e tracciare le attività malevole per diversi mesi.

Analisi di Incidenti

Durante un test di penetrazione, un’azienda ha scoperto che i suoi log non erano configurati correttamente. Gli attacchi non venivano rilevati perché i log non raccoglievano tutte le informazioni necessarie. La configurazione errata ha permesso agli attaccanti di muoversi lateralmente nella rete senza essere scoperti.

In un altro incidente, un sistema di monitoraggio mal configurato ha permesso a un attaccante di esfiltrare dati sensibili. I log erano stati sovrascritti e non archiviati correttamente, rendendo impossibile determinare l’entità dell’attacco e l’origine della compromissione.

Mitigazione e Prevenzione

Per affrontare le falle di sicurezza nel logging e nel monitoraggio, le organizzazioni devono adottare tattiche di mitigazione efficaci e strategie proattive. Queste includono l’implementazione di strumenti di monitoraggio all’avanguardia e la creazione di processi standardizzati per la risposta agli incidenti.

Tattiche di Mitigazione

Una tattica chiave per mitigare le falle nel logging e monitoraggio è l’implementazione del logging centralizzato. Centralizzare i log permette una vista unificata degli eventi, facilitando il rilevamento di anomalie. Utilizzare strumenti come SIEM (Security Information and Event Management) può aiutare a identificare comportamenti sospetti e intruzioni.

Assicurarsi che tutti gli eventi critici siano adeguatamente registrati è fondamentale. Questo include login, tentativi di login falliti, e transazioni ad alto valore. Inoltre, è necessario configurare tutte le applicazioni per inviare i log a un archivio centralizzato, garantendo che nessun evento sia trascurato.

Le organizzazioni dovrebbero anche automatizzare la risposta agli incidenti. Automazione significa che quando viene rilevata un’anomalia, vengono immediatamente avviate azioni di contenimento come la quarantena dei sistemi compromessi o l’avviso agli amministratori di sistema.

Strategie Proattive

La prevenzione richiede strategie che anticipino i problemi prima che si verifichino. Una pratica essenziale è condurre test di penetrazione regolari per identificare e risolvere le vulnerabilità nei sistemi di logging e monitoraggio. Questi test simulano attacchi reali per valutare la prontezza del sistema a gestire minacce.

Le organizzazioni devono anche investire in formazione continua del personale. Gli addetti alla sicurezza devono essere costantemente aggiornati sulle nuove minacce e sulle migliori pratiche di logging e monitoraggio. Creare esercitazioni regolari e corsi di aggiornamento aiuta a mantenere alta la consapevolezza e la prontezza del team.

Infine, adottare una cultura della sicurezza è cruciale. Garantire che ogni membro dell’organizzazione comprenda l’importanza del logging e monitoraggio aiuta a creare un ambiente dove la sicurezza è una priorità condivisa. Questo può essere facilitato da politiche aziendali chiare e da un supporto attivo della dirigenza.

L'articolo OWASP A09 Security Logging and Monitoring Failures: Guida alle Migliori Pratiche proviene da il blog della sicurezza informatica.

Nella mattina del 6 luglio 2024, un utente noto come “BlackKing” ha rivelato su un forum di hacking una significativa violazione dei dati riguardante una piattaforma di viaggi e turismo cinese. Questa fuga di informazioni, avvenuta nel marzo 2024, ha portato all’esposizione di 7,5 milioni di record, di cui 5,82 milioni contengono identificativi di residenti.

Dettagli della Violazione

Secondo quanto riportato dall’Hacker, la violazione ha compromesso un’ampia gamma di dati personali.

I campi di dati inclusi nella fuga comprendono:

• calc_sex: Sesso calcolato
• hlr_province: Provincia HLR
• hlr_city: Città HLR
• hlr_carrier: Carrier HLR
• calc_birthyear: Anno di nascita calcolato
• calc_birthmonthday: Giorno e mese di nascita calcolati
• id_province: Provincia ID
• id_city: Città ID
• Name: Nome
• CtfTp: Tipo di Certificato
• CtfId: ID del Certificato
• Gender: Genere
• Birthday: Data di nascita
• Address: Indirizzo
• Zip: CAP
• Mobile: Numero di cellulare
• Tel: Numero di telefono fisso
• Fax: Numero di fax
• Email: Indirizzo email
• Nation: Nazionalità

Implicazioni della Violazione

Se la violazione venisse confermata la fuga di dati rappresenterebbe una seria minaccia per la privacy degli individui coinvolti. I dati personali esposti possono essere utilizzati per una serie di attività illecite, tra cui frodi d’identità, phishing e altri tipi di cyberattacchi. La presenza di dati come il numero di cellulare, l’indirizzo email e l’indirizzo fisico rende particolarmente pericolosa questa violazione.

Al momento, non possiamo confermare con precisione la veridicità della violazione, poiché l’organizzazione non ha ancora rilasciato alcun comunicato stampa ufficiale sul proprio sito web riguardo l’incidente. Pertanto, questo articolo dovrebbe essere considerato come una ‘fonte di intelligence’.

Reazioni e Misure di Sicurezza

Le autorità cinesi non hanno ancora rilasciato dichiarazioni ufficiali riguardo alla violazione. Tuttavia, è probabile che vengano avviate indagini approfondite per determinare la fonte del leak e per prevenire future violazioni di questo tipo. Gli utenti delle piattaforme di viaggio e turismo sono consigliati di monitorare attentamente le loro comunicazioni per eventuali attività sospette e di adottare misure di sicurezza come l’aggiornamento delle password e l’attivazione dell’autenticazione a due fattori.

Conclusione

La violazione dei dati della piattaforma turistica cinese evidenzia ancora una volta la necessità di una maggiore sicurezza e protezione dei dati personali online. Mentre le autorità lavorano per contenere i danni e prevenire future violazioni, gli utenti devono essere proattivi nella protezione delle proprie informazioni personali. Questa vicenda serve da monito sull’importanza della sicurezza informatica nel mondo digitale di oggi.

Come nostra consuetudine, lasciamo sempre spazio ad una dichiarazione da parte dell’azienda qualora voglia darci degli aggiornamenti sulla vicenda. Saremo lieti di pubblicare tali informazioni con uno specifico articolo dando risalto alla questione.

RHC monitorerà l’evoluzione della vicenda in modo da pubblicare ulteriori news sul blog, qualora ci fossero novità sostanziali. Qualora ci siano persone informate sui fatti che volessero fornire informazioni in modo anonimo possono utilizzare la mail crittografata del whistleblower.

L'articolo Shock Cina e Turismo: 7,5 Milioni di Dati Personali Rubati da una Piattaforma di Viaggi proviene da il blog della sicurezza informatica.

It’s said that “Golf is a good walk spoiled,” so is attaching an amateur radio to a bike a formula for spoiling a nice ride?

Not according to [Wesley Pidhaychuk (VA5MUD)], a Canadian ham who tricked out his bike with a transceiver and all the accessories needed to work the HF bands while peddling along. The radio is a Yaesu FT-891, a workhorse mobile rig covering everything from the 160-meter band to 6 meters. [Wes] used some specialized brackets to mount the radio’s remote control head to the handlebars, along with an iPad for logging and a phone holder for streaming. The radio plus a LiFePO4 battery live in a bag on the parcel rack in back. The antenna is a Ham Stick mounted to a mirror bracket attached to the parcel rack; we’d have thought the relatively small bike frame would make a poor counterpoise for the antenna, but it seems to work fine — well enough for [Wes] to work some pretty long contacts while pedaling around Saskatoon, including hams in California and Iowa.

The prize contact, though, was with [WA7FLY], another mobile operator whose ride is even more unique: a 737 flying over Yuma, Arizona. We always knew commercial jets have HF rigs, but it never occurred to us that a pilot who’s also a ham might while away the autopilot hours working the bands from 30,000 feet. It makes sense, though; after all, if truckers do it, why not pilots?

youtube.com/embed/I6YLW5jOs10?…

This article introduces the EIT’s Regional Innovation Scheme, outlines its successes over the decade since its foundation, explains how it helps ventures in modest and moderated innovator countries to realise their potential, and shares two success stories,

euractiv.com/section/digital/o…

We’ve covered the Tiny Tapeout project a few times on these pages, and while getting your digital IC design out there onto actual silicon for a low cost is super cool, it is still somewhat limited. Now, along comes the German FMD QNC project funding MPW (multi-project wafer) runs not in bog standard Silicon CMOS but Silicon-Germanium bipolar technology. And this is accessible to you and me, of course, provided you have the skills to design in this high-speed analog technology.

The design can be submitted via Github by cloning the IHP-Open-DesignLib repo, adding your design, and issuing a pull request. If your submission passes the correctness checks and is selected, it will be fabricated in-house by the IHP pilot line facility, which means it will take at least four months to complete. However, there are a few restrictions. The design must be open source, DRC complete (obviously!) and below a somewhat limiting two square millimetres. Bonus points for selecting your project can be had for good documentation and a unique quality, i.e., they shouldn’t have too many similar designs in the project archive. Also, you don’t get to keep the silicon samples, but you may rent them for up to two years for evaluation. In fact, anybody can rent them. Still, it’s a valuable service to trial a new technique or debug a design and a great way to learn and hone a craft that is difficult to get into by traditional means. Such projects would be an excellent source of verifiable CV experience points we reckon!

If you fancy getting your hands on your own silicon, but bipolar SiGe is a bit of a stretch, look no further than our guide to Tiny Tapeout. But don’t take our word for it—listen to the creator himself!

When we talk about keyboards that do it all, we usually mean either big ones with lots of keys and doodads like rotary encoders and displays, or small ones with lots of layers (and usually a few doodads, too). But this — this is something else entirely. Chinese PC maker Linglong have crammed an entire mini PC into a keyboard that’s small enough to fit in your back pocket. Oh, and it folds, too. All you need is a display.

Why do you need a display? Why not include one, if you’re going to wedge everything else in there? Well, the company envisions its users pairing it with a VR or AR glasses. But we can see use cases far beyond ownership of special spectacles, of course.

For instance, office work. Linglong says this key-puter (you read it here first) will last up to ten hours for light use, and nearly six hours for watching movies, but heavy use will have you down to four hours, which really isn’t that bad.

Spec-wise, it looks pretty good, with an AMD Ryzen 7 and either 16 or 32 GB of memory and a half- or full-terabyte hard drive. The whole thing is around 4 x 6″ (15 x 10cm), presumably in the folded orientation, and weighs less than two pounds (800 g). The projected cost is $400-500 depending on specs.

Unfortunately, this little key-puter isn’t available just yet. There are just 200 units available for Beta testing, and no, we don’t have one!

Main and thumbnail images via Linglong

Un enorme data breach ha colpito DigiVation Digital Solutions Pvt. Ltd., un’azienda di innovazione digitale con sede a Mumbai, in India. I dati trafugati, che includono nomi, indirizzi email, numeri di telefono e password di migliaia di clienti, sono ora in vendita su BreachForum, un noto marketplace online per dati rubati.

Questo evento rappresenta un grave colpo per DigiVation e per i suoi clienti, che ora si trovano ad affrontare un elevato rischio di frodi, furti d’identità e altri danni. Al momento non è chiaro come i dati siano stati ottenuti, e nemmeno se DigiVation è a conoscenza del databreach.

Modalità di vendita

Il threat actor dichiara di possedere un file CSV contenente dati dell’azienda DigiVation inerenti al 2023.

Dettagli:

• Anno: 2023;
• Volume: 98.693 righe di dati;
• Tipo di file: CSV (Comma-Separated Values);
• Dominio: digivationworld.com;
• Origine: DBS Business Center, situato presso “World Trade Tower, Barakhamba Lane, New Delhi, 110001, India”.

Questa volta i dati non sono in vendita, tuttavia, una parte del file è stata resa accessibile alla community del darkweb. Il file può essere completamente accessibile in cambio di crediti, in questo caso 8.

Il file CSV contiene diverse tipologie di informazioni come nomi, indirizzi mail, numero di telefono, nello specifico è composto da 27 colonne. Questa fuga di dati espone i dati personali di migliaia di persone al rischio di frodi, furti d’identità e altri danni.

L’autore del breach non ha dichiarato nulla su come è stato eseguito l’attacco ma si è semplicemente limitato a pubblicare la data nella quale il database è prelevato, è importante che gli individui interessati prendano precauzioni per proteggersi, come cambiare le password e monitorare i propri conti bancari.

Criticità

Gli aspetti critici sono molteplici:

• Elevato volume di dati: Il numero di righe interessate (98.693) indica una significativa esposizione di dati sensibili.
• Sensibilità dei dati: I dati trafugati includono informazioni personali come nomi, indirizzi email, numeri di telefono e password, che possono essere utilizzati per scopi illeciti.
• Disponibilità parziale: La parziale disponibilità dei dati sul darkweb potrebbe indurre gli utenti a tentare di accedere al file completo, aumentando il rischio di ulteriori danni.
• Mancanza di informazioni sull’attacco: L’assenza di dettagli su come è stato eseguito l’attacco rende difficile per DigiVation implementare misure preventive efficaci.

Conclusioni

Il data breach di DigiVation Digital Solutions Pvt. Ltd. è un evento preoccupante che evidenzia l’importanza di una solida sicurezza informatica per le aziende che gestiscono dati sensibili. Le organizzazioni devono essere proattive nell’implementare misure di protezione efficaci e nel rispondere prontamente agli incidenti di sicurezza informatica.

L'articolo DigiVation Sotto Attacco: Una potenziale fuga di Dati Sensibili Espone Migliaia di Clienti proviene da il blog della sicurezza informatica.

Usually the business card itself is the reminder to get in contact with whoever gave it to you. But this is Hackaday, after all. This solar-powered card reminds the recipient to send [Dead Rat Productions] an email by beeping about every two hours, although the gist of that email may simply be begging them to make it stop, provided they didn’t just toss the thing in the garbage.

The full-on, working version of the card is not intended for everyone — mostly serious-looking A-list types that ooze wealth. Most of [Dead Rat Productions]’ pub mates will get an unpopulated version, which could be a fun afternoon for the right kind of recipient, of course.

That person would need a Seeed Studio Xiao SAMD21, a solar panel, plus some other components, like an energy-harvesting chip to keep the battery topped up. Of note, there is a coin cell holder that requires prying with a screwdriver to get the battery out, so there’s really no escaping the beeping without some work on their part. We rather like the artwork on this one, especially the fact that the coin cell sits inside the rat’s stomach. That’s a nice touch.

When I was growing up, about 4 or 5 years old, I had an unorthodox favourite type of reading material: service manuals for my dad’s audio equipment. This got to the point that I kept asking my parents for more service manuals, and it became a running joke in our family for a bit. Since then, I’ve spent time repairing tech and laptops in particular as a way of earning money, hanging out at a flea market in the tech section, then spending tons of time at our hackerspace. Nowadays, I’m active in online hacker groups, and I have built series of projects closely interlinked with modern-day consumer-facing tech.

Twenty three years later, is it a wonder I have a soft spot in my heart for schematics? You might not realize this if you’re only upcoming in the hardware hacking scene, but device schematics, whichever way you get them, are a goldmine of information you can use to supercharge your projects, whether you’re hacking on the schematic-ed device itself or not. What’s funny is, not every company wants their schematics to be published, but it’s ultimately helpful for the company in question, anyway.

If you think it’s just about repair – it’s that, sure, but there’s also a number of other things you might’ve never imagined you can do. Still, repair is the most popular one.

Repair, Of Course

Asked to pay for a schematic? You can most likely find it elsewhere for free.
It’s an old chestnut that tech marvels of the past used to come bundled with schematics, and that’s no longer the case. Indeed, they are often top secret. For laptops and phones, one part of that is extensive NDAs that cover information on many a chip within them, including schematics. That said, somehow, this hasn’t stopped certain companies like Clevo, who has been seen putting their designs’ schematics right inside the service manual, for example, the P75xZM_ESM.pdf.

Still, schematics are a market; repair shops earn their keep from being able to fix devices, so a PDF is likely to leak one way or another, often it just takes time. For certain laptop manufacturers and series, this doesn’t happen, but most of all it seems to depend on popularity. In a way, schematics being leaked is a decent indicator that a product is popular enough to hit repair shops en masse, creating demand for underpaid workers to bring a loaded microSD card with them on a trip back home from the factory employing them.

I’m aware that companies sometimes can’t publish much, and, it’s still interesting how publishing schematics and other repair documents is not more popular with companies, despite everything it brings. During my call-in laptop repair days, travelling around with a tiny Asus netbook in my toolbox that used to be a makeup suitcase, I can remember one specific phrase I heard often: “yeah, we don’t like %BRAND%, we’ve had our %BRAND% device break and it couldn’t be fixed”.

Companies Who Publish Nevertheless

When it comes to publicly shared schematics, for instance, Framework laptops have adopted a “Raspberry Pi” approach – share schematics that concern external ports, where no NDAs could conceivably be involved, and even publish further specifications about these ports. This has created a vivid hacking and modding ecosystem around Framework, attracting a good amount of people, and this part in particular is something other companies could do as well. I’ve talked aplenty about the Framework ecosystem already, and I mention the schematic involvement there quite a bit, too!

It’s not just about connectors – there’s plenty of places in a laptop where failures are likely to occur, like power management. Intel might scoff at the CPU and Thunderbolt part pinouts being published, but schematics for these aren’t usually involved in a laptop repair anyway, what fails is usually power management, and chances are, just the schematic pages for that could be published without violating an NDA. Raspberry Pi’s schematics used to work in this way; sadly, RPF has given up on publishing Linux-powered Pi schematics due to being stuck in a perfectionism loop – the Pi 5 schematics are nowhere to be seen, and the USB-C-fixed Pi 4 schematics aren’t available either.

Pine64 is a strange case – their products are not open-source, in large part due to their operation’s scale landing them in a cloning-happy environment. Still, they publish a ton of the information that you might want. Pine64 publishes schematics for their products, and is forthcoming with things like – for instance, ever broke a barrel jack socket on your Pinecil? It’s a rare fault, but in case you somehow have, they stock replacement sockets. Of course, Pinecil schematics are available too, in full, same goes for PinePhone and most of their other products.

I was particularly active in the Pinecil community of the Pine64 discord, and thanks to schematics being accessible in a searchable way, we could help people fix their Pinecils on a community basis, across timezones, often quicker than the tech support could give them a response. In fact, because of the conversations happening in an official Pine64 community, Pine64 tech support could read the conversations in our channel, and avoid repeating many of the debugging steps with the Pinecil owner in question. It really helped that, everything they had to do over email, we could do over real-time chat! Schematics were a crucial part of that, from tracing what could it be that’d die from a reverse polarity what was shorting out the 3.3 V regulator, to the part numbers.

A good few failures were relatively common, and a few community members across different continents, including me, stocked up on some of the commonly involved parts and mailed them out to people in flat envelopes. Compared to the Pinecil sales numbers, the number of failures that we handled was pretty low, but we did help a good few people; generally, people were quite happy about fixing something they own, as opposed to getting a new iron and putting the broken one into a cupboard drawer!
here’s a trae you can cut to protect your old Pinecil from FUSB failure, and gain 24V support as a side effect
It wasn’t just replacing components – together, we narrowed down a particularly common fault that would kill Pinecils or at least make their USB-C PD power input inoperable, and figured out a fix that, in the end, involved simply cutting a trace. The gist is, a pin of a specific IC on the Pinecil was connected directly to the power input rail, this pin specifically was sensitive to overvoltage, killing the chip in a way that sometimes would even pull down the entire 3.3 V rail. What’s interesting, it didn’t have to be connected to that rail at all! The community designed a fix, people have applied it for both failure immunity and also being able to use 24 V bricks. Later on, Pine64 applied the fix to a new batch of the Pinecil hardware, which is now immune to this fault.

Before the ability to just cut the trace was figured out by [Thanos the tank engine] and others, I managed to design an addon board that’d down-regulate the voltage with a Zener diode, and even published the files for it. After all, you can design a whole lot if schematics are available!

Build All The Cool Stuff

Hackers have long used schematics to design things like addons – physical board attributes, you can redesign with calipers in hand, but schematics capture everything else. All those consoles put into tiny formfactors, made possible because of the motherboard being cut down? Schematics were likely involved in one way or another.

Friends of mine have done the same kind of schematic-inspired design, on a number of occasions – in particular, [Wificable] has designed an MXM reuse adapter and a good few MXM cards only thanks to available schematics, and her TinyRiser, an adapter that pulls extra PCIe from a particular lineup of Lenovo Tiny computers, was only possible because we could get find the relevant PDF in a Telegram group.
Got a technical question the manufacturer doesn’t expand on? A schematic is a reliable way to check.
It’s not just addons, it’s also finding information you can’t find otherwise. Wondering what your laptop’s USB-C port does, whether it supports DisplayPort, or charging input? The manufacturer’s website might not be helpful at all, but the schematics show it all instantly, on the page with the block diagram. I’ve seen a product being developed, an ExpressCard slot adapter housing an SSD, that researched laptop schematics to figure out 3.3 V current limits on the ExpressCard slot and how they were implemented in different laptops.

Tapping into the iPhone battery market to get a reliable source of slim batteries for your project? Use the schematics to find the battery connector pinout – and the connector part number. Remember the M.2 card with a 1:2 PCIe switch, that I’ve shown you the design process of? That one was only possible because of a laptop schematic we found featuring the ASM1182e chip. Schematics often contain part numbers, and these are super helpful – you could consult one of the connector bibles, or you could simply copy the part number for a connector out of a schematic PDF and get the exact part number necessary.

Remember that Sony Vaio P motherboard rebuild project I’ve started? I’ve just recently received the v1 PCBs of a motherboard I designed, now they’re waiting to be assembled, and I couldn’t have had done this without all the connector pinout information I found in the schematic. In particular, it might be that this motherboard replacement will be impossible to adapt to the second revision of these Vaios, since, as far as I’ve seen, that revision’s schematics haven’t leaked. Well, either way, expect an article about the new motherboard soon!

There’s way, way more you can learn from schematics as you go. One of my current projects requires learning a fair bit from the PinePhone schematic and specifically its LTE modem that boasts open firmware, as part of uncovering yet another series-worthy topic; naturally, you will hear about that one soon. Schematics keep a treasure trove of hacker-friendly information in them, and information deserves to be free.