iButtons are microchips housed in small, round, metal containers, and are similar to coin cell batteries in appearance. Among other things, they’re used for logging data in industrial contexts, particularly where it’s desirable to track parameters like temperature over time. [Geoffrey Wells] has worked with these sensors, and decided that the aging solutions for reading these devices are too cumbersome and out-of-date. Thus, he designed ChillPoint as a more modern solution.

As you might have guessed by the name, [Geoffrey] was inspired to build a rig specifically for inspecting iButton data loggers in cold chain logistics applications. It’s built around an ESP32-C6, which has a 1-Wire probe on the front for communicating with the target device. On contact, the reader dumps all the data, storing it on its own flash storage. The data can then further be accessed by connecting to the ChillPoint handheld device over its own WiFi access point, upon which it hosts a web UI for access. The handheld can be used for scanning iButtons single-handed, while a smartphone, tablet, or laptop can be used as a screen to monitor the results live.

The project is nearing completion, and [Geoffrey] says both the hardware and software will be open source once it’s all said and done. Anyone interested in adding a ChillPoint to their toolbox should keep an eye out for its upcoming CrowdSupply campaign.

If you find yourself working with these devices on the regular, this project may be appealing to you. We’ve looked at iButtons many times over the years.

hackaday.com/2026/06/24/a-more…

Introduction

During our research of activity affecting a diplomatic organization in Indonesia, we uncovered a previously undocumented malware family that we have named SharkLoader. What initially appeared to be an isolated case quickly expanded into a broader campaign as we identified additional SharkLoader infections across multiple countries and sectors.

Our investigation revealed that SharkLoader serves as a loader designed to deploy Cobalt Strike Beacon on compromised systems. We observed the threat actor deploying SharkLoader through exploitation of internet-facing applications, including Microsoft Exchange, Microsoft SharePoint, and Openfire Server, as well as through malware-based delivery mechanisms.

Beyond the diplomatic entity in Indonesia, we identified related activity targeting government organizations in Taiwan, software development companies across multiple countries, and entities in other sectors located in Hong Kong, Lebanon, Syria, Colombia, North Macedonia, Nepal, Serbia, and more. The observed victimology suggests a campaign with broad geographic reach and a diverse target set rather than a narrow focus on a specific industry or region.

For now, we are tracking this activity as StrikeShark. Although the operators utilize several open-source post-compromise tools associated with Chinese-speaking developers, we have not identified direct code reuse, infrastructure overlap, or operational similarity to confidently attribute the activity to any known APT or cybercrime group. As a result, attribution remains preliminary and the campaign’s ultimate objectives are still under research.

Initial infection

Our analysis of SharkLoader intrusions indicates that the threat actor employs multiple methods to gain initial access to victim environments. During our investigation, we observed two primary infection vectors: the exploitation of vulnerabilities in internet-facing applications and the deployment of custom dropper samples, some of which were disguised as legitimate software.

Exploitation of public-facing applications

In the incident affecting an Indonesian diplomatic entity, the threat actor exploited Microsoft Exchange vulnerabilities, including CVE-2021-26855 (ProxyLogon), to gain access to the target environment. Similar activity was observed in Taiwan, where software development organizations were compromised through exploitation of Openfire (CVE-2023-32315). In a separate incident affecting a Colombian organization, the threat actor exploited a GeoServer instance vulnerable to CVE-2024-36401.

Beyond these incidents, we identified additional exploitation activity targeting vulnerabilities in multiple internet-facing enterprise applications and network appliances including those listed below:

Remote Code Execution (RCE)

• Apache Shiro: CVE-2016-4437
• Hikvision Products: CVE-2021-36260
• Microsoft SharePoint: CVE-2021-27076
• Zimbra Collaboration Suite: CVE-2022-27925
• Microsoft Exchange Server: CVE-2022-41082
• F5 BIG-IP system: CVE-2023-46747
• Fortinet FortiOS: CVE-2024-21762
• React Server Components: CVE-2025-55182

Authentication Bypass

• Fortinet FortiOS: CVE-2022-40684
• Cisco IOS XE Web UI: CVE-2023-20198

As of the time of writing this article, we haven’t obtained the exploits the attackers used. However, based on the vulnerabilities observed across multiple attacks, we assess with medium confidence that the threat actor primarily relies on publicly available proof-of-concept (PoC) exploits to gain initial access. All the vulnerabilities identified during our investigation have publicly available exploit code, including PoCs hosted on GitHub and other open-source platforms, suggesting the actor leverages existing offensive resources rather than develops custom exploit capabilities. The victim profile also indicates that the activity is largely opportunistic, affecting organizations across various industries, regions, and technology environments without a clear focus on a specific target set. Also, one of the IP addresses associated with the C2 domain was also observed conducting internet-wide scanning activity, potentially aimed at identifying and exploiting vulnerable internet-facing systems at scale.

Following exploitation, the attacker established persistence on compromised servers through the deployment of webshells. Although we were unable to recover the webshell files, a series of commands whose execution we observed in our telemetry along with the detection records of webshells strongly indicate their use for post-exploitation activities.

One of the earliest observed actions involved copying the legitimate Windows application SystemSettings.exe to a new location before executing it.
cd C:\Windows\ImmersiveControlPanel\
copy SystemSettings.exe C:\ProgramData\
cd C:\ProgramData\
SystemSettings.exe
This application was later abused as part of a DLL sideloading chain used to launch SharkLoader, which in this scenario was hidden in the malicious SystemSettings.dll library. We suspect that this DLL along with malicious encrypted files, which we’ll describe further, was uploaded through the webshell to the same directory as SystemSettings.exe.

In another case involving the exploitation of CVE-2021-27076, the threat actor launched SystemSettings.exe triggering the subsequent SharkLoader sideloading chain from different directories on the system, which suggests renewed operational activity in the victim environment. In some of the cases, they used security product vendor names as the directory names, allegedly to appear legitimate.
cd C:\ProgramData\KasperskyLab\
dir
.\SystemSettings.exe
cd %APPDATA%
dir
cd kasperskylab
dir
.\SystemSettings.exe

Dropper-based distribution

In several observed cases, the threat actor distributed SharkLoader through custom dropper executables masquerading as legitimate software installers or applications such as Google Update and Cisco AnyConnect. However, the exact delivery mechanism used to distribute these droppers remains unknown.

The observed dropper filenames include:

• GoogleUpdateStepup.exe
• AnyConnect-win-4.10.04071-predeploy-k9exe
• AutoUpdate.exe
• 319-pfd-8001-reva_traitement biologique_master.zip

In one of the samples we analyzed, the threat actor used a legitimate Cisco AnyConnect VPN installer as a lure. The custom dropper extracted zlib-compressed data embedded within its resource section, decompressed it into an MSI package, and wrote the file to %APPDATA%\reports\AnyConnect-win-4.msi. The MSI package was a legitimate Cisco AnyConnect VPN installer, which was subsequently executed via the ShellExecuteW API, making the user believe the custom dropper was a legitimate application.

While the Cisco AnyConnect installer was decompressed and executed, SharkLoader components were silently dropped into directories in %APPDATA% different from %APPDATA%\reports\ in the background, executing the malware loader once the installation process completes.

Malicious Cisco Secure Client installer

In addition to installer-themed lures, several SharkLoader droppers use decoy PDF documents to persuade victims to open the malicious file. However, not all samples employ this technique, as some droppers function solely as a delivery mechanism for SharkLoader without presenting any lure content.

Among the samples analyzed, most droppers write the decoy PDF to a subdirectory named aswerf within the %TEMP% directory, while others save the document directly to %TEMP%.

Analysing the sample shows the PDF files are stored within the dropper’s resource section under the resource name TELEMETRY and are compressed with zlib. Upon execution, the dropper extracts and decompresses the embedded PDF, writes it to disk using the same filename as the dropper executable but with a PDF extension, and launches it via cmd.exe /c to display the decoy document to the victim.

The following are examples of PDF documents extracted and displayed by the droppers during the deployment of SharkLoader.

Lure document 1. The document appears to be related to a biological treatment process and was produced by an engineering consultant

Lure Document 2. Translated title: Liquid Rocket Engine Design Program

In one dropper sample, discovered on a machine located in Lebanon (MD5: 1F65544978B8EA0E745E573B8EE9684B), the dropper extracts and decompresses SystemSettings.dll from zlib-compressed data embedded within the binary and writes it to %APPDATA%\xwreg. It also extracts and decompresses DscCoreR.mui and SyncRest.dat from resources named VAULTSVCD and UMRDPRDAT, respectively, and writes them to the same directory.

The dropper extracts SystemSettings.dll from the binary and retrieves encrypted components from the resource section

The dropper then copies the legitimate SystemSettings.exe application from C:\Windows\ImmersiveControlPanel to the target location to facilitate DLL sideloading. Across other SharkLoader dropper samples analyzed, the malware components were observed being written to either %APPDATA%\xwreg or %APPDATA%\xgdf.

SharkLoader installation

SharkLoader is composed of multiple components that work together to load and execute the final implant, a Cobalt Strike Beacon.

While the majority of SharkLoader samples analyzed rely on the sideloading of SystemSettings.dll, other variants leverage alternative DLL side-loading targets, including msedge.dll, PrintDialog.dll, and miracastview.dll, each of them leveraging a corresponding legitimate application.

Across the different variants examined, the encrypted modules were also observed using a variety of filenames, including:
GameInputInboxs32.mui
diagerr.xml
NtfsLog.etl
Ignored.Dat
VistaCompat.nls
The SharkLoader execution flow is as follows:

SharkLoader infection chain observed in the StrikeShark campaign

In the dropper-based infections, after deploying all required SharkLoader components, the dropper creates two scheduled tasks through the Windows Task Scheduler COM interfaces. Task names:

• OneDrive Standalone Update Task-S-1-5-21-4165425321-4153752593-2322023643-1000
• MicrosoftUpdateTaskUserS-1-5-32-2456537112-101246289-228944324-1000

Both tasks are configured to execute the copied SystemSettings.exe from the malware’s working directory (for example, %APPDATA%\xwreg or %APPDATA%\xgdf), triggering the side-loading of the malicious SharkLoader DLL.

The first scheduled task uses a time-based trigger that executes every five minutes, providing long-term persistence.

The second task is configured to execute every second, likely to ensure immediate execution of SharkLoader following deployment.

After a delay of approximately 1.5 seconds, the dropper removes the second scheduled task by using the Task Scheduler COM interfaces, leaving the first task in place to maintain persistence on the system.

SharkLoader DLL – Main implant

For the detailed analysis of the infection chain, we’ll focus on the SharkLoader components deployed by a malicious dropper named 一种异常状况的截图（包括操作系统和输入法版本）.pdf.exe (MD5: 24FCEBDEECBA65004FDB0923763D74FD), which was identified in a campaign targeting a government entity in Taiwan.

“PerfectDLL Hijacking” technique

Once the malicious DLL is loaded, SharkLoader implements a technique commonly referred to as “Perfect DLL Hijacking” and originally described by a security researcher named Elliot Killick on his blog. The purpose of this technique is to bypass the Windows loader lock and safely create a malicious thread via the CreateThread API without risking a deadlock.

According to Microsoft’s Dynamic-Link Library Best Practices, the Windows loader holds a synchronization object known as the “loader lock” while executing the DllMain function. This mechanism ensures that only one thread can perform DLL loading and initialization operations within a process at any given time. As a result, invoking APIs such as CreateThread or LoadLibrary from within DllMain can lead to deadlocks because the loader lock remains held throughout the execution of the function.

To avoid this issue, SharkLoader manipulates the process’s internal loader state to release the loader lock before invoking CreateThread from the DllMain execution path. By doing so, it attempts to execute its malicious code without triggering the loader-related deadlocks that can occur when threads are created while the loader lock remains held.

Implementation of the Perfect DLL Hijacking technique to bypass the Windows Loader Lock

Based on the code, SharkLoader first resolves the addresses of several undocumented loader structures within ntdll.dll, including:

1. LdrpLoaderLock: the critical section object used by the Windows loader to synchronize module loading and initialization operations
2. LdrpWorkInProgress: an internal loader state variable that tracks whether module initialization is currently in progress

After locating these structures, SharkLoader forcefully releases the loader lock by invoking LeaveCriticalSection on LdrpLoaderLock. It then decrements the value of LdrpWorkInProgress with InterlockedDecrement64, effectively marking the initialization process as complete.

Finally, the malware signals the loader completion event via SetEvent before creating a new thread to execute its malicious functionality. As a result, these actions manipulate the loader’s internal state and cause Windows to treat the DLL initialization process as having completed successfully. This allows SharkLoader to continue execution after forcefully releasing the loader lock, despite still operating from within the DllMain execution path.

Decryption and loading of >DscCoreR.mui

As shown in the previous section, the loader creates a new thread after escaping the Windows loader lock. This thread subsequently spawns a second thread responsible for decrypting and reflectively loading the encrypted file, DscCoreR.mui.

The routine first reads the encrypted file into memory and extracts the first 16 bytes to use as the Blowfish decryption key. It then initializes the Blowfish cipher by using custom P-array and S-box constants embedded in the loader and decrypts the file in ECB mode with the extracted key. Once decryption is complete, the resulting PE file is reflectively loaded into memory and executed without being written to disk.

Structure of the encrypted DscCoreR.mui file containing the 16-byte Blowfish key bytes followed by the encrypted PE bytes

The decrypted DscCoreR.mui file is a packed PE file with its MZ header removed, likely as an anti-analysis measure. After decryption, SharkLoader processes the PE image by parsing its headers, allocating memory for the image, mapping its sections, applying relocations, resolving imported functions, and setting the appropriate memory protections. Once the in-memory PE loading process is complete, the main loader, SystemSettings.dll, transfers execution to the entry point of the mapped image, which contains the packer stub.

The stub then unpacks the protected code, invokes the DLL’s DllMain function, and returns execution to SystemSettings.dll. Finally, SystemSettings.dll calls the exported function SetUserProcessPriorityBoost from the mapped DLL, triggering execution of the fully unpacked next-stage DLL.

DscCoreR.mui and SyncRes.dat DLLs

Within the decrypted and unpacked DscCoreR.mui code, the malware proceeds to load and decrypt a second encrypted file, SyncRes.dat, before reflectively loading the resulting DLL into memory.

The mapped DLL installs multiple API hooks by using Microsoft Detours, which will be discussed in the next section.

After mapping and loading SyncRes.dat for API hooks, the DscCoreR.mui performs installation of the Vectored Exception Handler (VEH) and then creates a thread in a suspended state that is later used to execute the Cobalt Strike Beacon shellcode. Additionally, to facilitate additional API hooks, it decompresses and loads the MinHook library and uses it to install hooks on the VirtualAlloc and Sleep APIs.

The DscCoreR.mui then decompresses the Cobalt Strike Beacon shellcode into the memory region associated with the suspended thread and then the suspended thread is resumed, resulting in execution of the beacon.

Decryption and loading of SyncRes.dat

To decrypt SyncRes.dat, the malware extracts a 16-byte AES-128 key and a 16-byte initialization vector (IV) directly from the file itself. The first 16 bytes of the file contain the AES key, while the subsequent 16 bytes contain the IV. The remaining file content consists of AES-encrypted data, which is decrypted using the extracted key and IV. Once decrypted, the resulting data reveals a PE image with its MZ header removed, similar to DscCoreR.mui.

Structure of the encrypted SyncRes.dat file showing the AES key, IV, and encrypted PE bytes

Similar to the decrypted DscCoreR.mui module, the decrypted SyncRes.dat file is also protected by an unknown custom packer. After decryption, the loader reflectively loads the PE image before transferring execution to the module’s entry point.

The entry point contains a packer stub responsible for unpacking the protected code in memory. Once the unpacking routine is complete, the malware invokes a specific exported function named StartEngineData, which serves as the primary execution routine of the third-stage DLL.

Before continuing with the DscCoreR.mui analysis, we will first discuss SyncRes.dat.

SyncRes.dat decrypted DLL: Multiple API hooks

The decrypted and unpacked SyncRes.dat DLL is primarily responsible for installing multiple Windows API hooks by using the Microsoft Detours library. After attaching all detour hooks, it calls DetourTransactionCommitEx to apply them in one commit.

The following table lists the hooked Windows APIs and their corresponding hook handler functions.

Upon completing the installation of API hooks via the decrypted SyncRes.dat, the DscCoreR.mui DLL proceeds with the remaining functions, which are discussed below.

VEH registration and access violation handling

Following the installation of the API hooks, the malware registers a Vectored Exception Handler (VEH) to monitor exceptions generated during runtime. The handler specifically checks for access violation exceptions (0xC0000005). When such an exception occurs, it retrieves the faulting memory address from the exception record and calls VirtualProtect to restore read, write, and execute (RWX) permissions to the corresponding memory page before resuming execution.

During our analysis, no access violations were observed. It is possible that this mechanism is intended to handle access violations that may occur under specific runtime conditions.

Thread creation for Cobalt Strike Beacon execution

The malware creates a new thread in a suspended state that is intended to execute the Cobalt Strike Beacon shellcode. The thread entry point is configured to point to a memory buffer that will later contain the beacon shellcode.

At this stage, the buffer does not yet contain the actual Cobalt Strike Beacon shellcode. Instead, the thread is created in a suspended state so that the malware can prepare and inject the shellcode into the buffer before execution. Once the beacon payload has been written into the buffer, the malware resumes the suspended thread using the ResumeThread API, which triggers the execution of the Cobalt Strike beacon.

MinHook DLL, API hooking, and Cobalt Strike beacon

After creating the suspended thread for beacon execution, the malware decompresses a zlib-compressed MinHook PE file embedded within DscCoreR.mui. The MinHook library is used to install API hooks for the VirtualAlloc and Sleep functions. Once the MinHook DLL is decompressed and loaded into memory, the malware resolves the exported functions MH_Initialize and MH_CreateHook, which are then used to install hooks on the VirtualAlloc and Sleep APIs.

After the hooks are installed, the malware invokes a function that decompresses a zlib-compressed Cobalt Strike Beacon shellcode embedded within the malware. The function first decompresses the shellcode into a temporary buffer and then allocates executable memory using VirtualAlloc with RWX permissions. The decompressed beacon is subsequently copied into the allocated memory region.

Because the VirtualAlloc API has already been hooked at this stage, the hook handler captures the address and size of the allocated memory used to store the beacon shellcode. The hook records the addresses and sizes of the first three successful memory allocations and stores these values in global variables to track specific memory regions allocated during execution. These tracked regions are associated with memory buffers used by the Cobalt Strike Beacon during runtime.

The second hook, on the Sleep API, is used when Cobalt Strike Beacon calls Sleep, such as during beacon sleep intervals. It temporarily modifies the memory protection of the tracked allocation regions by using VirtualProtect, changing their protection to PAGE_READWRITE (RW) before invoking the original Sleep function. After the sleep period ends, the malware restores the memory protection of those regions to PAGE_EXECUTE_READWRITE (RWX). This behavior suggests that the malware developer implemented this mechanism to evade memory scanning techniques that identify executable (RWX) code regions in memory.

Finally, after the API hooks are installed and the Cobalt Strike Beacon shellcode has been written to the thread buffer, the malware calls the ResumeThread API to resume the suspended thread and begin execution of the beacon.

Persistence mechanism

While the analyzed SharkLoader implant does not contain a built-in persistence mechanism especially when it comes to cases when it is dropped after the exploitation of a public-facing application, our investigations revealed that the threat actor employs several techniques to maintain access to compromised systems.

Registry Run key: In the incident that affected an organization in Hong Kong, the attacker manually created a registry Run key to launch SystemSettings.exe upon user logon. The following command was used:
reg add HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v "MFUpdate" /t REG_SZ /d "$appdata\Identities\SystemSettings.exe" /f
This technique allows the malware to automatically execute whenever the user logs in, ensuring persistent access.

Scheduled task: In the separate compromise that affected a diplomatic government entity in Indonesia, the attacker established persistence through a scheduled task configured to execute SharkLoader daily. The task, named "\Microsoft\Windows\Edge\Edgeupdate", was configured to run C:\ADriveLogs_Logs\SystemSettings.exe by using the following command:
Schtasks /create /s /u "" /p "" /ru "SYSTEM" /tn "\Microsoft\Windows\Edge\Edgeupdate" /sc DAILY /tr "C:\ADriveLogs_Logs\SystemSettings.exe /F"
Running the task with SYSTEM privileges ensures that SharkLoader executes even if no user is logged in.

Post-compromise activity

Following initial compromise and persistence, the attacker engaged in extensive reconnaissance and credential theft activities.

System information enumeration: The attacker initially gathered basic system information by using the following commands:
systeminfo
ipconfig /all
tasklist /svc
Post-exploitation tools: Our analysis revealed the use of several third-party post-exploitation tools, most of which are open-source and developed by Chinese-speaking developers. These tools included:

We also detected the use of SharpGPOAbuse by the threat actor, a tool designed to modify Group Policy Objects within Active Directory environments.

Active Directory enumeration: In the compromise affecting a diplomatic government entity in Indonesia, the attacker used both Cobalt Strike and a webshell to enumerate the internal Active Directory environment. They executed a series of commands to gather information about the network, users, and groups:

• Network information:
  ping -n
  netstat -ano
  arp -a
  net share
• User and group information:
  query user
  nslookup
  quser
  net group /domain
• Specific group membership:
  powershell "Get-ADGroupMember -Identity "" -Recursive | Select-Object Name, ObjectClass"
  dsquery group -name "" | dsget group -members -expand | dsget user -samid -display -email"
  powershell "Get-ADGroupMember -Identity "" -Recursive | Where-Object { $_.ObjectClass -eq "computer" } | Select-Object Name, SamAccountName"
  powershell -exec bypass -c "Get-ADUser -Filter * -Prop * | select sAMAccountName
  net group "Domain Controllers" /domain
  net group "Enterprise Admins" /domain
  net group "Organization Management" /domain
  net group "domain admins" /domain
• Process enumeration:
  tasklist /SVC | findstr $selfname.exe
• Directory listing:

dir \\c$
dir \\c$\inetpub
dir \\c$\inetpub\custerr
dir \\c$\inetpub\wwwroot\
Credential dumping: The attacker also attempted to dump credentials from the compromised machine by targeting both the LSASS process and the NTDS database file. The following commands were observed:
ntdsutil "ac i ntds" "ifm" "create full $temp" q q
Procdump64.exe -accepteula -ma lsass.exe $temp\lsass.dmp
Dumping the LSASS process allows the attacker to extract in-memory credentials, while accessing the NTDS database enables retrieval of Active Directory account password hashes. This combination of techniques allows the attacker to obtain privileged credentials for lateral movement, privilege escalation, and deeper compromise.

Victimology

The victimology observed in this campaign shows a combination of strategic and opportunistic characteristics. Confirmed victims include government-related entities, such as the ministry in Taiwan and the diplomatic organization in Indonesia, as well as software development companies in Taiwan, Lebanon, and Syria. Additional affected organizations were identified in Hong Kong, Colombia, Macedonia, Nepal, and Serbia.

Targeting of government and software development organizations may indicate a cyber-espionage objective, although our confidence remains low due to the limited post-compromise activity observed, which primarily consisted of credential access, system reconnaissance, and lateral movement. The compromise of government and software development organizations could indicate an interest in gathering political intelligence or intellectual property.

At the same time, the use of SharkLoader and Cobalt Strike, alongside the exploitation of public-facing applications and malicious installers and droppers, suggests the attacker may also be opportunistically targeting vulnerable systems. The absence of clear evidence of data exfiltration thus far does not exclude this possibility, as Cobalt Strike’s file operation and data exfiltration modules could be employed at a later stage.

Although the full scope of the campaign is not yet known, the combination of targeted and opportunistic activity suggests it should continue to be closely monitored.

Attribution

Our investigation reveals no code or infrastructure overlap linking SharkLoader to any existing threat actor at this time. The TTPs employed during the operation also do not align with those of known actors.

However, analysis of the post-exploitation open-source tools used during the campaign revealed that several reconnaissance tools, including FScan, Searchall, and Pillager, were developed by individuals identified as Chinese speaking developers on GitHub.

We assess StrikeShark to be a Chinese-speaking threat actor with low confidence. This assessment is based on limited indicators and should be considered preliminary. Further investigation is required to characterize this cluster more fully, and the possibility remains that other actors may also be utilizing these tools.

Conclusion

Our investigation discovered a previously undocumented intrusion cluster that we are tracking as StrikeShark. The StrikeShark campaign represents a sophisticated malware threat to entities worldwide. The use of SharkLoader to deploy Cobalt Strike, coupled with API hook installation to evade detection, demonstrates a significant level of technical expertise. The campaign’s broad targeting across sectors and geographic regions suggests a potential focus on espionage or information gathering. While the precise objectives remain under investigation, the combination of targeting government entities and software developers warrants heightened vigilance.

Given that our visibility is limited to incidents observed through Kaspersky telemetry, we suspect the actual number of compromises may be significantly higher and extend beyond these victims as the threat actor actively used several exploitations of public facing application.

Indicators of compromise

Additional information about this activity, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. If you are interested, please contact intelreports@kaspersky.com.

C559CC68986933200FD5D9E4388E2F58 Installer
B3352B42432DEDC4A519F011DC8B5D5A Dropper
24FCEBDEECBA65004FDB0923763D74FD Dropper
9C872A0D5D5A38950E8B9AC9B488BE3F SharkLoader DLL
AA3086BE652C8B20B0B29B2730D57119 SharkLoader DLL
A514D1BB62D7916475946FE7C07AC0AA Encrypted file
9CBD560F820C95D7C38342CD558CB5C6 Encrypted file
connect-microsoft[.]com
ms-record[.]com
ms-record[.]top
ms-tray[.]top

securelist.com/strikeshark-cam…

There is a phenomenon where as you get older, your sense of scale becomes somewhat fixed in the earlier era that shaped you– things like expecting the Dollar Store to carry items for 1$, or to get a burger and fries for less than twenty bucks– or, in this case, thinking of supercomputers as being petaflop-scale machines. That’s not wrong, per se– most of the world’s fastest machines benchmarks are best measured in petaflops– but when you’re clocking at 2198 of the things, it becomes easier just to say that the LineShine computer can do 2.188 exaflops. At double precision. With CPUs only. Yes, we are impressed.

Even more impressive is that this machine just debuted in China, which means it was built without the benefit of the latest-and-greatest Western chips, thanks to US sanctions. It’s using a made-in-China LX2 CPU with 304 ARMv9 cores onboard. Well, it’s actually using around 46 thousand of them, but who’s counting?

Each CPU actually consists of two separate compute dies and onboard high bandwith memory (HBM) and DRAM– 4GB of HBM and 32GB of DDR5. The 152 ARMv9 CPU cores on each chip are all built with Scalable Vector Extensions (SVE) and Scalable Matrix Extensions (SME), so despite the lack of GPUs LineShine will have no problem doing the sorts of vector processing that is traditional for high-performance computing, given the 13.79 million cores.

On the other hand, the lack of GPUs shows when you change benchmarks– LineShine is number one in the rankings for High Performance Linpack (HPL), but getting outside the 64-bit box, the supercomputer only hits number four on the HPL-MxP mixed-precision benchmark, behind machines that pair their CPUs with accelerators like GPUs or NPUs. That may mollify the American ego, as while their El Capitain was bumped to second place on the HPL list, they can still claim the pole position on HPL-MxP. Which computer is actually more capable depends entirely on what you want to do with it, and neither Lawrence Livermore National Laboratory nor China’s National Supercomputing Centre in Shenzhen advertise their compute queues, though this paper suggests at least one job will be crunching earth observation data.

The definition of a supercomputer has shifted over time, and it’s only a matter of time before LineShine and El Capitain end up on the auction block, like other supercomputers before them. We might question it when it comes to desktops, but for institutional HPC, no amount of computing ever seems to be enough.

hackaday.com/2026/06/24/linesh…

[Stefan] of CNC Kitchen has an informative video describing his experiences with trying to cleanly laser-mark 3D printed plastics using different methods, and it also happens to be a fantastic tour of all the different laser options available to hobbyists and workshops these days.

Laser marking is a fast and effective way to put things like product names, serial numbers, and other information on plastics. [Stefan] wondered whether laser options would be capable of creating clean and professional marks on 3D-printed items, and approached things with his usual attention to detail.

Great results can be had, but using the right tool and dialing in the right settings is critical to results.
How does a laser mark plastic? When the laser hits the material, its energy is dumped into it and can cause pigment bleaching, microfoaming, charring, melting, or ablation (vaporizing) of the surface. The goal is to have a combination of laser and material that delivers a crisp, high-contrast result.

There are several kinds of laser technologies easily available today, and of course a variety of filament types. [Stefan] printed a whole bunch of different PLA, PETG, ASA, TPU, and polycarbonate samples in different colors and tested them with different laser machines, including:

• UV laser (355 nm wavelength)
• Blue diode laser (450 nm wavelength)
• MOPA fiber laser (1,064 nm wavelength)
• CO₂ laser (10,600 nm wavelength)

So is it possible? Yes, but it’s still a bit of a fussy process. There isn’t a one-size-fits-all solution for marking plastic, because results depend a lot on the the right combination of laser type, settings, and target material. That being said, [Stefan] was able to obtain some really great results.

Overall the UV laser was the most suited to marking 3D-printed plastics. [Stefan] says it produced the cleanest results on the widest range of materials with the least fiddling. The MOPA fiber laser also worked, but is clearly more of a metal-marking tool. We’ve seen them etch super-fine PCB traces and while great results are possible it isn’t quite in its element with plastics. Other lasers could get good results under just the right circumstances, but are overall best suited to cutting tasks rather than marking thermoplastics.

Check out the video below for the full details, including some really fantastic closeups.

youtube.com/embed/jA-E5CGcBxI?…

hackaday.com/2026/06/24/all-th…

How do you measure the inside of a cave? You could do a bunch of hard work with classic surveying gear… or you could just use a laser scanner. [9nl] did the latter, with a scanning rig of his own creation.

The build is based around an Ouster VLP-16 mid-range lidar sensor. It shoots out pulses of light and measures how long it takes them to bounce back in order to determine the range of objects in the vicinity, and thus can be used to great effect for 3D scanning tasks. For [9nl], though, the sensor had a serious limitation. Since it only had a 40-degree field of view, it wasn’t ideal for the desired application of scanning a cave. However, by building a custom rig that could rotate the sensor, [9nl] ended up with a rig that could 3D scan an area through a full 360 degrees. There’s nothing wildly complex involved, just some good old mechanical engineering—putting the sensor on a shaft and spinning it with a belt drive. Then it’s just a matter of processing the data correctly. The hard part is then getting the rig in and out of the cave without breaking anything.

There are plenty of off-the-shelf 3D scanning solutions that can do this work, but few of them come cheap. Plus, rolling your own teaches you a great many things as you hone your solution to your particular needs. Video after the break.

youtube.com/embed/gx1AoM0YKCs?…

[Thanks to Kovy Jacob for the tip!]

hackaday.com/2026/06/24/laser-…

This week Jonathan chats with Tristan Sherliker about the Craig Wright case, Open Source and the law, and Tristan’s own Open Source project, BunTool. How did Open Source help win the day at the Bitcoin trial? And why is right now such an interesting time to be in the legal field? Watch to find out!

• 
  
  • twobirds.com/en/people/t/trist…
  • buntool.co.uk/
  • twobirds.com/en/insights/2024/…
  • Evidence Download

  
  

Full Ruling:

• judiciary.uk/wp-content/upload…

youtube.com/embed/YLw8pp0G6nY?…

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 have the guest 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

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

hackaday.com/2026/06/24/floss-…

There are lots of different ways to build a clock. [Sciter_] came into the possession of some old calculator parts, and decided to reuse them for just such a project.

The heart of the build is an ATmega328P microcontroller, running off of a 32.768 kHz crystal. This allows the chip’s counters to neatly divide down the frequency to get a steady 1 Hz pulse for accurate timekeeping. Time is displayed on a vacuum fluorescent display (VFD) harvested from an old calculator. These displays need rather high voltages to run, which in this case are produced by a HV5812 driver chip and supporting circuitry. The display itself is neatly cradled in a pair of copper pipe elbows for a stylish look, with some addressable RGB LEDs present to provide some charming underglow.

Power for the device comes from a single AA battery, using a transformer-based low voltage converter. Alternatively, it can run off a USB 5 V power supply, which also charges the NiMH AA cell while available with the aid of an LM2576-ADJ buck converter.

Overall, it’s a neat homebrew clock that taught [Sciter_] plenty during its construction, and not the first time we’ve seen somebody put together a clock with second-hand VFDs. If you’re finding fun ways to reuse old display tech, don’t hesitate to let us know on the tipsline.

hackaday.com/2026/06/24/vfd-cl…

The train was one of the game-changing inventions that defined the Industrial Age. No more would humanity rely on tempestuous animals to haul goods and passengers great distances across the land. Fire and steam came along to rapidly increase the speed of travel and transformed the very fabric of society itself.

To this day, the vast majority of train networks rely on the same basic principle—heavy locomotives and carriages running steel wheels on steel tracks. Yet, there is a curious alternative twist on this concept that sees trains of carriages riding on tires instead. But what would possess anyone to build a rubber tired train?

Where The Rubber Meets The Rail

An MP-05 running on the Paris Metro. Credit: Momo Ratp, CC BY-SA 4.0
The first practical rubber-tired train system came about in the wake of World War II. The Paris metro had been poorly maintained during the German occupation, and was in dire need of repair or replacement. The state-owned public transport operator RATP and tire supplier Michelin came to the table, developing a concept wherein vehicles running on pneumatic tires would ride on a flat steel or concrete “rollway.” The vehicles would also have backup steel wheels that run against a steel rail for safety, keeping the train upright in the case of a tire blowout. Guidance would be provided by extra rubber tires mounted to the wheel bogies on a vertical axis, running against a vertical guideway built into the track, in a manner not dissimilar from later O-Bahn systems.
An MP 89 CC consist running on line 6 of the Paris Metro at Corvisart station. These electric multiple units entered service in 1997. Credit: author
By the 1950s, when the concept was being seriously developed, steel-wheeled railways had been around for well over a century. They were the norm for good reason, but running rubber-tired trains did offer some advantages. The pliable tires would soak up vibrations, which was both good for passenger comfort as well as also virtually eliminating high-pitched squealing noises that are common on steel railways.

The rubber tires, running on concrete or steel surfaces, also offered greatly improved grip. This allowed the rubber-tired metro trains in Paris to climb much greater grades with ease, compared to traditional steel-wheeled railcars. It also aided in early automation efforts on the Paris Metro, as the higher grip level made it easier to ensure locomotives stopped at the right position when entering stations. Rail wear is also greatly reduced compared to steel-on-steel systems.
Note the guidewheels which run against the vertical guideways built into the track. Credit: author
Of course, rubber tires also came with some drawbacks. Tracks were more expensive to build due to the need to incorporate both rollways and guideways, and commonly a steel rail to supply electricity to the trains. Rubber tires don’t last as long as steel wheels, either, aren’t as robust, and are subject to blowouts when damaged. The flexing of pneumatic rubber tires also makes the trains less energy efficient, and generates more heat in operation, which can be a concern in underground operations. As tires break down, they also create particulate pollution which isn’t great for urban air quality or for the people breathing it in.
A bogie from an MP 89 of the Paris Metro, showing the main wheels as well as the guide wheels. Credit: Rama, CC BY-SA 2.0
The Paris Metro found the oddball concept to be of great use, particularly given some of the higher grades faced in certain parts of the network. In time, lines 1, 4, 6, 11, and 14 would all be retooled to the Michelin-designed system with rubber-tired railcars running on 1,435 mm rollways. Various airport routes would later adopt rubber tired services, too, as well as the Toulouse, Lille, Lyon, and Marseille metros as well.
Various rubber-tired metro systems have sprung up around the world. The basic concept is usually the same, though exact implementations differ. This system deployed in Sapporo, Japan, relies on a central rail guidance system, and was built by Kawasaki Heavy Industries. Credit: 出々 吾壱, CC BY SA 3.0
The system was not just limited to France, either. Mexico City found a rubber-tired metro to be the perfect transport solution, as the reduced vibrations were a massive boon given the area’s unstable soils. Other famous examples include the Montreal Metro in Canada, and lines 1, 2, and 5 of the Santiago Metro in Chile. Many other smaller-scale examples can be found around the world, often serving airport routes or shorter-distance lines.

Rubber-tired metros are unlikely to ever fully overtake more traditional steel-wheeled trains in popularity. There are more drawbacks than positives for most typical operations, particularly when it comes to maintenance and ongoing costs. Nevertheless, they have their place, particularly where grip is at a premium, grades are steep, or there is a keen desire to avoid excessive noise and vibration to keep the peace or avoid disturbing the subsurface. These rail-like curios stand out as a weird surprise treat for any railfan visiting Paris, or any of the other similar systems that can be found around the world.

hackaday.com/2026/06/24/the-tr…

As announced by [André] on Bluesky, next month the much loved Rpilocator.com website will cease displaying the stock status and pricing of Raspberry Pi computers from various online retailers.

One of the main reasons is that the indexing bot used by the site has been blocked by most shopping sites. It’s not clear whether this blocking is on purpose or just another consequence of website owners protecting themselves from the onslaught of obnoxious ‘AI’ scraping bots. But in any event, the effort of finding workarounds that may only work for a few days or weeks was becoming too much.

According to [André] there are still about 11,000 users of the site each month, which even when accounting for the human-bot ratio is still a sizable number of visitors who’ll now have to get their fix somewhere else. He also indicates that he receives numerous emails from presumably real people about the site to point out small issues they have noticed.

Although the site may still be back in the future, it’s also important to recognize how much the single-board computer landscape and raison d’être for this tracking site have shifted since the 2020s Chip Crisis days. Currently it’s less about finding where these boards are in stock, and more about taking the hits to one’s wallet as memory prices continue to spiral out of control. Making what were once fun, cheap little hobby boards into luxury items that cut into your rent-food-and-gas budget.

hackaday.com/2026/06/24/raspbe…