They did mention that, aka cookie stealer. Keep learning young padawan.

It used to be that way with 365 tenants but it's on by default now.

even using Excel would be better lol

I hate how several KQL templates don’t work right off the bat.

John is just doing things how he's comfortable, I guess as long as you get the end result. That's all that matters.

This is the best way, how would you do that?

sometimes you have to deal with raw logs. sentinel and log analytics ease up the hunt but no harm in learning to dig through raw logs

Definitely a consideration because the default for Azure is 30 days which is inadequate. The maximum was raised to 180 days but just to CYA the correct answer is "as long as feasible" which means rolling into permanent storage.

The DC in this example is in the Azure environment. It logged the pw spray including failures and the successfully compromised user - Afterwards, 10:45 you were shown that compromised user manipulating machines because they already had that users access into the environment. The machine in this case "WS-3" was likely a VDI from Azure, thus already in the environment. If it was physical and in a separate location with Azure AD, it could still be compromised, though we would probably be looking at attempts to use Onedrive or some other vector to have access to the machine. The exercise does not explicitly describe the physical vs virtual desktop scenario and you are only meant (IMO) to be looking at what was done with the Azure account (which would have been possible in either scenario once the actor had access to interactive login).

Azure VDI interesting take/great insight thank you

@@KrysticsCorner But WS3 wasn't the original foothold. WS1 was. How did the threat actor get WS3 to reach out to WS1's SMB share with no control over it, download and execute the payload? Workstations aren't going to just arbitrarily reach out to any host serving SMB shares and download things. This exercise seems to take a lot of liberties and doesn't demonstrate a real world scenario. There's a lot of assumptions and cut corners here.

@@iConk3r I've seen this happen real world. It isn't that a machine normally does this, simply that it is possible. In my scenario the Dom creds were not MFA protected, however, and the machines were physical. I wish I understood more about the micro level of Microsoft auth in the background here, but I don't have enough info to help further right now. Apologies.

@@wildstorm74users not being educated is basically a given and not a good excuse for a security team. There were many steps along the way where these attack steps could have been mitigated, detected, and even outright prevented. Security admins who blame end users are lazy and limit their own potential to actually implement cool and fun shit

@@wildstorm74 yeah but the initial access itself needed 2FA and it doesn't say how he bypassed the initial 2FA.

@@wildstorm74 Prolly the user accepted MFA by accident - or was tricked through social engineering to accept it. ... Cookies would mean no password or MFA would be needed, it'd become an anomalous token As the ID was bruteforced/sprayed... Cookie/token hijack isn't the case, as they're raising unnecessary alarm bells

@@HexNebula MFA was via TXT which means that the token would have logically had to have been stolen via spearphishing. Plus, number matching is enforced in Azure so unless MFA is phone call, the user cant just click "yes" and log in. Token theft or sim swap are likely, but sim swap is very very rare.

@@Soup69GodMost likely a targeted phish after the successful password entry. John misspoke when he says the successes for Paul Bowman were later in the same minute, it was 49 minutes after. The attacker would have had time to perform an AitM attack targeted at Paul Bowman, possibly leveraging his known password as a way to gain trust. Although, an AitM attack doesn't require knowledge of the password, so it could be something else entirely.

I think in this case the amount of failed logins within a certain timeframe would cause an alert. Not sure if its the same for like "all users" vs per user though.

That's true,

If its easier for YOU, then thats great. Use whatever tools you can. the point is CSV means comma seperated so whatever can deal with that is fine. For me I use Sentintel which has all of the count and sort functions he used here built into the tool.

They did not have to bypass it directly. They used cookies that still had valid access from an authenticated session.

@@KrysticsCorner I was talking about the first one. I get how though malware you can steal cookies. But the first account should have been protected by 2FA right? How did they bypass that?

@@casfrenthere are a few ways, but Evilproxy phishing is one common effective method. Google evilproxy, non FIDO2 mfa methods are vulnerable to this attack.

​@@casfren I don't think that was covered in the video, but the training is out there for you to look at on your own.

Congrats