We got hit by an alarmingly well-prepared phish spammer

Original Article ↗ Hacker News Discussion ↗

A university mail system was compromised after a phishing attacker used stolen credentials to self-enroll in VPN access and then abused an internal, unauthenticated SMTP relay to send convincing spoofed emails. Commenters argue this isn’t elite tradecraft so much as predictable exploitation of weak controls: no VPN 2FA, implicit trust for anything on the internal network, and legacy services that can’t or don’t authenticate. The exchange broadens into lessons on zero-trust design, user-focused incident response, and practical tactics like better logging, anomaly detection, and alias-based email hygiene to mitigate increasingly industrialized phishing and spam campaigns.

Attacker sophistication and objectives

  • Some see the attacker’s behavior as unusually prepared for “typical spammers,” moving quickly through VPN signup, internal docs, and SMTP use without exploration.
  • Others argue it’s not remarkable by serious-hacker standards and could be an automated script plus basic network scanning.
  • Debate over the real goal: mass spam vs. high‑value phishing that perfectly impersonates internal departments (HR, pensions, IT) using legitimately-signed mail.
  • One speculative view: the spam flood might even serve as a distraction from other activity.

VPN, 2FA, and access control

  • Multiple commenters are surprised VPN access lacked 2FA and/or certificate requirements.
  • Several note that simply requiring admin approval for VPN enrollment would have blocked this path.
  • Criticism that VPN accounts have separate credentials instead of SSO, increasing attack surface.

Unauthenticated internal SMTP & legacy baggage

  • The internal, no‑auth SMTP relay is widely viewed as the main design flaw; “being on the network” was incorrectly treated as authentication.
  • Pushback: many orgs still depend on old hardware/software (MFPs, NAS, payroll/HR apps) that can’t authenticate, so insecure relays survive for cost and inertia reasons.
  • Dispute over whether this is “oversight” vs. a conscious risk decision to avoid breaking unknown dependencies.

Zero trust, ZTNA, and network architecture

  • Several advocate “zero trust” or ZTNA-style access instead of flat VPNs: tunnel-in should still face per-host and per-service access controls.
  • One commenter describes a painful zero‑trust rollout where opaque device posture checks cause constant user issues, blamed on poor implementation rather than the model itself.

Human factors and phishing as an industry

  • Emphasis that phishing is a professionalized, sometimes state-linked industry, not just hobbyist “script kiddies.”
  • Stories from hotels and the military highlight that people and informal processes are often the weakest link.
  • Suggestions: strict processes (never ask for passwords, refund only to original payment method), broad 2FA, anomaly monitoring, and post‑incident reviews.

Defensive techniques and email hygiene

  • Proposed responses include immediate account lockdown, forced in‑person password resets, tighter ACLs, geo/IP-based access limits, and simulated internal phishing tests.
  • Heavy layered email filtering (multiple scanners, including outbound) is recommended but acknowledged as imperfect.
  • Many describe using custom domains, catch‑all addresses, and per‑service aliases to detect and isolate phishing, with debate over the limitations of Gmail “+tag” schemes.

AI and automation in future attacks

  • Some suspect that what looks like deep prior research may increasingly be AI‑driven multi‑agent systems that rapidly learn from successful techniques.
  • Concern that generative AI plus scraped personal data makes phishing emails far harder to distinguish from legitimate communication.