The MFA Illusion

Identity is the new firewall

Attackers no longer need your password. They don't even need to break your MFA. They just need to sit between you and a login screen.

        TL/DR

• Your end users are likely providing their credentials and access on a regular basis and may be unaware it is even happening
• Unless you have some form of identity threat protection, you are flying blind
• Make a plan to get off passwords and especially towards phish-resistant MFA - NOW
• Automate remediation actions in your identity provider for real-time protection
• Enable Continuous Access Evaluation or other measures to reduce token replay risks

For over 25 years multi-factor authentication was the silver bullet. "Enable MFA” was what we all preached and the first time I saw an RSA fob I was sure this would solve everything.  OK, that was a long time ago, and I had much less gray hair. This was also back in the day where almost all cybersecurity was focused on “the firewall” as our security saviour, then IPS and so on, and so on.

So to prevent identity threats, perhaps the dumbest idea of all came into all of our requirements, well just change the password every 90 days AND use MFA, and then you are certainly good.  Also make your password really strong, and don’t allow anyone to re-use them AND use MFA - OK, now you are really good.

Today, attackers don't need to steal your password at all. They just need to intercept the session after you successfully authenticate - credentials, MFA code, and all. This technique, known as Adversary-in-the-Middle (AiTM) has grown into a primary vector responsible for some of the largest corporate breaches of recent years. And the uncomfortable truth is that most organizations are still running MFA that offers zero protection against it.

Identity is our new “firewall” in most cases and may be the only thing standing between your organization’s data and an attacker.

Understanding the Adversary-in-the-Middle Attack

A traditional phishing attack aims to steal credentials. The attacker sends a fake login page, the victim types their password, and the attacker captures it. MFA broke this model and even with the password, the attacker lacked the second factor that expired before it could be reused.

AiTM attacks do not try to steal credentials, but instead proxy the entire authentication process in real time.

AITM ATTACK FLOW — REAL-TIME SESSION HIJACKING VICTIM(Employee) → ATTACKER'SPROXY SERVER → LEGITIMATESERVICE (M365) The attacker does not break MFA — they let the victim complete it, then steal the resulting authenticated session cookie.

The victim receives a phishing email pointing to a convincing lookalike domain or an organization you have been in contact with already, and hey they are just sharing a file with you, so what could be the harm.  Click, go ahead, you know you want to.

They click and see a pixel-perfect Microsoft login page, and enter their credentials. The proxy server forwards these to Microsoft in the background. Microsoft responds with an MFA challenge. The proxy displays this to the victim. The victim completes the MFA and the proxy relays that response to Microsoft. Microsoft, satisfied, issues an authenticated session cookie. The proxy captures that cookie. The attacker now holds a valid, authenticated session and can access the victim's account without ever knowing their password or their MFA secret.

THREAT LANDSCAPE Why AiTM Has Become the Attack of Choice Several converging factors have made AiTM the dominant enterprise credential threat: →  Commoditized toolkits lower the barrier — no deep technical skill required →  Traditional MFA adoption has made pure credential theft less valuable, pushing attackers upstream →  Session cookies have long lifetimes; one stolen cookie can provide persistent access for days or weeks →  Cloud services (Microsoft 365, Google Workspace, Okta, Salesforce) are high-value targets with unified access to vast data →  Conditional access policies often don't re-evaluate mid-session, allowing lateral movement once inside →  Business Email Compromise (BEC) fraud — redirecting wire transfers — can be executed directly from stolen sessions

Why Conventional MFA Fails

Conventional MFA methods remain highly effective against bulk credential attacks, password spraying, and unsophisticated phishing. The problem is that they were never designed to resist a real-time proxy interception. The codes they generate (TOTP codes, SMS OTPs, push notifications) are possession factors that prove nothing about the connection through which they travel.

When a user approves a push notification, they are confirming: "I intend to authenticate." They are not confirming: "I am authenticating directly to Microsoft, via a connection I trust, to a server whose identity has been cryptographically verified." That distinction is everything.

What Makes Authentication Truly Phish-Resistant

The term "phish-resistant MFA" has a precise technical meaning, and it centers on a single concept: origin binding. A phish-resistant authentication method cryptographically ties the authentication response to the specific origin (the domain and server) that the user's browser is communicating with. If that origin is not the legitimate service, the authentication simply fails. A proxy server sitting in the middle will never receive a valid authentication token, because the browser will refuse to generate one for an unrecognized origin.

This is the fundamental innovation of the FIDO2 standard and its consumer-facing implementation, passkeys. When a user registers a FIDO2 credential with login.microsoft.com, that credential is mathematically bound to that exact origin. An AiTM proxy operating at microsoftonline-secure.net will receive nothing usable, the browser will not generate a valid authentication response for the wrong domain.

How to move forward

Transitioning to phish-resistant MFA is not an easy change, but moving users away from passwords will be a security change they will definitely welcome, unless you end-users really enjoy changing their passwords.

Phase 1: Prioritize

Not every user and every system presents equal risk. Begin by identifying your highest-value targets: privileged administrators, finance personnel with payment authority, executives, and any account with confidential data access. These accounts should receive phish-resistant MFA and more restricted Conditional Access Policies.

Enable automated remediation, because it is not possible to manually manage identity threats at the speed end-users are providing their passwords in AiTM attacks. MS Defender for Identity and Crowdstrike’s ITP are great examples and are really quite good at detecting anomalous login activity.

Phase 2: Deploy FIDO2 / Passkeys

Microsoft Entra ID, Google Workspace, Okta, and Ping Identity all support FIDO2 authentication. MS EntraID with MS Authenticator is an especially good example for any MS shop. Hardware security keys (YubiKey, Google Titan) remain the gold standard for those who need it all and don’t mind hardware deployment. Platform passkeys built into Windows Hello, macOS, iOS, and Android provide FIDO2-grade security for the general workforce without requiring physical hardware distribution.

Undeniably, passkeys are difficult in most consumer aspects, and their ability to work on another device or within an app (even if they are shared in a password manager) makes them difficult when not used in a corporate environment.  However, the days of passwords and non phish resistant MFA solutions are gone in the corporate world and if you are not actively monitoring identity threats in your environment, you are missing how many users are falling victim to AiTM threats every week.

Phase 3: Eliminate Weaker Fallbacks

Phish-resistant MFA delivers no protection if users can fall back to a simple password or SMS OTP. Conditional access policies must be configured to enforce phish-resistant methods for protected resources, no exceptions, no fallback to legacy MFA.

Phase 4: Layer Complementary Controls

Phish-resistant MFA addresses authentication but does not stop all authentication threats. Short session token lifetimes forcing frequent re-authentication; continuous access evaluation that revokes sessions on anomalous signals; and most importantly, ensuring only managed devices can authenticate to your organizational domain where possible.

Proposed amendments to FAR - Attention GSA'ers

DoD, GSA and NASA are proposing to amend the FAR with a new subpart and contract clause for anyone contracting with Uncle Sam or handling government data.  The changes would require contractors or organizations handling government data to take certain information security measures and these would be contractually required.

Written comments are due on or before October 23rd, and the FAR case is 2011-020.

"Basic safeguarding" of data includes such items as:

• Use of public computers
• Intrusion protection
• Transmitting of electronic information
• Physical and electronic barriers

According to the proposed rule, basic protection measures are "first-level information technology security measures used to deter unauthorized disclosure, loss, or compromise."

It is interesting to note that although these should already be included under FISMA it also pertains to the use of COTS products.  Anyone contracting with Uncle Sam should keep abreast of the changes and provide comments.

http://www.gpo.gov/fdsys/pkg/FR-2012-08-24/pdf/2012-20881.pdf

District Court Rules Online Video Streaming Subject to VPPA Restrictions

I believe the word "DUH" is needed here

District Court Rules Online Video Streaming Subject to VPPA Restrictions

Thought for the day

Optimists look at a glass of water filled 50% and say it is half full
Pessimists look at the same glass as half empty

A security person looks at the glass and says "how do I know this is water and not some deadly chemical"

Chris Cunningham (just now)

Cookie Guidance from the UK ICO

In 2002 the European Directive 2002/58/EC laid the ground work for the protection of privacy for electronic communications. This was amended in 2009 by directive 2009/136/EC commonly referred to as the “cookie rule”. This directive required governments in the EU to implement these changes in their own laws by May 25, 2011. The UK ICO allowed for a “lead in period” of one year, and that year is now up. On May 25th, The UK ICO published their recommendations on the directive and how the UK ICO views the issues and requirements in the directive, as well as some insight into how enforcement actions may take place within the UK. This is a valuable resource for organizations operating websites in the UK.



As should be anticipated, any cookies that are not strictly necessary or any cookies that handle sensitive data should get extra attention, since you can be assured the DPAs will be paying special attention to them. This is an area where explicit consent should be obtained.

A couple of items from the guidance should be noted by any organizations using cookies on their websites, especially cookies that track users actions across multiple sessions.


• Explicit consent is not a requirement in all cases


• Users on the site should be conspicuously advised of the use of cookies on the site, and their choices on allowing the cookies.


• Exceptions for a cookie being “strictly necessary” should be sued very narrowly


• Make the use of third party cookies very clear to the end-user

How a carrot and a stick relate to US privacy legislation

Yesterday, the Obama Administration released their latest efforts to effect real privacy standards and legislation in what they are calling the Consumer Privacy Bill of Rights. The paper, entitled Consumer Data Privacy in a Networked World outlines several measures that will drag the US, kicking and screaming, into the development of a real privacy standard that will rival the European and OECD standards and directives.
The plan is broken down into several areas. First, there is a Consumer Privacy Bill of Rights that is similar to the OECD Privacy Principles, albeit unnecessarily complicated and duplicative. Secondly, the Bill of Rights would be implemented in Codes of Conduct that industry would need to develop in concert with the government’s “assistance”. Thirdly, the FTC would be the enforcer of these codes of conduct similar to their current role. Lastly, the plan calls for a Federal breach notification standard and calls for enforceable federal legislation that would enable mutual recognition by other countries. To date, Congress has failed miserably in every attempt to enact Federal data privacy legislation, so I applaud the Administration for trying the carrot approach, since the stick has not been effective.

Consumer Privacy Bill of Rights

The Obama Administration is hoping that even if Congress does not implement Federal legislation, that this will be the starting point for industry discussion and a beginning of privacy standards that can be used by businesses and industries. The Bill of rights is similar to the OECD standards and includes:

•Individual Control
•Transparency
•Respect for Context
•Security
•Access and Accuracy
•Focused Collection
•Accountability

Codes of Conduct

The plan calls for companies and groups to develop these codes of conduct in cooperation with the FTC and the National Telecommunications and Information Administration (NTIA). The enforcement powers would most likely be given to the FTC under Section 5 off the FTC Act, similar to how the FTC now brings actions against organizations for unfair and deceptive trade practices. Any Federal legislation resulting from this should preempt any state laws to the extent they are inconsistent with the Federal law.

Time will tell if the plan will advance privacy legislation and improve consumer protection, but it is already an improvement of anything we have seen come down from Capitol Hill – which is nothing. If this indeed moves forward, the next step will be gaining recognition by the EU, but forgive me if I don’t hold my breath on this just yet.

More to come on this topic as it develops.

Working Party Opinion on Consent 15/2011

On July 13 the Article 29 Working Party issued Opinion 15/2011 on the definition of consent.

In their words:
“The Opinion provides a thorough analysis of the concept of consent as currently used in the Data Protection Directive and in the e-Privacy Directive. Drawing on the experience of the members of the Article 29 Working Party, the Opinion provides numerous examples of valid and invalid consent, focusing on its key elements such as the meaning of "indication", "freely given", "specific", "unambiguous", "explicit", "informed" etc. The Opinion further clarifies some aspects related to the notion of consent. For example, the timing as to when consent must be obtained, how the right to object differs from consent, etc.”

The opinion, all 38 pages of it, answer some of the questions that face many organizations when it comes to tactical privacy decisions involving consent. It has many real world examples, and gives great insight into the WP thinking for possible future changes. It is easy to fall into the trap of only looking at 95/46 and not taking the various member state implementations into account, and consent is no exception to this rule.

Following are some items to consider when making decisions based on consent.

- Currently, the Council’s definition of consent is
"any freely given specific and informed indication of his wishes by which the data subject signifies his agreement to personal data relating to him being processed"
- Consent should not be used as an exemption form other data protection principles, you still need to process for purpose, use limitation, openness, etc.
- Consent is a weak basis for justifying the processing of personal data, and loses even more value when stretched to include items not in the original scope of the processing or for other purposes is not sufficient to prove consent
- Subjects should be able to exercise a real choice when consenting, and negative consequences of non-consent is not a good idea (duh!)
- Consent must be specific, and for the exact purpose of the processing
- Controllers should review data subject’s choices periodically
- Consent should be verifiable, and you should maintain proof of the consent
- Consent in the case of sensitive personal data must be explicit
- Explicit consent in the on-line world may be a clickable button, but not the lack of clicking or un-checking a default. In other words inaction typically will not be viewed as valid consent
- Be careful when using consent in the employment context. The WP’s stance on employee consent remains as it was in WP48 and WP 114

"where consent is required from a worker, and there is a real or potential relevant prejudice that arises from not consenting, the consent is not valid in terms of satisfying either Article 7 or Article 8 as it is not freely given. If it is not possible for the worker to refuse it is not consent.… An area of difficulty is where the giving of consent is a condition of employment. The worker is in theory able to refuse consent but the consequence may be the loss of a job opportunity. In such circumstances consent is not freely given and is therefore not valid. The situation is even clearer cut where, as is often the case, all employers impose the same or a similar condition of employment.”