The document provides an overview of multi-factor authentication (MFA) implementation best practices and common mistakes. It discusses both the benefits of MFA in providing an extra layer of security beyond passwords, as well as potential downsides such as false security if not implemented properly. Examples are given of poor implementations, including not enforcing MFA, allowing insecure methods like SMS, and design flaws. Ideal implementations encourage the use of hardware security keys and push notifications with centralized administration and user training. Bypasses of MFA like man-in-the-middle attacks are also mentioned. The document concludes with a demonstration of using AI to assist with social engineering and phishing attacks.

1. Curtis Brazzell | CISSP
Managing Security Consultant @ GuidePoint Security
(My thoughts do not reflect.. blah blah.. Thanks Brad, for the pizza!!  )

2. About Me
 Local to This Community! (Brownsburg, IN)
 Passionate about security since the 90’s
 Former DBA/Sys Admin (4-6 years)
 Security Consulting for 12+ years
 SOC/IR Lead
 DFIR Lead (Malware Analysis)
 AppSec/Pentesting/Physical/Wireless/Architecture/Social Engineering
 Currently an MSC for GuidePoint Security on the AppSec (Tactical) Team
 Researcher/Blogger/”Author”
 Presenting at BSides Fort Wayne on New Phishing Techniques!

3. Agenda
 The Good, the Bad, and the Ugly Side of MFA
 Examples of Poor Implementation (so many examples)
 Nap
 Even More Examples
 Ideal Implementations (and their weaknesses)
 Summary
 Phishing Chat GPT PoC Demo

4. The “Good” Side of MFA
Extra layer of
protection
(something you
“have” or “are”)
Helps supplement
password security
(weak/reused/bre
ached credentials)
One of the
strongest
preventative
measures against
account takeover

5. The “Bad” Side of MFA
 Insecure mediums (SMS, still better
than none)
 Mobile authentication on mobile
platforms (Mixing “know” and
“have”)
 Lost/stolen hardware and recovery
 User opt-in (“We support it”)

6. The “Ugly” Side
of MFA
 Bad user experience (Balancing user
convenience with security)
 False sense of security
 Not a silver bullet
 User awareness training (locations/IPs, real-time
prompts, alternative methods)
 Twitter charging extra for MFA
 Poor implementations

7. Examples of Poor Implementation (BMF)
 Implemented, But Not Enforced
 Sometimes there are friendly reminders
 Can jump into an account with only a password
 Supporting and enforcing are not the same
 Leaves security to the user (opt-in)
 User preference of convenience over security
 Don’t leave enrollment a choice for critical apps
 If you do this, train your users and make MFA simple
 Importance of protecting users (data exposure,
increased attack surface, etc)

8. Examples of Poor Implementation (cont.)
 Less-Secure Methods Accepted
 Recovery codes unsecured on filesystems
 PINs/Tokens users’ type

9. Examples of Poor Implementation (cont.)
 More PhishAPI (Real-time Phishing Framework)
 MFA Requirements
 Gamified

10. Examples of Poor Implementation (cont.)
 Less-Secure Methods
Accepted
 Even if SUPPORTED and
not the default, it’s still
a problem! (path of
least resistance)
 Use hardware tokens or
push as the default?
Forms can be set to
only prompt for tokens!

11. Examples of Poor Implementation (cont.)
 Less-Secure Methods Accepted
 SMS Interception (“SMS ain’t no county I ever heard of!)
 Seriously though, why’s this a problem?
 No end-to-end encryption
 SIM Swapping / Cloning / SE attacks

12. Examples of Poor Implementation (cont.)
 Open Enrollment
 Enforced, but at the user’s leisure or next login
 Beat user to self-enrollment on attacker-owned device
 Simply logged in as user and approved as they would
 Sessions can be too long, won’t apply until next auth cycle if
already logged in when applied.
 Huge security gap (20% of captured creds were not enrolled
yet. Customer was blindsided.)

13. Examples of Poor Implementation (cont.)
 Infinite or Overly Long Enrollment Period
 Increased risk when combined with Open Enrollment
 Can’t assume users will access or within reasonable timeline (PTO, lack of need in roles, VPN, etc)

14. Examples of Poor Implementation (cont.)
 Infinite Re-Enrollment (Link Doesn’t Expire After First Use)
 Enroll again as attacker
 Stale enrollment links in email can be exposed in logs or discovered by attackers
 Not really an issue with most current MFA solutions

15. Nap
 Anyone awake?
 Survey room. If no one is awake grab pizza and quietly slip out. Otherwise, continue.

16. Examples of Poor Implementation Use
 Users Accepting Attacker’s Push Requests
 Timing is everything! (don’t assume)
 Always review IP/Location information! (not all MFA solutions provide this)
 Annoyance factor / alert fatigue
 Confusion (lack of training, IT must need something, background process, location
with travel or VPN, etc)
 Shockingly effective 🙈

17. Examples of Poor Implementation (cont.)
 MFA is Disabled After Email Change or Password Reset
 If enrollment is optional or not continuously enforced, it can lead to a gap of protection
 Shouldn’t be performed automatically but as a centralized admin control (help desk ticket, etc)

18. Examples of Poor Implementation (cont.)
 Logic Flaws (Homebrew Bad Design)
 Ignoring or canceling MFA prompt still creates session (recent example)
 “Forgot PIN” functionality reset with just a username and password (recent example)
 PINs in mobile apps might be bypassed by hiding a view (recent example) – Hooking in Objection
 Biometrics don’t tie to a specific user of the device (recent example)
 Reset instructions go to email instead of phone number

19. Examples of Poor Implementation (cont.)
 Insufficient Anti-Automation
 Low entropy (last 4 SSN, phone, DoB, etc)
 No rate-limiting server-side
 No lockout policy
 Brute Forcing until valid value is determined

20. Examples of Poor Implementation (cont.)
 Security Questions
 Security questions by themselves are NOT MFA (just something else you “know”)
 Should NOT be Boolean values, years, or other short values (I’ve seen DoB & Last 4 SSN combos)
 Should NOT be easily enumerated with wordlists (teacher’s first name, etc)
 Should NOT be easily researched (OSINT, Google phone # example!)
 Okay if used as an additional piece of user verification (usual login activity, etc)

21. Examples of Poor Implementation (cont.)
 Security Questions (Google example)
Wrong way Google to do it (Something you know) A better way of handling it (Something you have)

22. Examples of Poor Implementation (cont.)
 MFA Code Reusability
 Say the code has high entropy and the server is rate-limiting with account lockouts…
 Is the code invalidated after use?
 Can I get a token as an attacker and apply it to a victim account?

23. Ideal Implementations
 Still not a silver bullet!
 My recommendation for best hardening practices?
 Forced enrollment for all (when possible)
 Short, one-click enrollment period (no first-time login)
 Use U2F hardware proximity devices only (BLE, USB, NFC, etc - no tokens/pins/or hardware with tokens)
 If implemented properly, some biometric auth is great!
 If you can’t use U2F, use mobile push notifications
 Central administration
 Trusted SSO/MFA Providers (Okta, MS, Duo, OAuth, Auth0, etc)
 Employee Training (prompts, backup methods, etc)
 Mobile Device Management (for mobile MFA)
 Alert on and monitor unsuccessful attempts
 Bypass techniques STILL exist:
 Machine-in-the-Middle (MitM) Session Hijacking (stealing tokens post-authentication)
 Transparent/Reverse Proxies (Attacker’s fake login makes requests on behalf of users to facilitate login)
 Assets not protected by MFA (internal, etc) – Don’t give up on password security!

24. Ideal Implementations (Bypass Examples)
 Modliska
 https://vimeo.com/308709275

25. Ideal Implementations (Bypass Examples)
 Evilnginx
 https://mrturvey.co.uk/aiovg_videos/how-to-
phish-for-passwords-and-bypass-2fa/

26. Summary
 MFA is a GOOD thing overall (don’t
discourage SMS to the point devs or execs
only use creds)
 If done properly, it will greatly reduce
successful account takeover attacks (SE,
credential stuffing, brute forcing, cracking,
etc)
 If done perfectly, users are still exposed to
some risk. Training is essential!
 Sophisticated Phishing (and Vhishing)
attacks are increasingly sophisticated
(Deepfakes, AI, etc)

27. Phishing with Chat GPT (Demo)
 Let’s get buzzwordy!

28. Phishing with Chat GPT (Demo)

29. Phishing with Chat GPT (Demo)

30. Phishing with Chat GPT (Demo)

31. Phishing with Chat GPT (Demo)

32. Thank you!
 Questions?