123 Reg says an "AI-driven" attack read customer data and cites a China nexus; the evidence given is servers and tools
123 Reg, as reported by The Register, says an AI driven attack on 18 September read customer contact data, and points to servers in China and Singapore and AI tools found on them. No customer count, entry route or public notice was found, and CrowdStrike's own report names no state.
By Parminder Kumar Sharma · · 16 min read
Forty days to the press report, and three claims resting on one kind of evidence
123 Reg, the UK domain registrar owned by GoDaddy, says the intrusion happened on 18 September 2026. The Register published its report at 11:45 UTC on 28 October. That is 40 days (derived). It is the only interval the record supports, because nothing read gives the date customers were emailed, the date the attack was contained, or the date any regulator was told.
As reported by The Register, the company makes three claims: that this was "the first known AI-driven cyberattack against our company", that there is a Chinese nexus, and that a Chinese state sponsored group could be behind it. The evidence reported for the first two is about the attacker's servers and tools: addresses hosted in China and Singapore, AI attack "skills" on Chinese infrastructure including copies of skills Anthropic open sourced, and the open source tool ARTEX, said to have been observed in the attack. Nothing reported shows how the requests that read 123 Reg's data behaved.
That is what the record does not establish: that an AI agent, rather than a person using AI tools, ran the reads; that the operator sits in China; or that a state is involved. The CrowdStrike post the company cites says the activity it describes "has not been attributed to a named adversary" and that the actor is likely a Chinese speaker and financially motivated, assessed with moderate confidence. It does not mention 123 Reg. The company's link to that actor is the company's own statement.
How this was read, from 18:40 to 18:55 GMT on Wednesday 28 October 2026. No customer notice, Information Commissioner's Office (ICO) filing or stock exchange notice was found. 123 Reg's home page and support page carried no notice. GoDaddy's site refused a robots file read with an access denied page, so it was skipped, and a forum thread quoting GoDaddy's notice answered a bot check, so it was skipped too. The Register's robots file does not admit this briefing's research agent, so its page was read through a fetch tool that returns a summary rather than page text: everything attributed to The Register is second hand and shown as reported. GoDaddy's notice is read only as relayed by VINnews. CrowdStrike's post was read in full and saved. The ICO pages were read in full.
Stated and not stated: the incident record
The table keeps apart the dates, the data, the entry route and the response. "Not stated" means not found in any source read, which are second hand for the company's own words. It does not mean the information does not exist.
What the company's statements as reported by The Register (28 October 2026) and GoDaddy's notice as relayed by VINnews (28 October 2026) state, and what they do not.
| The question | Stated | Not stated |
|---|---|---|
| Access window | The intrusion was on 18 September (123 Reg email, via The Register). GoDaddy's notice says the incident occurred on 18 September (via VINnews). | When access began and ended, and whether it was one day or several. |
| Discovery | GoDaddy's notice: detected the following day, 19 September (via VINnews). | 123 Reg's own discovery date, and who found it. |
| Containment | 123 Reg worked with Singapore based internet service providers to shut down attacker servers. GoDaddy says the incident was contained and further steps were taken. | The date, and whether access was cut at the API or only at the attacker's servers. |
| Notification | Customers began receiving emails this week. Law enforcement, the FTC and the UK and EU data protection authorities were notified. | Dates, the UK authority by name, how many emails went out, and whether notice to customers was legally required. |
| Entry route | Data was pulled from an API. GoDaddy: the attacker obtained information through an API. | How the attacker reached the API: a credential, a flaw or a misconfiguration. |
| Records, accounts, people | Nothing. | Any count of customers, accounts or records. |
| Data fields | Names, phone numbers, countries, language and currency preferences, account creation dates, products on the account, marketing preferences, company VAT numbers, and "related customer relationship data". | Whether email addresses, postal addresses, domain names or support history are in the set, and what the relationship data contains. |
| Passwords | GoDaddy: the attacker did not obtain passwords. 123 Reg's email says it will never contact customers to request a password. | 123 Reg's own statement on whether passwords or hashes were exposed, and how they are stored. |
| Payment data | Not listed among the exposed fields by either. | Any statement either way for 123 Reg. |
| Activity | "Limited to reading" (123 Reg email). Copies may have been made (spokesperson). GoDaddy: no evidence of changes to websites or accounts. | Whether data left the network, how much, and whether access was repeated. |
| Attacker | A Chinese state sponsored group is suspected, possibly the one that used ARTEX against South Korean financial organisations. | Any evidence tying the 123 Reg intrusion to that group. |
Two features of this record matter before any claim about AI. First, there is no public notice on 123 Reg's own site that a reader can check, so every fact above is as relayed. Second, the one number that would size the harm, how many customers, is absent from all of it. A breach with no stated count cannot be compared with any other.
Five dates that must not be merged, and two notices that may be one incident
The intrusion date, the detection date, the notification dates and the publication date are different facts. Only two have a source here, and only one has a source from the company itself. The diagram sets them out, with the intervals this briefing derived.
The Register describes a 123 Reg notice. VINnews describes a GoDaddy notice about its Websites + Marketing product. The two share a date and a good deal of wording. Whether they are one incident or two is not stated by either; that they are one is inference.
The two notices set side by side. 123 Reg as reported by The Register, 28 October 2026; GoDaddy as relayed by VINnews, 28 October 2026.
| Point | 123 Reg (via The Register) | GoDaddy (via VINnews) |
|---|---|---|
| Product named | Customer data and product information from an API. | Websites + Marketing: profile, settings and contact information. |
| Date | 18 September. | Occurred 18 September, detected the next day. |
| Label | The first known AI driven cyberattack against the company. | Its first known AI driven cyberattack. |
| Reading | Activity "limited to reading"; copies possible. | Activity limited to reading; no evidence of changes or account access. |
| Authorities | Law enforcement, FTC, UK and EU data protection authorities. | Law enforcement, and voluntarily the FTC and UK and EU data protection authorities. |
| Advice | Be wary of unsolicited contact, log in directly, turn on two step verification. | Watch for suspicious emails and calls, turn on two step verification, no request for passwords, payment details or codes. |
If it is one incident, the detection date of 19 September applies to both and the gap from detection to the press report is 39 days (derived). If it is two, 123 Reg's detection date is unknown. Either way, the first public account found was a news report, not a notice on a company site.
"AI driven": what the evidence is, and what it is not
"AI driven" can mean three different things: a person using AI tools to write scripts, a person directing an agent step by step, or an agent running a whole intrusion unattended. A customer notice that uses the phrase does not say which. The company's reported evidence is about preparation. Its spokesperson said the AI skills and the mirror of Anthropic's open sourced skills were "consistent with preparation of this class of AI-augmented operation". Note the second phrase: "AI-augmented" is a weaker description than "AI-driven", used in the same statement.
CrowdStrike's post shows what first hand AI evidence from the attacker's side can look like. Its analysts reached open directories on servers it says the actor controlled, which held Claude Code session histories, ARTEX configuration files and Claude memory files. Even then it describes an operator giving prompts: in one session the operator asked Claude where threat actors sell Korean breach data. 123 Reg's evidence is of the same kind, files on attacker servers. What neither shows is the victim side: the request rate, the sequence, the pauses and the retries in 123 Reg's API logs that would separate a script, an agent and a person.
This is the friendly name fallacy in a new place. A label that sounds like a finding does the work of one. What the notice's own facts describe is an API that returned customer contact data to someone who should not have had it, a failure class that predates AI. Whether AI made it faster, wider or harder to spot is not stated. The framing also has a reader: a company that describes an incident as the first of its kind, by a suspected state sponsored actor, presents an attack that was hard to prevent. That is an observation about incentives, not a finding that the claim is wrong.
The China claim: servers are not operators, and a tool is not a group
The table takes each strand of the attribution in turn. The company, CrowdStrike and Anthropic each have an interest. 123 Reg and GoDaddy are describing their own incident. CrowdStrike sells security products, and its blog lists a post about working with Anthropic. Anthropic makes Claude Code, which appears in CrowdStrike's account, and no comment from it was reported.
Each strand of the attribution against what CrowdStrike's post of 7 October 2026 says. The company's statements are as reported by The Register, second hand.
| Strand | What the company says | What the record supports | Left open |
|---|---|---|---|
| Server location | Core attacker addresses were hosted in China and Singapore. | A place where servers sit. CrowdStrike's actor used proxy addresses, a Hong Kong address and, it says, likely an LLM reseller. | Whether the operator is in either country. Hosting can be rented from anywhere. |
| The tool | ARTEX, an open source Chinese developed tool, was observed in the attack. | CrowdStrike calls ARTEX a recently released open source tool developed in China. | Any user can run an open tool. Who ran it against 123 Reg is not stated. |
| Timing | The Korean campaign was the same period as the attack. | CrowdStrike says late September to early October 2026 with no day. 18 September is 12 days before the end of September (derived). | Whether 18 September falls in CrowdStrike's window. |
| Anthropic skills | A mirror of open sourced skills sat on a Chinese server. | Open sourced files can be copied by anyone. | Which model, if any, ran them, and whether Anthropic's service was used. Not stated. |
| State sponsorship | A Chinese state sponsored group could be behind it. | CrowdStrike: no named adversary; likely a Chinese speaker, financially motivated, moderate confidence. | Any evidence of a state. The CrowdStrike assessment points to money, for the Korean actor. |
Two further points sit under the table. The "strong Chinese nexus" phrase is the spokesperson's, as reported, and the evidence behind it is the servers and the tool, which are the first two rows. And the attribution chain has a step that is only asserted: that the 123 Reg intruder is the CrowdStrike actor. CrowdStrike's own post, for its part, does not mention 123 Reg. This site read the same CrowdStrike post earlier and found its AI evidence rests on the actor's own files and its bank breaches on a single press footnote. The ARTEX name also travelled between cases elsewhere: in the Seoul police case it appears in a press report but not in the police text.
"Limited to reading" is what a breach is
The reassuring phrase in the customer email is that the attacker's activity "was limited to reading" customer data. The ICO's guidance defines a personal data breach as a breach of security leading to, among other things, unauthorised disclosure of, or access to, personal data. It adds that there is a breach whenever someone accesses data "without proper authorisation". Reading is the breach. The phrase tells customers that nothing was changed; it does not tell them the data is safe.
The spokesperson's remark that copies may have been made is the more honest line, and it is the reason given for sending notices at all. The data as listed is contact data, plus what each customer holds and has chosen: that is the raw material for a message that sounds right.
What is not stated matters as much: whether the relationship data includes support history, whether email addresses are in the set, and whether the contacts are the same as the public registration contacts of a domain. None is answered in the sources read.
Technical details
Neither 123 Reg's email as reported nor GoDaddy's notice as relayed publishes an indicator: no address, domain, file name or log line. The Register's article, as reported, lists none either. The only indicators published anywhere in this story are CrowdStrike's, for the South Korean ARTEX campaign. The company says ARTEX was observed in its own attack, but no source shows that these addresses touched 123 Reg. They are a starting list for a hunt. A match would be informative; an absence would prove nothing.
The first block is CrowdStrike's own indicator table, copied as printed, with the addresses defanged as CrowdStrike printed them. The proxy addresses were used during the Korean activity. The last address is the one CrowdStrike calls a threat actor controlled address, which hosted an ARTEX instance.
101.53.80[.]20 Proxy IP address
205.214.59[.]31 Proxy IP address
124.155.252[.]63 Proxy IP address
154.201.79[.]246 Proxy IP address
23.248.249[.]90 Proxy IP address
23.158.220[.]98 Proxy IP address
103.248.148[.]84 Proxy IP address
203.160.133[.]172 Proxy IP address
209.209.85[.]38 Proxy IP address
38.244.50[.]120 Threat actor-controlled IP address
The second block is the two other artifacts CrowdStrike names in its text. The first is the open directory path on the ARTEX server, where a Chinese language prompt told the model how to conduct testing. The second is the domain CrowdStrike says the actor likely used as an LLM API proxy or reseller. A defender with web proxy or DNS logs can search for both.
http[:]//38.244.50[.]120:18899/.claude/CLAUDE.md
xcai[.]pro
The third block is the technique list CrowdStrike published, which is the only behavioural content in the post. It describes the actor's preparation and its use of proxies, not an intrusion method. It says nothing about the API a victim exposed.
Resource Development T1583.003 - Acquire Infrastructure: Virtual Private Server
Resource Development T1588.007 - Obtain Capabilities: Artificial Intelligence
Command and Control T1090 - Proxy
What to hunt, in plain words, is derived from the gaps above and not published by any source. Take the API behind customer contact data and review reads for the window around 18 September: which key or session read, how many records, at what rate, at what hours, and from which addresses. A script, an agent and a person leave different rates and rhythms; that is the evidence the notice does not supply. Compare the addresses with the list above, then widen to any address that read far more than a normal client.
The UK angle: what the ICO's guidance asks, and what the record cannot test
123 Reg is a UK registrar and its customers are in the UK, so the UK data protection regime applies to this story. The Register reports that the company notified "data protection authorities in the UK and EU". Neither source names the ICO, although the ICO is the UK's authority.
The ICO's breach guidance ("Personal data breaches: a guide", read 28 October 2026) against what the record on this incident can and cannot test.
| What the ICO says | What the record on 123 Reg shows | Can it be tested? |
|---|---|---|
| Report a notifiable breach to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it. | The authorities were notified. No date is stated. If awareness was 19 September, 72 hours ends on 22 September (derived). | No. The notification date and the date of awareness for 123 Reg are not stated. |
| Information may be given in phases if the investigation is not complete. | Entry route, count and containment date are all absent from the public account. | Not from the record. |
| Tell affected individuals directly and without undue delay if the breach is likely to result in a high risk to them. | Customers began receiving emails the week of 28 October, 39 days after 19 September if it is one incident (derived). | No. The ICO sets no number of days, and no date of the company's risk decision is stated. |
| Tell people what happened, the likely consequences and the measures taken, with advice, which can include looking out for phishing. | The notices as reported advise caution about unsolicited contact and two step verification. | Partly. Advice matches. The count, consequences and DPO contact are not reported. |
| Record every breach, reported or not. | Not stated. | No. |
None of this shows non compliance. The record is too thin to test any of it, and that is the finding. For a customer, the ICO's public guidance says organisations do not always have to tell you about a breach, that it is for the organisation to assess whether they need to, and that sometimes they tell you to be open. That the company sent notices does not by itself show a high risk finding, and the ICO guidance on the page read gives no per day limit for telling individuals.
What to do, in order
Take this with you
Ranked actions for customers and for anyone who runs an API that returns customer data
- Treat any call, text or email about this incident, a domain renewal or an account problem as unproven. Close it and type the registrar's address yourself.
- Turn on two step verification on the registrar account, and on the mailbox that receives its password reset links.
- Keep the notice you received, with the date and the account it names, in case you need it later.
- Tell whoever answers your phone or manages your domain that a caller may know your name, your products and when you joined.
- Ask the supplier in writing: which fields, whether passwords or hashes were exposed, how many customers, the dates of discovery, containment and notification, and the UK authority notified.
- If you run an API that returns customer data, pull read logs for the window around 18 September and look at rate, volume, hour and source address per key.
- Put a rate limit and a per key volume alert on reads of contact data, so that a scripted or agent driven sweep stands out whoever runs it.
- When a vendor calls an attack AI driven, ask for the victim side log that shows it. Tools on an attacker's server are preparation, not proof.
The question that exposes the gap
If 123 Reg says the attack was AI driven, which line in its own API logs shows it, and would that line look any different if a person had typed the same requests?
Key facts
Sources
- PrimaryCrowdStrike Counter Adversary Operations post of 7 October 2026, read in full: the ARTEX campaign against South Korean financial organisations, no named adversary, likely a Chinese speaker and financially motivated with moderate confidence, the indicators and the ATT&CK table. The vendor's own post, which does not mention 123 RegCrowdStrikeaccessed 2026-10-28
- PrimaryPersonal data breaches: a guide, read in full on 28 October 2026: the definition including unauthorised access, the 72 hour test, phased reporting, telling individuals without undue delay and the advice they should be givenInformation Commissioner's Officeaccessed 2026-10-28
- PrimaryICO public guidance on what a personal data breach is and whether an organisation must tell you, read on 28 October 2026Information Commissioner's Officeaccessed 2026-10-28
- Primary123 Reg's support page, read on 28 October 2026 to look for a customer notice of the incident; none was found on this page or the home page123 Regaccessed 2026-10-28
- Reported byThe Register, 28 October 2026 11:45 UTC: 123 Reg's customer email and spokesperson statements on the AI driven label, the data fields, the China and Singapore servers, the Anthropic skills mirror, ARTEX and the regulators. Read second hand through a summarising fetch tool because its robots file does not admit this briefing's research agentThe Registeraccessed 2026-10-28
- Reported byVINnews, 28 October 2026, relaying GoDaddy's notice about its Websites + Marketing product: occurred 18 September, detected the next day, API, limited to reading, no passwords obtained, FTC and UK and EU authorities, advice. GoDaddy's own notice was not foundVINnewsaccessed 2026-10-28
- Reported byTech Digest, October 2026: a summary of The Register's account giving the 123 Reg spokesperson's list of affected fields and that customers began receiving emails this weekTech Digestaccessed 2026-10-28
