Keeping track of time is essential, even for microcontrollers, which is why a real-time clock (RTC) peripheral is a common feature in MCUs. In the case of the STM32 family there are three varieties of RTC peripherals, with the newest two creatively called ‘RTC2′ and RTC3’, to contrast them from the very basic and barebones RTC that debuted with the STM32F1 series.

Commonly experienced in the ubiquitous and often cloned STM32F103 MCU, this ‘RTC1’ features little more than a basic 32-bit counter alongside an alarm feature and a collection of battery-backed registers that requires you to do all of the heavy lifting of time and date keeping yourself. This is quite a contrast with the two rather similar successor RTC peripherals, which seem to insist on doing everything possible themselves – except offer you that basic counter – including giving you a full-blown calendar and today’s time with consideration for 12/24 hour format, DST and much more.

With such a wide gulf between RTC1 and its successors, this raises the question of how to best approach these from a low-level perspective.

You Can Count On Me

If it was just about counting seconds, then any of the timer peripherals in an MCU would be more than up to the task, limited only by the precision of the used system clock. The RTC requirements are a bit more extensive, however, as indicated by what is called the backup domain in F1 and the backup registers in the RTC2 and RTC3 peripherals. Powered by an external power source, this clock and register data are expected to survive any power event, the CPU being reset, halted or powered off, while happily continuing to count the progress of time until the rest of the MCU and its firmware returns to check up on its progress.

Naturally, this continuation requires two things: the first is a power source to the special power pin on the MCU (V_BAT), often provided from a ubiquitous 3 V lithium cell, along with a clock source that remains powered when the rest of the MCU isn’t. This provides the first gotcha as the RTC clock can be configured to be one of these three:

• Low Speed External (LSE): usually an external 32,768 Hz oscillator which is powered via V_BAT.
• Low Speed Internal (LSI): a simple internal ~40-ish kHz oscillator that is only powered by V_DD.
• High Speed External (HSE): the external clock signal that’s generally used to clock the MCU’s CPU and many of its peripherals. Also not available in all low-power modes.

Thus, the logical RTCCLK choice for an RTC that has to survive any and all adverse power events is the LSE as it feeds into the RTC. Take for example the STM32F103 RTC block diagram:
Simplified RTC diagram of the STM32F103. (Source: RM0008)
Here we can see the elements of the very basic RTC1 peripheral, with the sections that are powered by V_BAT marked in grey. The incoming RTCCLK is used to generate the RTC time base TR_CLK in the RTC prescaler, which increases the value in the RTC_CNT register. It being a 32-bit register and TR_CLK usually being 1 Hz means that this counter can be run for approximately 136 years if we ignore details like leap years, without overflowing.

For initializing and using the RTC1 peripheral, we can consult application note AN2821 alongside reference manual RM0008, which covers a clock and calendar implementation, specifically on the STM3210B-EVAL board, but applicable to all STM32F10x MCUs. If you want to keep a running calendar going, it’s possible to use the backup registers for this whenever the counter reaches a certain number of seconds.

That said, where having just this counter is rather pleasant is when using the C <time.h> functions with Newlib, such as time(). As Newlib on STM32 requires you to implement at least [url=https://www.man7.org/linux/man-pages/man2/gettimeofday.2.html]_gettimeofday()[/url], this means that you can just let RTC_CNT do its thing and copy it into the seconds member of a timeval struct – after converting from BCD to binary – before returning it. This is significantly easier than with RTC2 and 3, with my own implementation in Nodate’s RTC code currently fudging things with mktime() to get a basic seconds counter again from the clock and calendar register values.

All The Bells And Whistles

If the RTC1 peripheral was rather basic with just a counter, an alarm and some backup registers, its successor and the rather similar RTC3 peripheral are basically the exact opposite. A good, quick comparison is provided here, with AN4759 providing a detailed overview, initialization and usage of these newest RTCs. One nice thing about RTC3 is that it adds back an optional counter much like the – BCD-based – RTC1 counter by extending the RTC_SSR register to 32-bit and using it as a binary counter. However as the summary by Efton notes, this counter and some other features are not present on every MCU, so beware.

Correspondingly, the block diagram for the RTC2 peripheral is rather more complicated:
Block diagram of the RTC 2 peripheral in the STM32F401 MCU. (Source: ST, RM0368)
Although we can still see the prescaler and backup/tamper registers, the prescaler is significantly more complex with added calibration options, the alarms span more registers and there are now three shadow registers for the time, date and sub-seconds in RTC_TR, RTC_DR and RTC_SSR respectively. This is practically identical to the RTC3 block diagram.

These shadow registers lay out the individual values as for example in the RTC_TR register:
The RTC_TR register in the STM32F401. (Source: ST, RM0368)
Taking the seconds as an example, we got the tens (ST) and units (SU), both in BCD format which together form the current number of seconds. For the minutes and hours the same pattern is used, with PM keeping track of whether it’s AM or PM if 12 hour format is used. Effectively this makes these shadow registers a direct source of time and calendar information, albeit generally in BCD format and unlike with the basic RTC1 peripheral, using it as the source for C-style functions via Newlib has become rather tricky.

Unix Time Things

In the world of computing the ‘seconds since the Unix Epoch’ thing has become rather defining as the starting point for many timing-related functions. One consequence of this is that indicating a point in time often involves listing the number of seconds since said epoch on January 1st of 1970, at 00:00:00 UTC. This includes the time-related functions in the standard C libraries, such as Newlib, as discussed earlier.

This is perhaps the most frustrating point with these three-ish different STM32 RTC peripherals, as although the RTC1 is barebones, making it work with Newlib is a snap, while RTC2 and RTC3 are for the most part a nightmare, except for the RTC3 implementations that support the binary mode, although even that is a down-counter instead of an up-counter. This leaves one with the dreadful task of turning those shadow register values back into a Unix timestamp.

One way to do this is by using the mktime() function as mentioned earlier. This takes a tm struct whose fields define the elements of a date, e.g. for seconds:
tm tt;
tt.tm_sec = (uint8_t) bcd2dec32(RTC_TR & (RTC_TR_ST | RTC_TR_SU));
By repeating this for each part of RTC_TR and RTC_DR, we end up with a filled in struct that we can pass to mktime which will then spit out our coveted Unix timestamp in the form of a time_t integer. Of course, that would be far too easy, and thus we run head-first into the problem that mktime is incredibly picky about what it likes, and makes this implementation-dependent.

For example, despite the claims made about ranges for the tm struct, running a simple local test case in an MSYS2 environment indicated that negative years since 1970 wasn’t allowed, so that not having the RTC set to a current-ish date will always error out when the year is less than 71. It’s quite possible that a custom alternative to mktime will be less headache-inducing here.

Of course, ST could just have been nice and offered the basic counter of RTC1 along with all of the good stuff added with RTC2 and RTC3, but maybe for that we’ll have to count the seconds until the release of RTC4.

hackaday.com/2025/09/10/bare-m…

Adobe ha segnalato un bug critico (CVE-2025-54236) che colpisce le piattaforme Commerce e Magento. I ricercatori hanno chiamato questa vulnerabilità SessionReaper e la descrivono come una delle più gravi nella storia di questi prodotti.

Questa settimana, gli sviluppatori Adobe hanno già rilasciato una patch per il bug di sicurezza, che ha ricevuto un punteggio CVSS di 9,1. Si segnala che la vulnerabilità può essere sfruttata senza autenticazione per prendere il controllo degli account dei clienti tramite l’API REST di Commerce.

Secondo gli esperti della società di sicurezza informatica Sansec, il 4 settembre Adobe ha notificato a “clienti Commerce selezionati” l’imminente correzione, che è stata rilasciata il 9 settembre.

I clienti che utilizzano Adobe Commerce su Cloud sono già protetti da una regola WAF implementata da Adobe come misura di sicurezza provvisoria.

Né Adobe né Sansec sono a conoscenza di casi in cui SessionReaper sia stato utilizzato in attacchi reali. Tuttavia, Sansec segnala che l’hotfix iniziale per CVE-2025-54236 è trapelato la scorsa settimana, il che significa che gli aggressori hanno avuto più tempo per creare un exploit.

Secondo i ricercatori, lo sfruttamento efficace del problema dipende dalla memorizzazione dei dati della sessione nel file system (questa è la configurazione predefinita utilizzata nella maggior parte dei casi). Si consiglia vivamente agli amministratori di installare la patch disponibile il prima possibile. Tuttavia, gli esperti avvertono che la correzione disabilita alcune funzioni interne di Magento e questo potrebbe causare problemi nel codice personalizzato ed esterno.

Gli esperti di Sansec prevedono che CVE-2025-54236 verrà sfruttata in attacchi automatizzati su larga scala. Fanno notare che questa vulnerabilità è tra le più gravi nella storia di Magento, insieme a CosmicSting , TrojanOrder , Ambionics SQLi e Shoplift .

In passato, problemi simili sono stati sfruttati per falsificare sessioni, aumentare i privilegi, accedere a servizi interni ed eseguire codice.

L'articolo Vulnerabilità critica in Adobe Commerce e Magento: il bug SessionReaper proviene da il blog della sicurezza informatica.

Nella giornata di oggi, la nuova cyber-gang “The Gentlemen” rivendica all’interno del proprio Data Leak Site (DLS) il primo attacco ad una azienda italiana.

Disclaimer: Questo rapporto include screenshot e/o testo tratti da fonti pubblicamente accessibili. Le informazioni fornite hanno esclusivamente finalità di intelligence sulle minacce e di sensibilizzazione sui rischi di cybersecurity. Red Hot Cyber condanna qualsiasi accesso non autorizzato, diffusione impropria o utilizzo illecito di tali dati. Al momento, non è possibile verificare in modo indipendente l’autenticità delle informazioni riportate, poiché l’organizzazione coinvolta non ha ancora rilasciato un comunicato ufficiale sul proprio sito web. Di conseguenza, questo articolo deve essere considerato esclusivamente a scopo informativo e di intelligence.

All’interno del post, la gang riporta quanto segue:

Laboratorio Clinico Santa Rita
Santa Rita Laboratorios offers a wide range of medical laboratory services, including hematology, immunology, microbiology, and molecular biology. The company is committed to preserving health through accurate diagnostics and operates with state-of-the-art technology and high-resolution equipment. They provide personalized medical assistance 24/7, as well as home sample collection services for client convenience. Intended clients include individuals seeking reliable laboratory tests and diagnostics.”

Chi sono i criminali informatici di The gentlemen

La cyber gang The Gentlemen è emersa di recente nello scenario del cybercrime distinguendosi per un approccio organizzato e un’infrastruttura ben strutturata. Il gruppo opera attraverso un proprio data leak site nel dark web, dove pubblica avvisi di compromissione e minacce di esposizione dei dati.

La loro comunicazione è caratterizzata da uno stile curato e studiato, con un’immagine pubblica che mira a costruire credibilità e timore nel settore della criminalità informatica, nonostante la relativa novità della loro presenza. Questo aspetto lascia intendere che dietro al progetto possano esserci attori già esperti di ransomware e data extortion.

Il modus operandi dei The Gentlemen ricalca i modelli tipici del ransomware moderno: compromissione iniziale delle infrastrutture, esfiltrazione dei dati sensibili e successiva estorsione basata sulla minaccia di pubblicazione. Le prime vittime individuate dal gruppo appartengono a settori sensibili come sanità, manifattura e servizi, aree particolarmente appetibili per la pressione che la perdita o la fuga di informazioni può generare. Il loro sito non si limita a elencare le vittime, ma fornisce anche dettagli sui dati sottratti, aumentando così la pressione psicologica sulle aziende colpite.

La rapidità con cui il gruppo si è imposto nell’ecosistema del cybercrime solleva interrogativi sulla sua reale origine e sulla possibilità che sia una riorganizzazione o una “costola” di operatori già noti. La capacità di attrarre l’attenzione della comunità di sicurezza informatica. In un panorama già saturo di gang ransomware, i The Gentlemen puntano a differenziarsi con uno stile comunicativo elegante ma allo stesso tempo aggressivo, posizionandosi rapidamente come una minaccia emergente di cui monitorare attentamente le mosse future.

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.

Cos’è il ransomware as a service (RaaS)

Il ransomware, è una tipologia di malware che viene inoculato all’interno di una organizzazione, per poter cifrare i dati e rendere indisponibili i sistemi. Una volta cifrati i dati, i criminali chiedono alla vittima il pagamento di un riscatto, da pagare in criptovalute, per poterli decifrare.

Qualora la vittima non voglia pagare il riscatto, i criminali procederanno con la doppia estorsione, ovvero la minaccia della pubblicazione di dati sensibili precedentemente esfiltrati dalle infrastrutture IT della vittima.

Per comprendere meglio il funzionamento delle organizzazioni criminali all’interno del business del ransomware as a service (RaaS), vi rimandiamo a questi articoli:

• Il ransomware cos’è. Scopriamo il funzionamento della RaaS
• Perché l’Italia è al terzo posto negli attacchi ransomware
• Difficoltà di attribuzione di un attacco informatico e false flag
• Alla scoperta del gruppo Ransomware Lockbit 2.0
• Intervista al rappresentante di LockBit 2.0
• Il 2021 è stato un anno difficile sul piano degli incidenti informatici
• Alla scoperta del gruppo Ransomware Darkside
• Intervista al portavoce di Revil UNKNOW, sul forum XSS
• Intervista al portavoce di BlackMatter

Come proteggersi dal ransomware

Le infezioni da ransomware possono essere devastanti per un’organizzazione e il ripristino dei dati può essere un processo difficile e laborioso che richiede operatori altamente specializzati per un recupero affidabile, e anche se in assenza di un backup dei dati, sono molte le volte che il ripristino non ha avuto successo.

Infatti, si consiglia agli utenti e agli amministratori di adottare delle misure di sicurezza preventive per proteggere le proprie reti dalle infezioni da ransomware e sono in ordine di complessità:

• Formare il personale attraverso corsi di Awareness;
• Utilizzare un piano di backup e ripristino dei dati per tutte le informazioni critiche. Eseguire e testare backup regolari per limitare l’impatto della perdita di dati o del sistema e per accelerare il processo di ripristino. Da tenere presente che anche i backup connessi alla rete possono essere influenzati dal ransomware. I backup critici devono essere isolati dalla rete per una protezione ottimale;
• Mantenere il sistema operativo e tutto il software sempre aggiornato con le patch più recenti. Le applicazioni ei sistemi operativi vulnerabili sono l’obiettivo della maggior parte degli attacchi. Garantire che questi siano corretti con gli ultimi aggiornamenti riduce notevolmente il numero di punti di ingresso sfruttabili a disposizione di un utente malintenzionato;
• Mantenere aggiornato il software antivirus ed eseguire la scansione di tutto il software scaricato da Internet prima dell’esecuzione;
• Limitare la capacità degli utenti (autorizzazioni) di installare ed eseguire applicazioni software indesiderate e applicare il principio del “privilegio minimo” a tutti i sistemi e servizi. La limitazione di questi privilegi può impedire l’esecuzione del malware o limitarne la capacità di diffondersi attraverso la rete;
• Evitare di abilitare le macro dagli allegati di posta elettronica. Se un utente apre l’allegato e abilita le macro, il codice incorporato eseguirà il malware sul computer;
• Non seguire i collegamenti Web non richiesti nelle e-mail;
• Esporre le connessione Remote Desktop Protocol (RDP) mai direttamente su internet. Qualora si ha necessità di un accesso da internet, il tutto deve essere mediato da una VPN;
• Implementare sistemi di Intrusion Prevention System (IPS) e Web Application Firewall (WAF) come protezione perimetrale a ridosso dei servizi esposti su internet.
• Implementare una piattaforma di sicurezza XDR, nativamente automatizzata, possibilmente supportata da un servizio MDR 24 ore su 24, 7 giorni su 7, consentendo di raggiungere una protezione e una visibilità completa ed efficace su endpoint, utenti, reti e applicazioni, indipendentemente dalle risorse, dalle dimensioni del team o dalle competenze, fornendo altresì rilevamento, correlazione, analisi e risposta automatizzate.

Sia gli individui che le organizzazioni sono scoraggiati dal pagare il riscatto, in quanto anche dopo il pagamento le cyber gang possono non rilasciare la chiave di decrittazione oppure le operazioni di ripristino possono subire degli errori e delle inconsistenze.

La sicurezza informatica è una cosa seria e oggi può minare profondamente il business di una azienda.

Oggi occorre cambiare immediatamente mentalità e pensare alla cybersecurity come una parte integrante del business e non pensarci solo dopo che è avvenuto un incidente di sicurezza informatica.

L'articolo Gli hacker criminali di The Gentlemen pubblicano la prima vittima italiana proviene da il blog della sicurezza informatica.

I ricercatori di Check Point hanno scoperto una campagna di phishing attiva su larga scala che sfrutta Google Classroom, una piattaforma a cui si affidano milioni di studenti ed educatori in tutto il mondo.

Nel corso di una sola settimana, gli aggressori hanno lanciato cinque ondate coordinate, distribuendo più di 115.000 e-mail di phishing rivolte a 13.500 organizzazioni di diversi settori. Sono state prese di mira organizzazioni in Europa, Nord America, Medio Oriente e Asia.

Uno strumento affidabile trasformato in un vettore di minacce

Google Classroom è progettato per mettere in contatto insegnanti e studenti attraverso inviti a partecipare a classi virtuali. Gli aggressori hanno sfruttato questa fiducia inviando inviti fasulli che contenevano offerte commerciali non correlate, che andavano dalla rivendita di prodotti ai servizi SEO.

Ogni e-mail indirizzava i destinatari a contattare i truffatori tramite un numero di telefono WhatsApp, una tattica spesso legata a schemi di frode.

L’inganno funziona perché i sistemi di sicurezza tendono a fidarsi dei messaggi provenienti da servizi Google legittimi. Sfruttando l’infrastruttura di Google Classroom, gli aggressori sono stati in grado di aggirare alcuni livelli di sicurezza tradizionali, tentando di raggiungere le caselle di posta elettronica di oltre 13.500 aziende prima che le difese venissero attivate.

Anatomia della campagna

• Scala: 115.000 e-mail di phishing inviate tra il 6 e il 12 agosto 2025.
• Obiettivi: 13.500 organizzazioni in tutto il mondo, in diversi settori.
• Esca: Falsi inviti a Google Classroom contenenti offerte non correlate all’istruzione
• Invito all’azione (call to action): Un numero di telefono WhatsApp, progettato per spostare la conversazione al di fuori della posta elettronica e del monitoraggio aziendale.
• Metodo di consegna: Cinque ondate principali, ognuna delle quali ha sfruttato la legittimità di Google Classroom per eludere i filtri.

Come Check Point ha bloccato l’attacco

Nonostante l’uso sofisticato da parte degli aggressori della fidata infrastruttura, la tecnologia SmartPhish di Check Point Harmony Email & Collaboration ha rilevato e bloccato automaticamente la maggior parte dei tentativi di phishing. Ulteriori livelli di sicurezza hanno impedito ai messaggi rimanenti di raggiungere gli utenti finali.

Questo incidente sottolinea l’importanza delle difese a più livelli. Gli aggressori utilizzano sempre più spesso servizi cloud legittimi, rendendo i gateway di posta elettronica tradizionali insufficienti a bloccare le tattiche di phishing in continua evoluzione.

Cosa devono fare le organizzazioni

• Educare: Istruire utenti, studenti e dipendenti a trattare con cautela gli inviti inattesi (anche quelli provenienti da piattaforme familiari).
• Prevenzione avanzata delle minacce: Utilizzate un rilevamento basato sull’intelligenza artificiale che analizza il contesto e l’intento, non solo la reputazione del mittente.
• Monitorare le applicazioni cloud: Estendete la protezione dal phishing oltre le e-mail anche alle app di collaborazione, alle piattaforme di messaggistica e ai servizi SaaS.
• Difendersi dall’ingegneria sociale: Essere consapevoli che gli aggressori spingono sempre più spesso le vittime verso comunicazioni al di fuori dei canali “ufficiali” (come WhatsApp) per eludere i controlli aziendali.

Gli aggressori continuano a trovare modi creativi per sfruttare servizi legittimi come Google Classroom per ottenere fiducia, aggirare le difese e raggiungere obiettivi su larga scala. Con oltre 115.000 e-mail in una sola settimana, questa campagna evidenzia la facilità con cui i criminali informatici possono armare le piattaforme digitali a scopo di frode.

Riconosciuto come Leader e Outperformer nel GigaOm Radar 2025 per l’Anti-Phishing, Check Point Harmony Email & Collaboration fornisce la difesa avanzata e stratificata necessaria per proteggere le organizzazioni dagli attacchi di phishing, anche quando si nascondono in bella vista.

L'articolo Phishing in Classe! 115.000 email per 13.500 organizzazioni con Google Classroom proviene da il blog della sicurezza informatica.

NO INCENERITORE: LIBERI DAI VELENI DI ROMA È UN PATTO PER IL FUTURO
“No all’inceneritore” è stato lo striscione che Carla, attivista di Albano, ha confezionato con le sue mani per consegnarlo a bambine e bambini che, con orgoglio hanno poi portato lungo tutto il percorso del corteo. Con quella luce negli occhi che solo i più piccoli sanno sprigionare, erano a decine, tanto da formare con le loro mamme e papà una testa del corteo numericamente tanto significativa da separare, a grande distanza da tutti loro riempita, lo striscione liberi dai veleni di Roma che gli attivisti dell’Unione dei Comitati hanno condiviso con i tre Sindaci di Albano, Ardea e Pomezia. Il “No all’inceneritore” è stato il coro continuo che ha accompagnato tutto il corteo fino alla Chimec, primo stabilimento a rischio di incidente rilevante (RIR), situato a poche centinaia di metri dal terreno di Ama. L’elevata concentrazione di stabilimenti RIR, quattro nella sola area di Santa Palomba, fa dell’area un’area a elevato rischio di crisi ambientale e in quanto tale inidonea a ospitare l’impianto.
In migliaia siamo partiti per arrivare davanti alla Chimec dove ci sono stati gli interventi istituzionali aperti da Veronica Felici, Sindaco di Pomezia, Maurizio Cremonini, Sindaco di Ardea e Massimiliano Borrelli, Sindaco di Albano. Per il Municipio 9, il sito ricade nel suo territorio, il Consigliere Massimiliano De Julis; gli interventi istituzionali sono terminati con Alessandra Zeppieri, Consigliera alla Regione Lazio. Al corteo i consiglieri comunali di Pomezia Giacomo castro e Renzo Mercanti, di Albano Salvatore Tedone e Barbara Cerro, consigliera di Marino.
La fiaccolata che al ritorno ha concluso il corteo ha reso ancor più suggestiva la straordinaria mobilitazione a sostegno di “liberi dai veleni di Roma”, una mobilitazione che ha coinvolto in donne e uomini consapevoli che la difesa della Terra dove viviamo, della salute di tutti noi e delle generazioni che verranno, dell’ambiente e di un paesaggio senza eguali passa per l’impegno in prima persona. Liberi dai Veleni di Roma diviene così un patto per il futuro della Terra dove viviamo capace di coinvolgere cittadini e istituzioni anche nei passi successivi.
Infatti, a sostegno della nuova petizione abbiamo raccolto oltre seimila firme, gran parte delle quali nei martedì estivi in presidio al sito. La prossima settimana intendiamo far valere tutte quelle firme davanti al Parlamento perché tutte le forze politiche comprendano che va posta fine alla stagione di Gualtieri posto al di sopra della legge per effetto di una norma che ha favorito e legalizzato l’abuso di potere. A chiedere di cancellare il potere di ordinanza in deroga a tutte le pertinenti normative di settore sono le donne e gli uomini che pretendono che la legge sia uguale per tutti, Gualtieri compreso, e che Repubblica finalmente tuteli tutti noi, oltre quanto di nostro già facciamo, specialmente per quei meravigliosi piccoli che aprivano il corteo di ieri. È per loro che trasformeremo il sito destinato a emettere veleni per oltre trent’anni in un parco naturale con polo museale perché Santa Palomba siamo tutti noi che difendiamo il diritto al futuro della Terra dove viviamo. Liberi dai veleni di Roma è quindi il nostro patto per il futuro.

Ambiente, StopInceneritore, NoInceneritore, NoInceneritori, ZeroWaste, Rifiuti, Riciclo, EconomiaCircolare, NoAlCarbone, EnergiaPulita,