Social Engineering & Phishing.

Pretext-Design — was funktioniert

• An echte Arbeit angepasst. Referenz auf ein echtes Ticketing-System, einen echten Vendor, einen echten Quartals-Prozess. OSINT zuerst, schreiben zweitens.
• Plausibler CTA. "Bestätige deine Timesheet bis Freitag" schlägt "Verifiziere dein Passwort jetzt." Die angefragte Aktion ist etwas, das das Ziel sowieso erwarten würde zu tun.
• Kein Eskalationsdruck. "Dringend — Account in 1 Stunde gesperrt" triggert den Trainings-Reflex. Legitime IT nutzt selten Countdown-Drohungen.
• Wie das System aussehen, nicht wie ein Angreifer. Office-365-legitime Notification → HTML-Struktur, Header, Footer, Unsubscribe-Link kopieren. Vs. eine echte diffen bis ununterscheidbar.
• Richtiger Sender. Spoofed Display Name + benachbarter Domain-Typosquat. Ziele lesen den Display Name; nur ~5% prüfen den tatsächlichen From:-Header.

Kanal-Trade-offs

• E-Mail. Höchstes Volumen, niedrigste Conversion. Verteidigt durch Mail-Gateways, Sandbox-Detonation, URL-Rewriting. Mit 5–15% Click-Rate bei Erstsend rechnen.
• SMS (Smishing). Niedrigere Volumen-Kapazität, höhere Conversion. Sandbox existiert für SMS nicht so wie für E-Mail. Mit 20–35% Click-Rate rechnen, wenn der Pretext scharf ist.
• Voice (Vishing). Höchste Conversion gegen Helpdesk-Personal. Am schwersten zu skripten. Am effektivsten Montagmorgens bei höchstem Ticket-Volumen.
• In-Person / physisch. Tailgating, Dropped-USB. Höchstes juristisches-/Scope-Risiko. Immer schriftlich autorisiert mit On-Call-White-Cell-Kontakt.
• Supplier-Impersonation. E-Mail von bekanntem Vendor mit bekanntem Payment-Detail-Change-Request. Sehr hohe Conversion gegen Finance-Teams; hohe juristische Prüfung.

Speziell Admins anvisieren

• Tooling-Trust. Admins klicken Links aus Tools, die sie täglich nutzen — Jira, Confluence, PagerDuty, GitHub. Pretext, der wie eine Notification aus einem davon aussieht.
• Helpdesk-Pretext. Richtung umkehren. Du rufst als User mit authentisch wirkender Ticket-Referenz an; bittest Helpdesk, eine MFA zu pushen, behauptest "Handy kaputt", bekommst einen temporären Code.
• Console-Link-Redirect. URL, die zuerst auf echter Admin-Console landet, dann zu deinem Harvester redirected. Browser-Security-Indikatoren zeigen "sicher", weil der erste Hop echt war.
• OAuth-Consent-Phishing. Kein Passwort phishen; einen OAuth-Scope-Grant phishen. Das Ziel sieht eine echte Microsoft-Consent-Seite und klickt Allow.

Operative Leitplanken (Engagement nicht verbrennen)

• Schriftlicher Scope, nur benannte Targets. Kein Improvisieren neuer Empfänger mitten in der Kampagne.
• Credentials von einem Operator gehandled. Erbeutete Creds liegen nie in einer geteilten Inbox oder einem Chat. Hashen bei Capture, Hash speichern, nur bei Nutzung entschlüsseln.
• Sender-Infra auf Anfrage sauber attributierbar. Domains nicht über Kunden hinweg wiederverwenden. NICHT die gleiche Domain, mit der du letztes Quartal echte Blue-Team-Arbeit gemacht hast.
• Kill-Switch. Ein Kommando, das alle Landing-Pages runterfährt, erbeutete Tokens revoked und White Cell benachrichtigt. Vor Kampagnenstart testen.