About Ohey

Threat intelligence built on our own evidence.

We built Ohey because too much of what gets reported falls apart once you read the code.

A magnifying glass examines a captured page of code as a sandbox and contract feed into an evidence folder.
Warning signs repeat the same alert along a line.

Threat intelligence is too trusting.

That might come as a surprise, given the industry. Public indicator-sharing sites and sandboxes are used, and abused, by people who want something published. Post a host to one of the main sharing sites and within a day it shows as malicious on VirusTotal.

In a perfect world, that's the system working: someone flags a host and everyone blocks it. But not every indicator on those sites has history, evidence or proof behind it, and some of it is plain manipulation.

How gambling sites ended up in malware configs.

In our early days in threat intelligence, one pattern kept confusing us. Commodity malware (AsyncRAT, Remcos, Quasar, NanoCore) kept turning up with the same kind of control server in its config: a South Asian gambling site, usually on a domain bought after it expired, that still had some DNS history or backlinks. The network logs never showed those domains answering the malware. They returned redirects and 404s from an ordinary website on ports 80 and 443, sometimes on made-up subdomains like "c2", "malware" or "conti".

Working with Hieu Ngo of TRM Labs, we figured it out. It was black-hat SEO, and the threat intelligence community was the tool. The operators bought expired domains that still had a reputation and put them in malware configs, knowing researchers, sandboxes and feeds would publish them. Every one of those posts is a link to the domain. For a short while the links pushed traffic to the gambling sites, and the operators kept that benefit until the domains were blocked everywhere.

In August 2026 a large DNS security vendor wrote up the same domains as a malware operation, counting 31,000 samples that connect to them. The samples naming the domains were taken as proof, and that's how the operation is now recorded: as a malware campaign, when it was another case of our industry being used.

A gambling website is chained to a labelled tag.
Eleven website reports are checked against the code on their pages.

Eleven clinic sites wrongly reported as phishing.

On 10 October 2026, reporters on another feed flagged 11 sites for credential theft. Each page had a Telegram bot token in its source, which is how a lot of phishing kits send stolen logins home. We read the code. The sites were a web agency's demo pages for real clinics, and the bot told the agency when a clinic opened its link. Not one of the 20 pages we'd kept had an input field. We turned all 11 down, and 18 more of the agency's demos never went into the feed.

We see it all through our intake: IP addresses supposedly part of a campaign with none of the ports open it would need, "phishing" pages with no way to send a password anywhere, and phishing simulations run by well-known companies. That's not a healthy way to handle threat intelligence, and we took it personally.

How a host gets into the feed.

So we built our own path for every report: our own scanner, our own detection rules, our own infrastructure and our own review. Four kinds of evidence put a host in the feed without a person, and all four are ours. One of our rules matches code a page served to our browser. A malware sample we ran names the server in its config. A file we downloaded from the host matches a known-bad hash, our sandbox flags it, and an independent check agrees. Or a blockchain contract we decoded points to the server.

Some hosts always wait for a person, whatever the evidence: the most visited sites, well-known services, shared platforms and IP addresses that host 10 or more domains. When a sample calls a dozen servers, each one is judged on what it did, so the update server it checked on the way out never lands in the feed next to its controller.

A reported website passes through checks before joining a list.
Three shop websites display matching code fingerprints.

Detection rules written from the malicious code.

A URL tells you very little. Attackers swap domains daily, break into sites people trust and host their kits on the same cloud platforms as everyone else. Our scanner opens every site in a fresh browser on its own ISP connection, the way a first-time visitor arrives, and reads each script after it has unpacked itself to run. A kit that repacks itself on every build still trips the same rule, and when a ClickFix lure copies a command to the clipboard, we decode it and record the server it downloads from.

We write every rule ourselves, from code we captured, and the day a rule ships we run it over every page response we've kept. Sites that served that code before the rule existed go into the feed with the same evidence.

Built by malware researchers.

We're malware researchers. Ohey grew out of Derp.ca, where we track malware infrastructure every day and publish investigations with the hashes and indicators behind them. The same work decides what goes in the Ohey feed: we decode the smart contracts that hide swappable control servers, take samples apart to find the servers they really use, and map the chain from a hacked site to whatever it serves its visitors.

Read the research at Derp.ca

Hudson Rock

How a business website became a malware trap.

A joint investigation with Derp.ca traced how a compromised Artlist website was used to deliver malware.

Read the joint investigation

The Hacker News

Thousands of fake GitHub repositories.

The Hacker News cites Derp.ca's research into malicious developer tools in its coverage of the FakeGit malware campaign.

Read the FakeGit coverage

OX Security

Malware in npm packages.

OX Security credits Derp.ca for help with its investigation into the Miasma attack on npm packages.

Read the Miasma investigation

Risky Business

Inside the Qilin ransomware.

Catalin Cimpanu's Risky Bulletin linked Derp.ca's teardown of Qilin's Windows encryptor, one of several Derp.ca write-ups the newsletter has picked up.

Read the Risky Bulletin edition

Malwarebytes

Tracking PavinLoader.

Malwarebytes' threat intelligence team credits Derp.ca's earlier analysis of the loader from the HellsUchecker ClickFix campaign.

Read the Malwarebytes analysis

NCSC CTO

1,509 WordPress sites feeding SocGholish.

Ollie Whitehouse, CTO of the UK's National Cyber Security Centre, featured Derp.ca's TA2726 research in his weekly Cyber Defence Analysis newsletter.

Read the newsletter issue

Apiiro

FakeGit's contract and wallet.

Apiiro credits Derp.ca with first documenting the FakeGit contract and the operator's wallet.

Read the Apiiro analysis

SigmaHQ

An Axios detection rule.

SigmaHQ's detection rule for the Axios npm compromise cites our analysis.

Read the SigmaHQ rule

Malpedia

Vidar in Malpedia.

Malpedia indexes our Vidar write-up in its entry for the malware family.

Read the Malpedia entry

Try the feed for 14 days.

Request a trial and we'll send you a live API key, with the same feed, removals and reasons a customer gets.