The user said he had removed the Chrome extension twice. It still came back. At first, I thought Chrome Sync was probably restoring it, so we disabled sync and removed the extension again. After the next restart, it was back. That was when I stopped looking at Chrome itself and checked the Windows policies controlling the browser. Inside the Registry, I found this path: HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist There was one extension ID configured there. That changed the whole investigation. Chrome was not randomly reinstalling the extension. Windows policy was telling Chrome that the extension had to be installed. I checked the extension files under the user’s Chrome profile and found one called: Secure Search Helper The name sounded harmless. But its manifest showed permissions like: tabs webRequest and access to: <all_urls> Meaning it potentially had visibility into a lot of what the user was doing inside the browser. I checked Sysmon next. Event ID 13 showed that the Chrome policy registry value had been created the previous afternoon. A few seconds earlier, Sysmon had also recorded reg.exe being launched from PowerShell. So now we had a proper timeline. PowerShell runs. reg.exe modifies Chrome policy. Chrome sees the forced-extension policy. The extension installs automatically. The user removes it. Chrome checks the policy again and installs it back. That explained why normal removal was not working. We isolated the laptop, preserved the Registry entries, extension files and Sysmon logs, then removed the policy after collecting the evidence. We also revoked the user’s active sessions because with a browser extension like this, I would not be comfortable assuming only browsing history was exposed. The part I found interesting was that the user actually did the right thing. He saw an extension he did not recognise and removed it. The problem was sitting one level deeper. As long as that Registry policy remained there, Chrome was simply going to bring the extension back. So if you ever remove a suspicious Chrome extension and it keeps reinstalling itself, don't only check the browser. Check the policies controlling the browser too. Sometimes Chrome is not the one making the decision.

The user said some of his finance emails were “just disappearing.” At first, I thought maybe he was accidentally moving them or Outlook was syncing badly. His laptop looked clean, Defender was quiet, and there was nothing obvious running on the endpoint. So I stopped looking at the laptop and checked the mailbox itself. That was where I found a rule called: RSS Feed Cleanup The name did not look serious at all. But when I opened the rule properly, it was looking for emails with words like: invoice and payment Then it would mark those emails as read and move them straight into the RSS Subscriptions folder. So the messages were actually being delivered. The user just was not seeing them in his Inbox. I checked mailbox-level forwarding next, thinking maybe somebody was also forwarding mail outside the company. Nothing there. Then I checked the Microsoft 365 audit logs. The rule had been created around 9:16 PM the previous night and modified again less than a minute later. That was definitely not something the user remembered doing. Now we had a different type of incident. The attacker was not trying to destroy the mailbox. They were trying to quietly control what the user could see. And if you think about finance-related emails, that can become very serious very quickly. If somebody can hide legitimate invoices or payment conversations, they can create room for fake payment instructions later without the victim seeing the original thread properly. We disabled the rule, revoked the user’s active sessions, reset the credentials and started reviewing the sign-in history and OAuth permissions. We also checked whether any similar rules had been created in other mailboxes. What stood out to me here was that the laptop was not the problem. You can rebuild the laptop completely and still miss an incident like this if the persistence or manipulation is sitting in the cloud account. Sometimes when a user says, “My emails are disappearing,” it is worth checking more than Outlook. Check the mailbox rules too. That small rule can tell you a lot.

The employee changed his Microsoft 365 password twice. The attacker still logged back in. That was the moment we knew we were not dealing with a normal stolen-password incident. The first alert came from an impossible-travel sign-in. The employee had authenticated from Maryland, then the same account appeared from another country less than an hour later. We reset the password. Twenty minutes later, another suspicious session appeared. So we reset it again and forced MFA re-registration. The attacker came back. At that point, I stopped looking at the account and started looking at the employee’s laptop. Inside the Downloads folder was a file called: Invoice_Viewer.exe The employee remembered downloading it from a website that claimed he needed a special viewer to open an invoice. Windows logs showed the file running at 9:14 AM. Seconds later, it launched PowerShell in the background. Then we found something else. A scheduled task called MicrosoftEdgeUpdateCheck had been created on the machine. The name looked legitimate enough to ignore if you were moving quickly, but it was not one of Microsoft Edge’s normal update tasks. We also found an outbound HTTPS connection from the compromised host to an external IP address. The file hash was submitted for malware analysis. It came back as an information stealer. That explained why changing the password had not solved the problem. The malware had stolen browser data, including authentication cookies and active session information. The attacker was not repeatedly discovering the employee’s new password. They were reusing a session that had already been authenticated. We revoked every active Microsoft 365 session, isolated the laptop from the network, removed the persistence, reset the credentials again, and rebuilt the endpoint. The suspicious logins finally stopped. A compromised account does not always mean the attacker still knows your password. Sometimes you already changed the password. The attacker is still inside because they stole the session.

One of the users called and said something that sounded strange at first. “My mouse moved by itself last night.” She said she had left the laptop open on her desk, went to get something, and when she came back the cursor was moving around the screen. No one else was near the laptop. The next morning, we checked it. At first, nothing really stood out. There was no unknown user logged in and no obvious remote desktop session. Then I started checking the processes and found: TeamsUpdate.exe That name can easily pass because Microsoft Teams obviously has update components. But this particular file was running from: C:\Users\amara\AppData\Roaming\Microsoft\Teams\TeamsUpdate.exe I checked the digital signature. NotSigned That was the first major red flag. A file pretending to be part of Microsoft Teams should not be sitting there unsigned. I checked the network connections for the process and found it maintaining an HTTPS connection to an external IP address. Then I checked how the program was starting. There was a scheduled task called: Teams Update Check It was pointing directly to the same TeamsUpdate.exe. So even after a reboot, the program could come back. At this point, we isolated the laptop before doing anything else. When we spoke to the user properly, she remembered receiving a Teams meeting link a few days earlier. The page opened and told her that her version of Teams needed an update before she could join the meeting. She downloaded the update. The meeting never worked, so she closed everything and forgot about it. That “update” was the file we were now investigating. Further analysis showed that it was not a Teams updater at all. It had remote-access functionality and was maintaining communication with an external system. That finally explained the mouse movement. Someone did not need to RDP into the laptop. The remote-access software was already running inside her normal Windows session. The part that stood out to me was the naming. TeamsUpdate.exe Teams Update Check Microsoft\Teams If you are rushing through an investigation, all of that can look normal. But the unsigned executable and the location gave it away. This is why I always say that seeing a familiar process name is not enough. Check where it is running from. Check who signed it. Check what it is talking to. Sometimes the difference between legitimate software and malware is sitting inside the full path.