By Adrian Cheek, Senior Cybercrime Researcher
A stolen password often leaves work for the person holding it. He or she may still need to identify the service, locate its login page, and establish what the account can reach. For some industrial remote access platforms, however, the stolen browser record already contains much of that context and removes most of that work. In these cases, the stolen record is not just a password but a labeled route to a specific machine. Several industrial remote access platforms place session identifiers directly into URLs, with some also exposing customer accounts, machine names, forwarded protocols, and ports through their path structure. The tunnel becomes a hostname, and on one of the four platforms examined here the account, machine, protocol, and port each become a path segment. When credential stealing malware harvests a browser profile from an engineer’s laptop, it copies those URLs out along with the passwords, because to the browser they are simply more saved entries. The resulting record is a route to one identified machine at one identified site rather than a password that might work somewhere.
Using Flare, we examined 15,101 credential entries referencing four industrial remote access platforms, drawn from 2,005 collection events across 30 Flare source feeds. The methodology identifies the field supporting each result. The records contain 601 distinct session addresses and 62 additional URL-path artifacts: 55 account-level tokens and seven router configurator identifiers. For the largest platform group, 374 of 511 tunnel addresses were associated with a stored credential for the device interface, meaning the route and the login were stolen together. Of 2,032 usernames recorded against those addresses, 1,952 were administrative account names. The data does not establish whether any address or credential remains valid. Among 464 addresses observed on more than one collection date, the median interval between first and last observation was 51 days; the longest was 1,005 days.
When refrigeration controllers in several hundred French supermarkets were driven to high temperatures on October 11-12, 2026, two of the affected retail groups publicly located the compromise at a refrigeration equipment supplier and at a service provider that manages refrigeration in their stores, rather than in the stores themselves. No route in has been established, and nothing here is evidence about that incident. What this data does show is that 24 collection events in this corpus carried both an industrial remote access route and a credential for a refrigeration control vendor. The section below, The October 2026 Refrigeration Incident and the Population Measured Here, sets out what those cases contain.
All figures below come from passive examination of credential data already in circulation on criminal markets and in stealer log channels. No platform was logged into, no tunnel was opened, no token was tested, and no industrial device was contacted. The organizations identified by this data are not named here, for reasons set out in the methodology.
At a Glance
Table 1. Headline measures. Every count is a floor. Each depends on an operator’s machine having been infected, that log having reached a feed Flare collects, and the stolen browser profile having retained the entry. Equipment reachable through these platforms but never opened on a compromised machine is absent from all of it.
Key Findings About Industrial Remote Access Addresses
- Three of the four platforms place the session identifier in the hostname. A 32 character hexadecimal label, a 30 character alphanumeric label, and a pair of eight character hexadecimal labels respectively serve as the address of a specific tunnel to a specific device. The identifier is therefore stored and stolen as part of an ordinary URL, so a copied browser profile hands over a route to a specific device.
- Keyword search over credential corpora does not surface this material. The value sits in the URL field, which is not where credential monitoring conventionally looks.
- 374 of 511 tunnel addresses from the largest platform, 73.2%, appear in the same stolen record as a credential for the device behind them. Of 2,032 usernames stored against those addresses, 1,952 are administrative, which is 96.1%.
- One vendor’s path structure spells out the target in the URL itself. The first segment names the customer account, the second names the machine, the third names the forwarded protocol and its port, and in 76 entries a fourth segment names the private network address of the target inside the plant.
- Of the 464 addresses appearing in logs captured on more than one date, the median gap is 51 days, 46 exceed 90 days, 10 exceed 180 days, and 2 exceed a year.
- Although 130 infected machines carried at least one tunnel address, three of them carried 167 each and 43 carried ten or more, a concentration consistent with service contractors or integrators holding access to a portfolio of unrelated customer sites.
- Across 52 named customer accounts the device naming conventions identify water and wastewater operators, food and beverage producers, energy sites, and process manufacturers. The names are chosen by operators for their own convenience and were never intended to travel.
- The refrigeration maintenance chain sits inside the same corpus. 24 collection events carried both an industrial remote access artifact and a credential for a refrigeration control vendor, one of them holding ten tunnel addresses alongside accounts on three separate supermarket refrigeration control platforms.
Identity-First-Threat Intelligence
Combine the Knowledge of Exposures with Flare’s Leaked Credential Database
Use Flare to access the infostealer credential database and check which credentials are circulating. Combine this with confirmed exposures to find and delete valid old passwords.
What a Remote Access URL Actually Contains
Industrial remote access platforms exist to solve a specific problem. A machine builder in one country needs to reach a packaging line in another without asking the customer’s IT department to open a firewall, and the standard answer is an outbound tunnel. A small router or gateway at the plant dials out to the vendor’s cloud, the engineer logs into a portal, and the portal stitches the two halves together. The engineer then gets a browser window showing the machine’s own interface.
Giving each live session its own hostname or its own path is a reasonable way to address that browser window. It keeps sessions isolated from one another in the browser’s origin model, it survives proxying, and it requires no client software. The consequence is that the address bar now holds a value that identifies the session, and sometimes the customer and the machine as well.
A saved password is stored against the URL it was entered on, history retains the full path, and session restore keeps the tab, so malware that copies a browser profile copies the addresses with it. The URL field is captured faithfully because it is the field the malware needs in order to make the password useful.
Across the four platforms examined, the addresses fall into a small number of shapes. The table below describes what each shape discloses to anyone holding the stolen record.
Table 2. The disclosure shapes observed. None of these is a vulnerability. Each is a design decision that becomes a disclosure once the address leaves the browser it was saved in.
The Tunnel Address is in the Session
The largest single group in the data belongs to one cellular router vendor’s management platform. Its live sessions are addressed by a 32 character hexadecimal label on a fixed proxy domain. The data holds 511 distinct labels of this form, against 2,032 credential entries. An older variant of the same scheme, on the vendor’s previous domain, uses a 30 character label and accounts for eight more.
A 32 character hexadecimal value has a nominal 128 bit address space, making random guessing impractical if the labels are generated unpredictably. That does not protect a label copied from a compromised browser. Whether possession of the label is sufficient to resume access depends on the platform’s session controls, which this study did not test.
The second platform uses a 30 character alphanumeric label on regional proxy domains, and the data holds 59 distinct ones spread across ten regional endpoints in Europe, North America, South America, South Asia, and South East Asia. The third places two eight character hexadecimal components into a hostname on a hosted server operated under a large automation vendor’s own domain, and the data holds 20 distinct ones. The fourth uses a 40 character label combined with a short customer identifier, and the data holds three.
Table 3. Session addresses by platform group. Counts are distinct labels after lowercasing. These are 601 distinct device-specific addresses; the data does not independently verify that each corresponds to a separate physical device or that any session remains valid. Current and Legacy lines are the same vendor running two schemes.
A credential linked to one of these addresses arrives with a specific destination. Whether the address still resolves, whether a session can be resumed, and whether the associated credential remains valid were not tested.
A Path Structure that Discloses More at Every Level
The industrial gateway platform in this set does something beyond the session hostname. Its portal addresses a device through a readable path, and each additional segment adds information. The shape is a customer account name, then a machine name, then a protocol and port, and occasionally then a private network address.
The data contains all of these levels, in the following distribution.
Table 4. Path depth distribution for the industrial gateway platform. Most entries reach no further than the portal root. Deeper entries expose destinations used by the operator; the source record alone does not establish which browser mechanism retained the URL.
Where the third segment holds a protocol name followed by a private address and a port, the URL has disclosed the internal addressing of the customer’s plant network. Seven distinct private addresses appear this way across three address ranges. One entry forwards a remote desktop session to a host on a flat ten dot network. Another forwards a graphical console to an address inside a 172 dot 31 range.
Of 384 entries that name a forwarded protocol, 377 name a graphical remote console and four name remote desktop; three use other or unclassified protocol labels. The observed use is predominantly graphical remote access to equipment interfaces. 38 distinct forwarded ports appear, many of them high-numbered ports. These entries do not demonstrate whether the corresponding plant-side services were otherwise reachable.
Six entries reach a named control screen inside the device’s own web visualization, the screen names being operational words in several languages. An address at this depth tells the holder which machine to reach and which page of its interface the engineer habitually works on.
Both Halves of the Chain in One Record
A session address on its own still requires a login once the tunnel is open, because most of these devices present their own authentication. The question is whether the stolen record contains that login too.
For the 511 tunnel addresses from the largest platform, 374 appear in a stolen record that also carries a credential entered against that same address on a login or administration path, which is 73.2%. Counted more loosely, as any stored username against the address, the figure is all 511, and the stricter definition is used throughout because it is the one that identifies a credential for the device interface. The paths those credentials were entered on identify what they open.
Table 5. Paths against which credentials were stored, reached through a tunnel address. The administration paths belong to the embedded web interface of the router itself, which is the device that bridges the plant network to the carrier network. The listed paths total 2,009 of the 2,032 entries; 23 entries fall outside the displayed categories.
Of 2,032 usernames stored against these addresses, 1,952 are an administrative account name, which is 96.1%. The remainder are a small set of service and vendor accounts, one of which names a building management contractor in its own address and another of which names a heat pump manufacturer. Six credentials were stored against the router’s password change page, which is where an administrator goes to set the device password.
A single stolen record in this group therefore contains the address of one cellular router, the administrative username for it, and the password that was typed into its administration interface. The router sits between a plant network and a mobile carrier network. This is the device class that featured in the Polish energy sector incident analyzed by CERT Polska in August 2026, where a cellular router bridging to a shared carrier network was a link in the chain that ended with industrial controllers being stopped.
The Addresses Persist in Stolen Records
These identifiers remain in stolen browser records long after their first observation. Where the same label appears in logs collected on different dates, the data establishes repeated storage of that identifier, although it cannot establish whether the corresponding session remained valid. The condition is met by 464 addresses, which are the basis for the table below.
Table 6. Observed persistence of session addresses, measured from repeat appearance in separately collected logs. This measures how long the address remained in stored browser data. It does not establish that the address still authenticated at the end of that interval, which could only be determined by testing it.
We cannot confirm from outside that a label still grants access, only that labels appear in logs stolen months apart. Whether any individual address remains usable depends on how the platform handles previously issued addresses, which is not publicly documented and was not tested here. The practical consequence is that a security team has no basis from the outside for assuming a leaked address has expired, and equally none for assuming it has not. That question can only be answered by the platform vendor.
Restricting the measurement to logs carrying distinct hardware identifiers, so that repeat collection from the same machine cannot account for the result, 57 addresses still appear on more than one separately infected machine. One address appears on eight separately compromised machines, which shows that the same device-specific identifier was retained across multiple workstations. Whether that identifier remained usable was not tested.
One Infection, a Portfolio of Sites
Of the identified machines, 130 carried at least one session address, and the distribution across them is heavily skewed.
Table 7. Session addresses per infected machine. The three machines in the final row each carried 167 addresses.
The three most productive machines carried 167 tunnel addresses each and are located in South America. Their logs are dated across July and September 2026, which indicates either repeated infection of the same workstation or several machines in the same organization. A machine in Western Europe carried 47, one in Southern Europe carried 34, and machines in North America, East Asia, and Central Europe carried between 31 and 33.
This concentration is consistent with the access held by system integrators and service contractors across multiple customer sites. Such access is often maintained on field engineers’ laptops, which are ordinary consumer grade targets. The dataset establishes the concentration, although it does not independently identify the contractual relationships behind it. Of the token bearing infections where a malware family could be attributed, the families are commodity information stealers sold on criminal markets. Corporate Windows domain membership was identified for 2 of the 130 machines carrying session addresses. That is a limited indicator of management status, because the domain field is empty for the remaining 128 rather than recording an absence of membership, and one of the two recorded values does not resemble a corporate domain.
The recorded infection dates range from March 2022 to October 2026, including 30 in September 2026 and four in October 2026. These recent observations show that this class of artifact continues to appear in collected logs.
Account Level Tokens Travel the Same Way
Session addresses are the clearest case because they identify a specific remote access destination. Three other token types appear in URL paths in this data and deserve separate treatment, because they concern the account instead.
The data holds 45 distinct invitation acceptance tokens, each a 16 character alphanumeric value in a path segment. An invitation token enrolls a new user into a customer’s account on the platform. A further three password reset tokens appear in the same form on that platform, and six more appear on the cellular router management platform as 64 character values on its own reset path, so the pattern holds across two vendors rather than one. These are single use values in normal operation, and their presence in a browser credential store means the invitation or reset email was opened on a machine that was later compromised. Whether any remain redeemable depends on platform expiry policy, which we did not test.
Seven distinct router configurator identifiers appear in paths of the form that opens one specific router’s configuration record, including network and wide area network settings. A further 37 entries reference the platform endpoint that issues a router configuration file. A configuration file for an industrial router is a sensitive artifact in its own right, because it commonly contains the tunnel enrollment material that lets a device join the customer’s account.
One mobile application token appears, stored by the vendor’s Android client under its package name rather than a web origin, and the pattern behind it reaches further than the single instance. A credential stealer that collects application stored values as well as browser values will capture platform tokens that never appeared in a browser at all, and the saved entry format makes them easy to overlook in any search keyed on web domains.
Separately, 307 distinct account identities appear against one platform’s portal, the majority of them corporate email addresses at machine builders and engineering contractors across Europe, North America, South America and Asia. Another 22 appear against a second platform, several of them operator chosen account names that identify the engineering firm holding the account.
The Machine Names are the Attribution
Session hostnames give nothing away, while the industrial gateway platform’s paths name the customer account and the machine in readable form. Both names are chosen by the people who installed the equipment. They are chosen for operational convenience, in the expectation that only colleagues will read them.
The data holds 52 distinct customer account names and 53 distinct machine names. Classified by what the names describe, with the organizations unnamed, the spread is as follows.
Table 8. Sector distribution inferred from account and machine naming. Sector assignment rests on the semantics of operator chosen names and on the account holder’s evident line of business. It is an interpretation of text, not a verified corporate record.
Specific naming patterns carry more than sector. One account names a borehole server and a client station at what the naming identifies as a national water utility, another names a treatment plant by numbered asset, a third names a whey processing line at a dairy producer and a fourth names a wind turbine site. Several name the end customer inside the machine name, so that a machine builder’s account discloses which of its customers’ factories the equipment sits in. Two accounts belong to industrial refrigeration firms, which the section, The October 2026 Refrigeration Incident and the Population Measured Here, returns to.
None of these organizations are named in this report. The naming data is specific enough to identify sites, and publishing it would convert a research finding into a target list. Where the data identifies infrastructure operators, the appropriate route is notification through the relevant vendor security team and national computer emergency response team, which is the route being taken.
The October 2026 Refrigeration Incident and the Population Measured Here
On October 11-12, 2026 the refrigeration controllers in several hundred French supermarkets were driven to high temperatures, spoiling stock and in some cases starting fires. The equipment involved was Danfoss refrigeration system management hardware. The Paris prosecutor opened an investigation, and CERT-FR issued an advisory telling operators to disconnect these controllers from the internet or restrict access to them.
The route in has not been established publicly. CERT-FR named no vulnerability, no firmware version, no method, and no actor. What two of the affected retail groups did say points somewhere specific. One stated that the attack had affected one of its refrigeration equipment suppliers. Another described the incident as affecting a service provider that manages refrigeration systems in its stores. Neither named the provider. Both located the compromise outside the stores and inside the supply chain that maintains the equipment.
This research does not address what happened in France, and nothing in this data is evidence about that incident. It measures the credential exposure of the population those two statements point at, which is the contractors and integrators who reach industrial equipment remotely on behalf of their customers. That measurement was made for reasons unrelated to the incident and returns the following.
Table 9. Overlap between the remote access artifact population and credentials for refrigeration control vendors. An event is one stolen log, so both classes of material in a counted event were captured from the same machine. The event count is not a machine count: only 11 of the 24 events carry a hardware identifier, and those 11 resolve to 9 distinct machines, so some events are repeat collection from the same workstation.
Four cases in that overlap are set out below, with the organizations unnamed as elsewhere in this report.
- One machine held 10 cellular router tunnel addresses of the kind described in section The Tunnel Address is the Session, and on the same machine credentials for three separate supermarket refrigeration control platforms. Those were the offline management tool of a major refrigeration controls vendor, a regional portal of a second controls vendor, and three hosts belonging to a manufacturer whose rack and circuit controllers are installed in supermarkets internationally. The same workstation carried both the remote access routes and the refrigeration control accounts.
- A machine in France held the gateway platform tenant path of an industrial refrigeration contractor, together with that firm’s directory backed internal intranet, its customer portal across production and development hostnames, and a monitoring system account. The infection is dated June 2026, four months before the incident.
- A machine held credentials for the controller vendor’s own web based store management product across its production hostname and three non-production ones. That product family is the one involved in the October incident. This finding concerns vendor operated infrastructure and has been referred to the vendor rather than detailed here.
- Two of the 52 named tenants on the gateway platform are industrial refrigeration manufacturers. Their path entries name end customer sites and forward graphical console sessions to equipment at those sites, so the stolen record discloses which of their customers’ plants the refrigeration equipment sits in.
Only a narrow inference follows. The population that maintains refrigeration control systems is inside the same commodity infostealer corpus as the population that maintains industrial equipment generally, it is exposed in the same way, and in 24 measured events a single stolen log carried both the remote access route and the refrigeration control account. That is a statement about a standing condition rather than about any incident.
The corresponding negative result is that no refrigeration credential in this corpus was stored against a bare address of the kind these controllers use when published directly to the internet, so no entry in this data joins to the exposed controller population enumerated separately in that research. The control layer and the credential layer do not meet directly. They meet at the contractor, which is what the overlap above measures.
Why Conventional Credential Search Does not Surface This
The findings illustrate a gap in searches centered only on an organization’s email domain or service domain. Credential monitoring is organized around the question an organization asks, which is whether its own accounts are exposed, and those two fields are the right ones for that question. Neither finds a session address, because the username against one is commonly a generic administrative name carrying no organizational identity, and the domain belongs to the platform vendor. A water utility searching only its own email or service domains could miss a route to its borehole controller, because the relevant identifier may appear only in a path segment under the platform vendor’s domain.
This is a convention in how credential data is queried across the industry rather than a limitation of any one source. A different query shape recovers it, and the three moves below produced everything described in this report.
- Search on the platform’s own domain rather than on the victim’s. In the cases examined here, customer exposure was identifiable under the platform vendor’s domain, even where the customer’s own domain was absent from the record.
- Parse the URL field as structure rather than treating it as a label. The subdomain label and the path segments are separate fields carrying separate facts, and a flat string match over the URL reads none of them.
- Count distinct parsed values rather than records. The 15,101 credential entries reduce to 601 session addresses. Reporting the record count would have overstated the finding by a factor of twenty five.
The Flare export supported this by preserving the complete URL field alongside the infection date, the hardware identifier, and the source feed label for every entry. A corpus that normalized URLs down to domains, which is a common and otherwise sensible storage decision, would have destroyed this finding before anyone could look for it. Table 12 states which field each result depends on.
Observed Exposure and Technique Relevance
The mapping below separates what this dataset evidences from what it establishes as a precondition. A credential corpus study observes stolen material and the access it would enable. It does not observe an adversary using it. No execution, persistence, lateral movement or command and control technique is claimed from this data.
Table 10. Technique relevance. Entries marked dataset are evidenced by the records examined. Entries marked precondition describe access this material would enable and which this study did not observe being used.
Key Judgments
High
- Session addresses for industrial remote access equipment are present in commodity infostealer logs in quantity, and the exposed unit is a machine rather than an account. 601 distinct addresses across four platforms, parsed from the URL field of 15,101 credential entries drawn from 2,005 separate logs.
- For the largest platform group, the stolen record commonly contains both the route to a device and an administrative credential for it. 374 of 511 addresses, 73.2% with 1,952 of 2,032 stored usernames administrative.
- These addresses remain in stored browser data for months. 464 addresses observed on more than one collection date, median interval 51 days, maximum 1,005 days.
- Exposure is concentrated on a small number of machines, in a pattern consistent with service contractors and integrators. 43 of 130 infected machines held ten or more addresses and three held 167 each. The employment or contractual status of each workstation owner was not independently established.
- The refrigeration maintenance chain is exposed in this corpus in the same way as the wider industrial one. 24 collection events carried both an industrial remote access artifact and a credential for a refrigeration control vendor, and 2 of the 52 named gateway tenants are refrigeration manufacturers whose path entries name end customer sites.
Moderate
- Some recovered addresses may remain usable after collection, but their validity and authentication requirements were not tested. The repeat-observation measurement establishes continued presence in stolen records, not continued access. Platform session policies would be needed to assess this risk for each vendor.
- The affected estate includes water, energy, and food infrastructure operators. Sector assignment rests on interpretation of operator chosen naming rather than verified corporate records, although several names are unambiguous about the function of the equipment.
- The observed population is incomplete. Every count depends on an operator machine having been infected, the relevant data having been collected, and that log having reached a Flare feed. The size of the unobserved population cannot be estimated from this sample.
Low
- The recovered material contributed to the October 2026 French supermarket refrigeration attack. No evidence supporting this hypothesis was identified in the dataset. The overlap described in section 9 was measured independently, and public statements concerning refrigeration suppliers and maintenance providers establish the relevance of that population without establishing involvement in the incident.
- Any specific organization identified here has been targeted using this material. Nothing in the data records an adversary acting on it, and the concentration of addresses on integrator machines is equally consistent with indiscriminate commodity theft.
What Security Teams Can Do This Week
If you Operate Industrial Equipment Reached Through a Vendor Cloud Platform
- Ask your platform vendor two questions in writing. How long does a session address remain valid, and does revoking a user session invalidate addresses already issued to it? The answers determine whether a stolen address from months ago is still a live route into your plant.
- Treat your remote access platform account as an identity to be monitored under the vendor’s domain, not your own. Your exposure in credential data appears under the platform vendor’s domain with a generic username. Searching for your own name will not find it.
- Rename equipment that carries customer, site, or process names in the platform. The machine name travels in the URL. A line identifier serves your engineers as well as a name that identifies the customer and the product.
- Enforce multi-factor authentication (MFA) on the platform account and confirm with the vendor that it is required on session resumption rather than only at initial login. A stolen session address is most dangerous where resumption skips the second factor.
- Change the device level credential on any equipment reached from a machine you believe was compromised, and treat the embedded router administration account as the priority. In this data the router administration password is the credential most commonly stolen alongside the route to it.
If you are an Integrator or Service Contractor
- Recognize that your engineers’ laptops hold the aggregated access of your entire customer base. This data cannot establish whether those machines are centrally managed, because the domain field is populated for only two of the 130, so treat the management status of field engineering laptops as something to verify rather than assume.
- Move platform access off browser stored passwords onto single sign on with hardware backed authentication, so that a browser profile theft does not yield reusable credentials.
- Separate customer access by engineer or by contract where the platform supports it, so that one infection does not expose every site you maintain.
- Include customer equipment access in incident response scoping. An infection on an engineer’s laptop should trigger review of every customer route and credential that machine held, with notification decisions guided by contractual, regulatory, and incident-specific obligations.
If you Run a Remote Access Platform
- Avoid relying on a long-lived URL-embedded bearer value as the sole authorization control. Use short-lived, revocable sessions bound to authenticated users, and assess whether sensitive values can be excluded from browser history, logs, and credential-store URLs. Moving a value into a fragment, header, or cookie changes exposure paths but does not by itself protect against malware running on the endpoint.
- Keep customer and machine names out of path segments, or map them to opaque identifiers at the boundary. The operational convenience of a readable path is paid for by every customer whose site is named in a stolen log.
- Expire session addresses promptly and revoke them when the authorizing user session ends. The repeated appearance of addresses in stolen data demonstrates a lasting record of those values, although this study does not establish their effective lifetime on the platform.
- Publish the session lifetime. Customers cannot assess this risk without it, and at present they cannot determine from outside whether an address stolen last quarter is still a route into their plant.
Finding 601 Industrial Remote Access Addresses Recovered From Stealer Logs, 73% Paired With Device Credentials: Where Do We Go from Here
Industrial remote access platforms allow engineers and contractors to reach equipment across customer sites without requiring each operator to expose its network directly to the internet. The problem is what gets retained on the engineer’s machine. Session addresses, account names, device identifiers, and internal network details can all end up in browser records collected by infostealer malware.
This research identified 601 distinct remote access session addresses across 15,101 credential entries, with 73% paired with device credentials. The median period over which addresses appeared in stolen records was 51 days. The exposure was concentrated on a relatively small number of contractor and integrator machines, including three that each held 167 routes. The same dataset also contained records associated with the refrigeration maintenance chain, although there is no evidence linking these findings to the October 2026 incident.
The outstanding question is whether the recovered addresses remain usable. That requires validation by the platform vendors, particularly where an address is accompanied by credentials. Operators need to understand how long these sessions remain valid, and integrators need to account for the number of customer environments accessible from a single engineer’s laptop. For defenders, the practical starting point is to search for the platform’s domain in stealer records and examine the URL structure. The affected industrial operator may never be named in the stolen data, even when a route to its equipment is present.
Identity-First-Threat Intelligence
Combine the Knowledge of Exposures with Flare’s Leaked Credential Database
Use Flare to access the infostealer credential database and check which credentials are circulating. Combine this with confirmed exposures to find and delete valid old passwords.
Methodology and Limitations
Data Sources and What Each Contributed
Every quantitative statement in this report derives from the Flare platform. No other credential source was used, and no commercial internet scanning data was used anywhere in this piece. The material outside Flare is limited to published vulnerability advisories, the CERT Polska incident report referenced in the section Both Halves of the Chain in One Record, and the press reporting of the October 2026 French incident quoted in the section The October 2026 Refrigeration Incident and the Population Measured Here, all of which are cited where they appear and none of which contributed a figure.
The analysis draws on five exports taken from the Flare platform on October 13, 2026. Searches were keyed on the domains and product names of the platforms themselves rather than on any victim identifier, which is the methodological point made in the section Why Conventional Search Does not Surface This. The five searches and what each returned are as follows.
Table 11. The five Flare searches behind this report. The eight combined platform terms were talk2m.com, ewon.biz, portal.ixon.cloud, ixon.cloud, gatemanager, secomea, rms.teltonika-networks.com and tosibox. The eight refrigeration terms were StoreView, AK-SM, adap-kool, my.danfoss.com, alsense, xwebpro, webapps.copeland.com and televisgo. The final row of that search contributes almost nothing to the session address count and is the source of the overlap measured in section 9.
Those 5,223 records came from 30 distinct Flare source feeds. The session address material sits almost entirely in the stealer log feeds, which supplied 2,998 records, with a further 189 from sample feeds, 109 from private feeds, and 9 from live and direct feeds. The marketplace and channel feeds in the same result set, including Telegram channels at 1,199 records, code repository drilling at 469, and a Russian marketplace at 110, returned no session addresses. The reason is that this class of artifact lives in raw stealer output rather than in the curated listings built from it, because the curation step discards the URL field.
Which Flare Fields Each Finding Rests On
The findings in this report are possible because the export preserves per credential entry structure instead of a normalized summary. The mapping below states which field each result depends on, so that any of them can be checked against the same export.
Table 12. Finding to field mapping. Field names are given in their short form; the user_information and malware_information prefixes are omitted. Two results depend on fields that a normalized credential store would commonly discard. The persistence measurement in section 5 requires an infection date to travel with every entry, and the machine level counting in section 6 requires a hardware identifier. Without those two fields this report would state that the addresses exist and nothing about how long they last or how they concentrate.
The exports preserve fields including the URL the credential was stored against, the application that stored it, the username, a partially redacted password, the source feed, the malware family where attributed, the infection date, and a hardware identifier for the infected machine. Coverage of those fields across the 15,101 entries is uneven, and two of the gaps bound results in this report.
Table 13. Field coverage across the 15,101 credential entries. Two gaps matter. The hardware identifier is present on 57.8 percent of entries, which is why machine counts are reported separately from event counts throughout and why the section 9 overlap is given as an event count. The malware family is attributed on 8.5 percent, which is why section 6 characterizes the families only as commodity stealers and gives no distribution.
The parsing described below operates on these fields and adds no external enrichment.
All collection was passive. No platform account was accessed, no tunnel was opened, no token or address was tested for validity, and no industrial device was contacted, scanned, probed or authenticated to. Passwords in the source data are partially redacted by the platform and no password value is reproduced here. The one record in the collection involving a named individual’s corporate session has been excluded from this report entirely and referred to the relevant vendor security team.
Parsing and Counting
URLs were split into scheme, host and path, with path segments percent decoded. Session addresses were identified by pattern match against the subdomain label forms documented in the section The Tunnel Address is in the Session, then lowercased and deduplicated. Account and machine names were taken from the first and second path segments of the gateway platform. Protocol and port were taken from the third. Private addresses were matched against the three ranges reserved by RFC 1918.
Counts are of distinct parsed values, not of records. This distinction matters by more than an order of magnitude here, and an earlier pass of this analysis that reported record counts overstated the population by a factor of 25. Where a count of entries is given rather than a count of distinct values, the table says so.
The refrigeration overlap in the section Why Convention Credential Search Does not Surface This was measured by testing, for each collection event, whether the same event carried both a remote access platform artifact and a credential whose hostname belongs to a refrigeration controls vendor. Matching is anchored on the registrable hostname rather than on free text anywhere in the record. An earlier pass matching product names anywhere in the URL returned 158 events, of which the large majority were false positives: a recruitment platform whose path contains a string identical to a refrigeration product name, and a username containing the same string as a substring. Host anchored matching reduces this to 24, and each of the 24 was inspected individually. The vendor set was fixed in advance from the controls vendors named in public advisories on this equipment class, and was not extended after seeing results. The 24 are collection events rather than machines, since only 11 carry a hardware identifier and those resolve to 9 distinct machines, so the overlap is reported as an event count throughout.
Machine level deduplication uses the hardware identifier where present, which 8,723 of 15,101 entries carry, yielding 375 distinct machines. Where the identifier is absent the collection event identifier was used as a weaker proxy, and the two measures are reported separately. The persistence measurement in section 5 is reported on both bases, and the stricter hardware identifier basis is the one quoted in the key judgments.
Limitations
- Every count is a floor. An address appears here only if an engineer opened it on a machine that was infected, the stealer captured that entry, and the log reached a feed Flare collects. Equipment reached only from uninfected machines is invisible to this method.
- Validity is not established. The persistence measurement shows how long an address remained in stored data. It does not show that the address still authenticated, and determining that would require testing addresses belonging to third party industrial operators, which is not a legitimate research activity.
- Sector attribution is interpretive. It rests on the semantics of names chosen by operators. Several are unambiguous, several are abbreviations whose expansion is inferred, and no corporate registry was consulted to confirm any of them.
- Platform coverage is uneven. The four platforms differ by orders of magnitude in installed base, and the relative counts here reflect which platforms’ users happened to be infected rather than which platforms are most exposed. The ratio between platforms should not be read as a comparison between vendors.
- Some source records contain malformed fields. Three records carry a hostname in the country code field, which is a data quality artifact in the upstream log rather than in the analysis. Affected records were excluded from geographic counts and retained for address parsing.
- Infection dates are supplied by the stealer log and are not independently verifiable. They are used here only for interval measurement, and an inaccurate date at either endpoint would change the intervals reported in the section The Addresses Persist in Stolen Records.
Disclosure Posture
No organization identified by this data is named, and no session address, token, account name, or machine name is reproduced in full. The parsed values are specific enough that publishing them would provide a route into operating industrial plant. Material concerning identifiable infrastructure operators, and material concerning vendor operated infrastructure, is being routed to the relevant vendor security teams and national computer emergency response teams ahead of publication. Commercial internet scanning platforms used for corroboration elsewhere in this research line are not named, consistent with our practice.
Primary Sources
The external material referenced in this report is listed below. None of it contributed a figure, and all quantitative results derive from the Flare platform as set out in the Methodology and Limitations.
CERT-FR, CERTFR-2026-ALE-012, Incident de securite ciblant les controleurs a distance des installations de refrigeration. Published 12 October 2026, revised 13 October 2026. https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-012/ Lists Copeland xweb, Danfoss AK-SC, Danfoss AK-SM and Dixell xweb as affected. Names no CVE, firmware version or initial access route.
CERT Polska and CSIRT NASK, Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. Published 8 August 2026. https://cert.pl/en/posts/2026/08/incident-follow-up-report-energy-sector-2025/ Source for the cellular router bridging chain referenced in section 4.
The Hacker News, Attackers Heat French Supermarket Fridges Up to 50C by Hijacking Danfoss Controllers. 13 October 2026. https://thehackernews.com/2026/10/attackers-heat-french-supermarket.html Source for the retail group statement attributing the incident to a refrigeration equipment supplier, quoted in section 9.
BleepingComputer, Cyberattack shuts down refrigerators at French supermarkets. 12 October 2026. https://www.bleepingcomputer.com/news/security/cyberattack-shuts-down-refrigerators-at-french-supermarkets/ Source for the retail group statement attributing the incident to a service provider managing in-store refrigeration, quoted in section 9.
