Writing code can be entrusted to AI, but who can be entrusted with domain names (security)?

Author: Yajin

On October 31, the websites of more than a dozen DeFi projects were successively hijacked. One of the affected projects, Kintsu, posted on X[1] that its domain purchased through Vercel was hijacked at the registrar level. There are two key terms in this statement: one is Vercel, and the other is registrar. Let's start with Vercel.

Vercel is a website deployment platform. Developers submit their written code to it, and it is responsible for building and launching the site, then delivering the web pages to users via servers distributed around the world. Vercel is also the company behind the front-end framework Next.js[2], which is very popular among developers, and most of the projects mentioned this time have their web pages hosted on Vercel. In addition to hosting websites, Vercel also sells domains, allowing users to purchase domains and manage DNS settings from the same backend.

From the data we found, the code for these projects hosted on Vercel was not altered; what was changed was where the domain pointed.

This incident is worth the attention of every application service provider, especially digital asset service providers. In the past two years, vibe coding has become popular, which involves describing requirements in natural language and letting AI write the program. This greatly lowers the threshold for developing applications: with AI writing the code, submitting it to deployment platforms like Vercel, Netlify, or Cloudflare for one-click launch, and purchasing a domain on the platform, one can have a decent website in just a few minutes.

While the threshold has lowered, the underlying principles have not become simpler. Many people are unaware of where their domain is registered, who can modify its pointing, and what keys are needed for modifications. Vercel is just one type of platform; these issues apply to all one-click deployment methods. This article aims to clarify these questions in as simple a manner as possible.

01 How a URL is Found

Now let's look at what Kintsu referred to as "registrar." To understand what a registrar does, we first need to see how a URL is found. We can think of a website as a store. The domain name is the store's name, like example.com; the server's IP address is the store's street number. Users only remember the store name, so someone needs to translate the store name into the street number, and this translation process is called "domain resolution."

The translation process involves three roles.

The registry acts like a central registry office. Each type of suffix has its own registry, such as .com, .xyz, .finance, etc. The registry only remembers one thing: where the "asking place" for a certain domain name is located.

The registrar acts as an intermediary running errands for users. Ordinary people cannot go directly to the registry to register; they must go through a registrar to buy a domain, renew it, or modify registration information. Users can specify which "asking place" is responsible for their domain in the registrar's backend.

The nameserver is the "asking place." It has a table that lists which store name corresponds to which street number. Each row in this table is called a resolution record. When we talk about "changing resolution," we are referring to changing this table on the nameserver.

After a user enters a URL in the browser, the browser first asks the central registry: where is the asking place for this store? Then it asks the asking place: what is the street number? Finally, it finds the store according to the street number and opens the webpage.

The browser first asks the registry, then the nameserver, and finally finds the store by street number.

So, if someone wants to trick customers into their fake store, there are two methods. The first method is to go to the asking place and change the street number on the table. The second method is more covert: to go to the registrar and completely replace the asking place registered for this store with one they control, then write a fake street number at the new asking place. When using the second method, the store owner checks the original asking place, and nothing has changed on the table, yet customers have already been led away.

Two methods: change the table at the asking place, or replace the asking place entirely with one controlled by the attacker.

02 Who Manages the Domain Bought with One Click

Understanding the registry, registrar, and nameserver, we can now look back at deployment platforms like Vercel. Deployment platforms are responsible for running the written programs online. To make things easier for users, many deployment platforms have integrated domain purchasing and DNS management into their backend, allowing users to interact solely with the platform from domain purchase to website launch.

However, behind the platform, all the roles mentioned earlier are still present. Some platforms are registrars themselves, while others act on behalf of users to find registrars; Vercel belongs to the latter category. We checked Kintsu's domain, and the registrar listed in the registry is Name.com, not Vercel itself.

This "one-stop" approach is very convenient, but the downside is that users often do not know that their domain has a registrar and are unlikely to care about the security at the registrar level. For Vercel, in its backend and interface[3], the nameserver can be modified, and the authorization code for transferring the domain can also be obtained. In other words, whoever holds the platform account or its interface permissions could potentially change the domain's pointing or even transfer the domain away.

Many projects rigorously check their code and contracts, yet their domains are under a single account that no one monitors, and when issues arise, they don't know whom to turn to.

In the AI era, "one-click" is becoming "zero-click." Vercel's command line tool[4] now supports scripts and AI assistants to purchase and renew domains without human intervention. Vercel also provides an MCP interface for AI assistants (a standard way for AI assistants to call external tools), with 28 tools related to domains and DNS[5]. This means that when a developer tells the AI, "Help me launch the website and set up a domain," the AI can handle domain purchasing and resolution changes for them.

What developers save is not just clicks, but also the opportunity to understand these processes: which account the domain is purchased under, which registrar is behind it, and who can modify it, likely never passing through their eyes from start to finish.

In one sentence, the AI has completed the domain purchase and resolution setup for the developer.

03 Where the Attacker Made Changes

According to public reports[6], on October 31, the number of websites being targeted increased to more than a dozen. In addition to Kintsu, there are DeFi projects like StonkFun, Pickle, Echelon, Origami, Fluxbeam, Stakepoint, SupSwap, Longbow, SHPRD, and ApeX DeFi.

Domain registration information is public, and anyone can query it. We checked the domains of 11 of these projects and found that all their registrars are Name.com, with 7 of them having modifications in the registry on October 31. As of 6 PM Beijing time on the 31st, 5 domains were still pointing to the attackers' servers.

The attackers used both methods mentioned earlier. pickle.finance[7] and stakepoint.app still have a table on Vercel's nameserver that lists Vercel's own server address, indicating that their original asking place should have been on Vercel; however, their asking place registered in the registry was changed to Name.com’s nameserver around 1 AM UTC on the 31st, with the new street number being 31.56.52.52.

In another case, fluxbeam.xyz, supswap.xyz, and apexdefi.xyz originally had their asking places at Name.com, and the registry's registration has not changed since February or May of this year, yet the table at the asking place now also lists the street number as 31.56.52.52, suggesting that the table itself was altered. This address is registered under a company named Snowcore[8], and the IP range is registered in the Netherlands, unrelated to Vercel.

Different projects' URLs have all been pointed to the same address controlled by the attacker.

For the remaining domains, some have been reverted to normal servers, some have switched to other service providers, and others are in the process of transferring the domain out, indicating that the project teams are attempting to recover.

Both methods have one thing in common: they require modifications to be made on the registrar side. Whether the attackers obtained permissions from Name.com itself, from the integration between Vercel and Name.com, or from the individual project accounts remains unclear from the public data. As of our inquiry, neither Vercel nor Name.com has publicly commented.

Kintsu mentioned in its announcement that the fix has been delayed, which may be related to caching. DNS servers around the world cache asking place information for a period of time, commonly around an hour. After the project team changes the registration back, some users' computers may still be using the old answer, continuing to be directed to the fake store. This is our speculation and has not been confirmed.

04 Keys Are More Than Just Passwords

As mentioned earlier, it is still undetermined where the attackers obtained permissions on the registrar side. Regardless of where the entry point is, the ability to change a domain ultimately comes down to a certain key. When talking about keys, many people think of account passwords and verification codes. Those who use AI to write programs and automate deployments actually have another type of key: access tokens.

Tokens are strings of characters that allow programs to call the platform's interfaces on behalf of users without needing passwords or verification codes. For example, in Vercel, when creating a token, one must select a scope of permissions[9]: it can manage just one project, all projects of a team, or select "entire account" to gain full permissions. The expiration time must also be chosen; after expiration, the token automatically becomes invalid. The larger the scope selected, the greater the potential loss if the token is leaked.

There are more ways for tokens to be leaked than many people realize:

• Written into code or configuration files. If a token is written into code, submitted to a public repository, or packaged into the frontend, anyone can see it.

• Hand over to the AI programming assistant. The programming assistant reads the configuration files in the project or directly obtains the tokens pasted by the user in the conversation to help users deploy. The assistant connected to the deployment platform via MCP holds the authority to modify domain names and resolutions. This information will be sent out with the conversation, and if the assistant reads a webpage or document that has been tampered with, it may be induced to execute operations that should not be performed.

• Through a relay station. Some users, for cost or convenience, do not directly call the AI vendor's interface but use a third-party "relay station." All conversation content passes through the relay station, and if tokens are included, the operator of the relay station can see them clearly.

• Access to various plugins and integrations. Each time a third-party service is integrated, there is another place to keep the keys.

Tokens that can change domain names may leak from these places.

It should be noted that the entry point of this incident has not been concluded; we are not saying it was caused by token leakage; rather, in today's world where AI writing programs is becoming more common, tokens that can modify domain name servers and resolution records deserve to be safeguarded as seriously as private keys.

05 Five, Why Websites Involving Assets Being Hijacked is Particularly Dangerous

When ordinary websites are hijacked, users may leak their account passwords on fake pages. For services involving assets, such as exchanges, wallets, payment institutions, and DeFi applications, once the domain is hijacked, the consequences are often more direct: every operation a user performs on a fake page may result in real asset loss.

This is especially true for digital assets. When users click "Authorize," "Exchange," or "Stake" on a DeFi webpage, the webpage submits a transaction to the wallet, and the user clicks confirm in the wallet. What the webpage submits is often incomprehensible to many users, who can only trust the URL itself. A hijacked URL may submit a transaction that authorizes tokens to the attacker; once signed, the attacker can transfer the funds at any time. Once the on-chain transfer is completed, it is nearly impossible to recover.

The same goes for payment institutions. When users fill in their card number and verification code on a payment page, or pay according to the displayed receiving address, if the fake page changes the receiving information, the money will end up in the attacker's hands. The domain name, page, and process that users see are identical to what they usually encounter, making it difficult to detect.

In my view, the focus of security attention in the AI era needs to shift. As more code is written by AI, teams concentrate their security efforts on code reviews and contract audits, which is not wrong, but users still pass through registries, registrars, domain name servers, and deployment platforms to reach a website. This pathway is also part of security, and these stages are precisely where AI does the most work and where people understand the least.

No matter how tight the backend systems and contracts are, as long as one link in this pathway is breached, users will hand over their assets on a fake page.

06 Six, Recommendations for Application Service Providers and Digital Asset Service Providers

Clarify who holds the domain name. Check which registrar your domain name is registered with, where the domain name server is, and who manages the related accounts. Even for domains purchased with one-click on a platform, you should know who is behind it.

Lock the domain name. Enable registrar lock to prevent the domain from being transferred arbitrarily. Important projects can apply for registry locks, requiring manual identity verification when modifying key information such as the routing address.

Protect accounts and tokens. Use hardware security keys for multi-factor authentication on accounts. Tokens should only have the minimum necessary permissions and set expiration times. Tokens should not be written into code, pasted into AI conversations, or passed through unknown relay stations. Unused tokens should be deleted promptly.

Give the AI assistant a separate key. When allowing the AI assistant to help with deployment, create a separate token for it, only granting the permissions needed for the current project, and set a shorter expiration time. Operations like buying a domain, changing domain name servers, and transferring out domains should be confirmed by a person, not left to AI to complete automatically.

Monitor changes. Any change in domain name servers, resolution records, or domain status should trigger an alert. Attackers enabling HTTPS on fake websites typically need to apply for a new certificate for that domain, and publicly issued certificates have public records; monitoring these records can help detect anomalies early.

Prepare emergency plans in advance. Consider how to notify users immediately if something goes wrong with the domain and how to find real customer service from the registrar. Kintsu complained in an announcement that customer service was just a robot. In such situations, having prepared human channels in advance may determine the speed of loss mitigation.

07 Seven, The Easier It Is to Go Live, the More You Need to Know Who Holds the Keys

AI has made writing code easier, as well as going live, buying domain names, and configuring resolutions. The barriers have lowered, but the responsibilities have not diminished. When users enter a URL, they are entrusting the entire pathway behind the URL, as well as everyone and every program holding the keys.

These stages are often invisible and rarely thought about, but in the eyes of users, they are part of the service just like the code written by the service provider. If any link fails, users will hold the service provider accountable.

As tools do more for us, do we still clearly understand which keys we have handed over?

Reference Links

[1] Post: https://x.com/Kintsu/status/2116382643017101513 [2] Next.js: https://nextjs.org [3] Interface: https://vercel.com/docs/rest-api/reference/endpoints/domains-registrar [4] Command Line Tool: https://vercel.com/docs/cli/domains [5] 28: https://vercel.com/docs/mcp/vercel-mcp/tools [6] Public Report: https://cryptoadventure.com/stepdrainer-hits-12-crypto-sites-in-dns-hijack-wave/ [7] pickle.finance: https://rdap.org/domain/pickle.finance [8] Snowcore: https://rdap.db.ripe.net/ip/31.56.52.52 [9] Permission Scope: https://vercel.com/kb/guide/how-do-i-use-a-vercel-api-access-token