FBI's FortiBleed alert names no CVE, and its 86,644 is SOCRadar's count, which stood at 30,791 on 17 June

86,644 is SOCRadar's count, and the same page said 30,791 the day before

On Tuesday 6 October 2026 the FBI and the US Secret Service (USSS) published joint advisory JCSA-20261006-01 on FortiBleed. Its first paragraph carries one number, 86,644 compromised devices in 194 countries, and a footnote credits it to SOCRadar, a security vendor, not to the agencies. SOCRadar's own post, as the Internet Archive captured it at 12:59 UTC on 17 June, was titled "The Compromise of 30,000 Fortinet Firewalls" and said 30,791 devices. A capture at 14:11 UTC on 18 June, 25 hours and 12 minutes later, says 86,644. That is 2.8 times the first figure (our arithmetic). The breakdown tables on the page still use the old base: the top username entry, 6,599, is printed as 21.43%, and 6,599 is 21.43% of 30,791.

What that does not establish. It does not show the campaign grew 2.8 times in a day. SOCRadar does not say why the figure changed, and its FAQ says "different firms are counting different things". It does not show that every one of the 86,644 is a Fortinet firewall: CloudSEK, another vendor, says the operators' raw credential file also holds other vendors' devices and calls the headline numbers "an upper bound". It does not show that any given device is affected today: SOCRadar says each login was verified by the attackers' own tooling and was working "at time of collection". It gives no count for the UK. And it does not show that a vulnerability is involved. The alert names no CVE, and says affected organisations need "remediation steps beyond standard patching and password resets".

What the alert states, and what it leaves out

JCSA-20261006-01 is eleven pages, marked TLP:CLEAR, co-authored by the FBI and the USSS and titled "FortiBleed Operations Continue Targeting Exposed Systems Leading to Reports of Lockouts". Its version history has one entry, 6 October. Its footnotes credit SOCRadar for the count, CloudSEK for the account of the operators' own server, and Fortinet for the mitigations and the hashing guidance. The lockout paragraph and the two indicator tables carry no footnote (the paragraph above the IP table cites CloudSEK), so the alert does not say which observations are the agencies' own. Its only hint is the phrase "Based on initial responses".

What advisory JCSA-20261006-01 states and does not state. Source: the advisory PDF on ic3.gov, read in full on 7 October 2026.

1. Topic

   How access was gained

   Stated in the alert

   The campaign "exploits reused or leaked credentials and legacy SHA-256 password storage". Credential stuffing and password spraying from earlier Fortinet leak dumps and infostealer logs.

   Not stated

   How the credentials were first obtained. Any CVE. Any affected or fixed version.

2. Topic

   Number of devices

   Stated in the alert

   SOCRadar "verifying more than 86,644 compromised devices across 194 countries".

   Not stated

   Any FBI or USSS count. Any US or UK count. How many logins still worked on 6 October.

3. Topic

   Lockouts

   Stated in the alert

   Some victims "may get locked out" if the actor deletes or changes the password for original accounts. Actors "create new accounts not previously on the device".

   Not stated

   How many organisations were locked out, and how any recovered.

4. Topic

   Ransomware

   Stated in the alert

   "Reporting indicates" access brokers using the chain gave access to affiliates, "currently including INC/Lynx ransomware and Payload ransomware".

   Not stated

   Any victim, count or date. Who the reporting came from. Which broker.

5. Topic

   Indicators

   Stated in the alert

   13 IP addresses in Table 1, with dates observed from 18 June to 23 July 2026. Seven more in the text. 19 account names found on victim systems.

   Not stated

   Any dated activity after 23 July, 75 days before publication. File hashes.

6. Topic

   Patching

   Stated in the alert

   Remediation needed is "beyond standard patching and password resets". The one version number is FortiOS 7.2.11 and later, for PBKDF2 hashing.

   Not stated

   Any vulnerable version, fixed build or patch.

7. Topic

   Recovery

   Stated in the alert

   Isolate, hunt, report, then apply eviction countermeasures "after collecting enough threat hunting data". Review REST API keys.

   Not stated

   How to regain control of a device you are locked out of.

8. Topic

   The UK

   Stated in the alert

   Nothing. The reporting routes are US ones: IC3, FBI and USSS field offices, CISA's operations centre.

   Not stated

   Any UK count. Any NCSC route.

Topic	Stated in the alert	Not stated
How access was gained	The campaign "exploits reused or leaked credentials and legacy SHA-256 password storage". Credential stuffing and password spraying from earlier Fortinet leak dumps and infostealer logs.	How the credentials were first obtained. Any CVE. Any affected or fixed version.
Number of devices	SOCRadar "verifying more than 86,644 compromised devices across 194 countries".	Any FBI or USSS count. Any US or UK count. How many logins still worked on 6 October.
Lockouts	Some victims "may get locked out" if the actor deletes or changes the password for original accounts. Actors "create new accounts not previously on the device".	How many organisations were locked out, and how any recovered.
Ransomware	"Reporting indicates" access brokers using the chain gave access to affiliates, "currently including INC/Lynx ransomware and Payload ransomware".	Any victim, count or date. Who the reporting came from. Which broker.
Indicators	13 IP addresses in Table 1, with dates observed from 18 June to 23 July 2026. Seven more in the text. 19 account names found on victim systems.	Any dated activity after 23 July, 75 days before publication. File hashes.
Patching	Remediation needed is "beyond standard patching and password resets". The one version number is FortiOS 7.2.11 and later, for PBKDF2 hashing.	Any vulnerable version, fixed build or patch.
Recovery	Isolate, hunt, report, then apply eviction countermeasures "after collecting enough threat hunting data". Review REST API keys.	How to regain control of a device you are locked out of.
The UK	Nothing. The reporting routes are US ones: IC3, FBI and USSS field offices, CISA's operations centre.	Any UK count. Any NCSC route.

One detail needs care. The alert tags the first-access step with ATT&CK technique T1190, whose name in the alert's own table is "Exploit Public-Facing Application". The alert's words under that tag are only "targeted publicly exposed FortiGate infrastructure". A technique tag is not a CVE, and the alert names none.

A name that sounds like a bug, three things it labels, and no bug

FortiBleed labels at least three different things. For CloudSEK it is "the label given to a verified dataset of working device credentials". SOCRadar's FAQ says it "coined the term" for a campaign. The alert uses it for "a credential-harvesting and access-broker operation" and, elsewhere, for an attack chain. The suffix invites a comparison with a memory-disclosure bug that a patch closes. That comparison is ours, and none of the sources makes it. All of them say the opposite. Fortinet, 19 June: "This is not a new Fortinet vulnerability". SOCRadar: "There is no single CVE behind it". CloudSEK: "not a software vulnerability".

Yet vulnerabilities sit in the history, and the history is why a patch is not the answer. Fortinet's blog says the activity involves "reusing credentials from previous incidents" and cites two of its own advisories, FG-IR-26-060 and FG-IR-25-647. Both are real flaws. FG-IR-25-647 (9 December 2025, CVE-2025-59718 and CVE-2025-59719) and FG-IR-26-060 (27 January 2026, CVE-2026-24858, scored 9.4 by Fortinet) are FortiCloud single sign-on login bypasses that Fortinet marks as exploited. CISA listed CVE-2025-59718 on 16 December 2025 (due 23 December) and CVE-2026-24858 on 27 January (due 30 January). The PSIRT page for FG-IR-26-060 lists the actor's main operations as downloading the customer configuration file and adding an administrator account for persistence.

Our inference, labelled as one. A patch for those flaws closes the route in. It does not change a password that already sits in a downloaded configuration file. Fortinet does not describe that mechanism, and the alert cites neither advisory. SOCRadar says some researchers have discussed whether CVE-2026-24858 contributed in "a subset of cases", that this is under investigation, and that FortiBleed is "primarily a credential reuse and offline cracking campaign". For a different Fortinet product with a real, unfixed flaw, see our briefing on FortiMail CVE-2026-104286. FortiMail is not FortiGate, and the contrast is the point: there the problem is a missing fix, here a fix would not be the answer.

How each source describes first access. Sources as named, read on 7 October 2026.

1. Source and date

   FBI and USSS, 6 Oct

   How first access is described

   Reused or leaked credentials and legacy SHA-256 storage. Credential stuffing, password spraying, hashes cracked offline.

   CVE named as the cause?

   No

2. Source and date

   NCSC, 18 Jun

   How first access is described

   "brute-force, dictionary and credential stuffing attempts" against internet-facing FortiGate and VPN portals.

   CVE named as the cause?

   No

3. Source and date

   CISA, 18 Jun

   How first access is described

   Internet-accessible Fortinet devices targeted "using compromised credentials". No method given.

   CVE named as the cause?

   No

4. Source and date

   Fortinet blog, 19 Jun

   How first access is described

   Credentials reused from previous incidents, plus brute force, against devices with weak password hygiene and no MFA.

   CVE named as the cause?

   No. Cites two earlier advisories as the source of the credentials.

5. Source and date

   SOCRadar, 16 Jun on

   How first access is described

   Leaked credentials from earlier breach dumps and infostealer logs tried against devices, plus a legacy hashing gap. A whitepaper summary adds SSH brute force against admin accounts.

   CVE named as the cause?

   None as the cause. CVE-2026-24858 "discussed", under investigation.

6. Source and date

   CloudSEK, 19 Jun

   How first access is described

   Credential reuse, brute force and offline hash cracking against exposed devices.

   CVE named as the cause?

   No

Source and date	How first access is described	CVE named as the cause?
FBI and USSS, 6 Oct	Reused or leaked credentials and legacy SHA-256 storage. Credential stuffing, password spraying, hashes cracked offline.	No
NCSC, 18 Jun	"brute-force, dictionary and credential stuffing attempts" against internet-facing FortiGate and VPN portals.	No
CISA, 18 Jun	Internet-accessible Fortinet devices targeted "using compromised credentials". No method given.	No
Fortinet blog, 19 Jun	Credentials reused from previous incidents, plus brute force, against devices with weak password hygiene and no MFA.	No. Cites two earlier advisories as the source of the credentials.
SOCRadar, 16 Jun on	Leaked credentials from earlier breach dumps and infostealer logs tried against devices, plus a legacy hashing gap. A whitepaper summary adds SSH brute force against admin accounts.	None as the cause. CVE-2026-24858 "discussed", under investigation.
CloudSEK, 19 Jun	Credential reuse, brute force and offline hash cracking against exposed devices.	No

Which number counts what

The published figures do not describe one thing. CISA's alert of 18 June, revised on 22 June, says leaked credentials are associated with "approximately 74,000" devices. SOCRadar's own figure went from 30,791 to 86,644 between two captures 25 hours apart. And the later figure CyberScoop quotes from SOCRadar's chief information security officer, "more than 400,000 or 450,000 firewalls", is a different kind of number. SOCRadar's whitepaper summaries say the operation targeted "more than 430,000 FortiGate firewalls". Those are targets, not verified logins, and the pages we read do not define "targeted".

On the ratio: 86,644 is 20.1% of 430,000, or 19.3% to 21.7% against the 450,000 and 400,000 in the interview (our arithmetic). It would be wrong to read that as one targeted firewall in five compromised, or to read the sequence 30,791, 86,644, 430,000 as growth. The first two are the same label, "Compromised Devices", on the same page, 25 hours apart. The third counts targets. SOCRadar's chief information security officer told CyberScoop the later numbers "show the campaign is broader and more serious than we understood at the beginning". That may be so. A rising count from a changing definition is not a measurement of rise.

What "verified" means also moves. The alert says SOCRadar is "verifying" the devices. SOCRadar's FAQ says every credential was "verified by the attacker's own automated tooling" before it was recorded. The first is a researcher checking. The second is the attacker testing. The SOCRadar pages we read describe no independent re-test of the 86,644.

The figures in circulation and what each counts. Sources: SOCRadar (archive captures of 17 and 18 June 2026, its FAQ and report pages), CISA, CloudSEK, read 7 October 2026. Derived items are ours.

1. Figure

   30,791

   Source and date

   SOCRadar post, Internet Archive capture 17 Jun, 12:59 UTC

   What it counts

   "Compromised Devices". 21,108 unique IPs, 8,316 unique domains.

2. Figure

   About 74,000

   Source and date

   CISA alert, 18 Jun, revised 22 Jun

   What it counts

   Fortinet devices tied to "exposure of leaked credentials".

3. Figure

   86,644

   Source and date

   SOCRadar post, capture 18 Jun, 14:11 UTC. Quoted by the FBI and USSS

   What it counts

   "Compromised Devices". "80,000+" unique IPs, 22,405 unique domains.

4. Figure

   More than 430,000

   Source and date

   SOCRadar report summaries, Volumes I and II (pages undated, Volume II file uploaded July 2026)

   What it counts

   FortiGate firewalls the operation "targeted".

5. Figure

   21,632, then 918, then 148

   Source and date

   CloudSEK, 19 Jun

   What it counts

   Entries in the operators' device-registration email database. Organisations with captured internal Kerberos traffic. Confirmed Active Directory compromises.

6. Figure

   11,250, 409, 354, 12

   Source and date

   SOCRadar's second report, reading one operator spreadsheet

   What it counts

   Portals scanned. Admin access. Full chain to domain admin. Organisations marked LOCKED.

Figure	Source and date	What it counts
30,791	SOCRadar post, Internet Archive capture 17 Jun, 12:59 UTC	"Compromised Devices". 21,108 unique IPs, 8,316 unique domains.
About 74,000	CISA alert, 18 Jun, revised 22 Jun	Fortinet devices tied to "exposure of leaked credentials".
86,644	SOCRadar post, capture 18 Jun, 14:11 UTC. Quoted by the FBI and USSS	"Compromised Devices". "80,000+" unique IPs, 22,405 unique domains.
More than 430,000	SOCRadar report summaries, Volumes I and II (pages undated, Volume II file uploaded July 2026)	FortiGate firewalls the operation "targeted".
21,632, then 918, then 148	CloudSEK, 19 Jun	Entries in the operators' device-registration email database. Organisations with captured internal Kerberos traffic. Confirmed Active Directory compromises.
11,250, 409, 354, 12	SOCRadar's second report, reading one operator spreadsheet	Portals scanned. Admin access. Full chain to domain admin. Organisations marked LOCKED.

CloudSEK, whose own business is threat intelligence, reads the same operators' files and goes the other way. It says the widely repeated "21,632" is a count of entries in the operators' device-registration database, that only 918 organisations show captured internal Kerberos traffic (4.2%, our arithmetic), and that 148 (0.68% of 21,632) are confirmed compromises with cracked directory credentials. It also says the raw credential file mixes in other vendors' devices. Neither vendor publishes the underlying files; SOCRadar says it gave its dataset to national CERTs. The alert cites both and does not reconcile them.

Both are vendors with something to sell on this topic. SOCRadar runs the free FortiBleed checker and its FAQ ends in offers of monitoring. CloudSEK's report argues that others' numbers are inflated. That does not make either wrong. It means the alert's count and its account of the operators' workflow come from two sources that disagree about what the large numbers mean.

After the login: new administrators, then lockouts

The alert's account of what happens inside a device is short. During the initial intrusion, actors "create new accounts not previously on the device", and "in certain cases" delete existing accounts "to block organizations from accessing affected devices and to maintain persistence" while they try to move laterally. Elsewhere it says they extracted user databases and session tokens, and that SSH may have been used where the port was open. It tells defenders to review REST API keys too, remove unknown ones and refresh the rest.

This is where the friendly name does damage. "Bleed" suggests that closing the leak ends the loss. The alert describes a state: accounts exist that you did not create, and accounts you did create may be gone. A new password for your own account does not touch the first, and cannot be set for the second if you can no longer log in. The NCSC said as much on 18 June: "changing credentials alone may not be sufficient" if the actors have obtained persistence, and it advised a factory reset after collecting logs, configuration and other artefacts. That is 110 days before the FBI and USSS wrote that remediation needs "steps beyond standard patching and password resets" (our arithmetic, 18 June to 6 October).

The alert's own advice has two speeds, and the order matters. Its key actions say to terminate all administrator and VPN sessions and reset credentials. Its incident response section, for a device already compromised, says to isolate it, hunt, report, and then apply eviction countermeasures, starting them "after collecting enough threat hunting data". Our reading: reset now on devices with no sign of trouble, and on a device with an unexplained account, stop and collect first. The NCSC's order agrees: obtain logs and configuration, then factory reset, because the reset destroys them.

Two cautions on the lists. The alert's account-name list has 19 names, several imitating vendor support and cloud services and one the default administrator name itself. Fortinet's January advisory FG-IR-26-060 lists 12 names an actor used then, and Fortinet's June blog gives four examples. Only one name appears on both the alert's list and the advisory's, and none of the blog's four is on the alert's list (our comparison). A published list is a start, not a test: review every account against a record you made. And the alert's IP table, introduced as addresses "currently" conducting brute force attacks, carries dates ending on 23 July, 75 days before publication. The alert itself says to read them as "historically observed infrastructure".

Ransomware: what ties FortiBleed to it, and who says so

The alert's sentence is carefully limited. "Reporting indicates" that access brokers using the chain have supplied ransomware affiliates, "currently including INC/Lynx ransomware and Payload ransomware". It names no victim, count, date or source. CyberScoop's "lead to ransomware attacks" is the alert's "observed as an initial entry point for ransomware affiliates" in plainer words.

What ties FortiBleed to ransomware, by source. Sources: the advisory, SOCRadar's blog and second report, CloudSEK, read 7 October 2026.

1. Source

   FBI and USSS, 6 Oct

   The link it asserts

   Brokers using the chain gave affiliates access, "currently including" INC/Lynx and Payload.

   What it rests on

   "Reporting indicates". No source, victim or count given.

2. Source

   SOCRadar, update of 29 Jun and second report (July)

   The link it asserts

   The operation is linked to Lynx and INC "with high confidence". Payload is not mentioned.

   What it rests on

   An operator workstation showing access to both groups' ransomware panels, a tracking spreadsheet, and 3 of 5 victims in an INC open directory also in FortiBleed target lists.

3. Source

   CloudSEK, 19 Jun

   The link it asserts

   Access packaged for sale in the format brokers use. The operators' origin is "unresolved".

   What it rests on

   Files in the exposed directory. Predates SOCRadar's attribution and makes no ransomware link.

Source	The link it asserts	What it rests on
FBI and USSS, 6 Oct	Brokers using the chain gave affiliates access, "currently including" INC/Lynx and Payload.	"Reporting indicates". No source, victim or count given.
SOCRadar, update of 29 Jun and second report (July)	The operation is linked to Lynx and INC "with high confidence". Payload is not mentioned.	An operator workstation showing access to both groups' ransomware panels, a tracking spreadsheet, and 3 of 5 victims in an INC open directory also in FortiBleed target lists.
CloudSEK, 19 Jun	Access packaged for sale in the format brokers use. The operators' origin is "unresolved".	Files in the exposed directory. Predates SOCRadar's attribution and makes no ransomware link.

The only numbers on outcomes come from SOCRadar's reading of one operator spreadsheet: about 11,250 portals scanned in 150 countries, admin access on 409, 354 taken through the full chain to domain admin, and 12 organisations marked "LOCKED", which SOCRadar says means encrypted for ransom. Those are 3.6% of the portals, 86.6% of the 409, and 12 of 409, or 2.9% (our arithmetic). That is one sheet, relayed by a vendor, and it is not the 86,644. It also shows why a word needs care. "LOCKED" in the spreadsheet is a victim encrypted. "Lockout" in the alert is a defender who cannot log in to a firewall. They are different harms with similar names.

What neither the alert nor the vendors establish: which organisations that appear in any dataset ended up with ransomware, whether the brokers supplying Payload affiliates are the actors SOCRadar links to INC and Lynx, or whether any UK organisation is among the 12. SOCRadar's report gives no country breakdown of the 12.

For UK organisations: what the record says, and what it does not

No source gives a UK count. The NCSC's alert of 18 June says there are "some indications of potential impact in the UK" and gives no number. The UK does not appear among the top 20 countries in SOCRadar's chart of credential entries. The 20th bar, read from the image, is about 400 entries, and the chart looks to be on the early base: by our reading of the bars, India and the United States together are about 9,700 entries, 31.5% of 30,791, which matches the post's "nearly a third". SOCRadar's list of the top 50 organisations by revenue has two UK entries, ranks 34 and 47, with names withheld. And SOCRadar's second report says the operators' spreadsheet legend marks the UK as a "Priority 1" country, alongside the United States, Germany and others. None of that is a count of UK devices. Read together, it says the UK is a market the operators prioritised and a small share of the entries SOCRadar charted, and no more than that.

The NCSC's advice already covers most of it. Its alert tells UK organisations to confirm the device exists and is theirs, look for unauthorised accounts and unexpected log activity, isolate the device if there is evidence, report it, factory reset, investigate other edge devices that share credentials, and harden: no internet-exposed management interfaces, latest version, no default or reused passwords, MFA on all VPN and management logins, PBKDF2 and a forced re-login. It points to its free Early Warning service. Its older guidance says the same about exposure. Its blog of 22 March 2017 on management interfaces says an attacker with stolen privileged credentials can be "thwarted if they can be prevented from accessing the interfaces they would need to use them". Its ransomware guidance, published 13 February 2020, says to "enable MFA at all remote access points into the network, and enforce IP allow listing using hardware firewalls".

What UK-relevant sources say about internet-facing administration of a firewall. Sources as named, read 7 October 2026.

1. Source

   FBI and USSS, 6 Oct

   What it says

   Trusted hosts (good), a local-in policy (better), no internet administration (best).

   Reading

   Removal is the top option.

2. Source

   NCSC, 18 Jun

   What it says

   When re-commissioning: "Ensure management interfaces are not exposed to the internet."

   Reading

   No exposure.

3. Source

   NCSC, 27 Aug (OT advisory)

   What it says

   Manage boundary devices, firewalls included, only from a "segregated management network that is not connected to the internet".

   Reading

   Written for OT. Applies by analogy.

4. Source

   Cyber Essentials v3.3, Apr 2026

   What it says

   Change default admin passwords or disable remote administration. Block internet access to the admin interface unless there is "a clear and documented business need", then protect it with MFA or a small IP allow list plus managed passwords.

   Reading

   Exposure allowed, with conditions.

Source	What it says	Reading
FBI and USSS, 6 Oct	Trusted hosts (good), a local-in policy (better), no internet administration (best).	Removal is the top option.
NCSC, 18 Jun	When re-commissioning: "Ensure management interfaces are not exposed to the internet."	No exposure.
NCSC, 27 Aug (OT advisory)	Manage boundary devices, firewalls included, only from a "segregated management network that is not connected to the internet".	Written for OT. Applies by analogy.
Cyber Essentials v3.3, Apr 2026	Change default admin passwords or disable remote administration. Block internet access to the admin interface unless there is "a clear and documented business need", then protect it with MFA or a small IP allow list plus managed passwords.	Exposure allowed, with conditions.

Our reading of the table: Cyber Essentials is the most permissive of the four. The firewall rule accepts either an allow list with a managed password approach or MFA for an exposed administration page. A separate user access rule says to implement MFA "where available", so an assessor may expect it on a device that supports it. We have not tested how assessors apply the two. Either way, the scheme sits outside the agencies' "best" and the NCSC's "not exposed". It is also a statement about configuration at a point in time. It says nothing about whether a working login is already in someone's dataset. For firewalls an MSP manages, the scheme says accounts used by an MSP to manage your infrastructure are in scope, so the question for the supplier is the same as for your own team.

The ICO's guidance defines a personal data breach to include a loss of availability as well as unauthorised access, and says a notifiable breach must be reported "without undue delay, but not later than 72 hours" after becoming aware of it, in phases if the facts are not yet known. If an unauthorised administrator on a firewall could reach systems holding personal data, or a lockout makes personal data unavailable in a way that harms people, that clock may be running. Whether a given firewall compromise is notifiable depends on the data reachable and the likely risk to people. That is a judgement for your data protection lead. The alert does not make it for you.

The dates, to scale

The NCSC and CISA published on 18 June. The FBI and USSS published on 6 October. That is 110 days, and 112 from SOCRadar's first post of 16 June (our arithmetic). Fortinet's advisories that its blog cites are older again: 301 days from FG-IR-25-647 to the FBI alert and 252 from FG-IR-26-060. The last date in the alert's IP table, 23 July, is 75 days before the alert. The advice to reset credentials, remove exposure and add MFA is not new: CISA and the NCSC gave it on 18 June. What the FBI and USSS alert adds, on the record, is the lockout description, the ransomware-affiliate reporting and the indicator lists.

What to do, in the order worth doing

For a council, NHS trust, school, MSP or smaller organisation with Fortinet firewalls or VPN gateways. Items marked agencies follow the FBI and USSS alert, CISA, the NCSC or Fortinet. Items marked judgement are ours, and we label them so you can weigh them.

The question the alert does not answer

Every control above acts on a door or a login. None of them tells you whether, at some point since June, someone added a name to the administrator list of a firewall you are responsible for and left your own account alone. The alert says that happens "during the initial intrusion". Which record, kept by whom, would show it to you today?

Key facts