Five Days of Validin, Day 4: "Is this real?"

A staff member forwards you an email. You are the closest thing your organization has to a security team. You have about four minutes before they decide you are too slow to be worth asking and start making the call themselves.

The first three days were about your own infrastructure. Today is about everyone else’s, so the worked example moves off symbolics.com and onto the kind of domain that actually turns up in a suspicious email.

Two habits first

Defang the domain everywhere you paste it. Write suspicious-domain[.]example in tickets, chat, and email. Somebody will eventually click a live link inside a security discussion. The brackets make it inert.

Check the actual link target, not the display text. In a phishing email these are almost never the same. View the message source, or hover and read the status bar. The domain you query is the one the link really goes to.

The command

curl -s -H "Authorization: Bearer $VALIDIN_KEY" "https://app.validin.com/api/axon/domain/osint/history/suspicious-domain.example?limit=250&time_format=iso"

In the web interface, search the domain and read the OSINT panel and the indicator annotation icons.

What comes back

Real output, trimmed:

{
  "records": {
    "osint": [
      {
        "key": "example.com",
        "value": "adblockplus.org - latvian easy list - Host",
        "first_seen": 1684108800,
        "last_seen": 1751155200,
        "tags": ["category/informational", "type/ads"],
        "url": "https://easylist-downloads.adblockplus.org/latvianlist+easylist.txt"
      }
    ]
  },
  "records_returned": 2,
  "limited": false
}

Four fields carry the meaning. value names the source and its verdict. tags classifies the kind of observation. url links to the actual feed so you can check it yourself. The dates tell you whether this is current or historical.

The mistake to avoid: a hit is not a verdict

This is the whole skill, and it is worth a minute.

The record above is real. Read carelessly, it looks like the domain is “on a list,” which sounds bad. Read properly, category/informational and type/ads mean an advertising blocklist flagged the host for serving ads. That is a fact about advertising. It says nothing about phishing, malware, or fraud.

Compare it with another real result, this one from an IP address:

{
  "value": "Maltrail: Suspicious",
  "tags": ["category/suspicious"],
  "url": "https://github.com/stamparm/maltrail.git"
}

category/suspicious from a security feed is a different claim entirely.

Read the tag, not the presence of a result.

category/malicious and category/suspicious are security verdicts. Take them seriously.

category/informational is context, not accusation. Ad lists, tracker lists, categorization feeds. Common on entirely legitimate sites, including probably yours.

Then check the dates. A suspicious verdict from 2019 with no recent observation is a different situation from one seen last week. Domains change hands, get cleaned up, and get re-flagged.

And check the url. It tells you who is making the claim. A well-known security feed and somebody’s personal blocklist deserve different weight.

When you get a security verdict

Multiple security-category sources flagging a domain as phishing or malware is a fast, defensible no.

Reply to the staff member, tell them it is confirmed, and thank them specifically for asking. That last part is not politeness. The person who forwards a suspicious email is doing the single most valuable security behavior available to a small organization, and whether they do it again depends entirely on how you respond this time.

Then block the domain wherever you can, and check who else received it.

When nothing comes back

This is the more common case and the more interesting one. Silence is not a clean bill of health. It means no source Validin ingests has published about this domain. Every malicious domain has a window before anyone reports it, and an attack aimed specifically at your organization may never be reported at all.

So pivot, using the commands you already know.

Pivot one: how old is it?

Run Day 1’s DNS history command against the suspicious domain.

A domain first observed eleven days ago, asking your finance director to update wire instructions, does not need a threat report to be suspicious. Real organizations have history.

This is where the symbolics.com comparison earns its place. That domain has continuous, boring, consistent records stretching back as far as the dataset goes, with one clean hosting migration and stable nameservers across seven years. That is what a legitimate long-lived organization looks like from the outside. A foundation that has supposedly existed for twenty years and has three weeks of DNS history is telling you something.

Pivot two: who are its neighbors?

Take the address from that output and ask who else lives there:

curl -s -H "Authorization: Bearer $VALIDIN_KEY" "https://app.validin.com/api/axon/ip/dns/history/203.0.113.42?limit=250&annotate=tags&time_format=iso"

Real output from a shared-hosting address I looked at:

{
  "query_key": "184.168.221.41",
  "status": "finished",
  "records": {
    "A": [
      {"key": "184.168.221.41", "value": "profesija.ba", "value_type": "dom",
       "first_seen": "2019-10-17T00:00:00Z", "last_seen": "2019-11-06T00:00:00Z"},
      {"key": "184.168.221.41", "value": "ftth.ba", "value_type": "dom",
       "first_seen": "2020-05-06T00:00:00Z", "last_seen": "2020-06-10T00:00:00Z"}
    ]
  }
}

A suspicious domain sharing an address with a hundred other recently registered domains is a pattern. One sitting alone on dedicated infrastructure is a different situation.

Two useful follow-ups on the same address. Reverse DNS identifies the hosting provider:

curl -s -H "Authorization: Bearer $VALIDIN_KEY" "https://app.validin.com/api/axon/ip/dns/hostname/203.0.113.42?limit=250"

{"records": {"PTR": [
  {"key": "184.168.221.41", "value": "41.221.168.184.host.secureserver.net",
   "first_seen": 1663804800, "last_seen": 1786168800}
]}}

secureserver.net is GoDaddy. That tells you instantly whether you are looking at budget shared hosting or a major cloud platform, and it shapes how much the neighbor list means.

And the address itself may have been reported:

curl -s -H "Authorization: Bearer $VALIDIN_KEY" "https://app.validin.com/api/axon/ip/osint/history/203.0.113.42?limit=250"

That is where the Maltrail: Suspicious result above came from. Apply the same tag-reading discipline.

Turn this around on yourself

The neighbor check is worth running against your own hosting address once, not just against suspicious ones.

Mail server reputation is partly address-based. If your outbound mail leaves from an address that also sends spam, your appeal letters and receipts land in junk folders. Nonprofits regularly discover their deliverability problem is actually a neighbor problem, and it connects directly back to yesterday’s post.

One caution. If your domain resolves to Cloudflare, AWS, or another large platform, the neighbor list will be thousands of unrelated customers and tells you nothing. This check is meaningful for traditional shared hosting, and for the historical addresses from Day 1.

The judgment call no tool resolves

You will sometimes land on a domain that is new, unreported, and serving something plausible. Nothing here settles that. What settles it is verification through a separate channel.

If the message claims to be from a vendor, call the number on your existing invoice, not the number in the email. If it claims to be from a board member, use the number in your own records. If it requests a payment change, treat that as requiring verbal confirmation, always, from a number you already had.

That policy is free and it stops the attack class that costs nonprofits the most money. Write it down before you need it, because these attacks are engineered to create urgency that makes rules feel negotiable.

Build the muscle before you need it

Run this once now against a domain from a phishing email you have already received. Get familiar with the output while nothing is at stake. The four-minute version only works if you have done it before.

That is six queries out of your fifty, and this is the one worth reserving budget for. The other four commands can wait a day. This one cannot.

Tomorrow, Day 5: making all of this a routine that survives you.