Ghost Vendors & Rapsheets: Validating Your 0-Day Supply Chain
Just read the Krebs article regarding the offensive security startup run by individuals with questionable backgrounds. It raises a massive red flag for procurement and vendor risk management.
While we often focus on the technical validity of an exploit (PoC verification, CVE ID assignment, etc.), the source of that exploit is becoming just as critical. If a broker is offering a zero-day for a major browser (like Chromium-based) or a popular OS, are we also inheriting legal or surveillance risks?
Before onboarding any new exploit broker, I recommend heavy OSINT. Specifically, look at the domain history and certificate transparency logs. A "startup" that appears overnight with a "premium" zero-day for a critical asset (e.g., a hypothetical CVE-2026-1337 Chromium RCE) but has only 30 days of SSL history is a huge risk.
Here’s a quick script I use to check for "ghost" domains via crt.sh to see if they’ve been hiding or are brand new:
import requests
def check_domain_history(domain):
url = f"https://crt.sh/?q={domain}&output="
try:
resp = requests.get(url)
data = resp.()
if not data:
return "No certificates found."
# Parse the earliest 'not_before' date
dates = [entry['not_before'] for entry in data]
return f"First Seen: {min(dates)}"
except Exception as e:
return f"Error: {str(e)}"
print(check_domain_history('potential-vendor.com'))
We need to treat exploit vendors like we treat third-party libraries. How are you guys vetting your offensive vendors? Is legal getting involved in your red team procurement?
Solid script. In the Red Team space, we often just want the 0-day to get the job done, but the 'ghost company' aspect is scary. I've seen brokers request payments in crypto to entities that dissolve weeks later. We've started requiring KYC documents for any vendor over a certain dollar amount, which kills a lot of the 'shady' deals but keeps us safe.
From the defensive side, this is a supply chain nightmare. If we buy a 'test' exploit that has a callback or a loader, we just owned ourselves. We isolate all vendor PoCs in an air-gapped lab before even looking at the code. Also, we verify the hash of any provided binaries against public sandboxes to ensure they aren't repackaged malware.
It's not just the code; it's the telemetry. If these guys are running 'fake intelligence companies,' who are they selling the usage data to? When you buy an exploit, you might be paying for the privilege of being spied on. Always verify the infrastructure they use for delivery doesn't overlap with known C2 infrastructure.
Beyond air-gapping, you need to vet the entity itself. If the "company" has no digital footprint beyond their landing page, walk away. I automate part of this by checking domain age and historical registrant data. Here's a quick snippet I use to filter out the fly-by-nights:
whois -H suspicious-vendor.io | grep -E "Creation Date|Registrar"
If it's younger than 6 months or uses privacy services by default, treat them as hostile.
Building on the vetting aspect, I cross-reference the technical contact info against public business registries. If the domain registrant is a privacy service or a free email provider for a supposed "corporate" vendor, that's an instant rejection. You can automate a quick sanity check using Python:
import whois
domain = whois.query('vendor-domain.com')
print(domain.emails)
This helps confirm if there's a real human behind the curtain.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access