Two-factor authentication (2FA) is a method of establishing access to an online account or computer system that requires the user to provide two different types of information. Implementing 2FA From cloud to on-premises access can help keep attackers stay away? But what if an attacker wants to target you? Is your 2FA implementation good enough to protect you in that situation?
If you have rolled out 2FA already, you probably made some of the same decisions I did when implementing it. It had to “just work” and work well, not be too intrusive, and not allow too many false authentications. Then I had to balance the need of protecting inside the office with that of enabling remote access.
Physical Fob to Smartphones
In the early days, a physical fob or device was often the only way to implement 2FA. You would generate additional manual keys that could be entered in case the fob didn’t work and locked you out of access. Then along came smartphones and applications where you could download an app on your phone that would either push an approval, a number, or some other action that the user needed to enter or execute on the system to gain access.
Also Read: Latest Cyber Security News – Hacker News !
Some complain that 2FA’s reliance on a text message to a phone is not secure with attackers able to clone or swap SIMs to impersonate the phone number of a device. Banking access, for example, typically offers only SMS messages as the second authentication factor. When deciding between merely a password to protect your banking application and a text message to your phone, I’d argue that a text message is more secure. An attacker would still have to go through the process of SIM cloning or swapping. In business, however, even NIST doesn’t recommend text messages alone for securing 2FA.
Remove 2FA “fail-open” processes
Next, re-review how you set up 2FA. To avoid pushback from management, you probably set up 2FA in a way that should the technology fail, there were ways around the issue to provide access. Like every other IT administrator, I set up two factors to work even if the service was down. Should the cloud service that 2FA relies on to authenticate not work for any reason, this “fail open” process allows the system to continue and not block access.
While that sounds great on paper, it was a boon for attackers. As a recent cybersecurity alert points out, attackers used this along with other techniques to take over a network after wiggling into a workstation.
Two-factor authentication is more mature and doesn’t need these emergency fall-back procedures. Your stakeholders now know these applications well enough to realize that they rarely fail. Review your security implementation to ensure that you won’t be subject to this attack sequence.
Also Read: Latest IOCs – Threat Actor URLs , IP’s & Malware Hashes
Threat case: Russian State-Sponsored Cyber Actors Gain Network Access by Exploiting Default Multifactor Authentication Protocols
As recent cybersecurity alerts from CISA and FBI state that Russian state-sponsored cyber actors gained initial access to the victim organization via compromised credentials and enrolling a new device in the organization’s Duo MFA.
The victim account had been un-enrolled from Duo due to a long period of inactivity but was not disabled in the Active Directory. As Duo’s default configuration settings allow for the re-enrollment of a new device for dormant accounts, the actors were able to enroll a new device for this account, complete the authentication requirements, and obtain access to the victim network.
The actors also modified a domain controller file, c:\windows\system32\drivers\etc\hosts, redirecting Duo MFA calls to localhost instead of the Duo server. This change prevented the MFA service from contacting its server to validate MFA login—this effectively disabled MFA for active domain accounts because the default policy of Duo for Windows is to “Fail open” if the MFA server is unreachable. Note: “fail open” can happen to any MFA implementation and is not exclusive to Duo.
Using these compromised accounts without MFA enforced, Russian state-sponsored cyber actors were able to move laterally to the victim’s cloud storage and email accounts and access desired content.
How can I configure the fail mode for the Windows Logon console and RDP logins?
By default, Duo Authentication for Windows Logon will “fail open” and permit the Windows logon to continue if it is unable to contact the Duo service. You can set the fail mode during installation to “fail closed” by deselecting the “Bypass Duo authentication when offline” box during installation. This will deny all login attempts if there is a problem contacting the Duo service.
To change the fail mode after installation, use the Registry Editor (regedit.exe) with administrator privileges to create or update the following registry value in HKEY_LOCAL_MACHINE\SOFTWARE\Duo Security\DuoCredProv:
| Registry Value | Type | Description |
|---|---|---|
FailOpen | DWORD | Set to 1 to allow “fail open” or 0 to restrict to “fail closed”. Default: Fail open. |
Duo settings managed by Windows Group Policy override any changes made via Regedit. Update the “Duo Service: Fail Open if Unable to Contact Duo” setting in the Group Policy Object (GPO) instead.
Mitigations
The FBI and CISA recommend organizations remain cognizant of the threat of state-sponsored cyber actors exploiting default MFA protocols and exfiltrating sensitive information. Organizations should:
- Enforce MFA for all users, without exception. Before implementing, organizations should review configuration policies to protect against “fail open” and re-enrollment scenarios.
- Implement time-out and lock-out features in response to repeated failed login attempts.
- Ensure inactive accounts are disabled uniformly across the Active Directory, MFA systems etc.
- Update software, including operating systems, applications, and firmware on IT network assets in a timely manner. Prioritize patching known exploited vulnerabilities, especially critical and high vulnerabilities that allow for remote code execution or denial-of-service on internet-facing equipment.
- Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts) to have strong, unique passwords. Passwords should not be reused across multiple accounts or stored on the system where an adversary may have access.
- Continuously monitor network logs for suspicious activity and unauthorized or unusual login attempts.
Note: If a domain controller compromise is suspected, a domain-wide password reset—including service accounts, Microsoft 365 (M365) synchronization accounts, and krbtgt—will be necessary to remove the actors’ access. (For more information, see https://docs.microsoft.com/en-us/answers/questions/87978/reset-krbtgt-password.html). Consider soliciting support from a third-party IT organization to provide subject matter expertise, ensure the actor is eradicated from the network, and avoid residual issues that could enable follow-on exploitation.
Also Read: Defending and Preventing Against Active Directory Kerberos Attacks
The primary concern, regardless of whether you have empowered 2FA, reexamines how you set it up. Make sure the attacker can’t use your default settings against you.
References:
https://www.csoonline.com/article/3656695/its-time-to-re-evaluate-your-2fa-setup-on-microsoft-networks.html
https://www.cisa.gov/uscert/ncas/alerts/aa22-074a
https://help.duo.com/s/article/1081?language=en_US