How to add and verify a new domain in AlienGate

• Audience: anyone bringing a new website, subdomain or host into an AlienGate workspace for the first time
• Applies to: app.aliengate.io — Infrastructure Security → Websites & IPs → + Add Target
• Time to complete: ~2 minutes in the product, plus however long it takes you to publish one text file to the web server
• Leads on to: Article 01 — How to Run a Vulnerability Assessment

What you will end up with

By the end of this guide you will have:

• a new host verified as yours, with the proof of ownership published on the host itself,
• that host listed as an asset in Websites & IPs, counted in your attack surface,
• its first discovery pass already running — started automatically by the verification, not by you,
• a target you can select in the Scanner Console and actually scan.

Why AlienGate makes you do this

An active vulnerability scan is an intrusive act. It crawls, it submits forms, it sends payloads. Pointing one at a host you do not control is, depending on where you are, somewhere between rude and illegal — and a platform that scanned anything you typed into a box would be a convenient weapon for someone else to misuse.

So AlienGate will not scan a host until you have proven you control it, and the proof it accepts is the one thing only a person with access to that server can do: publish a file on it.

This is the same mechanism search consoles and certificate authorities use, for the same reason. It takes two minutes and you only do it once per host.

The flow

Websites & IPs → + Add Target → enter the host
   ↓
Next Step panel                  AlienGate issues a token for this host
   ↓
Publish the token at /.well-known/aliengate-verify.txt
   ↓
Open that URL in a browser yourself      ← do not skip this
   ↓
Verify ──► Verifying Domain… ──┬─► Domain Verified Successfully!
                               └─► Verification Failed ──► fix the file ──► Verify Again
   ↓
Host appears in Websites & IPs, first discovery pass starts on its own
   ↓
Scannable: Scanner Console → Scan targets

Step 1 — Add the target and read the Next Step panel

Go to Infrastructure Security → Websites & IPs (app.aliengate.io/dashboard/manage-targets) and click + Add Target in the top right. Enter the host you want to bring in.

AlienGate issues a verification token for that host and shows the Next Step panel.

Three numbered steps, each stated by the product:

The token sits in the dark field under step 01 — it reads like aliengate-verify=2011eef8b74c4498 — with a Copy button and a Download button. Either route works: copy the string and write the file yourself, or download the ready-made file and upload it unchanged.

The field is elided for display. The panel shows the token truncated (aliengate-verify=2011eef…). Use Copy or Download rather than typing what you can see.

Two details decide whether this works on the first attempt:

• The path is exact: /.well-known/aliengate-verify.txt, at the root of that host. Not /aliengate-verify.txt, and not the same path on the parent domain. The leading dot makes .well-known a hidden directory on Unix-like systems, which is the single most common reason it goes missing from a deploy.
• "Publicly accessible over HTTP(S)" means publicly: no login, no IP allowlist, no VPN, no Deny from all inherited from a parent directory. The verifier is an anonymous client on the internet with no session and no special treatment.

Step 2 — Publish the file, then look at it yourself

Put the file on the server by whatever route you normally ship static files — a deploy, an upload, a volume mount, a one-line nginx location block. Then, before you touch Verify, open the URL in a browser.

What you want to see is the token, as plain text, and nothing else.

This check takes one second and it is the difference between verifying on the first attempt and going round the loop three times. It catches things the verification error will not explain for you:

• a web server returning a styled 404 page with HTTP 200 — the file "exists" and contains your error template,
• a redirect to HTTPS landing on a certificate the verifier will not accept,
• a file saved as aliengate-verify.txt.txt by an editor with extensions hidden,
• the file served as a download rather than inline, because the server sets an attachment disposition on .txt,
• the parent directory listing being disabled in a way that also blocks the file,
• a CDN or WAF serving a challenge page to clients it does not recognise.

If a browser on a network you do not control can read the token, the verifier can too. That is the whole test. Checking from inside the office network or over the VPN proves nothing — use a phone on mobile data, or a private window with the VPN off.

Step 3 — Verify

Back in the Next Step panel, click Verify.

AlienGate shows Verifying Domain… — "We're checking your verification file. This may take a moment." — with a progress bar and the subtext Verifying ownership via HTML file…. There is a Cancel button if you realise mid-check that you published the wrong thing.

If the fetch does not find a matching token you get Verification Failed, with Cancel and Verify Again. Fix the file and re-run the check; the token does not change between attempts, so there is nothing to re-copy.

When it succeeds:

Domain Verified Successfully! — "shop.0-day.jp has been verified and added to your attack surface." Click Done. A Domain created successfully toast confirms it in the top right.

Leave the file in place. Nothing in the product tells you to remove it, and removing it is how a host stops verifying the next time the platform checks. Treat /.well-known/aliengate-verify.txt as part of the site, and make sure your deploy pipeline keeps shipping it.

Step 4 — Read what changed on Websites & IPs

The asset list reloads with the new host in it.

Three things changed, and only one of them is the obvious one:

1. The host is in the table. It has a row, classified Exposed Service under the primary domain, showing No technologies detected, 0 Safe vulnerabilities and No SSL issues.

2. The Subdomains counter went up; Verified Domains did not. In the capture, Subdomains moved from 3 to 4 while Verified Domains stayed at 1. A verified subdomain of a domain you already hold counts as a subdomain, not as a second verified domain — worth knowing if you are tracking against a plan limit.

3. It started scanning on its own. Under the hostname: Scanning now · 0%. Verification kicks off a discovery pass immediately. You did not ask for it and you do not need to wait for it.

The defaults on a fresh row are not findings. No technologies detected and 0 Safe describe a host that has existed in the platform for four seconds. The pass that just started will fill in the fingerprint.

Step 5 — Know what that automatic pass is, and is not

Open the Scanner Console and you can watch it run in the live security terminal.

[i] 2 job(s) active.
[Subdomain Finder] shop.0-day.jp — Extracting subdomains from Certificate Transparency Logs.
[Web Application Scan] shop.0-day.jp — 0%

12:58:50  [+]  Engines online — 2 job(s) dispatched.
12:58:50  [i]  Streaming live telemetry from the scan engine.
12:58:51  [~]  shop.0-day.jp · waiting for a scan slot

The Subdomain Finder job is the automatic pass. It is reconnaissance — it pulls names out of Certificate Transparency logs to map what else exists under the host. The product files it under "Reconnaissance — observations, not vulnerabilities", and that label is exact.

It is not a vulnerability scan. It does not crawl the application, it does not test anything, and it certainly does not look behind a login. A host that has only ever had this pass run against it will show no findings, and that means nothing at all about its security.

This also explains a thing that confuses people the first time: launch one engine of your own shortly after verifying, and the terminal reports two jobs active, with yours waiting for a scan slot behind the discovery pass. That is the queue working, not a fault. Read the per-engine progress bars rather than the overall percentage, which is averaged across both.

What to do next

The host is now a selectable target in the Scanner Console. From here:

• Article 01 — How to Run a Vulnerability Assessment — pick a scan type, select the new target, launch, and read the result.
• Article 04 — How to run an authenticated scan — if the host has a login, this is the one that matters. Most of a real application's attack surface is behind the sign-in page, and a scanner without a session reports the public shell as clean.
• Article 03 — Which IP addresses do AlienGate scans come from? — if the host sits behind a firewall or WAF, allow the scanner's addresses before you run anything, or the scan will be blocked rather than clean.

Troubleshooting

Reference

The verification file

What verification does and does not start

Where things live