Learn

FIELD LOG 040

Four of these seven are somebody else's system failing into yours

Field Log // 040 Status Live Difficulty Free Cost Nothing
The Story

Seven items, and four of them are the same shape: a backup vendor's OAuth app, an npm package, an AI tool holding your provider keys, a federal court's contractor, and a refrigeration maintenance firm's remote access. None of those is a vulnerability in anything the victim ran. The lead item is the one that actually threatens self-hosted machines, and the last one is a backfill from a week ago that is still the best operational technology story of the month.

One. ConnectWise, continued, and the picture got much bigger. Yesterday we reported that a compromised ConnectWise Cloud Backup credential had been used to sign into 173 Microsoft 365 tenants. Here is what changed since. On 17 October at 07:00 UTC ConnectWise disabled seven application identities and suspended Cloud Backup by revoking certificates across all users. The seven are ConnectWise Cloud Backup, ConnectWise Cloud Management, and six service specific Cloud Management identities covering MS Teams, Exchange Online, MS Graph, Partner Center and SharePoint Online. ConnectWise says it identified the issue on 14 October through its own monitoring. SaaS Security and Cloud Management were also taken offline temporarily during the review.

The scale figures need reading carefully, because there are three different measurements going around and they are not one number. Huntress confirmed unauthorised sign ins in 173 partner and customer tenants, which is the figure we carried yesterday. Separately, almost 1,000 Entra tenants showed sign ins from the malicious address, and 300 of those succeeded. Separately again, a second and targeted wave hit 16 tenants in policy, national security, trade and critical minerals sectors, and those attempts failed. In some otherwise successful sign ins the absence of a service principal prevented access anyway. Those are three distinct things, not an escalating count of the same thing. Huntress last observed malicious sign ins from the original address at 15 October 08:45 UTC, with manual activity continuing to about 14:20 UTC.

On the service itself: scheduled backups are not running, and access to backup archives and restoration is unavailable. ConnectWise says existing archives remain encrypted, isolated and preserved, with no evidence they were breached or accessed. ConnectWise has not determined whether a product vulnerability contributed, and the credential exposure mechanism is still under analysis, so nobody including us should be asserting a cause yet.

There is an unresolved contradiction here and it is the single most actionable line in this item, so I am printing it as unresolved rather than picking a side. ConnectWise's list of disabled identities includes the Teams, Exchange Online and SharePoint Cloud Management apps. Huntress says those apps do not appear to have been disabled. Nobody has reconciled the two statements. Do not trust either one for your own environment: go and check the actual status of those app connections in your own tenant.

The part that generalises well past ConnectWise: this was application authentication, not user authentication. Your user MFA and your interactive Conditional Access policies do not apply to a service principal, and disabling an app does not invalidate tokens already issued or remove credentials an attacker already planted. A consented multi tenant app is a standing grant that your own MFA does not protect. That is the lesson worth keeping from this whole episode.

Two. Nextcloud's Collabora app, CVE-2026-110447, exploited in the wild for about a month before anyone got told. This is the lead item for anyone running their own server. It is an OS command injection in the Collabora Online Built-in CODE Server app, package name richdocumentscode, triggered by a malicious request to the app's proxy.php endpoint. No authentication and no user interaction required. There is one key prerequisite: the built in CODE server has to be stopped, which happens after a restart, an upgrade or a crash. Affected versions are richdocumentscode before 26.4.303, and the fix is 26.4.303 or later.

Before anyone panics, read the not affected list, because most Nextcloud operators are not exposed. Per Collabora, standalone Collabora Online servers are not affected, nor are Docker or RPM and DEB installations, nor Nextcloud All-in-One. This is only the optional built in CODE server app. If you have that app, though, note that disabling it is not enough. The vendor said so explicitly. You upgrade it or you remove it.

What attackers actually do once in: deploy PHP webshells, then use those to hunt for password databases, password manager artifacts and cryptocurrency wallets. Some users reported ransomware operators exploiting the flaw, but BleepingComputer could not independently confirm that, so treat it as unconfirmed. The timeline is the real story here. The fix was committed on 9 September. The earliest reported attacks were on 10 September, the day after. Version 26.4.303 was released on 11 September. In mid September Collabora reported it to Nextcloud and maintainers issued warnings. A community warning urging immediate updates went out on 3 October. The advisory and CVE were finally published on 14 October, and it was reported publicly on 15 October. So the flaw was being exploited for roughly a month before it had a CVE attached to it.

Collabora attributed the delay largely to GitHub CVE processing backlogs, which it said were strained by rising volumes of AI driven security reports. Nextcloud said the delay gave users time to update. Those are the two stated positions and I am not going to adjudicate between them, but the practical consequence is unambiguous: for a month, anyone whose process starts with a CVE feed had nothing to react to. The operational advice is to check for PHP webshells rather than just upgrading, because persistence was the point of the exercise.

No number of exposed or compromised servers has been disclosed, and Nextcloud said it had not observed widespread exploitation, so I am not putting a figure on it. I am also not giving a severity score, because the reporting does not carry one I have verified. The threat actors have not been named.

Three. An npm package called imgdecode hides a loader inside a compiled Node addon. Found by SafeDep. It was uploaded on 30 September 2026 by npm user malfexteste8, had roughly 979 downloads, and was still available on npm at the time of reporting, latest version 1.0.3. A nine line JavaScript file loads a Windows DLL. When a Node program calls require on imgdecode from a Windows console, the DLL downloads encrypted shellcode from GitHub, decrypts it, and injects the result into a new dllhost.exe process. Version 1.0.0 waited on a sibling package called imgbundle to write a file; from 1.0.1 the DLL does the download and decryption itself; 1.0.3 dropped the dependency entirely.

The evasion is the interesting part. The DLL checks whether it is running in a developer's terminal before doing anything at all. After decrypting its payload it inspects the first bytes of the output, and if they match a JPEG or PNG signature it stops. SafeDep infers that is a remote kill switch: the operator turns the loader off by serving an actual image. And there is no install hook in this part of the chain, so nothing fires on npm install. The malicious code runs only when the module is loaded, which means scanners watching install scripts see nothing at all.

The wider campaign is older than this package. MALFEX has been targeting Windows through npm since August 2023, first documented by Checkmarx and CloudSEK, published under five npm publisher handles with eight packages identified. Three acted as loaders for Overlord RAT. Three more, cdn-img-fetch, img-to-native and native-runner, delivered a Node.js stealer. A third pathway used a postinstall hook. The operator republishes immediately after takedowns: imgbundle and runhelper replaced img-to-native and native-runner, and imgdecode appeared the same day runhelper was unpublished. The stealer itself runs anti analysis checks for VMs, sandboxes, Process Monitor and Wireshark, then harvests seed phrases, .kdbx, .pem, .ppk and .env files, Chromium browser data, Discord and Telegram data, crypto wallets and gaming app data. Its WebSocket C2 gives a remote shell, file transfer, process control, clipboard access, screenshots and keyboard and mouse input, and it persists through a Registry Run key and a scheduled task named MicrosoftEdgeUpdateService.

Four. An OpenCode breach exposed stored OpenAI, Anthropic and Google API keys. Disclosed on 17 October. Unauthorised access to a legacy system OpenCode was already planning to shut down. Third party provider keys stored in affected users' workspaces may have been exposed, including OpenAI, Anthropic and Google keys. The figure being quoted is 1.4% of Console users, and it is worth being precise about what that means: it is 1.4% of users who had linked external providers, not 1.4% of the whole user base. OpenCode emailed affected users that morning and said users who did not receive an email were not impacted.

OpenCode links the incident to a large scale distillation attack, which means training one model on another model's outputs at volume and without permission, but it has not said whether the exposed credentials were used to make those requests. It also has not said how the attackers got in, how long they were there, how many keys were involved, or who the attacker is. It says the incident is ongoing and that it is working with Anthropic, OpenAI and Google. Note the wording in the disclosure carefully: keys may have been exposed. Nobody has said they were stolen or used, there is no confirmed loss figure, and there is no key count.

Five. The DOJ took down a North Korean fake remote IT worker pipeline. Announced the week of 17 October as Operation Lonestar Roundup, with Texas searches running from 21 to 25 September. Fourteen people were charged across two separate indictments and two US nationals were arrested. More than 40 residences were searched in Texas, and about 187 computer devices were seized including laptops and KVM switches. About $3 million was generated, which prosecutors believe was routed to sanctioned North Korean entities, and the indictment covers 2019 to mid 2025. More than 70 US employers were affected, across Ohio, 16 other states and the District of Columbia, in healthcare, communications, cybersecurity support, retail and manufacturing.

A laptop farm, in plain terms, because the phrase gets used as if everyone knows it. A US based helper receives the laptop an employer ships out to a remote hire. The helper installs remote access software on it and keeps it running on a home internet connection. The actual worker then operates that laptop from abroad, while VPNs and proxies make the traffic look domestic. The helper gets paid for hosting it, and the wages go to North Korea. Authorities say the scheme is evolving: workers are recruiting more American facilitators, and sometimes subcontracting whole jobs out to third party foreign nationals.

This lands for any small business that hires remote contractors, which is why the warning signs DOJ and the FBI published are worth repeating: inconsistencies in work history, reluctance to appear on video, requests to redirect laptop deliveries, and payment accounts routing through intermediaries. DOJ also released a set of email addresses tied to these operations so employers can screen against them.

Six. A contractor incident took US bankruptcy court notices offline nationwide. Confirmed by the federal judiciary itself on uscourts.gov on 15 October. A cybersecurity incident affected IT systems and websites that BAE Systems runs for the Bankruptcy Noticing Center, which produces and sends bankruptcy notices for federal bankruptcy courts nationwide. Down are bnc.uscourts.gov, bankruptcynotices.uscourts.gov, notices.uscourts.gov, and the National Creditor Registration Service. Production and distribution of bankruptcy notices has stopped. The Administrative Office of the US Courts is coordinating with BAE, which is investigating, and it was still disrupted roughly a week later. The judiciary notice names no cause, no actor, no ransomware family and no data exposure, gives no start date, and describes no workaround, so none of those things are in this item either.

Seven. Backfill: attackers heated French supermarket refrigeration to 50C. We never covered this and it is a week old now, but it is the best operational technology story of the month and the reason it still matters is at the bottom of the item. On the night of 11 October, attackers took remote control of refrigeration at hundreds of French supermarkets through the Danfoss controller that runs each store's refrigeration, equipment that maintenance firms manage remotely. They forced units into defrost and heated some to as much as 50C. Stores discarded stock, and reports mention equipment beginning to catch fire.

The store counts do not agree between sources, so here they are as each chain reported them. For Intermarché and Netto, both part of Les Mousquetaires, AFP reported at least 300 stores while Reuters put it at about 150. Coopérative U said 80 of its 2,000. Carrefour said 80. Monoprix said about 30. E.Leclerc said several stores, after a refrigeration supplier was hit. On damage, Intermarché's CEO Thierry Cotillard expects losses in the tens of millions of euros, while Coopérative U's CEO said the cold chain held in most of its affected stores and only a minority lost goods. Per Reuters, Spain, Portugal, Poland, Germany and Belgium may also be affected. On hardware, the AK-SM 800 and AK-SC 355 made up most of the hit units. Support for the AK-SM 800 ended in May 2021 and the AK-SC 355 was phased out in 2016, and neither receives security updates. Some current AK-SM 800A units were also hit, running outdated firmware.

The entry method is not established, and this is the thing most of the coverage gets wrong, so I want to be careful about it. As of 13 October CERT-FR had named no vulnerability, no firmware version, no entry method and no indicators of compromise. There are several nearby facts floating around and none of them has been connected to this attack. A person close to the French Prime Minister said ANSSI found a vulnerability in software from a Danish company, but no CVE was named and it was not linked to the attack. The 2025 AK-SM 800A fixes for CVE-2025-41450, CVE-2025-41451 and CVE-2025-41452 have not been tied to this incident. Claroty reported thousands of internet reachable AK-SM 800A management interfaces, but that research describes no attacks at all. Four separate true statements that do not add up to an explanation, and I am not going to chain them into one.

Nobody has been named and nobody has claimed it. The Paris prosecutor's cybercrime section has opened an inquiry assigned to OFAC. Danfoss gave no count of affected systems, said it was aware of incidents in France affecting a limited number of refrigeration management systems, and had published no security advisory as of 13 October. CERT-FR's guidance is to disconnect AK-SM and AK-SC controllers from the internet or filter access tightly, and if a controller may be compromised, to restrict service provider access, factory reset it, apply fixes, change secrets, check accounts and fully reconfigure. The older models get no new fixes, so replacement is the main option there. For the AK-SM 800A, upgrade 3.x to 4.x before going to 5.3.x, because a 5.3.x unit cannot be downgraded.

The Build

1. ConnectWise: check your own tenant, because the vendor and the responder disagree

The contradiction over which apps are actually disabled is unresolved, so the only reliable answer is the one you read in your own directory. Preserve logs before you contain, not after.

# do this in order. logs first, containment second.
#   preserve sign-in and audit logs BEFORE containment
#   keep the listed app connections disabled until ConnectWise confirms rotation

# hunt
#   sign-ins from 2026-10-13 onward, especially 144.172.64[.]128
#   application credentials and secrets added since ~10-13
#   directory-role assignments made by these service principals
#   unauthorized mailbox forwarding, inbox/transport rules, delegated access
#   dormant SkyKick connections in EVERY managed tenant, not just the active ones

# verify the disputed apps yourself:
#   Teams / Exchange Online / SharePoint Cloud Management
#   ConnectWise lists them disabled. Huntress says they do not appear to be.

2. Nextcloud Collabora: upgrade or remove, then look for webshells

Disabling the app does not fix it, and the vendor said so outright. Persistence was the goal, so an upgrade alone leaves you with whatever was planted during the month this had no CVE.

# are you even exposed? ONLY the optional built-in CODE server app.
#   NOT affected: standalone Collabora Online, Docker, RPM/DEB, Nextcloud All-in-One

# if you run richdocumentscode
#   upgrade to 26.4.303 or later, OR remove the app
#   disabling it is NOT sufficient (vendor stated)

# then hunt, because attackers wanted persistence
#   look for PHP webshells
#   they searched for password databases, password-manager artifacts, crypto wallets
#   rotate anything the server could reach

# trigger condition was the CODE server being STOPPED (restart/upgrade/crash)

3. imgdecode: what to check if you installed it on Windows

Treat the machine as potentially compromised rather than cleaning one file. Nothing fired on install, so an install log is not evidence either way; the code ran when something required the module.

# packages in this campaign (eight identified, five publisher handles)
#   imgdecode  imgbundle  runhelper
#   cdn-img-fetch  img-to-native  native-runner

# persistence to check on Windows
#   scheduled task named MicrosoftEdgeUpdateService
#   a Registry Run key
#   a spawned dllhost.exe doing network egress

# then
#   isolate the machine
#   rotate every credential stored on it (.env, .pem, .ppk, .kdbx, browser data)
#   if seed phrases were on it, MOVE THE FUNDS

4. OpenCode: rotate the provider keys, then read your billing

The disclosure says may have been exposed, so this is precautionary rotation rather than incident response. The billing review is the part that would actually tell you if a key was used.

# revoke and regenerate at the provider, not in OpenCode
#   OpenAI, Anthropic, Google dashboards

# then
#   update every application that depends on those keys
#   review recent provider usage and billing for activity you cannot account for

# only users who had LINKED EXTERNAL PROVIDERS were in scope (1.4% of Console users)
# OpenCode says no email means not impacted

7. Danfoss controllers: disconnect first, and mind the upgrade path

Two of the three affected models get no security updates at all, so for those the honest answer is replacement rather than patching. The version ordering on the current model matters because it is one way.

# CERT-FR guidance
#   disconnect AK-SM and AK-SC controllers from the internet, or filter access tightly

# if a controller may be compromised
#   restrict service-provider access, factory reset, apply fixes,
#   change secrets, check accounts, fully reconfigure

# models
#   AK-SM 800   support ended May 2021   no security updates -> replace
#   AK-SC 355   phased out 2016          no security updates -> replace
#   AK-SM 800A  current. upgrade 3.x -> 4.x BEFORE 5.3.x
#               a 5.3.x unit CANNOT be downgraded

# entry method is NOT established. no CVE, no IoCs, nobody named.

The thread: four of these are not your software at all

Count the ones where nothing the victim installed was broken. A backup vendor's OAuth app. An npm package pulled in as a dependency. An AI coding tool holding your provider keys. A federal court's IT contractor. A refrigeration maintenance firm's remote access into a supermarket. That is five of the seven if you include the freezers, and four of them involve no vulnerability in anything the victim chose or configured.

It means the usual advice runs out early. Patch promptly is good advice and it would not have helped in any of those five. The ConnectWise item is the clearest case: a consented multi tenant app is a standing grant into your directory, and your own MFA does not apply to it, so the control you were relying on was never in that path. The imgdecode item is the same idea one layer down, where the dependency you trusted is the delivery mechanism and the install hook you scan for was deliberately left out.

The Nextcloud item is the exception that proves the rest of the point. That one was a real vulnerability in software people chose to run, and it still went roughly a month between the first attacks and a published CVE. So even the clean case, the one that fits the model, did not reach the feed in time to help you.

And then the freezers, which is where I would leave this. End of life industrial controllers with internet facing management interfaces are the softest target in the building, and nobody thinks of the walk-in freezer as a computer. Two of those three controller models stopped getting security updates years ago and are still running the cold chain for hundreds of stores.

Related: seven of these ten will never show up in a vulnerability feed, where the ConnectWise story starts, and the week the hardware you own turned on you.