At this example, what I've did was a simple password spray against On-Premises Exchange server that was successful. One way to investigate this further is to pivot off the Logon ID in 4648 to see there are more failed logons coming from the same source IP.

Another way would be to look at Event ID 4625 with Logon Type 8 and w3wp.exe as the caller process, but not sure how noisy it is in a typical Exchange environment.

However, keep in mind that this example was only a password spray against OWA... The artifact would be different if this was done against EWS for instance.

@DebugPrivilege Check in the MFT to see if any new shells were used. Pull the iis logs as well to review

@DebugPrivilege blue team is so much harder

@DebugPrivilege Wondered why we were still running Exchange

@DebugPrivilege Grab the reading glasses

@DebugPrivilege Deflect and say it's Microsoft's fault not telling you?

@DebugPrivilege It could be HAFNIUM or Galnium

@DebugPrivilege Possible ProxyNotShell MFA bypass. Could also be general postex/webshell authentication. I would check IIS logs/file system for webshell activity and do a quick 4688/4624 check for Rand0m across the enterprise. But the IIS logs are critical if they're there :)

@DebugPrivilege Check for proxylogon,proxyshell vulns.. Those are being actively exploited in the wild. Recently I came across it during an engagement.

@DebugPrivilege Looks like part of proxylogon attack, I've not looked at it fully however, domain account used initially, then local account used. Check for a new local account on the exchange server might be next steps .. that or YOLO it and do a full domain restore 😁

@DebugPrivilege Check to see if the server is vulnerable then start looking what this account did after it logged on. Any signs of post-exploitation? 👻

@DebugPrivilege Depends on if Rand0mAccount is known or not. w3wp.exe indicates that a login was done related to IIS/OWA. Check source IP reputation, check wwwroot folder for any backdoors placed. The last screen indicates impersonation. Probs isolate (depending on impact) and pull more logs.

@DebugPrivilege LogonType8 .. basic auth set on OWA/EWS and some local acct used for proxy access?

@DebugPrivilege This reminds me of why I'm not a DFIR professional.😄 Still, the quite different logins involving rand0maccount at the same time would raise my suspicion exploitation had occurred. Over the network, and then via explicit credentials as system from localhost? 🤔🤔

@DebugPrivilege Someone escalated an account to be able to impersonate all other exch accounts to maintain persistence?

@DebugPrivilege I will check the path of process, make sure nothing suspicious happens like Backdoor, check the hash of process and check the ip reputation. Go live response if the server has EDR agent to go deep on it. Then, if we se suspicious activity, isolated the server.

@DebugPrivilege Cry

@DebugPrivilege