Inside the FortiBleed Dataset: 46,799 Working Logins, and the Internal Addresses That Show Where They Came From

By Adrian Cheek, Senior Cybercrime Researcher

In the second week of June 2026, security researcher Volodymyr “Bob” Diachenko found a server that its operators had left open to the internet. On it sat the working files of a credential-harvesting operation: the scanning tooling, the automation scripts, cron jobs and bash histories, and a searchable database of usernames and passwords for tens of thousands of internet-facing firewalls. Threat intelligence firm Hudson Rock analyzed the dataset and named the campaign FortiBleed; independent researcher Kevin Beaumont obtained a copy and confirmed the credentials were real. Their analysis put the affected population near 73,900 unique Fortinet FortiGate devices across 194 countries, roughly half of every such firewall reachable on the public internet. None of it required a new vulnerability. The credentials already worked.

Flare pulled the circulating dataset apart to see what an attacker holding it actually has. What comes out is a deduplicated, enriched view of 46,799 hosts with a working credential, each tied to its operator, geography, and owning domain. None of it came from touching a host. There was no probing, no authentication, no exploitation, because everything here was derived from data already in open circulation. Anyone willing to go looking can pull the same file and work it the way we have.

Metric	Count
Hosts with a confirmed-valid credential	46,799
Hosts in public scope	45,430
Hosts in private / internal scope	1,369
Distinct endpoints staged for notification	27,274
Endpoints enriched to operator and geography	27,108
Endpoints carrying linked-domain context	11,618
Distinct affected domains	24,678
Distinct entities profiled	4,280
Distinct operators (ASN) represented	3,547

Key Findings About the FortiBleed Dataset

• The data indicates configuration theft is likely: 1,358 confirmed hosts carry non-routable internal addresses, and 312 targets are named after internal Active Directory realms. Neither is reachable or guessable from the internet, and both can only come from reading a device’s full configuration.
• The data indicates a systemic campaign by threat actors against customer deployments of Fortigate. Fortinet itself was not breached. As of June 19, 2026, we have no reason to believe Fortinet was compromised.
• 46,799 hosts carry at least one credential confirmed valid by the operators themselves. 45,430 sit in public address space; the rest resolve to private or internal ranges.
• 27,274 distinct endpoints were staged for victim notification after deduplication. 27,108 were enriched to operator and country. The exposure spans 194 countries and 24,678 affected domains, with no single country exceeding 14 percent of the enriched population.
• The exposure is on the management plane. 30,829 confirmed hosts expose remote administration on port 22 and 12,990 expose web management on port 80. What the attacker is buying is the credential, not an exploit, so a valid login lands inside the device at any patch level.
• 4,109 hosts expose management on a non-standard port. Port relocation slowed opportunistic discovery and stopped nothing, because the operators already held the endpoint list and the credentials to match.
• Government, banking, healthcare, and energy are all in it. Among entities whose sector could be identified, confirmed-valid credentials reach 101 government domains across 45 countries, along with hospitals, banks, utilities, and universities. This is a pre-validated access inventory for critical infrastructure and regulated institutions, far beyond a generic password list.
• Entire carrier fleets are caught up in it, alongside the small offices. Pivoting on the owning-domain field surfaces single operators tied to anywhere from 100 to 232 exposed devices, some spread across eleven countries and twenty-four networks. The credential counts, roughly three per device on the carrier estates, point to harvested VPN user directories rather than one-off admin logins.
• At the other end, most victims are tiny. 2,004 of the 3,547 operators hold exactly one exposed device, while the top 50 carry 45 percent of all exposure between them. Of the entities we could size, the two largest groups are organizations under 50 staff and under 10.
• The operators ran two collection methods at once, and their own files show it. The source tags split the data cleanly: every validated entry carries a reachable device, while 739 pre-held credential records carry none at all. One side is a standing credential hoard, the other a live validation engine, and the catalog keeps them separate. All 312 internal Active Directory realms sit on the pre-held side, gathered from inside environments rather than guessed at an external login.
• It is already being auctioned, and disclosure raised the price. The same class of data is for sale on a top-tier cybercrime forum. A seller listed it four days before public reporting existed at a 25,000 dollar opening bid, then pasted the research blog into the thread on disclosure and more than doubled the opening bid to 60,000. The seller’s own description of a hash dump and ongoing fresh collection corroborates the technical findings here.
• This was an industrial operation built to run over time. Public reporting attributes it to a Russian-speaking, multi-operator group that ran an estimated 1.16 billion login attempts against more than 320,000 firewall targets, cracking captured hashes offline on a GPU cluster. The dataset is what that machine produced over time, not the result of one break-in.

Presence of a credential in a circulating dataset is not the same as a current foothold, but it is one login away from one. The question every owner of one of these devices should be answering this week is whether the password in that file still works. If it has not been rotated since collection, assume it does.

How the Operation Worked

The affected devices are Fortinet FortiGate appliances, which fold firewall, SSL VPN, and remote management into a single box sitting at the boundary between the public internet and the internal network. That position is exactly why they are a target. One valid credential against the management or VPN service is a foothold inside the protected network, a map of internal architecture, and a path to lateral movement, all at once.

The reconstruction in the public reporting describes a self-feeding pipeline rather than a one-time breach. Internet-wide scanning identifies reachable management and VPN interfaces, and a curated password list, drawn from historical leaks specific to this product family, from infostealer logs, and from earlier brute-force results, is tested against each one. Successful logins are recorded, the compromised devices are turned into listening posts that intercept VPN authentication in transit, and whatever they capture is fed back into the scanner to widen the next pass.

Captured authentication hashes are cracked offline on a dedicated GPU cluster and validated automatically and continuously. In verifying the data, Beaumont logged in successfully against multiple organizations and noted that many affected devices run comparatively recent firmware, which undercuts any assumption that this is a legacy-only population.

Configuration Theft was a Key Element

Fortinet’s public line is that this is brute-forced and re-shared credential material rather than data lifted off devices, and that none of it ties to a new vulnerability. On the question of origin that is fair enough, and on the question of risk it changes nothing, because a credential that still works against a reachable device works no matter how it was obtained. What the line does not account for are two kinds of artifacts in this dataset that brute-forcing simply cannot generate. Both are internal-only, never visible from outside the network, and the fact that they are here at all means the operators were reading whole device configurations rather than hammering on login pages.

Fortinet published its own assessment as this analysis was being finished. The framing held up front: reuse of credentials from earlier incidents, brute-forcing against devices with weak passwords, no new vulnerability. The remediation steps underneath that framing point somewhere else. Customers are told to review device configuration for unauthorized changes, to look for injected administrative accounts, and, where directory integration is in place, to treat that account as compromised and comb domain-controller logs for lateral movement into the internal network.

1,358 Hosts Carry an Address that does not Exist on the Internet

Of the confirmed-access hosts, 1,369 sit in private or internal scope, and 1,358 of those land cleanly in non-routable space: 568 in 192.168.0.0/16, 501 in 10.0.0.0/8, 289 in 172.16.0.0/12, with a handful more in link-local and loopback ranges. Those ranges are unreachable from the public internet by definition. There is no way to scan them from outside, no way to reach them, and so no way to test a password against them remotely. An internal address like 10.230.201.115 can only have reached this collection by being read out of the device’s own configuration, where the firewall keeps a record of its internal interfaces and routes.

Address block	Hosts	Routable?
192.168.0.0/16 (RFC1918)	568	No
10.0.0.0/8 (RFC1918)	501	No
172.16.0.0/12 (RFC1918)	289	No
169.254.0.0/16 (link-local)	10	No
127.0.0.0/8 (loopback)	1	No

312 Targets are Named After an Internal Active Directory Realm

The second artifact is harder to explain away. 312 entries in the dataset are identified not by a public domain but by an internal naming convention: 290 end in .local, the rest in .corp, .lan, .internal, and .dc. These are the private Active Directory realm names an organization uses inside its own network, things like excellence.local, asianchemical.local, and gbgroup.corp. They resolve to nothing publicly and appear in no registry anywhere. A firewall knows its joined AD realm only because that detail is written into its configuration, so 312 of them turning up in this collection means the operators were reading the part of each config that binds the device to its internal directory.

The realms also connect the dataset to the real-world impact the reporting describes. From the operators’ own scripts and logs on that open server, Diachenko reconstructed tooling built to pivot from a cracked firewall credential into the Active Directory environment behind it, and the 312 realms here are the directory targets that pivot needs, captured at collection time and held in the catalog next to the credentials that reach them. Guessing a login page will never hand you an organization’s internal AD realm name; reading the configuration off the box is the only way it gets there.

The Exposure in Detail

Ports and Services

Exposure concentrates heavily on remote administration and web management. The distribution below counts host-port pairings across the confirmed-access population.

Port	Hosts	Typical service
22	30,829	SSH / remote admin
80	12,990	HTTP management
443	968	HTTPS management
2222	789	SSH (relocated)
1337	204	SSH (relocated)
1022	173	SSH (relocated)
10443	163	HTTPS (relocated)
8443	155	HTTPS (relocated)

What this confirms is that the management plane of these devices sits open to the internet rather than behind a trusted network, which is the condition that made bulk collection possible in the first place. The 4,109 hosts on a non-standard management port are worth a closer look, because relocating a port gets treated as a control when it is really only obscurity. It raises the cost of stumbling across a device, but it does nothing against an actor who already holds the endpoint list and a matching credential, and the fact that these hosts are in the dataset at all shows the relocation did not help them.

Where the Devices are

Enriched endpoints span 194 countries with no single territory dominating. The shape tracks the global install base of the product, which is consistent with indiscriminate, reachability-driven collection rather than victim selection.

Country	Endpoints	Share
United States	3,768	13.9%
India	3,256	12.0%
Taiwan	1,961	7.2%
Thailand	1,050	3.9%
Mexico	988	3.6%
South Korea	935	3.4%
Indonesia	793	2.9%
China	693	2.6%
Japan	640	2.4%
Hong Kong	630	2.3%

This ranking is not a quirk of our sample. A live internet-wide scan of Fortinet firewalls, run the day this was written, returns 388,628 reachable devices and puts the same countries on top, with the United States ahead of Taiwan, India, Japan, and Italy. Our enriched exposure follows the global install base closely enough that the collection reads as blind sweeping of whatever answered, with no sign of who was singled out. The live count also sets the scale. Against roughly 388,000 reachable devices, a validated-credential haul in the tens of thousands lines up with the independent estimate that the campaign reached around half the fleet exposed to the internet.

Figure 1. Live internet-wide device count for the affected product family, captured the day of writing. Source: Shodan

One Owner, a Whole Fleet

Treated as a flat list, the dataset reads as tens of thousands of unrelated devices. Pivot on the owning-domain field and a different shape appears: a handful of owners account for large fleets of exposed devices scattered across multiple networks, which is what a managed-service or carrier estate looks like, not a single subscriber with one box. One Mexican carrier domain ties to 232 exposed hosts spread over six autonomous systems. An Indian telecom ties to 175 across eleven. Regional operators in the Caribbean and Latin America sit between 89 and 134 hosts apiece.

Owning estate (sector)	Hosts	ASNs	Countries
LatAm carrier (telecom)	232	6	1
South Asian carrier (telecom)	175	11	1
Municipal government (public sector)	141	1	1
Andean carrier (telecom)	134	8	1
SE Asian carrier (telecom)	132	2	1
Caribbean carrier (telecom)	72	15	11
East Asian managed services	56	24	10

Twelve owning domains show up across three or more countries, and the largest are striking: one Caribbean carrier estate spans eleven countries and fifteen autonomous systems, and one East Asian managed-services provider covers ten countries and twenty-four. When a single owner has that footprint, one compromised credential set is not one site to remediate; it is a multinational operator’s perimeter across a whole region. The per-device credential counts tell the same story. Carrier estates average roughly three credentials per device and one pharmaceutical domain reaches eight, against a population average of 2.2, which points to harvested VPN user pools rather than a single admin account per box.

The concentration cuts the other way too. 2,004 of the 3,547 operators in the data hold exactly one exposed device, while the top 50 operators account for 45 percent of all exposure. The campaign caught both ends of the market at once: the single clinic on commodity broadband, and the national carrier’s managed-firewall fleet. The defensive implication differs by end. The long tail needs individual notification, and it will struggle to act. The concentrated head means a small number of large operators could remediate a disproportionate share of global exposure if reached directly and fast.

The Shape of the Victim Pool

The 3,547 operators behind these endpoints are mostly national and regional telecom carriers and broadband providers, which is what you would expect of small and mid-size subscribers running a perimeter box on commodity connectivity. The size bands bear that out: of the 2,680 entities we could band cleanly, the two biggest groups are organizations of 10 to 50 staff and under 10. The organizations least likely to be reviewing their own authentication logs or to have anyone on call are the ones that show up most. There are larger enterprises in here too, and for some of them the damage is already done. Diachenko reported full network compromises, with attackers persisting and moving laterally past the firewall, at organizations in Japan, Taiwan, Vietnam, Iraq, and Turkey, the worst of them a Turkish defense contractor with NATO ties. Most of the population, though, sits at the small end.

Government in 45 Countries, plus Banking, Healthcare, and Energy

Which sectors a dataset like this touches is the question that decides how much it matters, and the answer here is not reassuring. Restricting the count to entities whose sector can be pinned down with confidence, the confirmed-valid credentials reach government and public-sector bodies, banks and insurers, hospitals and clinics, energy and water utilities, and universities. Government stands out: credentials confirmed against 101 distinct government domains in 45 countries. That is not a scattering of outliers in the long tail. It is working access to the perimeter of public institutions across roughly a quarter of the world’s nations, sitting in a file that is already for sale.

Sector (identifiable subset)	Hosts	Profile
Telecom & ISP	1,000	Carrier and broadband estates
Government & public sector	272	101 domains, 45 countries
Education & research	140	Universities and institutes
Healthcare	93	Hospitals, clinics, pharma
Energy & utilities	74	Power, water, fuel
Banking & finance	70	Banks, insurers, securities

Two caveats matter for reading that table. The classification is deliberately conservative and keyword-anchored, and it labels only a minority of entities, so each count understates the real total. A domain we could not place is simply unlabeled, which means the true government, healthcare, and finance presence runs higher than what is shown. Telecom sits on top partly because carrier estates really are large and partly because their names are the easiest to classify, so its lead is inflated against the sectors that are harder to label. Take the table as proof that these sectors are in the data and a lower bound on how deeply, and nothing finer than that.

Even on the conservative read, the conclusion is hard to avoid. A credential collection that reaches government bodies in 45 countries, along with hospitals, banks, and utilities, belongs to a different category than a commodity password list. It is a pre-validated map of access into critical infrastructure and regulated institutions, already in circulation and already searchable.

Filtering Out Infrastructure

Not every address in a dataset like this belongs to a victim. A meaningful share fronts content-delivery and cloud platforms, where the resolved address belongs to the platform and notifying its abuse desk is non-actionable. We segmented those out during enrichment to keep the notification set clean.

Tier	Endpoints	Treatment
Drop (CDN / large cloud)	2,216	Excluded from notification
Verify (bulk hosting)	256	Held for owner confirmation
Direct (subscriber networks)	24,636	Eligible for notification

Drop-tier addresses concentrate on a handful of major content-delivery and cloud providers. Verify-tier addresses sit on three bulk hosting providers where the downstream owner is not yet confirmed. Pulling both out of the notification set raises its signal and avoids burying provider abuse channels under reports they cannot take action on a subscriber’s behalf.

Reconstructing the Method

A catalog carries fingerprints of the process that built it. Parts of how this campaign ran are written straight into the data; other parts are known only from the public incident reporting and show up here as corroboration rather than proof. The reconstruction that follows keeps those two apart, tagging each stage by whether the dataset itself stands behind it or whether the support comes from outside.

Two Pools, in the Operators’ Own Tags

Each profiled entity carries a source field recording which internal pipeline stage produced it. Those tags resolve into two distinct populations, and the split is absolute. Of 3,525 entities tagged as matched, every single one carries at least one reachable host and an observed port. Of 739 entities tagged from a known-credentials pool and nothing else, not one carries a host or a port. They are credential records with no device attached.

The seam between the two pools is the operators’ own bookkeeping. One pool is credential material they already held, pulled from earlier breaches of this product family and from infostealer logs, which is why it sits in the catalog with no live device behind it. The other is what they got by testing credentials against reachable devices and recording the hits, which is why every matched entry comes with a host and a port. The campaign ran both at once, a standing credential hoard feeding a validation engine, and the source tags let you watch the handoff between them.

A third tag confirms the toolkit includes credential spraying directly: one entity is marked from spray results, carrying credential records and no host, the residue of a spray run that has not yet been tied to a reachable device. It is a single artifact, but it is the operators’ own label for the technique.

Internal Credentials, Filed Separately

None of the 312 internal AD realms turn up in the matched pool. Every one is tagged from the known-credentials pool with no reachable host attached, and that placement is the point. The externally validated credentials and the internal directory material were gathered by different means and the operators filed them as different things. The external set was proven by reaching a device; the internal set, the .local and .corp realms, was never tested against an outside login because it was never outside in the first place. It came from inside the environment.

On the mechanism of that internal collection, the dataset shows the result but not the method. It records that internal directory credentials were gathered and held as a distinct class, but it does not contain hashes, protocol fields, or capture metadata, so it cannot by itself show how they were taken. External incident responders working live FortiBleed cases attribute the internal harvest to packet capture run on the compromised firewall, skimming authentication hashes for directory users whose traffic crossed the device. That mechanism is consistent with what this dataset shows, a population of internal directory credentials held separately from the externally validated ones, but the mechanism itself is established by those external reports, not proven here.

The Pipeline, Stage by Stage

#	Stage	Evidence basis
1	Seed from pre-held credential pools (prior product-family leaks, infostealer logs)	Dataset: known-creds tag, no host
2	Identify reachable devices by internet-wide scanning of management and VPN services	Dataset: SSH-dominated exposure; external reports
3	Extract device configurations, pulling local user tables and stored hashes	Dataset: internal IPs, AD realms, pooling
4	Crack stored hashes offline	External reports (no hash field here)
5	Pivot inside and harvest internal directory credentials	Dataset: internal-cred class; mechanism per external reports
6	Validate hits against live devices and catalog by country, sector, revenue	Dataset: matched tag with host; profile fields
7	Feed newly captured credentials back to stage 1	External reports (self-feeding loop)

The reason those stored hashes could be cracked at all explains why even current devices are caught up in this. The campaign leaned on how this product family used to store administrator passwords, a salted legacy scheme that a later release swapped out for something stronger, but only for accounts that logged in again after the upgrade. Until an admin re-authenticates, the old hash sits in a hidden field in the configuration backup, so a device can be fully patched and still be carrying crackable credentials in its own config. Fortinet has now confirmed this in its own advisory, pointing customers at the releases that use the stronger hashing and at a setting that strips the legacy hashes out. It closes the loop between reading a config and walking away with a working password: the hash was in the config, the config was read, and the old storage format let it be cracked offline.

One thing this data cannot tell us is timing. There are no timestamps on any record, so the collection cannot be dated from what we hold. One external advisory puts the collection window somewhere in the second half of May into early June 2026 and marks that as unvalidated, and we can only repeat it on the same terms, a single-source estimate that nothing in this dataset confirms or sharpens.

ATT&CK Mapping

For defenders building detection and hunt coverage, the campaign maps cleanly onto the ATT&CK Enterprise matrix. The mapping below follows the same discipline as the reconstruction: each technique is tagged by whether this dataset evidences it directly or whether it rests on external incident analysis. Techniques marked as dataset-evidenced are the ones a defender can be most confident sit in this operation, because the artifact is in the data itself.

Technique	Name	Basis
T1595.002	Active Scanning: Vulnerability Scanning	External; exposure profile consistent
T1589.001	Gather Victim Identity Info: Credentials	Dataset: pre-held credential pool
T1078	Valid Accounts	Dataset: 46,799 confirmed-valid hosts
T1133	External Remote Services	Dataset: VPN/mgmt exposure
T1110.004	Brute Force: Credential Stuffing	External: leaked-list reuse
T1110.003	Brute Force: Password Spraying	Dataset: spray-results artifact
T1110.002	Brute Force: Password Cracking	External: offline GPU cracking
T1602.002	Data from Config Repository: Network Device Config Dump	Dataset: internal IPs, AD realms
T1003	OS Credential Dumping	Dataset: stored-cred capture from config
T1040	Network Sniffing	External: on-device packet capture
T1018	Remote System Discovery	Dataset: internal AD realms captured
T1021	Remote Services	External: pivot into internal AD

This sits in Credential Access and Collection, well away from Exploitation, and that is what a SOC most needs to take from the mapping. There is no software vulnerability to patch here and no exploit signature to fire on. The work is done with valid accounts and by lifting the configuration, so the detections that earn their keep are authentication-anomaly hunting and config-access monitoring. A control stack tuned to catch exploits will watch this operation walk straight past it.

Three of these deserve to be at the front of a hunt. Valid Accounts carries the whole operation, since every later move rides on a login that looks legitimate, so the best return comes from authentication analytics on the management and VPN planes, flagging impossible travel, off-hours admin sessions, and source addresses that do not match how the device is normally operated. Network Device Configuration Dump is the collection step our data proves outright, which makes any unexpected configuration export, backup pull, or admin-level read of the config worth an alert, especially on a perimeter device where that kind of access should be rare and accounted for. The third comes out of the directory targets in the data and Fortinet’s own advice: where the device is joined to Active Directory or LDAP, treat the integration account as suspect and watch the domain-controller logs for it turning up elsewhere, for new accounts appearing, and for lateral movement spreading off the back of it.

Key Judgments

HIGH: We assess with high confidence that the exposure is real, broad, and current. Independent verification of live credentials, the presence of configuration-only fields in this dataset, and the consistency of the data through enrichment all support this, and the population is not confined to legacy hardware.

HIGH: We assess with high confidence that the value of this dataset is in the credentials themselves and not in any exploitable flaw. There is no unpatched vulnerability holding it together, which means a device that looks fully maintained is still exposed if its stored credentials were taken and never rotated, and no patch-state dashboard will show that gap.

HIGH: We assess with high confidence that the collection involved wholesale configuration extraction, not only credential guessing, based on 1,358 non-routable internal addresses and 312 internal directory realms in this dataset that no external technique can produce.

MODERATE: We assess with moderate confidence that detection of follow-on access will be poor across most of the affected population. Credential reuse against a legitimate interface produces no exploit signature, and external reporting notes tunneling tooling consistent with quiet persistence, so absent authentication-log review an intruder looks like an administrator.

MODERATE: We assess with moderate confidence that re-collection is likely if the root condition is left in place. The management plane is broadly internet-reachable, which is what enabled bulk capture and what will enable it again, and restricting that plane to trusted networks is the single highest-value structural fix.

MODERATE: We assess with moderate confidence that any single endpoint’s credential remains valid today, because validity was recorded at collection time and some owners will have rotated since. The conservative default holds: treat a matched credential as live until it has been rotated.

Already for sale, and the price doubled on disclosure

None of this is waiting to be monetized; it already has been. The same class of data has been up for auction on a top-tier Russian-language forum, and the three posts in that thread track how a disclosure pushes an asset’s price up instead of down. The seller had it listed before any of the public reporting existed, then raised the price the moment that reporting confirmed what they were sitting on.

The first post went up on June 12, four days ahead of any public reporting. The seller offered a Forti VPN dataset in ip:port:login:password format, 34,000 lines, 6,896 unique IPs in the top tier and 3,100 unique United States IPs among them. The advertisement said outright that the underlying flaw was not yet public and that what was on offer was a hash dump, with the sale to run through the forum’s escrow. The opening bid was 25,000 dollars. A structured, validated dump sitting on a sales thread that far ahead of the first advisory tells you the collection was already finished and moving while defenders had no idea it existed.

By June 16 the tone had changed. The seller now said the flaw would be patched soon and research was underway, but that they were still dumping and the accesses were fresh, and bumped the opening bid to 30,000 dollars. Still dumping is the phrase that matters. This was not an old archive being cleared out; the pipeline was still running while the security community was only beginning to write about it.

Then on June 17, with the FortiBleed reporting now out, the seller dropped the research blog link straight into the auction and reset the price to 60,000 to open, 25,000 increments, 120,000 to take it outright. The published research had become the sales pitch. A defender’s disclosure was being used as the seller’s own proof of authenticity, and the asking price more than doubled in a day on the strength of it.

Figure 2. Auction thread for the affected credential data on a Russian-language cybercrime forum, captured from Flare. The three posts span June 12 to 17, 2026, with the opening price rising from 25,000 to 60,000 dollars as public reporting validated the dataset.

Two things the seller says line up with what the data shows on its own. The material is described as a hash dump, which matches the configuration-extraction and stored-hash evidence in the dataset, and the claim of fresh, ongoing collection matches the self-feeding pipeline the incident reporting describes. The listing and the catalog are the same operation seen from two ends, one the people selling the access, the other the inventory that access produced.

From Login to Incident

A working perimeter credential is the first move in a well-worn sequence, and the early steps look the same whether the operator is after money or after access for its own sake. They log in through the VPN or management interface, get inside, move laterally, escalate, knock out backups and security tooling, and find the systems that matter. From there it splits three ways.

Encryption and extortion. The credential is sold or used directly by a ransomware affiliate. Double extortion is the norm, because exfiltrated data pressures payment even when backups survive. Initial access to encryption commonly runs in 24 to 72 hours.

Exfiltration only. No encryption, no ransom note, nothing visibly broken. The data is staged, taken, and sold or sat on for later. These can run for weeks without anyone noticing, and a perimeter device left in place as a listening post is close to ideal cover for it.

Quiet, persistent access. The foothold is held and sold on instead of being used directly. Access brokers exist to turn one working credential into a sale, and a login nobody thinks to rotate keeps earning for as long as it stays good.

The exposure classes in this dataset are the documented entry point for all three. Edge and remote-access appliances have been the most consistent initial-access vector in recent ransomware and nation-state intrusions, and a pre-validated, searchable list of working credentials removes even the reconnaissance step.

What Security Teams Can Do this Week

For any organization running one of these appliances:

• Rotate every administrative and VPN credential on every FortiGate appliance you run, not only those that appear in a published lookup. Treat the dataset as incomplete.
• Pull the management and remote-access interfaces off the public internet. Restrict them to trusted source networks. This is the structural fix that prevents re-collection.
• Enforce multi-factor authentication on every remote-access and management service.
• Review authentication logs for administrative sessions you cannot explain, new or unexpected local accounts, and changes to security policy or configuration.
• Hunt for persistence and injected accounts. Look for unexpected tunneling utilities, altered scheduled tasks, and unauthorized configuration changes, and check the administrator and VPN user lists against a known-good configuration. Fortinet has flagged specific account names being injected for persistence, including forticloud, fortiuser, fortinet-support, and fortinet-tech-support; any of these that you did not create should be treated as attacker-placed. If you find evidence of access, treat the device as compromised and open a full investigation rather than rotating and moving on.
• Confirm affected accounts have re-authenticated since the early-2025 storage-hardening change. Accounts that never re-authenticated retain weaker stored material and should be rotated and re-enrolled regardless.

Methodology and Limitations

This analysis was produced entirely from passive sources and from data already in public or semi-public circulation. No active scanning, probing, authentication, or exploitation of any kind was performed against any host referenced here, and no traffic was sent to any in-scope asset as part of this work. The same class of data is freely available to any party willing to run the same queries, including the operators of this campaign.

Organizations are not named, and that is a deliberate editorial choice. Identifying owners by name would hand an attacker a pre-sorted target list and shorten the distance between reading this and targeting the hosts it describes. Withholding the names does not make the hosts safer, because the same identities sit in the same circulating data, but it avoids giving a published article the role of waypoint for the next intrusion. Affected owners can request a direct review against their own infrastructure.

Findings should be treated as indicators, not confirmed exploitable conditions. The conditions below in particular warrant care during triage:

• Credential validity reflects status recorded in the source collection and may have changed through owner rotation since capture.
• Geographic and operator attribution is based on autonomous-system registration, reverse DNS, and certificate metadata, which can be inaccurate or stale, and may not reflect the true operating location of the owning entity.
• Port and service observations reflect exposure data, not active probing. A host may present services not captured here.
• Infrastructure segmentation reduces but does not eliminate misattribution where hosting is shared, outsourced, or registered under a parent entity.

The dataset is a scoped, deduplicated derivative of a larger upstream collection. The headline counts are a triage signal and a lower bound, not a precise tally, and nothing here should be read as a confirmed compromise without authenticated validation against asset inventory and device logs.