I’m assuming tedivm is the handle of one of the admins, nice touch with the “x-shameless-plug” headers though! X-shameless-plug: Looking for a dev job? Send your resume to 2230
NAMECHANGER TRACKER PLGUIN UPDATE
Side-note, whoever is managing the update servers for Malwarebytes added some extra X forwarded headers to the responses: GET /v1/database/rules/data/rules.v2013.06.27.08_v2013.06.27.07.ref.inc HTTP/1.1īut this did give me a binary blob which seemed to be the definitions file. Now in my case it looked like it was doing an incremental update for the day, it did the following requests:
So with this new information it starts to request this definition file’s information file, this is a yaml structured file describing its size, a hash to check on after downloading and some extra metadata.
NAMECHANGER TRACKER PLGUIN UPGRADE
Which in my case returned “v2013.06.27.09” which was a database I did not have yet ( for the purpose of being able to show the upgrade process I made sure mine was outdated ). GET /v1/database/rules/version.chk HTTP/1.1 It starts off by requesting the latest definition file: But at the end it does the part I’m interested in, it updates the definition files. All the requests go to “ ” for the updates. The first thing it does is check if the program is the latest version, this is followed by some news messages being checked for ( I think, not completely sure ). Turning on Wireshark gives a rundown of what Malwarebytes does when updating (I made this capture while writing this blogpost). The update that fixed the issue was “v2013.04.15.13” according to a Malwarebytes employee on the forums called “Maurice Naggar”. From a post by a user called “catscomputer” in this thread I found that it seemed to be an update to “v2013.04.15.12” that broke the operating systems. The one from when the bad signatures were added and the fixed definition files published. So what went wrong ? To figure that out we have to find out how the updating system works to try and get the appropriate definition files we need. Within 8 minutes, the update was pulled from our servers. As posted by Marcin Kleczynski on the Malwarebytes blog it was fixed within minutes: The developers were quick to put out updates to resolve the issue and even supplied a tool to fix the issues. Īs seen in the topic it started to identify running processes, registry entries and files stored on the hard disk. Ĭ:\Program Files (x86)\Malwarebytes’ Anti-Malware\mbamservice.exe () -> No action taken. Ĭ:\Program Files (x86)\Malwarebytes’ Anti-Malware\mbamscheduler.exe () -> No action taken. It even started to detect itself as malware ( a good clue something has gone horribly wrong )Ĭ:\Program Files (x86)\Malwarebytes’ Anti-Malware\mbam.exe () -> No action taken. Ĭ:\Windows\System32\WsmSvc.dll () -> No action taken. Ĭ:\Windows\System32\WebClnt.dll () -> No action taken. Ĭ:\Windows\System32\wcncsvc.dll () -> No action taken. Ĭ:\Windows\System32\upnphost.dll () -> No action taken.
Suddenly it seemed to identify parts of the operating system as well as itself as malwareĬ:\Windows\System32\SessEnv.dll () -> No action taken. A while back on April the 15th posts began to appear on the Malwarebytes forums regarding issues with the detection of malware.
0 kommentar(er)
