How do you plan to do this? I believe it's all about real time monitoring of incoming emails and end user education We've even hacked banks with this -ethically-

Will still get through regardless. Need to use hardware key mfa or Conditional Access policies..

@@trackker16 Conditional Access based on Device identity and location or fido keys :)

@@ryanfrank4834which specific conditional access policies do you recommend to combat this?

Right. There should be a phishing network card interface designed to simply 'be dumb' override by default to allow the 'script kiddy' into a honey pot. Give them all sorts of useless information using Bot Framework Composer. ;/

I have never seen BitB attacks outside of Steam - but im guessing its only going to grow :/

But if mails already mark in junk then what will be the use 😂

@@pravinsingh4184 Bypassing email filters is a separate thing- not as hard as you'd think if you are spearphishing/whaleing

I tried the phishlets but every time I use evilnginx “Google Safe browser” marks it as insecure domain even before doing anything. Do guys have any idea why this getting got caught?

​@@pravinsingh4184Ma boy got a point

well ultimately it's to make a point 🤪

Well, there's nothing on the targets machine, for this. I think maybe you could figure out something by checking the traffic, though, maybe?

@@nordgaren2358 the url generator has default values, like the random string at the end has a certain amount of characters and do not spell a word. So scanning for urls with that at the end might be a start

but they are saying even fido2 can be hacked if they steal the token

Haha follow up? Maybe if the front page of tech sites bring it up again, these videos are nothing but repackaged video versions of headlines from any computer security news site, super basic demonstrations that are obviously following an already written tutorial. Look elsewhere if you want real content

@@cryptoafc7655 do you mean the hardware token or the access token? Basically FIDO2 auth methods tie the auth factor to the online service and therefore you won’t be able to authenticate to the phishing site spun up by the evilginx reverse proxy.

@@cryptoafc7655 Pretty sure Fido2 is resistant to this.

@@_ppl I have a Yubi key 5, and without touching the button on it. I can't log on anywhere

Some people are connecting with a dynamic IP address which is changing from time to time, when your connection renews (and it can be forced as well, just restart your modem). So logging an IP address and only whitelisting that will lock you out from your account. Not to mention if you use VPNs for privacy reasons.

@@CZghostThey dynamic thing u said is fine I guess, cuz as long as you are connected (and even if you get disconnected for few minutes you will most likely get the same ip) you will have the same IP. Its more like a comprise for security rather than user experience which in something like banking web apps is good? IDK this whole thing was actually just a question.

How can you restrict remote logins to only company owned IP space? Force all remote users to use a Full-Tunnel VPN that sends all traffic through the office? What if the company network is down? Then no one can sign in.

@@iRyan230 You divide users in various subsets, for example, users that will always work on site have no reason to log in from foreign IPs. On the other end, there will always be a set of users who will need to use company resources on the go, and for those MFA and managed device policies are strictly enforced, alerting policies are more sensitive, raising alerts wherever any unfamiliar sign in activity is observed. As for the VPN, you can deploy enterprise grade VPN solutions with no downtime (in theory), you can get company specific IP spaces and those can be whitelisted in your IDP. This is by no means a perfect solution, but carefully designing these can mitigate a large portion of the threats, the rest can be easily handled by the incident response team. And regarding the example in this video, admin access is usually deferred to separate accounts that have even stricter access policies.

@@iRyan230conditional access policies will usually be based on location. If a user logins in from California at 8 am and then an hour later tries authenticating from Florida that sign in attempt will most likely be blocked.

He was asking more-so about the fact that if you do this, how do you handle your remote users (full-tunnel VPN?), or how do folks work when the network is down?@@Slickjitz

@@kylewolf5706 that’s why any good network engineer has built out redundancy so the network never truly goes down.

Good points, Token machine binding in preview too

Unfortunately even they would not be immune since the attack is targeting the active session cookie

@@OrionsArm They would be immune because they'd simply fail to work due to the different domain name. The same as the password not being memorised in the browser.

@@OrionsArm The key exchange would fail with the different domain name, meaning no session cookie would be generated. I was disappointed that wasn't covered in this video.

@@mountainslopes Not a different domain name he is reverse proxying and using the actual domain name

@@OrionsArm there is a different domain in the browser and yubikey check domain from the browser, you need to educate yourself

That was my line of thinking as well. What CA (conditional access) rule can we create to harden a tenant's configuration against this attack? Also great question about IP address usage, how would this behave when Microsoft detects this the session token from a different IP. Is this a default behavior or should we setup a CA rule to harden against it?

Word. When I tried it against office365 it worked, but in the azure portal it didn't. it'd keep me asking for mfa codd

This was not configured with conditional access from the looks of it.

Atypical travel CA rule could do the trick here. For example trigger another MFA prompt when attacker attempts to signin instead of blocking the account, this alone could help, but not necessarily prevent the attack as the attacker might be connecting from a similar geographical location.

@@azountsu conditional access could be it has to be an Entra registered device (registered on your network talking to your domain controller/Active Directory so they'd have to be in your network to register) and it has to be a compliant device (which could be whatever parameters you set). Could also block all IPs from countries you know you'd never have users in or are known threats like Ukraine, Russia, China, etc.

Hehe, that would be ironic. :D

Can you explain how FIDO2 keys protect from session hijacking? Isn't it just like 2FA?

I’m not sure, but fido2 would be the same. Ultimately what your doing is stealing the cookies. So as long as websites uses cookies or auth tokens, you can do this

@@greyshopleskin2315 If you have malware on the client’s machine or have some other way of stealing the session cookie from their browser, then yes, it’s the same. However, if we’re just talking about preventing phishing, then FIDO2 and certificate based auth will never authenticate you on a malicious site to begin with thus no session cookie to steal.

@@greyshopleskin2315FIDO2 will not authenticate through a different domain (the phishing domain used in this video for example), no authentication, no cookie

@@sapuseven in my opinion FIDO2 would not work as it is tied to the actual domain name cryptographically. So as the phishing site is not using the correct domain name, the FIDO2 token will not work to log in. However still, if the user is able to use some fallback mechanism instead of FIDO2 then it can still be successful.

.zip is already a TLD. The client computer’s DNS would route it normally like any other TLD.

@@iRyan230 Ah, for some reason I couldn't find it before, they don't seem to have any base page or anything. Very irresponsible top domain though.

Email going to spam shouldn’t matter at all since this is just demo purposes. These attacks very often come from senders the recipients already trust such as already comprised colleagues, or partner organizations, etc.

As a user that happens all the time. You get conditioned to having to paste the password in sometimes when the account creation address doesn't match.

Correct.

It uses letsencrypt to generate the certificate

Most likely Let’s Encrypt.

Huh? How would it retrieve the token then? The sign in is coming from a new device so surely it would require a new sign in.

I have phishlet google available for 3.2, capture user + password + cookie

Since it operates as a proxy, I would suspect it would show the location of the server running evilginx. HTTPS alone would stop it somehow passing the victim's IP to Microsoft. We had a recent BEC that had MFA, we couldn't determine how but suspected token theft in this method. Another thing we tend to do is customize the login screen to hopefully give the end user a slight pause when they get the default theme.

@@dyerseve3001 good call on changing the theme of the login page, thank you

@@dyerseve3001I’m all for changing the default theme but how would that offer protection here? The phishing site is still pulling from Microsoft in real time so the user would see the custom theme for your organization anyway.

They are dragging their feet with this attack which is seriously frustrating. This has got to be one of the largest security concerns organizations face today and they are practically silent in it(minus a blog post or two…)

It should, as long as other methods are not also enabled.

Only true way to stop is Fido 2 hardware token (stops token stealing)...User training, but that is it or Conditional Access grant control of a compliant device

@@jarredpow fido2 or smart card certificate authentication

@@jarredpow The video actually says that this bypasses 2fa.

@@exxon47_you cannot bypass a hardware key as it will not function unless it is at the correct site…

@@exxon47_ Not Fido 2 hardware tokens. They only work on the real domain

Pretty self explanatory, you just do the opposite of the attack lol

Would recommend sending an email from Azure Cloud Shell, so it's from Microsoft. Probably just coming from Gmail it didn't look "business -y" enough. (Or could swap the contents of the email so it's not as clearly spammy)

Yes also seen a Tenant branding one at the end of last week however surely that's not a surprise as the Reverse proxy will do whatever the tenant would have shown.

@@robinbarlow7619yup… I also worked with one that forwarded to another iDP too (Microsoft login page forwarding to Okta). This is such a mess and really frustrating that Microsoft is dragging their feet here. I know it’s complicated to resolve this at a large scale but it’s got to be one of the worst security threat’s organizations have faced in a long time.

Sometimes, but not all the time. Recent one I dealt with somehow did not get flagged as risky, but I would say a good majority of them do.

In that scenario, the attacker still gets the session cookie and the attack succeeds. You would need Windows Hello, Certificate Based Authentication, or FIDO2 to be phishing resistant.