Someone Reported a Suspicious Domain

A user forwarded a phishing email. Or a colleague pasted a line out of a proxy log into a channel and asked whether it looks bad. Or somebody clicked something on Friday and mentioned it on Monday. Either way you have one domain, no file, no alert, and no idea whether this is worth an hour.

One thing to be clear about before you start, because it changes what you can conclude. Stairwell's record is what names resolved to, over time -- built from a daily sweep of the registered domain space plus the hostnames found in files. It is not a record of what your machines connected to. There is no sensor in your network and no packet capture anywhere in this, which is why you get retrospective infrastructure intelligence without deploying network monitoring, and it is also why "did we talk to it" is a question for your own logs. What Stairwell answers is where the name pointed, when it moved, what else lives there, and which of your files reference it.

Easy Mode: let Backstory run this investigation and read the report it returns.

What will I know by the end?

What the domain has resolved to and when, whether it was ever activated after sitting dark, what else is parked on its addresses, which files in your environment reference it, which machines held those files, and a recorded conclusion the next analyst starts from.

Why this works

Three ideas carry this one, and the first is the one that makes the whole page possible.

The history is already there, whether or not the name touched you. Stairwell resolves hundreds of millions of registered domains daily, and separately resolves the hostnames its scanner extracts from the files it collects. So a domain forwarded to you this morning has a past you can read even if it never appeared in your fleet -- and if it did appear in one of your files, that link is recorded too, which is why Step 4 can turn a reputation question into an exposure question without a network sensor anywhere.

Crowding is the discriminator. An address answering for two names and an address answering for ten thousand are not the same kind of evidence. The second is shared hosting, a parking service, or a sinkhole, and an indicator pointing there is close to worthless. Read the neighbors before you weight the address.

Resolution history is not connection history. It says where the name pointed and when it moved. It does not say a machine of yours reached it. That half is in your own logs, and keeping the two apart is what stops a ticket overclaiming.

If you want the instruments themselves rather than this scenario, Network Intelligence covers the hostname panel on its own, and Hostnames and IP Addresses covers what ActiveDNS is and why the history exists at all.

Step 1: Search the name and open the Hostnames tab

Paste the hostname into Search and look at the Hostnames tab. Strip any URL down to the name itself first, since a path and a scheme give the parser something it does not need.

If nothing comes back, that is information rather than a dead end, and it is a stronger signal than it looks. Stairwell resolves hundreds of millions of registered domains every day, so most names that exist have a record whether or not they ever appeared in one of your files. A name with no record at all is usually one registered within the last day or two, or one that has never resolved. A brand new domain stood up for a single campaign looks exactly like this. Go to Step 5 and start from the file or the email instead.

Step 2: Read the resolution history

The hostname panel shows each answer the name has returned, the record type, and when that answer was first resolved. Answers not seen in the most recent resolution are marked inactive with the date they were last seen, so a domain that moved shows both where it used to point and roughly when it stopped.

Three record types, and each carries a different kind of lead.

Failed lookups are kept rather than discarded, and that is the detail to look for hardest. A name that answered NXDOMAIN for months and then began resolving is a name that was activated, and the date of that transition is frequently the most useful fact available about it. Compare it against the date on the email somebody forwarded you.

The shape of the history is your first real decision. A name that has resolved to the same address for six years, with an MX record belonging to a mail provider, is somebody's ordinary business. A name that started resolving eleven days ago, points at one address, and has no mail record is worth the hour.

Check the subdomains list on the same panel too. Going from one host to the shape of the whole domain often tells you whether you are looking at a service or at a staging area.

Step 3: Pivot on the addresses

For each address in the history, ask the reverse question: which hostnames have resolved here. That pivot turns one indicator into an operator's footprint, because infrastructure gets reused and the other names on an address are frequently the rest of the campaign.

It is also how you avoid the most common false lead in this workflow. An address answering for a large number of unrelated names is shared hosting, a parking service, or a sinkhole, and an indicator pointing there deserves much less weight than one pointing at an address answering for two names. Read the list before you act on the address, and do not carry a crowded address into a blocklist. When you do carry something into a blocklist, carry the eTLD+1 rather than the full hostname or the bare domain: it is the part one operator controls, and it is the only boundary that is neither too narrow to matter nor broad enough to block somebody else's customers.

Do this for the inactive addresses as well as the live one. Where the name used to point is often where the rest of the operation still is.

Step 4: Which of our files reference this name?

The hostname panel lists the files it appears in, and this is the step that turns reputation lookup into an investigation of your own environment. The hostnames in Stairwell come out of the files it holds, so a domain extracted from a binary you collected last year is a domain whose history you can read today, even though nobody knew it mattered until this morning.

Read the count first, because it decides what the list means. A hostname referenced by a handful of files is a lead. A hostname referenced by an enormous number of files is infrastructure the whole internet touches, and its presence in a file tells you nothing.

Then split the list the way you split any search result: which of those files are in your environment, and which are only in the global corpus. The second group is context. The first group is your exposure.

Step 5: Take the files to their sightings

Open the files that are yours and read their sightings. Now you have an answer with machines and dates in it instead of a yes or a no: which assets held a file referencing this domain, what it was called there, when it arrived, and whether it is still present.

From here the investigation is a file investigation, and it has a page of its own. Check prevalence, read the verdict, run AI Triage if you do not know what the file is, open Variants when the hash is a dead end, and run Run-to-Ground to find what landed alongside it. See An EDR Alert Just Fired for that sequence in order, including running Run-to-Ground again on what it surfaces and writing a rule when the family is worth standing coverage.

Hand off deliberately rather than continuing here. The file half is the same work regardless of whether you arrived from a domain, an alert, or a vendor notice, and it is written out once on that page.

Two other places the same indicators show up, worth knowing about while you are here:

• The Embedded Data section of any object panel lists the hostnames and addresses inside that file, which is where most infrastructure pivots start in the other direction. See The Object Panel.
• Search filters. net.hostname and net.ip narrow a file search by the infrastructure inside the files, which is how you ask "what else in my fleet references anything on this domain". See CEL Query Language.

Step 6: Consider letting Backstory take it from the domain

A hostname is one of the three things Backstory accepts as a starting point, alongside a file hash and an IPv4 address.

Seeded with a hostname it works in the opposite direction from a file investigation: it establishes the name's reputation and how common it is, and if the name is unusual enough to be interesting it finds the files in your environment that reference it and works on those, pulling the resolution history in as it goes. That is Steps 2 through 5 of this page, run for you, returning a report you can share. See Starting an Investigation.

It recurses. Once it reaches files, it runs Run-to-Ground on what it finds and then again on what that surfaces, which is the part of a hand-worked investigation that gets abandoned first. From a domain seed that is how a forwarded phishing email ends up naming machines nobody had connected to it.

Reach for it when the domain turns out to be connected to files rather than to nothing. It does not replace your judgment on what to do next, and it is not a network enforcement point: nothing here blocks a domain.

It does not write the threat report. Step 7 stays yours, and for infrastructure that step is worth more than usual, because an operator reuses addresses long after they abandon a name.

Step 7: Record what you concluded

Hostnames and addresses carry opinions, comments, and tags exactly as files do, which is what makes a conclusion about infrastructure as durable as a conclusion about a binary.

• Mark it Malicious when you established it, and the call is visible to everyone reading your environment.
• Mark it Trusted when it turns out to be your own software vendor's update service or your marketing team's tracking domain. That is how the next analyst who finds it inside a file starts from your answer instead of from scratch, and it is a much better use of ten seconds than another entry in a spreadsheet.
• Write the comment. The value of the conclusion is in the reasoning.

If the domain matters, put it into a threat report of your own along with the addresses from its history, so a file referencing it next month links to your work rather than being triaged from nothing.

What does this not tell me?

Worth restating, because it is the boundary people cross by accident when they write the ticket.

• Resolution history is not connection history. It says where the name pointed. It does not say a host of yours reached it. Pair it with your own network and proxy logs for that half.
• The Detonation tab is a partial view. It reports the hostnames and addresses a file reaches out to during behavioral analysis, it is a beta capability, and Stairwell is not a full sandbox. Read it as an addition to the static evidence.
• Stairwell is not inline. Blocking a domain happens in your network controls. This tells you what to block and why.

What should I read next?

• Network Intelligence, for the record types, the API, and the rest of what a hostname panel holds.
• An EDR Alert Just Fired, for the file half of the investigation once Step 5 hands you one.
• New IOCs Were Published, for doing this against a whole report's worth of domains at once.