Recently, I browsed to a website, which appeared to consume all the computer's resources. Although the mouse cursor continued to move, the browser (and other applications) slowed down fast and soon stopped responding to commands. The screen did some odd things - coloured boxes of pixels where I would normally see text, etc. After a short time, the machine rebooted itself.

I was able to repeat the same behaviour with more than one browser, and more than one window manager (it is running under linux). Note that I visited the url but did not explicitly download any files, etc.

I checked the logs after a reboot, and it shows that the X server suffered a segmentation fault.

If that had happened in everyday application use, I would just assume that the application had a bug. However, because a website was clearly the catalyst, I wondered whether malware may be involved.

It seems plausible to me that malware has nothing to do with it. A quick web search indicates that a segmentation fault on X is a problem that has occurred before, and is broadly consistent with the other things I saw. (How a website could cause that, I don't know, but it does look like the simplest explanation.)

But I realise that if malware is the cause, I wouldn't know the difference. Is there any sensible way to corroborate that this was not caused by malware?

I realise that in theory that could never be ruled out entirely.

  • 1
    Run memdump and PE explorer before accessing that site, it should give you the clue about what are the processes forked after accessing that site.
    – ifexploit
    Mar 28, 2016 at 11:29
  • What would you expect to see before/after?
    – SauceCode
    Mar 28, 2016 at 14:13
  • Just run the browser without loading that webpage and follow the above mentioned step. Do repeat the process when you are loading the webpage.
    – ifexploit
    Mar 29, 2016 at 8:29
  • try submitting the website URL to urlquery.net and see if anything stands out
    – julian
    Dec 8, 2017 at 1:26
  • Did you submit it in Virus-Total ? Apart from getting results from other AV vendors it does URL sand-boxing as well . If it is actually suspicious and leading to crash it should detect that. Jul 19, 2019 at 4:47

3 Answers 3


Indicators of compromise may be in the memory, files, network traffic.

Try looking for the logs, maybe you can activate some of them (secure, auth). Try monitoring the traffic using a sniffer in the same machine or in the network gateway, looking for differences before/after reaching for this site.


Getting a feel for "is it malware" depends a bit on how deep you want to go. Here are a few things you can try:

1. What do you know about the website itself?

  • (EASY) Is it a personal site (e.g. TimeCube), or a trusted mainstream site (e.g. Google)? You might be able to ask the owner/admin of a smaller site, and unless a mainstream site has been temporarily compromised, issues encountered just from navigating there are unlikely to be malware.

  • (EASY) Does a search regarding that specific site return similar experiences from other users?

  • (HARD) Are there any clues in the source code of the page?

2. What does your local environment tell you?

  • (EASY) Is there anything around the time of the crash in any system logs? (sounds like yes - this can be a good indicator of what's going on)

  • (EASY) Is it repeatable, and are different browsers affected? (sounds like yes - this can indicate if it's a browser or website problem)

Answering some of the above questions can help characterize the issue - it might be a fixable bug.

3. What's going on between you and the website?

  • (EASY) If you restrict javascript execution or increase security settings in the browser, does the problem persist?

  • (HARD) Has anything changed on the file system (before vs after the crash)?

  • (HARD) You might be able to do grab a packet capture while you're connected to the website, and see if any strange data is flowing in either direction.

Most malware is either trying to gain control, now or in the future, or extract useful data. The steps above can help to indicate that (A) no sensitive data has been passed to the website, and (B) that no significant file system changes have occurred that would lead to an issue in the future. At that point, the only 'control' that the website would have is in initiating a crash, which probably doesn't provide the website owner any benefit as malware.


This is why there has to be consistent log histories of the machine. The crashes could be due to some other reason but you can only safely assume the cause after several instances of crashes. Also you might like to try a non Occam's razor like answer where if an encrypted tunnel VPN out from the local network rules out the case that it is only particular to that tuple of the website, the local network, and your browser.

  • 1
    I don't understand what you are recommending the OP should try. Mar 28, 2016 at 3:26
  • I don't understand either.
    – SauceCode
    Mar 28, 2016 at 14:07

You must log in to answer this question.

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