Top Tweets for #WiNDoWS

The user kept getting MFA prompts he did not request. He denied all of them. Normally, you would assume somebody had his password and was just trying their luck. But this one felt different. We checked the sign-in logs and saw several attempts against his Microsoft 365 account. His password was changed, sessions were revoked, and we moved on. Then the MFA prompts started again. That was when we decided to look at the laptop properly. While checking the running processes, I found: WebViewHost.exe The name looked believable because Windows and Microsoft applications use WebView components all the time. But this one was running from: C:\Users\michael\AppData\Local\Microsoft\WebView\WebViewHost.exe I checked the signature. Unsigned. That already looked bad. Then I checked persistence and found a scheduled task called: Microsoft WebView Update It was launching the same executable. So now we had an unsigned Microsoft-looking binary that was starting automatically. I went through the Sysmon logs next. Around the same time the program appeared on the laptop, it created temporary files called: login_db.tmp and cookies_db.tmp That immediately made me think about browser data. I checked the process network activity and found it maintaining an HTTPS connection to an external IP address. At that point, we isolated the laptop. We could not say from two filenames alone that every password or cookie had definitely been stolen, so we preserved the files and the executable for proper analysis. But the combination was enough to treat it seriously. Unsigned executable. Fake Microsoft name. Persistence. Browser-related temporary files. Outbound connection. When we spoke to the user, he remembered installing what he thought was a PDF tool the previous evening. He needed to sign a document quickly, searched online, downloaded one of the first tools he found and installed it. The PDF tool worked. That was why he never suspected anything. Later analysis confirmed that another component installed alongside it was collecting browser information. That explained why simply changing the password was not enough for us. If an attacker has stolen active browser session data, the investigation has to go beyond just resetting credentials. You need to revoke the sessions as well and deal with the endpoint that leaked them in the first place. The interesting part was how normal the malware tried to look. WebViewHost.exe Microsoft WebView Update Even the folder path had Microsoft inside it. If you only look at names, it can fool you. Always check the path, signature, persistence and behaviour. That is usually where the real story is.