Kategorie

A new backdoor dubbed Mistic has been observed in financially motivated attacks targeting organizations in the insurance, education, IT, and professional services sectors. [...]

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.

Filename Description SystemSettings.exe Legitimate Windows application abused for DLL side-loading of the
malicious DLL SystemSettings.dll. SystemSettings.dll Main malicious SharkLoader DLL responsible for the core loader functionality. DscCoreR.mui An encrypted module that contains an embedded Cobalt Strike Beacon and the MinHook library. This module loads SyncRes.dat, installs a couple of API hooks, and executes the Beacon directly in memory. SyncRes.dat An encrypted DLL that is used to install multiple API hooks.

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.

Filename MD5 SystemSettings.exe D98F568496512E4F98670C61C97CB07A SystemSettings.dll AA3086BE652C8B20B0B29B2730D57119 DscCoreR.mui A514D1BB62D7916475946FE7C07AC0AA SyncRest.dat 9CBD560F820C95D7C38342CD558CB5C6 “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.

Hooked Windows APIs Detour function description CreateProcessA

• Saves all original CreateProcessA parameters for use in the parent process (PPID) spoofing routine.
• Creates a new thread that executes the process creation routine responsible for PPID spoofing.
  • Falls back to the original CreateProcessA if the thread creation fails.
• Identifies an svchost.exe process that has the same security context as the current SharkLoader process.
• Builds an extended startup attribute list to set the selected svchost.exe as the spoofed parent.
• Calls the original CreateProcessA with the modified parent attribute.

As a result, any new process created by the current process (primarily from the Cobalt Strike beacon) is spawned under svchost.exe instead of the current module process. CreateProcessW

• Saves all original CreateProcessW parameters for use in the PPID spoofing routine, which is executed through an APC-based mechanism rather than a dedicated thread compared to the CreateProcessA API hook.
• Schedules a delayed process creation (10 microseconds) through APC execution using CreateWaitableTimerW and SleepEx.
  • The timer callback performs the svchost.exe PPID spoofing logic, similar to the CreateProcessA spoofing routine.

As a result, new processes created via CreateProcessW by the current process (primarily from the Cobalt Strike beacon) are launched under svchost.exe through an APC-based execution mechanism OpenProcessToken

• Once hooked, the malware initializes jitasm to construct a direct syscall stub for NtOpenProcessToken at runtime.
• Invokes NtOpenProcessToken through the constructed direct syscall stub, redirecting the original API (OpenProcessToken) call flow.

AdjustTokenPrivileges

• Redirects the API call to a direct NtAdjustPrivilegesToken syscall stub constructed by jitasm.

OpenProcess

• Redirects the API call to a direct NtOpenProcess syscall stub constructed by jitasm.

WriteProcessMemory

• Redirects the API call to a direct NtWriteVirtualMemory syscall stub constructed by jitasm.

NtCreateUserProcess

• Redirects the API call to a direct NtCreateUserProcess syscall stub constructed by jitasm.

LoadLibraryA

• Redirects the API call to a function that resolves LdrLoadDll API using a ROR13-based API hashing algorithm.
• Uses the original parameters to invoke LdrLoadDll directly.
• If LdrLoadDll resolution or invocation fails, uses CreateTimerQueue and CreateTimerQueueTimer to schedule a 10-millisecond delayed execution of the original LoadLibraryA, with CreateEventW used for synchronization.

GetModuleHandleA

• Redirects the API call to a custom function that resolves the module base address through the following steps:
  • Enumerates loaded modules within the current process using CreateToolhelp32Snapshot, Module32FirstW, and Module32NextW.
  • Compares each enumerated module name with the module name provided in the API parameter.
  • Returns the module base address if a match is found.
• Falls back to the original GetModuleHandleA API if the custom resolution routine fails.

GetModuleHandleW

• Similar approach to the GetModuleHandleA API hooks above.

GetProcAddress

• The original GetProcAddress parameters are passed to the hook handler.
• The hook handler computes a Murmur32 hash of the requested function name.
• The hook handler parses the module’s PE structure and locates the export table.
• Each exported function name is hashed using the same Murmur32 algorithm and compared against the previously generated hash.
• If a hash match is found, the corresponding function address is returned. If no match is found, the call falls back to the original GetProcAddress.

LoadLibraryExA

• The hook handler redirects the API call to its original address. In short, the hooked LoadLibraryExA calls the original LoadLibraryExA function.

VirtualAllocEx

• Redirects the API call to a direct NtAllocateVirtualMemory syscall stub constructed by jitasm.

VirtualProtectEx

• Redirects the API call to a direct NtProtectVirtualMemory syscall stub constructed by jitasm.

VirtualProtect

• Redirects the API call to a direct NtProtectVirtualMemory syscall stub constructed by jitasm.

ResumeThread

• Redirects the API call to a direct NtResumeThread syscall stub constructed by jitasm.

GetThreadContext

• Redirects the API call to a direct NtGetContextThread syscall stub constructed by jitasm.

OpenThread

• Redirects the API call to a direct NtOpenThread syscall stub constructed by jitasm.

NtCreateThread

• Redirects the API call to a direct NtCreateThread syscall stub constructed by jitasm.

NtCreateThreadEx

• Redirects the API call to a direct NtCreateThreadEx syscall stub constructed by jitasm.

NtQueueApcThread

• Redirects the API call to a direct NtQueueApcThread syscall stub constructed by jitasm.

NtQueueApcThreadEx

• Redirects the API call to a direct NtQueueApcThreadEx syscall stub constructed by jitasm.

ExpandEnvironmentStringsA

• The detour redirects the API to a custom function that creates a new thread. That thread executes a routine that calls the ExpandEnvironmentStringsA API.

CreateFileMappingA

• The detour redirects the API call to a custom function that creates a new thread. Within the thread, it initializes thread-pool and timer objects, sets a threadpool timer for 10 ms and a waitable timer for 0.1 ms, then calls CreateFileMappingNumaA.
• If thread creation fails, CreateFileMappingNumaA is called directly without creating a thread.

MapViewOfFile

• The detour redirects the API call to a custom function that creates a new thread. The thread runs a similar thread-pool and timer setup to the previous function, resolves MapViewOfFileEx via GetProcAddress, calls it with zeroed arguments, and stores the return value.

UnmapViewOfFile

• The detour redirects the API to a function that tries to run the unmap (same API) in a new thread.
• The thread creates an event and timer queue, schedules a callback after 10 ms to call UnmapViewOfFile and signal the event, then waits and cleans up.
• If thread creation fails, it calls UnmapViewOfFile directly.

NtMapViewOfSectionEx

• Redirects the API call to a direct NtMapViewOfSectionEx syscall stub constructed by jitasm.

NtCreateNamedPipeFile

• Redirects the API call to a direct NtCreateNamedPipeFile syscall stub constructed by jitasm.

NtReadFile

• Redirects the API call to a direct NtReadFile syscall stub constructed by jitasm.

NtWriteFile

• Redirects the API call to a direct NtWriteFile syscall stub constructed by jitasm.

EtwEventWrite

• The detour redirects EtwEventWrite to a stub that always returns 1, which prevents ETW logging.

EventWriteEx

• The detour redirects EventWriteEx to a function that always returns 0, which prevents ETW logging.

EventWrite

• The detour redirects EventWrite to a function that always returns 0, which prevents ETW logging.

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:

Tool name Description FScan Network scanner tool with vulnerability
exploitation modules Searchall Sensitive information search tool Pillager Information gathering tool

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 [email protected].

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

Few things are as delightfully divisive as Android’s dark mode.

Some phones now ship with Android’s darker-style interface activated by default. Most reasonably recent devices offer it as a swift ‘n’ simple toggle. And most people, in my experience, have amusingly strong preferences about which approach they prefer — the standard Android “light” mode, in which screens tend to be bright and with shades of white as a foundation, and the dark mode (a.k.a. “dark theme”), where black and dark gray dominate and everything is much more muted and muddy.

It really is a night and day difference, so to speak — but no matter where you fall on the light vs. dark preference spectrum, it’s well worth your while to noddle over two pertinent points:

1. Android’s dark mode doesn’t have to be an all-or-nothing decision. With the right setup, you can use it as a dynamically activated sometimes switch that enables itself automatically based on different variables and gives you a darker, less glary motif when conditions call for it while leaving you with the lighter, brighter look the rest of the time.
2. Regardless of how often you’re using dark mode, a few easy adjustments will make it meaningfully more complete and effective as an end-to-end interface style for whatever you’re doing on your device.

It occurred to me recently that we’ve gone over several smart Android dark mode enhancements over the past weeks and months — and that, put together into a single power-pack bundle, these small-seeming items can add up to create a pretty dramatic difference in your Android-using experience, whether you’re a full-fledged dark mode convert or a more light-preferring vampire skeptic.

Here, specifically, are five easy ways to make Android’s dark mode meaningfully better for you.

[Keep the nerdy knowledge coming with my free Android Intelligence newsletter — something new and useful in your inbox every Friday!]

Android dark mode power-up #1: The app expansion

Up first is a feature that arose as part of our Android 17 discussion and sparked the entire idea for this collection — and that’s the one-tap switch in the latest Android version that forces every app on your phone to follow your dark mode preference, whether the program technically supports such a setting or not.

In Android 17, finding and flipping that switch will make every app turn dark whenever the system-wide dark mode is active. It eliminates the irksome exceptions that’ve traditionally stayed stubbornly light (due to developer laziness) even when your dark theme is on.

If you’ve got Android 17 on your phone already, it couldn’t be much easier to make it happen. Just look in the Display section of your system settings, tap the words “Dark theme,” then change the setting that shows up next from “Standard” to “Expanded.”

Android’s new “Expanded” option lets you force apps into dark mode compliance, even if they aren’t designed to do it on their own.

JR Raphael, Foundry

No Android 17? No problem: On devices with reasonably recent pre-Android-17 system software, you can actually find a switch buried deep in some developer settings that’ll let you enable the exact same option without any waiting.

Follow these instructions and enjoy your new universally consistent darkened dynamic.

Android dark mode power-up #2: A darkened web

That first trick fixes the issue of certain apps not following your dark mode preference — but what about the web? Most of us spend a fair amount of time in our browsers these days, and most websites won’t follow a dark mode setting and adjust their interfaces accordingly.

They absotively can, though. With the flip of a single switch buried within your browser’s bowels, you can force every website into a darkened motif whenever your system-level dark mode is up and running.

See?

Viewing a website in Chrome normally, at left, and with dark-mode-associated web darkening, at right.

JR Raphael, Foundry

Here’s the secret:

• Open up Chrome on whatever Android device you’re using. (And note that this will also work with any Chromium-based Chrome alternative, like Brave, Edge, or Vivaldi.)
• Type chrome:flags into the address bar.
• Type darken into the search box at the top of the screen that comes up next.
• See the line labeled “Darken websites checkbox in themes setting”? Tap the “Default” box beneath it, and change its setting to “Enabled.”
• Tap the blue “Relaunch” button at the bottom of the screen.

Now, when Chrome comes back a second or so later…

• Tap the three-dot menu icon in its upper-right corner.
• Tap “Settings” in the next menu.
• Scroll down until you see “Appearance.” Tap it, then tap “Theme.”
• Make sure the newly added box for “Apply dark theme to sites, when possible” — which we just magically made appear via our last little modification — is checked and active.

Chrome’s web-darkening option appears only after you’ve enabled an out-of-the-way flag.

JR Raphael, Foundry

And that’s it: From that moment onward, whenever your Android device is switched into its dark mode, any website you’re viewing within Chrome will automatically follow suit. Nothing more to it, and no further thought or action ever required on your part.

Not bad, eh?!

Android dark mode power-up #3: A dark mode schedule

Even as someone who isn’t into dark mode as a 24/7 sort of thing, I can definitely appreciate the presence of a dimmer, less glary look on my device in certain specific scenarios.

It’s incredibly easy to overlook or forget, but Google’s actually got a way to handle that for you. In fact, it’s been built into Android itself since 2020’s Android 11 release.

Just look in the Display section of your system settings and tap the line for either “Dark theme” or “Dark mode settings.” If you see a toggle alongside that line, make sure you’re tapping the actual words next to it — not the toggle itself.

Then look for the option to create a schedule.

An Android dark mode schedule, as seen in Google’s standard Android interface (at left) and in Samsung’s Android style (right).

JR Raphael, Foundry

You can create a time-based rule for when your device’s dark mode turns on and back off again, or — more intelligent yet — you can set it to automatically activate at sunset, wherever you are at any given moment, and then turn itself back off and switch you back over to light mode at sunrise.

You can also integrate dark mode into Android’s rarely noticed Bedtime Mode so that the screen getting dimmer is part of your pre-sleep winddown routine, if you really wanna get wild.

Or — ahem…

Android dark mode power-up #4: Contextual dark mode

A dark mode schedule is pretty forkin’ sensible. But the reality is that even with a time-based setup or a sunset-driven activation approach, you’ll still be using your phone in bright rooms with dark mode active and vice-versa.

And if you want Android’s dark theme present only when you’re actually in a dark room — as makes the most sense in my mind — there’s an even more intelligent option.

It comes our way via a handy little free app called Adaptive Theme. That app does one thing and only thing only: It automatically adjusts your device’s dark mode setting based on the actual ambient light around you, using your phone’s sensors rather than an arbitrary time or a not-always-relevant sunset status as a guide. It makes so much sense, you’ll find yourself wondering why your phone didn’t just work that way from the get-go.

The app does unavoidably have a slightly complex one-time setup, which I outline step-by-step here. It’s perfectly safe to do, though, and it shouldn’t take you more than a couple minutes to pull off.

And once you’ve done that, your Android dark mode will just work for you — flipping on when the lighting around you is dim (to your exact specifications) and flipping back off when you’re in brighter surroundings.

Adaptive Theme lets you take total control of how and when Android’s dark mode activates based on your environment.

JR Raphael, Foundry

Yes, please — and thank you. Last but not least…

Android dark mode power-up #5: The wallpaper wizard

Superficial as it may seem, the one piece of the puzzle we haven’t yet addressed — that isn’t ordinarily affected by Android’s dark mode setting — is your home screen wallpaper.

By default, whatever wallpaper you set at the system level stays the same even as your interface moves between its dark and light states — and when you’re anglin’ for a dimmer, less glary look in dark environments, that can be pretty darn jarring.

An app called, rather aptly, Dark/Light Wallpaper Scheduler is the answer you never knew you needed. It’s pretty self-explanatory — you tell it which wallpaper you want when your phone is in dark mode and light mode, then it automatically switches ’em out for you based on that status — but I wrote about it in detail here, if you’re interested in reading more about how exactly it works and how you can make the most of it.

And with that, my fellow Android-appreciating animal, your dark mode power-pack is complete. Now, would someone please turn off the lights? I don’t know about you, but all this talk of darkness has me hankering for a nap.

Wake up to even more useful Android wisdom every Friday with my free Android Intelligence newsletter — one practical new trick to try each week, straight from me to ye.

The U.S. Department of Justice (DoJ) on Tuesday announced the seizure of a cloud computing account put to use by subsidiaries of Cambodia-based corporate conglomerate HuiOne Group, as the Treasury unveiled fresh sanctions against nine individuals and 26 entities linked to Prince Group. "These subsidiaries are alleged to have assisted individuals and organizations in transferring proceeds of Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]

Threat actors have begun to exploit a recently disclosed critical security flaw impacting Cisco Unified Communications Manager (Unified CM) and Unified Communications Manager Session Management Edition (Unified CM SME). The vulnerability, tracked as CVE-2026-20230 (CVSS score: 8.6), is a case of improper input validation for specific HTTP requests that could allow an unauthenticated, remote Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]

An extensive program at Meta to gather a wide range of data from employees to train its AI model has been frozen after employees reportedly broke through its guardrails and accessed restricted data, and then did so again after Meta claimed to have fixed the vulnerability.

Whether or not the data collection by the $201 billion owner of Facebook was a good idea, analysts argue that the data protections deployed were woefully inadequate, given the extreme sensitive nature of the collected data.

“Meta had the resources to get it right, and yet they failed exponentially,” said Karianne Michelle, a director with consulting firm Acceligence. “That is what it looks like when the policy decision and the technical execution are happening in two different rooms that are not fully in sync. It is the kind of gap you see often enough at organizations under structural strain.”

Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group,  agreed.

“What we just observed from the Meta story is a classic failure mode in AI-era data strategy: collecting high-risk telemetry without equally mature access controls,” Jean-Louis said. “At that scale, a single misconfiguration turns internal data into a systemic exposure.”

The story, detailed in a Wired report, involved a program that Meta rolled out in April called the Model Compatibility Initiative (MCI), which collects computer inputs such as mouse movements, click locations, and keystrokes, as well as screen content, the story said. Meta employees were initially not allowed to opt out. 

The data collected included full prompts and transcriptions, private conversations, people and performance data, Wired said, adding, “Meta executives have repeatedly defended the data-gathering project, saying it was necessary to train AI systems to operate computer software the way humans do, and that employees were the best examples for the artificial intelligence to learn from.”

Wired also quoted Stephane Kasriel, a Meta vice president overseeing AI research, who saying that the company discovered that unauthorized employees were found to have accessed MCI data on June 18, and that the hole was closed “within four hours.” But, he added, “ the initial fix didn’t stick, and access to the data had to be further locked down.”

In an email statement, Meta confirmed that the program was being halted for the time being. “We have carefully designed this program with privacy safeguards, and while we have no indication at this time that any data was improperly accessed by Meta employees, we’re pausing it while we investigate,” Meta said. 

A ‘liability surface’

Analysts, consultants, and industry practitioners said they were more concerned about the inadequate protections than the underlying data exposure.

Carmi Levy, an independent technology analyst, said that although there should be concerns about Meta’s “Orwellian oversight of workers’ keystrokes and mouse movements,” the bigger issue is the paper-thin protections that it used to protect that data.

“As creepy as MCI was and is, the reason Meta has hit the pause button has nothing to do with the moral and ethical fuzziness of everyday employee surveillance, and everything to do with its failure to secure the data it collected in the process,” Levy said. “Conceivably, it will resume monitoring and data collection once it fully understands how highly sensitive data, such as employees’ private conversations, performance data, and transcriptions, ended up being inadvertently shared with the entire workforce.”

One of the critical background issues is that while the data collected was highly sensitive, it was not, from a strict compliance law perspective, PII (personally identifiable information). That distinction might have lulled Meta into a false sense of security and convinced it that the data did not merit strong protections. 

“I think companies can get a little too comfortable saying, ‘Well, it’s not PII,’ as if that makes the data low-risk,” said Tom Findling, CEO of Conifers.ai. “But internal prompts, transcripts, chats, data tables, and performance notes can tell you a lot about how a company works, what it’s building and where things are messy or exposed. That’s sensitive, even if it’s not someone’s Social Security number.”

Findling argued that Meta executives “wanted to pretend that they didn’t understand” how sensitive the collected data was, and that was their excuse for why they should not have to protect it sufficiently. “There is no doubt that Meta did not tag this at an appropriate risk level,” he said.

Info-Tech’s Jean-Louis took particular umbrage at the particulars of the collected data. 

“Employee behavioral data, such as keystrokes, screenshots, and usage patterns, is effectively sensitive by default. If you’re using it to train AI, you have to treat it like production secrets, not analytics exhaust,” Jean-Louis said. “When thousands of internal tables are broadly accessible, you have a liability surface rather than a data platform. Trust nowadays is a security control. Once employees believe their data is overcollected or underprotected, you introduce both insider risk and reputational damage at the same time.”

Acceligence’s Michelle echoed Jean-Louis’ concerns.

“The data Meta exposed is not the real risk. Security policy only works if people believe it, and belief is exactly what is now in question,” Michelle said. “That gap is where incidents like this one do their damage: once employees stop trusting what leadership says about their own data, the doubt follows every policy that comes next, producing workarounds, quiet noncompliance, and employees who stop raising flags.”

This article originally appeared on CSOonline.

The White House is drastically shortening the deadline for government agencies and organizations to adopt new quantum-resistant encryption systems that will withstand attacks that use quantum computers, as the federal government seeks to protect decades’ worth of secrets belonging to militaries, banks, governments, and most individuals on Earth.

The executive order, titled Securing the Nation against Advanced Cryptographic Attacks, requires computing systems for “high-value assets” and “high-impact systems” to transition to post-quantum cryptographic key establishment schemes by December 31, 2030, and to quantum-safe digital signature schemes by December 31, 2031.

Heading off a significant threat

The new deadline, which for many organizations is about five years sooner than the previous one, comes on the heels of recent research showing that the resources and cost for building a cryptographically relevant quantum computer are far less than previous consensus estimates. In response, Google, Cloudflare, and other companies recently tightened their timelines for moving off vulnerable systems to 2029.

Read full article

Comments

A high-severity SSRF vulnerability, tracked as CVE-2026-20230, in Cisco Unified Communications Manager Server is now being exploited in attacks. [...]

Tata Electronics has confirmed in a statement to BleepingComputer that it was the target of a cyberattack that impacted parts of its IT infrastructure. [...]

​​Microsoft has released the KB5095093 preview cumulative update for Windows 11 24H2 and 25H2, which fixes numerous bugs and begins rolling out new features, including the new Point-in-Time restore feature. [...]

The growing use of AI contributed to Oracle laying off 21,000 workers in a year, according to a Securities and Exchange Commission filing on Monday.

In its annual regulatory filing for the fiscal year ending May 31, Oracle said it has 141,000 full-time employees. In its 2025 filing, Oracle said it had 162,000 employees. The reported 12.9 percent reduction followed March reports of mass layoffs at the database management software company.

"[T]he adoption and deployment of AI technologies across our operations have resulted, and may continue to result, in reductions to our workforce," the filing reads.

Read full article

Comments

Healthcare technology company Xsolis says that sensitive data belonging to nearly 1.4 million individuals was compromised in a phishing attack that gave attackers access to its network. [...]

China’s e-commerce giant JD.com is preparing for a future where packages are delivered by robots instead of people. The company’s founder and chairman, Richard Liu, expects robots will “sooner or later” take over deliveries from the company’s roughly 700,000 couriers.

“It will definitely be robots delivering packages. But I really don’t want our 700,000 brothers to go without food and without jobs,” Liu said at the Asia-Pacific Economic Cooperation CEO Forum, according to the Financial Times.

He did not provide a more specific timeframe for the change. As part of the transition, Liu said JD.com has entered into agreements with about 120 schools to retrain couriers for new professions, including the repair and maintenance of robots.

The number of gig workers in China — including delivery drivers, chauffeurs, and factory workers on temporary contracts — is expected to reach about 320 million this year, according to Chinese researchers. At the same time, the youth unemployment rate stands at over 16%.

A new macOS ClickFix campaign is using Terminal commands to silently download, mount, and launch info-stealing malware from malicious disk image (DMG) files. [...]

A Russian-speaking initial access broker (IAB) driven by financial gain is assessed to be behind a large-scale credential-harvesting operation known as FortiBleed that has targeted over 430,000 FortiGate firewalls globally. The campaign, active since February 2026, involves collecting credential lists, searching for exposed services, brute-forcing accessible systems, and deploying bespoke Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]

Forty million UK iCloud users could be owed up to $100 (£77) each after a $3.9 billion (£3 billion) class action lawsuit against Apple was cleared for trial — and the company’s problems may be just getting started. 

For Apple, the worry is that this case could snowball to become yet another existential regulatory problem. The action was brought by consumer group Which?, which accused Apple of breaching UK competition law by giving its iCloud storage service preferential treatment and “trapping” customers with Apple devices into using iCloud. 

Trapping happy customers

Apple achieves this by encouraging its customers to sign up to iCloud for storage of photos, videos and other data while also making it difficult for them to use alternative providers to backup key data. The company also squeezes extra dollars out of customers by providing a stingy 5GB of storage for free, while putting important data including messages and photos inside that allocation. Even Google provides 15GB of storage in its free tier.

The problem is that the scale of Apple makes it difficult for competitors to reach customers with alternative solutions, while Apple’s control over the operating system gives it integration advantages third-party competitors don’t get. 

While there may well be justifications for constraining access to some personal data, those privacy and security challenges don’t apply to all of it. 

You are the product

When it originally filed the claim, Which? explained that Apple could resolve the claim without litigation by offering consumers their money back and opening up iOS to allow users a real choice for cloud services. This is unlikely to happen.

This case has been slowly making its way through the Competition Appeal Tribunal, which last week finally gave permission for the case to go to trial.

Apple won’t be looking at a hefty fine just yet. The first available trial date is in October 2028 and the legal fight is expected to last nine weeks, which might, or might not, equate to a Christmas surprise for Apple’s then CEO. There’s no time to sit back, however, as the company must still file its defense papers with the court by the end of next month, July 31.

The snowball factor

The UK is not alone. Italy has launched its own antitrust probe into Apple’s iCloud dominance under the EU’s Digital Markets Act (DMA). The problem with that litigation is that since Italy has commenced the probe, other nations across the bloc might also act.

Italy is looking to see whether Apple has failed to open up its iOS and iPadOS ecosystems to rival cloud services, arguing that third-party providers are unable to access the same system components as iCloud. The DMA insists competitors should enjoy the same degree of access as iCloud because Apple is seen as a gatekeeper, which means it is required to meet a higher set of standards.

Apple, of course, will inevitably — and rightly — argue that customer privacy needs to be protected, and that open, free, access to some of the data its trusted iCloud service can use is not in the consumer interest. 

The company has already proposed one way in which it can provide third-party services with access to confidential data with a trusted intermediary system that anonymizes that information in use. 

Why we need a Trusted System Agent model

That’s precisely what it offered Europe when it proposed a solution called Trusted System Agent — an intermediary that would allow virtual assistants to safely access the same features and capabilities as Siri AI for devices in the EU. Unfortunately, EU regulators didn’t accept Apple’s justification concerning the need to protect customer privacy, which is why Apple Intelligence won’t be available in Europe for a while, if at all.

In the event Apple’s iCloud service falls short of the Italian probe and therefore the DMA, the danger is that if EU regulators take the same evangelically hard-line stance with iCloud services as they have done so far with AI, customers might find themselves losing access to the service. 

First blood

That’s in Europe, of course. But the UK case is likely to get to court long before litigation processes in Europe get going, making the UK action an important test case in which yet another important component of Apple’s offering to consumers is up for trial.

Please join me on social media at BlueSky,  LinkedIn, or Mastodon, even better, please subscribe to The Core for your daily fix of human-curated Apple News.

Two members of the 'Scattered Spider' cybercrime group pleaded guilty to hacking the Transport for London (TfL) systems in 2024. [...]

Security firm AIR built a fake AI agent skill, pushed it through a popular skill marketplace and an Instagram ad, and says it reached roughly 26,000 agents, including some on corporate accounts. Every skill security scanner the firm tested it against marked it safe. The payload was harmless by design: it collected the user's email address and did nothing else. The point was to show Swati Khandelwalhttp://www.blogger.com/profile/[email protected]

President Trump signed an executive order on June 22 setting hard deadlines for federal agencies to move high-value assets and high-impact systems to post-quantum cryptography. Key establishment must move by December 31, 2030; digital signatures by December 31, 2031. EO 14409 leaves national security systems on a separate track. The deadlines matter because of a threat that does notSwati Khandelwalhttp://www.blogger.com/profile/[email protected]

When a production server spikes at 99% CPU or the disk starts grinding, the knee-jerk reaction is usually to blame a bad code push or a runaway backup job. But if you’ve spent enough time in security incident response, you know that "performance issues" are often the first sign that you’re dealing with Linux malware.