I received a CrowdStrike Alert where a particular user was using Chrome and the process was connected to the web browser but the user does not know what he did to connect to the malicious IP address that triggered the alert. How to determine what process accessed the web browser? Is there any way?

I tried a solution by collecting the history data from the laptop.

Please advise of any way to determine what would have accessed the web browser.

  • 2
    You can't. Domain resolution sometimes return a pool of addresses (for load balancing), and malicious domains usually point to different addresses every minute (fast-flux DNS).
    – ThoriumBR
    Sep 19, 2022 at 2:09
  • Short answer is that you can't. Not after the fact. You would have to be running a process analyser when the call happened to catch it. The likely scenario? A browser plug-in. But that's a pure guess based on likelihoods from other contexts.
    – schroeder
    Oct 4, 2022 at 15:23

1 Answer 1


First of all, what do you mean "using Chrome and the process was connected to the web browser"? Do you mean a non-browser process used some form of inter-process communication / debug APIs to control a Chrome process from outside of its address space? If so, how do you know, vs. the request to the malicious IP came from within Chrome? If not, do you mean that your user didn't directly tell Chrome to access the malicious IP or visit any web pages which automatically access that IP, but it did so anyhow? How do you know that? Most people have no idea what IP address (or domains) are being accessed by any given site they visit. For that matter, whether or not that's what you mean, how sure are you that the user didn't do something that directly caused Chrome to access the malicious IP? People lie to IT sometimes, after being caught doing something they shouldn't (not necessarily something malicious; it could just be e.g. watching porn on a work computer).

Unfortunately, regardless of the answer to the above questions, the answer is almost certainly "you can't". If the machine has process audit logging turned on, and the malicious process (assuming one exists at all) either doesn't know to modify the audit log or lacks permission to do so, you can tell what processes were running on the machine at that time by looking at the logs, but that won't tell you what they were doing.

For that, you'd need either to have been tracing the execution of the process in question, or have an audit log on the browser that positively identifies what is accessing it. The former (process tracing) is approximately never done except when debugging / reverse engineering, because it's extremely detrimental to performance and generates an enormous amount of log data (also, you'd again need to be sure there's no malicious process editing or deleting the logs after the fact). The latter (browser-based audit logging) isn't even a feature I'm aware of Chrome having (though it might, I'm no expert on its feature list), and besides, that still only works if the logging was enabled and the malicious "process"

  • was communicating with / controlling Chrome through a identifiable and un-spoofable mechanism (so, not something like debugger APIs), otherwise the Chrome log might say that it accessed the malicious IP but it couldn't tell you why
  • was in fact either a malicious process or a traceable Chrome feature like a browser extension, rather than something like a malicious DLL (or other loadable library) where the malicious code can pretend to be anything it wants - including normal user interaction - and the logging will report the spoofed source
  • was, again, not aware of or not privileged enough to tamper with the log.

Unfortunately, there's no way to retroactively log such information. It's like being in a room where two conspirators met yesterday, and wishing you could have a recording of what they said; if no recording was created at the time, there's nothing you can do now to bring one into existence. You might bug the room (turn on audit logging) in hopes of catching future meetings (malicious activity), but you can't reconstruct what happened before. The data is simply gone.

There are some places you can look, in case you get lucky (the equivalent of checking whether the conspirators took notes and then threw them in the trash, or maybe paid at the parking meter). For example, if you're on Windows, auditing of process creation is not enabled by default but some processes perform activity that is logged by default, so you could search the event logs around the time in question for anything logged due to a process that you don't recognize and go see if it's legit. I know less about what is and isn't logged by default on Linux and almost nothing for MacOS, but there's a decent chance the situation there is similar. You can also just go look at Chrome itself; are there any sites in its history for the relevant period that look sketchy? Does it have any suspicious browser extensions installed? Most users (and most malware) aren't any good at covering their tracks, even when they do have the requisite permissions.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .