Reput.io

Honestly, too many. And half of them are just to answer one thing: is that link or sender a real service the attacker is hiding behind, or actually shady? Phishing leans on trusted names (SendGrid, a Google Doc, Cloudflare). Sorting the legit hops from the bad one eats most of the time.

Small thing we just shipped: every new Reput.io account gets full data for 15 days, whatever plan you pick. That means the complete response on every lookup: provider detection, the reasons behind a verdict, geo, investigation hints. The context that helps you actually clear or escalate an alert. Free tier stays free after. https://reput.io #blueteam #threatintel #infosec

Most alert triage starts at the blocklist. We think that's backwards. A blocklist miss doesn't mean benign, it means "not on a list I checked". So the faster first question is "is this known-good?" Clear the legit infra, and what's left is a smaller, higher-signal pile. We wrote up an order of operations that does that, and where it's NOT safe to auto-clear (hint: cloud and CDN). https://www.reput.io/blog/soc-alert-triage-known-good-first #blueteam #SOC #threatintel

This week's infosec news had one shape: attackers barely built any infrastructure of their own. They borrowed everyone else's good name instead. Agentic botnets riding trusted AI tools. The NetNut residential-proxy takedown. Fake Google/Cloudflare pages. 81M logins against M365. All of it wearing reputation that reads clean. So we started a weekly read on exactly that. Reputation Radar #1: https://www.reput.io/blog/reputation-radar-01 #blueteam #threatintel #SOC

ORB networks are borrowed reputation at the network layer. Cisco Talos is tracking UAT-7810 expanding its "LapDogs" relay network by compromising internet-facing Ruckus and ASUS routers. Espionage traffic exits through a real device on a real ISP, so the source IP carries a home's or small business's clean reputation, not the attacker's. A reputation lookup on the relay tells a defender almost nothing; what's off is the traffic pattern. https://thehackernews.com/2026/07/china-linked-uat-7810-expands-orb.html #blueteam #threatintel #infosec

Supply chain reminder from Socket: five malicious versions of the jscrambler npm package shipped a Rust infostealer via a preinstall hook. The catch with these: the package was already trusted, so nothing in its reputation warns you. The tell is in the behavior, a sudden preinstall hook dropping a native binary. https://socket.dev/blog/jscrambler-supply-chain-attack #blueteam #threatintel #infosec

This week an AI agent stood up a working command-and-control server in about six minutes, with the human doing roughly 11% of the work (Trend Micro's writeup on "Patriot Bait"). The reputation angle: its old C&C ran through Cloudflare tunnels until firewalls caught on. The infra keeps hiding behind trusted names, now AI just builds it faster. Reputation Radar #2: https://www.reput.io/blog/reputation-radar-02 #blueteam #threatintel #infosec

HollowGraph runs its entire C2 over Microsoft Graph: calendar events dated to the year 2050, used as a dead-drop. All the malicious traffic looks like normal Microsoft 365. The one thing it can't hide behind Microsoft's brand: refreshing the stolen Azure credentials. That goes out over DNS to cloudlanecdn[.]com, a domain dressed up as a CDN. Solid write-up from Group-IB: https://www.group-ib.com/blog/hollowgraph-microsoft-365/ #threatintel #blueteam #infosec

A theme worth sitting with from this week's reporting: the malicious traffic wasn't hiding near trusted infrastructure, it was flowing through it. Group-IB's HollowGraph runs its C2 inside a compromised Microsoft 365 calendar. Operators plant tasking as calendar events, and stolen files come back out as events, all over the real Graph API. https://www.reput.io/blog/reputation-radar-03 #blueteam #threatintel #infosec

Last week Hugging Face got breached by an autonomous AI agent. This week we found out who it was: OpenAI's own models, during an eval, escaping the sandbox through a self-hosted package proxy. The escape hatch was the most trusted, least-watched box in the building. That's the pattern this week: not the destination, the intermediary. Proxy, gov portal, naming service. https://www.reput.io/blog/reputation-radar-04

New backdoor TELESHIM runs its command-and-control straight through Telegram. The reason is boring and effective: most security filters whitelist telegram.org, so the traffic just blends in. That's the trap with allowlists. "Trusted domain" and "safe right now" are not the same thing. A messaging platform can be legitimate AND the exact channel a backdoor is using this week. We do not blanket-allow telegram.org. We flag it investigate and keep the reason attached: heavily abused for C2. Same domain, honest signal. https://thehackernews.com/2026/07/teleshim-abuses-telegram-for-c2-in.html

Nice portfolio. Alert enrichment is where a lot of the triage time actually goes, so automating it pays off fast. One angle worth adding to an enrichment step: known-good context, not just known-bad. If the pipeline can tell an analyst "this IP is Teams / Windows Update / a CDN edge", a lot of alerts close on their own before anyone opens the ticket.

@eddietorial@infosec.exchange Same, a standalone pre-enrichment step is the way. The reason it's worth isolating: the known-good CIDR set changes often (cloud and CDN ranges shift). So don't bake the ranges into the sub-story, point it at a lookup it queries at runtime. Then a table update needs no re-import, only the data behind it moves.

@trojanfoxtrot@infosec.exchange Nice, the redirection and captcha-gating chain is exactly the part that eats the hours. The bit we keep chewing on is each hop: when it lands on SendGrid or a Cloudflare edge, is that the attacker hiding behind a real service, or the real service? Known-good context per hop tells you which ones to stop expanding.