We can all agree that having single-factor remote access gateways (VPN, Citrix, Remote Apps, etc.) exposed on the internet is a poor decision and a large security risk. These portals, can allow for a direct connection into the internal corporate environment. Once there, an attacker can begin to identify internal vulnerabilities, move laterally, escalate privileges, persist, and hoover out all the data they want. Fortunately, these portals are increasingly behind a multi-factor solution (phone call, hard/soft token, certificate, etc.). While this does help to reduce the attack surface from a direct brute force (username and password), there are often overlooked options or misconfigurations that can allow an attacker to bypass this solution or directly disrupt business operations. In this talk we’ll be covering methods that we’ve used to bypass MFA solutions to obtain internal network access from the internet.

1. MFA: IT’S 2017 AND
YOU’RE STILL
DOING IT WRONG

2. Who We Are
Dan Astor @illegitimateDA
Position: Senior Consultant
Focus: Offense
Chris Salerno @secrisk
Position: Director
Focus: Defense

3. Agenda
› MFA Overview
› Email
› Self-Service
› RemoteApps
› Shared MFA
› Social Engineering
› Internal MFA Bypasses

4. 1.
Overview

5. Overview
› MFA: Multi-Factor Authentication
› “Something” in addition to a password
› Push, Call, Soft Token, Hard Token, SMS,
Email, etc.
› Certs?
› External & Internal Services

6. Why Are We Having This Talk?
›We’re Past This... (sorta)
1.https://www.youtube.com/watch?v=UduILWi2p6s

7. Why Are We Having This Talk?
› External > Internal is still a thing
› Your Disaster Recovery VPN is still a VPN
› You have a group of users where MFA
“just won’t work”
› But really…it’s because…

8. 2.
Email

10. It’s Just Email…
› We see many environments with MFA
on all the “remote access portals” but
not on email.
› O365, OWA, Notes, etc.
› Password Spraying always works.
› Rarely detected

11. Attacks on OWA
› Usually easy to identify
› autodiscover
› If you cannot identify the “web portal” try
to connect to the Exchange service with a
thick client or other tool
o https://github.com/sensepost/ruler
o https://github.com/dafthack/MailSniper

12. OWA web portal is 2FA; using a client to connect to the exchange service is only 1FA though.
Use Ruler or other OWA service bruteforce tool to perform password spraying.

13. Attacks on O365
› Easy to identify, use any O365 login
(portal.office.com)
› Redirects to correct URL or logo appears
› PowerShell modules for MSOL & AzureAD
› Harvest all the info you can (Users,
Groups, etc.)

14. Using the AzureAD Modules to connect to the environment and pull all users (can also get cloud groups)
https://technet.microsoft.com/en-us/library/dn975125.aspx
https://docs.microsoft.com/en-us/powershell/azure/active-directory/install-adv2

15. Mailbox Pilfering
› Usually contain interesting files
› Search for: password, RSA, Duo, MFA,
VPN, etc.
› VPN soft-tokens emailed 
› MailSniper

16. Perform searches for sensitive information and attachments (VPN tokens, etc.)

17. Outlook Attacks for Shells
› Forms - create a malicious form in the
users inbox
o https://sensepost.com/blog/2017/outlook-forms-and-shells/
› Rules – create a rule that will execute
your code (or trigger your form)
o https://silentbreaksecurity.com/malicious-outlook-rules/

18. 3.
Self-Service

20. I’ll Just Help Myself…
› Self-Service portals are for users to help
themselves out instead of calling the
service desk.
› External self-service for MFA… What
could be bad about that?

21. Example RSA self-service portal

22. Self-Service Attacks
› Register a new device (your device)
› Obtain an emergency access token (EAT)
› Great post from Alex Leary from NetSpi
on EAT’s
o https://blog.netspi.com/targeting-rsa-emergency-access-tokencodes-
fun-profit/

23. After authenticating we attempt to register a new device. Once approved, we
get the email to import our token.

24. 4.
Microsoft
RemoteApp

25. Microsoft RemoteApp Servers
› RemoteApp concept is very similar to
something like Citrix XenApp
› Users login to a portal, and can launch
individual applications hosted on the
server. Applications are accessed over
RDP.

26. Example RemoteApp login

27. RemoteApp Auth
› RemoteApp supports auth from SSO
(pass-through), but can also do direct
MFA (i.e. Duo plugin) on the login.
› If you can directly connect to the
connection broker, you can bypass the
MFA (TCP 3389)

28. You can use the built-in RemoteApp client to connect to the service. This will
bypass the SSO as it connects directly to the service (Similar to OWA slide).

29. 5.
Social Engineering

31. The Scenario
› Do OSINT for employees that fit the role
you want to use.
› Identify the helpdesk #’s (may have to
call other numbers to obtain)
› Attempt to get a password or MFA
token reset
› Don’t forget about web based chat

32. Helpful Tips for Calls
› Play dumb. Like really dumb…
› They want to get you off the phone
› The more frustrated they get the more
likely they’ll just do what you need.
› Once had a rep tell us, “it’s a thinking
problem”

33. Using web based chat, we get a password reset and MFA token setup with our device. Helpful
to have the most common MFA solutions on a device with you (RSA, Duo, Symantec, etc.)

34. Using our device code and the password that was reset, we can now authenticate to the MFA
portal.

35. 6.
Shared MFA

37. Story Time…
› Password spraying on what appeared to
be a 1FA portal.
› Several successful accounts, but then
2FA stopped us.
› Randomly some accounts just always
allow us in?

38. Further Inspection...
› The account we found exhibiting this
behavior was confirmed to be
configured with 2FA.
› Account owner had told interns, “If this
phone ever rings, answer and hit 1.”
› Don’t’ crowdsource your MFA… ¯_(ツ)_/¯

39. 7.
Internal MFA

41. Remote Desktop
› Place MFA on a “jump host” (RSA, Duo,
etc.) for interactive logins
› When using RDP you are forced to enter
a passcode
› Network logins are still 1FA (map share,
execute commands remotely)

42. When using RDP, you get prompted for your passcode. When doing a network call to the
host, no MFA is required.

43. Hypervisors
› Highly sensitive zone is completely
segmented from the user network.
› MFA jump boxes are the only way into
the zone and ACLs are properly
configured.
› Look for hypervisors (vCenter, vSphere,
XenCenter, etc.) that may control the
zone from a zone you have access to.

44. Access to vSphere was 1FA. Once in, the “sensitive” servers are all accessible through the
hypervisor. Also, they had open sessions.

45. Dual NIC Monitoring Servers
› Highly sensitive zone is completely
segmented from the user network.
› MFA jump boxes are the only way into
the zone and ACLs are properly
configured.
› Look for system monitoring servers (ie.
Nagios)

46. Identified a Nagios server that was dual NIC’d into the zone. Use a port forward script to
punch a hole through from our VM to the target host (mssql database).
https://securityriskadvisors.com/blog/post/plastic-beach-gaining-access-to-cdes/

47. 5 Things to Remember
1. MFA all the things
2. Test your service desk and self-service
3. Monitor your logs
4. Expire your OTP’s
5. Think like an attacker

48. THANKS!
Any questions?
You can find us at:
@illegitimateDA · @secrisk
Presentation template by SlidesCarnival