August 22, 2022
365 Things: MFA and Logging
8/22/2022 - This week, Mandiant—a well-respected threat intelligence leader—published yet another reminder (https://cloud.google.com/blog/topics/threat-intelligence/apt29-continues-targeting-microsoft/) that threat actors continue to target Microsoft 365 multi-factor authentication. And to continue to beat the drum, here’s our reminder that the effectiveness of MFA is only as good as the attention paid to best practices and security controls used when administering that security solution. This means MFA must be configured with adequate controls, and MFA usage and log monitoring and analysis must go together.
In Mandiant’s article, they describe exploits by APT29—a Russian espionage group whose funding is tied to the RSFSR, and whose operations are clandestinely supported by the FSB, formerly the KGB in the old USSR. These exploits are targeting the United States and NATO partner countries, likely as a result of support of the Armed Forces of Ukraine in the ongoing war, not to mention other things that go back to before ENIAC calculated its first artillery firing table.
APT29’s targeted activities put financial services, as well as other critical key business and government sectors at risk. Specifically, APT29 has been targeting and disabling advanced logging features in Microsoft 365, presumably an attempt to obfuscate activities when exploiting poorly managed and configured Microsoft 365 tenants.
MFA is key to preventing APT29 and other threat actors from accessing your infrastructure. APT29 is actively exploiting new Microsoft 365 users’ authentication by compromising credentials to self-enroll their own MFA token to compromise 365-hosted assets like email, SharePoint, OneDrive, etc. By default, Microsoft allows users who are configured to use MFA to utilize self-enrollment. This means that—again, by default—anyone with user credentials configured in Azure AD (synchronized or created locally) can enroll with MFA, and this can be done from anywhere. Alternate security controls exist to require the use of MFA but not allow self-enrollment.
To put this into a real-world context, if an APT29 threat actor phishes users’ credentials, and they catch those credentials in a state where they are being used to enroll that user for the first time, then they can effectively enroll any mobile device for use in logging into your tenant. The list of ways they obtain those credentials is deep and long: we practice them almost every day in red team engagements with our clients, performing hundreds of penetration tests and social engineering engagements every year.
Once the threat actor has registered the device, they own that account until something changes, like a password, or they are found out. But by that time, the damage is likely already done, especially if the user has access to customer data or administrator rights to assets or controls.
Threat actors are also targeting dormant accounts, like all the terminated employees’ Active Directory user accounts that have yet to be disabled or deleted. These are particularly attractive since no user is there to catch when things are weird, like illegitimate emails showing up in the inbox or sent items.
There are several ways to help prevent MFA takeover. One of which is to ensure that enrollment takes place in a “trusted location.” Currently, Microsoft has limited the ability to manage trusted locations in Azure AD using Conditional Access policies. Locations can be set up by geographic region or by IP address. When configuring geographic location restrictions, remember to “Include unknown areas” option. This will prevent connection from IP addresses that can’t be mapped to a specific area or region. Also, IPv4 is the default and IPv6 needs to be configured as well. And there’s a checkbox for “other regions” that are not explicitly defined in the list—it’s a catch all. For some 365 tenants, the addition of CA policy functionality will be an increase in subscription costs, but it is necessary just like the seatbelts are in any car or truck.
The Microsoft Authenticator app is free—use it. Or use an already implemented solution like Duo, or Symantec VIP. Push notifications through SMS, phone calls, or emailed codes are no longer acceptable—there, I said it. Basic push notifications like SMS may be intercepted and are unencrypted in some cases. Email forwarders may also be nefariously configured allowing a threat actor to intercept emails (https://learn.microsoft.com/en-us/microsoft-365/security/defender/alert-grading-playbook-email-forwarding?view=o365-worldwide). Although the likelihood is low, a spoofed mobile device SIM card can give a threat actor access to a cloned mobile device where they can see the same codes in an SMS text message or intercept phone calls as the legitimate user.
Even push notifications to authenticator apps are of an increasing concern because untrained users will blindly accept a notification to authenticate because they have been conditioned to do so without thinking about it. Using compromised credentials, a threat actor will spam the user with push notifications until the user relents, just so the user can be left alone to get on with their day. Improperly trained users see additional security controls as a burden and not a security feature and may knowingly or apathetically avoid them if possible.
Currently the best form of MFA for 365 is number matching notifications (https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match) requiring the user to enter the number shown on their phone into the authentication interface. This feature can also show the user a map of where the authentication request originated. The map is important, especially if CA policies with trusted locations are not enforced. If the user is in New York City and an authentication prompt pops up on their phone with a map showing a place called Наро-Фоминск just west of Moscow, then the user should have a good indication that they didn’t initiate the authentication activity. Even if trusted locations are enforced, the map can indicate something is wrong if the user is unsure of the originating location that they learned about in ongoing information security awareness training classes…you’re doing that right?
All of these issues lead to why external logging and analysis using a third-party Security Information and Event Monitoring (SIEM) system alongside other security controls is so important. Microsoft even offers its own SIEM called Microsoft Sentinel. It’s also important that a SIEM is tuned continuously to eliminate the firehose of unnecessary information and monitored to address the alerts and issues that matter. After all, you can defend against an enemy you can’t see or don’t know is there.
To effectively manage a SIEM, one or more experienced security analysts generally care for and feed the solution. In a lot of cases, this is provided as a service by the solution provider in the form of a Security Operation Center, helping institutions avoid adding additional human capital. All critical IT infrastructure logging is forwarded to the SIEM for analysis. This means SYSLOG, SNMP, and other log data from storage, servers, workstations, switches, routers, firewalls, IDPS, endpoint security, and anything used to make IT work in your environment are collected, stored, and analyzed on an ongoing basis. Just like backups, the log collection and storage are just as important as analysis: these logs should be stored offsite and protected from tampering. Doing so should prevent a threat actor from deleting or altering the logs and help reduce the time needed to respond to an incident. In some cases a SOC may offer services to proactively stop nefarious activities they see before any real damage is done.
As the author dismounts his soapbox, we’ll leave you with this: good cyber security controls like MFA and logging are literally key to long term peace for mankind. Doing cyber security well and implementing things as simple as logging and MFA will ensure that we all thrive into the future. Who knows, you might even stop a war.
Download BlogAuthored By: Mike Smith AWS CCP
